Confusing AXFR errors

[kalfeher]

Description

When attempting an xfr from zonedata.iis.se, for se. using a non-tsig signed transfer I see the following error consistently:
dns: overflowing header size

When attempting an xfr from zonedata.iis.se, for nu. using a non-tsig signed transfer I see the following two errors occasionally:
dns: overflow unpacking uint16
dns: buffer size too small
However the transfer attempt for nu. will also work as expected about half of the time.

I'm using just the high level APIs for a simple transfer. AXFR via dig @zonedata.iis.se axfr se works as expected.

Steps to reproduce

func main() {
	name := "se."
	primary := "zonedata.iis.se:53"
	t := new(dns.Transfer)
	m := new(dns.Msg)
	m.SetAxfr(name)
	c, err := t.In(m, primary)
	if err != nil {
		fmt.Println(err)
		return
	}
	for r := range c {
		if r.Error != nil {
			fmt.Println(r.Error)
			return
		}
		for _, a := range r.RR {
			fmt.Println(a.String() + "\n")
		}
	}
}

Expected Behaviour

All records received for zone file (~8106000 RRs), finishing with the SOA RR.

Actual Behaviour

For SE zone I receive the error dns: overflowing header size at some point during the transfer. Number of records received before the error is not consistent.

For NU zone I receive the one of the following errors at some point during the transfer dns: overflow unpacking uint16 or dns: buffer size too small. As with the SE zone, the number of records received before the error is not consistent. Approx half of my transfer attempts succeed for the NU zone.

[miekg]

thanks for the repro. I just ran that on my laptop , without seeing any error.

Was some record removed from zone?

[kalfeher]

Unclear if changes have been made to the zone or platform. I reported the issue to IIS who shared internally, but I've not heard back.
The symptoms remain for me. My pcaps indicate that the records restart at some point (sometimes after only a few hundred RRs other times after a few thousand), which results a TCP segment that is never received. Then it's just DUP and retransmissions and eventually the connection fails. By restart, I mean the SOA is re-sent and RRs begin again from the top of the zone.
I suspect this is related to some special behaviour of the zonedata.iis.se host, particularly over high latency connections. I'm fetching from Australia.
I see the same symptoms in pcaps using dig, but the connection remains resilient and eventually the axfr completes.

As far as this DNS library is concerned, I'm trying to understand the errors in order to be more resilient to the behaviour of the host.

[miekg]

[ Quoting ***@***.***> in "Re: [miekg/dns] Confusing AXFR erro..." ]

Unclear if changes have been made to the zone or platform. I reported the issue to IIS who shared internally, but I've not heard back. The symptoms remain for me. My pcaps indicate that the records restart at some point (sometimes after only a few hundred RRs other times after a few thousand), which results a TCP segment that is never received. Then it's just DUP and retransmissions and eventually the connection fails. By restart, I mean the SOA is re-sent and RRs begin again from the top of the zone. I suspect this is related to some special behaviour of the zonedata.iis.se host, particularly over high latency connections. I'm fetching from Australia. I see the same symptoms in pcaps using dig, but the connection remains resilient and eventually the axfr completes. As far as this DNS library is concerned, I'm trying to understand the errors in order to be more resilient to the behaviour of the host.

Happy to include fixes need here. But resend tcp segments, or not something this lib should see (i think).... so that would hint at deeper golang problems? (minimal tcpdump would help here I guess?) Cheers!

[kalfeher]

se_cap_golang-filtered-01.pcap.gz

I've attached a pcap starting a few records before the first malformed RR is seen. The library returns dns: overflowing header size at the end.