Options
DNS now and in the future
wastedtime
Member Posts: 586 ■■■■□□□□□□
in Off-Topic
From RFC 1035, DNS responses larger then 512 need to be re-queried via TCP. The server is suppose to set the TC bit on the response of a UDP DNS datagram so that the client knows to request via TCP. Now I figured I would try this out using a bit of Wireshark and nslookup. Now to increase my chances of getting a large response I did the set type=any. I had a pretty hard time finding servers to give me large responses. At first I found a few that gave me some that were larger then 512 but they didn't set the TC bit and Windows didn't try to take it to TCP after it. Well I went though and tried a few more. Then it came a DNS response that was almost 3kB long. That was more then 4 times the longest ones I had been seeing (low 600s). I saw some odd responses in it but at the time I wasn't worried about it. I saw my UDP response with the TC bit set then a new TCP query and response.
After that I had a small discussion with someone over DNS and the queries responses that get sent. The discussion ended with the person saying that it is rare that you will need to use TCP for a DNS query. At that moment I agreed with him.
Later on after I got back from work and got a few things done I wondered about some of those answers I got from the DNS server. So I did the query at home and took a closer look at it. Some record types that I wasn't use to seeing RRSIG, DNSKEY, DS, Type 51 (looking at Wireshark capture). I kind of figured that it was DNSSEC and got to remembering that they finished implementing DNSSEC on the root servers this year. Right there I figured wow TCP is going to be the primary transport for DNS request from now on. So I started looking up DNSSEC and this mysterious Type 51 I got. Well the Type 51 seems to be NSEC3PARAM which was just part of the the NSEC3 extension of DNSSEC. But while I looked up how common it was for TCP DNS request with DNSSEC running I found this: https://www.dnssec-deployment.org/index.php/deployment-resources/olafur-gudmundssons-dnssec-blog/can-your-links-handle-dnssec-sized-answers/
It seems to talk quite a bit about EDNS0 (RFC 2761) which extends the possible length of UDP request well over the 512 byte barrier and fragmenting UDP datagrams. Now the TCP version has a easy way of addressing length by adding a 16 bit length field in the DNS request.
Does EDNS0 address the problem of the additional overhead of the numerous TCP request that will happen with DNSSEC without adding to much complexity and potential issues of discarded fragments? Most SOHO routers are not EDNS0 capable. There are issues with Firewalls and IDSs in handling of EDNS0 responses. So is there a better way that I haven't seen yet while looking this stuff up? It just seems like they threw the KISS method of the protocol out the window.
EDIT:
Sorry for the length.
After that I had a small discussion with someone over DNS and the queries responses that get sent. The discussion ended with the person saying that it is rare that you will need to use TCP for a DNS query. At that moment I agreed with him.
Later on after I got back from work and got a few things done I wondered about some of those answers I got from the DNS server. So I did the query at home and took a closer look at it. Some record types that I wasn't use to seeing RRSIG, DNSKEY, DS, Type 51 (looking at Wireshark capture). I kind of figured that it was DNSSEC and got to remembering that they finished implementing DNSSEC on the root servers this year. Right there I figured wow TCP is going to be the primary transport for DNS request from now on. So I started looking up DNSSEC and this mysterious Type 51 I got. Well the Type 51 seems to be NSEC3PARAM which was just part of the the NSEC3 extension of DNSSEC. But while I looked up how common it was for TCP DNS request with DNSSEC running I found this: https://www.dnssec-deployment.org/index.php/deployment-resources/olafur-gudmundssons-dnssec-blog/can-your-links-handle-dnssec-sized-answers/
It seems to talk quite a bit about EDNS0 (RFC 2761) which extends the possible length of UDP request well over the 512 byte barrier and fragmenting UDP datagrams. Now the TCP version has a easy way of addressing length by adding a 16 bit length field in the DNS request.
Does EDNS0 address the problem of the additional overhead of the numerous TCP request that will happen with DNSSEC without adding to much complexity and potential issues of discarded fragments? Most SOHO routers are not EDNS0 capable. There are issues with Firewalls and IDSs in handling of EDNS0 responses. So is there a better way that I haven't seen yet while looking this stuff up? It just seems like they threw the KISS method of the protocol out the window.
EDIT:
Sorry for the length.
Comments
-
OptionsKnobee
Registered Users Posts: 1 ■□□□□□□□□□
wastedtime wrote: »Most SOHO routers are not EDNS0 capable. There are issues with Firewalls and IDSs in handling of EDNS0 responses. So is there a better way that I haven't seen yet while looking this stuff up? It just seems like they through the KISS method of the protocol out the window.
EDNS0 was described first on Aug 20, 1999. If a SOHO router or Firewall/IDS device is not capable of dealing with it in 2010, I'd recommend that the problem be bounced back on the vendor of the hardware, not on the use of a "futureproofing" mechanism described over 10 years ago.
Yes, DNSSEC causes larger packets. Yes, if you are locked down to 512 byte packets you are going to fall back to TCP. Yes, if you haven't implemented EDNS0 you are going to hit this problem.
Alan Clegg
Internet Systems Consortium
Training and Support -
Options
Mojo_666
Member Posts: 438
I have seen a few issues with yahoo mail queries being over 512 and responses being blocked by routers. This is not really my area though but just thought I would throw that info your way. -
Optionswastedtime
Member Posts: 586 ■■■■□□□□□□
Welcome Knobee, glad to have someone from the ISC here. I appreciate the replies.
That pretty much confirms what I expected. I assume that EDNS0 was implemented to cut down on TCP traffic. Now that we are 10 years in the future has anyone considered just running DNSSEC traffic over TCP and avoiding UDP all together as more then likely it will be greater then 512. Also it will help in identifying smaller MTU areas that would drop a UDP datagram. That is more or less what I was talking about when I mentioned the KISS method. Would that kill modern high traffic DNS servers? Is EDNS0 going to be what everything has migrating to when DNSSEC becomes common place?