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.
