Claudio Jeker writes: > Until recently only AXFR was using tcp, If you look at the original DNS specs, i.e. RFC 1035, RFC 1123, etc, you will find that the protocol always specified that any DNS queries can be performed over TCP. In particular, this is the normal fallback method when a query over UDP results in a truncated (TC) response.
Actually, in the olden days there were even resolver implementations that *only* supported TCP for DNS queries, cf. http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg01855.html (I'm not saying this was a good idea :-) Then people stopped listening to Jon Postel's (may he rest in peace) advice to "be liberal in what you expect, conservative in what you send". Instead, concerns of "security" and short-term optimization and punishing people with "stupid" (= unexpected) configurations became more important. So IT people and their consultants and ISPs started to block DNS over TCP in many places, often leaving it open only for zone transfers, and felt good about it. Thus the new (you call it old, maybe I'm just an old fart) "rule" was born: > normaly resolver queries had to be udp. Some people tried to evolve the DNS to carry other information, such as IPv6 addresses, digital signatures (actually meta-information to make DNS information more trustable), mail policy information. And some zones (such as the root) wanted to have many nameservers for robustness. So suddenly, the 512 byte (yes, 512 bytes!) limit became a real issue, as fallback to TCP would very often just Not Work. > This rule was a bit relaxed because of the increased space needed > for IPv6 but many authorative dns servers will only listen to UDP > port 53 requests.. I would say, the "new rule" ("if you use TCP for DNS queries other than AXFRs, then you are stupid/up to no good, so I will block you") proved to harm the long-term evolution of the DNS protocol - as is quite often the case with these kinds of "security best practices" that violate transparency and other design principles. But since such rules are/were "best practices", you can never really get rid of them. So what happened instead is that the DNS protocol was extended to support larger-than-512-byte queries over UDP (EDNS0, RFC 2671). While "dig" doesn't use EDNS0 by default (but see the example below), modern recursive nameservers should normally make use of this, so that fallback to TCP isn't necessary that often. The fact that EDNS0 was added to the DNS is probably a good thing. But I think it would also be good if DNS over TCP generally worked. Although TCP does have higher overhead than UDP for typical DNS usage, it has some security advantage, e.g. it is much harder to spoof requests. So to me this is another example of short-sighted and badly thought-out "security" thinking that has harmed progress and brought dubious security improvements at best. Note that some people consider EDNS0 a security risk, because it facilitates "reflection" attacks with UDP DNS requests from spoofed (victim) source addresses that result in very large responses to be sent to the victim. -- Simon. $ dig @www.multipop.ch. +edns=0 ptr -x 195.141.232.78 ; <<>> DiG 9.5.0a6 <<>> @www.multipop.ch. +edns=0 ptr -x 195.141.232.78 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 895 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;78.232.141.195.in-addr.arpa. IN PTR ;; ANSWER SECTION: 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.spacebbs.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.amigaland.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.augsauger.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.begegnung.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satvision.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.hackernews.ch.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.natel-news.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satanlagen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satantennen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.wiso-schoch.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.xariffusion.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.sat-receiver.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.estherundpetr.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.luisenstrasse.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.arthurandersen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.elektronik-news.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.zuerichsee-gastro.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.pop.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.rtv.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.dsng.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.aa795.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.aerni.net. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.bar16.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.sysop.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.zingg.org. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satshop.cc. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.aquacare.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.glaettli.cc. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.multipop.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satshops.ch. ;; AUTHORITY SECTION: 78.232.141.195.in-addr.arpa. 38400 IN NS www.multipop.ch. ;; ADDITIONAL SECTION: www.multipop.ch. 38400 IN A 195.141.232.253 ;; Query time: 119 msec ;; SERVER: 195.141.232.253#53(195.141.232.253) ;; WHEN: Thu Mar 27 21:53:39 2008 ;; MSG SIZE rcvd: 1088 _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
