23

I'm the process of setting up a monitoring of DNS servers of several large web hosts. My goal is to compare their dns servers response times by tracking their response to ping.

In the process, I discovered that Bluehost nameservers do not respond to ping. I tried to get more information by running Pingdom DNS Check on bluehost.com and it produced the following error:

Name server ns1.bluehost.com (74.220.195.31) does not answer queries over TCP.

The name server failed to answer queries sent over TCP. This is probably due to the name server not correctly set up or due to misconfgured filtering in a firewall. It is a rather common misconception that DNS does not need TCP unless they provide zone transfers - perhaps the name server administrator is not aware that TCP usually is a requirement.

I would like to know the following:

  • To what extent is the above statement true?
  • What are the implications of a nameserver not answering queries over TCP?
47

The diagnostic text from Pingdom is exactly correct. TCP is not just for zone transfers.

DNS server implementations are now "required" (in so much as any RFC requires anything) to support TCP, per RFC 5966, "DNS Transport over TCP - Implementation Requirements".

Note that this is a requirement on the server software implementation, it does not strictly apply to the operation of any server - operational practice is not covered.

That said, if your particular DNS servers are not configured to support TCP, or if it is blocked, then the longer term effect will be an inability to support DNSSEC correctly. Similarly any other DNS data which causes responses to exceed 512 bytes might be blocked.

ob disclaimer: I wrote that RFC.

EDIT RFC 5966 has now been replaced by RFC 7766

  • RE: operational practice, one who hates DNSSEC could simply disable TCP and drop it at the firewall for good measure. Unsurprisingly, there are consequences. No amount of support for EDNS0 at two endpoints can force the devices between them to not interfere in some way. (fragmentation, false flagging by ancient firewalls, etc.) If you have large DNS records on your auth server (bloated TXT), TCP will be required if you don't wish to exclude a segment of your audience. Likewise, disabling it on a recursive server isolates you from DNS replies that your mail cluster may need to deal with spam. – Andrew B Jan 13 '17 at 2:36
3

it should support TCP and UDP - the TCP is for responses sizes >512 bytes (which would include zone transfers) (according to stuff I've read, anyway. I usually enable TCP and UDP for the NS's I run...)

-2

It's good to know what the RFCs say on the subject, and we already have a good authoritative answer on that, but for practical purposes, I find the advice from Prof. Daniel J. Bernstein, PhD, the author of DJBDNS, quite entertaining.

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

When are TCP queries sent?

If you're in one of the following situations, you need to configure your DNS server to answer TCP queries:

  • You want to publish record sets larger than 512 bytes. (This is almost always a mistake.)
  • You want to allow outgoing zone transfers, for example to a third-party server.
  • A parent server refuses to delegate a name to you until you set up TCP service.

If you aren't in any of those situations, you have no need to provide TCP service, and you should not set it up. DNS-over-TCP is much slower than DNS-over-UDP and is inherently much more vulnerable to denial-of-service attacks. (This applies to BIND too.)

Note that he omits an explicit mention of DNSSEC; the reason being is that, according to DJB, DNSSEC falls under the "always a mistake" category. See https://cr.yp.to/djbdns/forgery.html for more details. DJB has an alternative standard, called DNSCurve — http://dnscurve.org/ — which has already been independently adopted by some providers (like OpenDNS). Of interest: https://security.stackexchange.com/questions/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption.

Note that if the above documentation on DJBDNS setup is any indication of its features, it appears that it only supports AXFR for TCP. As many providers still use DJBDNS, they would thus unlikely to support DNS over TCP without extra efforts.

P.S. Note that DJB does, in fact, practice what he preaches. His own servers, (1), do run DNSCurve, (2), don't properly answer TCP. Only the +notcp would succeed (which is default):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, whereas a +tcp would fail (apparently with a different error message, depending on which of his servers gets selected):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached
  • 2
    Your DJB fanboi act is getting rather wearing. The DNS community has chosen DNSSEC, and much of the literature about DNSCurve completely conflates the orthogonal requirements of authenticity of the data and encryption of the data. IMNSHO, the bulk of your answer contributes nothing to this question. – Alnitak Jan 12 '17 at 22:20
  • @Alnitak, your insistence that TCP is required for DNS does not make it be an actual requirement for DNS. Clearly lots of people run without TCP, and don't experience ANY issues with availability of their own websites. Yet you continue promoting misinformation and FUD. – cnst Jan 13 '17 at 0:38
  • 2
    Is that document really from 2003? How can you claim with a straight face that it's still relevant in 2017? – Michael Hampton Jan 15 '17 at 7:35
  • 1
    @MichaelHampton, yes, wholeheartedly and absolutely. Some things don't change, and DJB may be an asshole, but he's a pretty smart one at that. All arguments he presents are philosophical in nature, and don't change as technology does. Meanwhile, (1), why is it so hard to believe, (2), why is linking to even older RFCs done with a straight face, and without you being a hypocrite, (3), what actual counterarguments do you have other than a "date"? People keep saying that his way has interoperability problems, yet the very arguments being proposed (e.g., bounced mail) he debunked back in 2003! – cnst Jan 16 '17 at 2:58
-5

TCP is only required, and usually only used when a long response is required. There can be negative impacts. Zone transfers are done over TCP as they are large, and need to be reliable. Not allowing TCP from untrusted servers is one way to ensure that only small answers are given.

With the introduction of signed DNS answers, there has been a requirement for loosening of the 512 byte limit to UPD answers. EDNS0 provides the mechanism for longer UDP responses. Failure to allow DNS over TCP is highly likely to break an secure DNS implementation.

It is perfectly possible to run a DNS server which only has UDP port 53 open to the Internet. TCP access to DNS peers is required, but this is a small list of hosts.

There is a newer RFC596 that now requires TCP for a full DNS implementation. This is aimed at implementors. The documents specifically does not address operators, but warn that not allowing TCP can result in a number of failure scenarios. It details a wide variety of failures that can result if DNS over TCP is not supported.

There have been discussions of using TCP to prevent DNS amplification attacks. TCP has its own denial of service risks, but distribution is more difficult.

  • DNSSEC didn't loosen the limit, EDNS0 did, in 1999 (see RFC 2671). – Alnitak Sep 17 '10 at 8:28
  • No, as explained by Alnitak, TCP is required in most cases (unless you can be absolutely certain that you'll never have a reply > 512 bytes, something you typically don't know in advance) – bortzmeyer Sep 17 '10 at 11:53
  • I have successfully run DNS through a firewall allowing only UDP. Barring pathalogical configurations, address lookups will be under 512 characters. I have seen references that DNS paths are limited to 256 characters. Evidence in the database for my mail server suggests that server DNS paths rarely exceed 100 characters, and sites which have multiple names returned by a PTR record rarely returs over 256 characters. All these reponses would run on UDP. Does anyone have a reasonable case that runs near 512 characters without DNSSEC or a zone transfer. – BillThor Sep 20 '10 at 0:40
  • Re DNSSEC, I didn't verify RFC for extended sizes, but the only references I have seen to using extended packet sizes on UDP have ben DSNSEC. – BillThor Sep 20 '10 at 0:42
  • One of the large content providers came unstuck a few year back when they added so many A records for one of their webfarms that it exceeded 512 bytes. That caused real interop problems. – Alnitak Sep 20 '10 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.