[dns-operations] .com delegation responses when glue addresses don't fit
mnordhoff at gmail.com
Fri Aug 21 01:09:06 UTC 2020
On Wed, Aug 19, 2020 at 5:49 PM Mukund Sivaraman <muks at mukund.org> wrote:
> We notice the following response from .com's namesevers:
> [muks at mx ~]$ dig +nord +dnssec +bufsize=512 @2001:502:1ca1::30 infoblox.com
> ; <<>> DiG 188.8.131.5200608151533.e8a2352e96 <<>> +nord +dnssec +bufsize=512 @2001:502:1ca1::30 infoblox.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15448
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 1
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;infoblox.com. IN A
> ;; AUTHORITY SECTION:
> infoblox.com. 172800 IN NS ns1.infoblox.com.
> infoblox.com. 172800 IN NS ns2.infoblox.com.
> infoblox.com. 172800 IN NS ns3.infoblox.com.
> infoblox.com. 172800 IN NS ns4.infoblox.com.
> infoblox.com. 172800 IN NS ns5.infoblox.com.
> infoblox.com. 172800 IN NS ns6.infoblox.com.
> infoblox.com. 86400 IN DS 33613 5 2 339462CBAEB1773800EA8B688D2CA048FCAB0EB2933A97AEE2B86A9A 212F37C5
> infoblox.com. 86400 IN DS 33613 5 1 629C2D6C060E2133CD0F4470F3ECC8834DA4FAD6
> infoblox.com. 86400 IN DS 49879 5 2 605656DB7C9DFE4D8A453C350B3DA63039A78878DA089AD4247AB9A0 D3B43998
> infoblox.com. 86400 IN DS 49879 5 1 C1DB78AD9A8928CB15A7E0CE9E4468D433F5C638
> infoblox.com. 86400 IN RRSIG DS 8 2 86400 20200823050241 20200816035241 24966 com. 0s/TnWuxLdVzCQqY0tVauNXeCpirT5rYacvEpxaQfTxCjP2XfZkqHy4A SNoGyYWGZQdxTa7zXVgrKuWOoKZ2CKxC/kd++VnEJKoFw3llOoq56Wz+ lq65BS7E6/ZlE4Qgce8rhbBQVkE6Sk1YXkuxDbwoPYfvkHlfWaboeiNO 6y731Xcrq3vjqdG6YZCHyH64SSnVFypUiRN26H2HPsYsSg==
> ;; Query time: 19 msec
> ;; SERVER: 2001:502:1ca1::30#53(2001:502:1ca1::30)
> ;; WHEN: Wed Aug 19 17:30:29 GMT 2020
> ;; MSG SIZE rcvd: 512
> [muks at mx ~]$
> Glue address records are required in this delegation response, but none
> are returned. TC=1 is not set. This causes problems with some resolvers.
> Can someone at Verisign please check correctness of this response, and
> set TC=1 for such responses?
> It appears to be the problem statement of:
There was a previous thread about this issue:
(The domain mentioned in that post is no longer problematic with
typical EDNS buffer sizes; you have to try 700 bytes or so.)
Verisign didn't respond at the time, unfortunately. IIRC, someone from
Verisign might have commented on
draft-andrews-dnsop-glue-is-not-optional on the dnsop list. I'd have
If someone has a contact with them, that might be better.
TLDs operated by other organizations were also affected to a lesser
extent -- I don't know of any affected domains in the wild, but it was
possible to reproduce the behavior on some of their servers. (I assume
they deploy multiple nameserver implementations.)
Of course, the whole point of DNS resilience is that every server
should work well, so it would still be good if everyone updated their
nameservers, and the draft was standardized.
More information about the dns-operations