[dns-operations] Always replying to UDP requests with TC=1, good practice or not

Mukund Sivaraman muks at isc.org
Sun Oct 18 16:32:12 UTC 2015


Hi Stephane

On Sun, Oct 18, 2015 at 05:33:41PM +0200, Stephane Bortzmeyer wrote:
> I had issues with the domain kura.io, since the name servers always
> reply with TC=0 (on IPv4; their IPv6 behaviour is more
> common). According to the DNS hoster, Rage4, it is for "dDoS
> protection" (I assume the goal is to make reflection attacks
> impossible).
> 
> It is the first time I meet this behaviour in the wild.

From the subject, you probably mean TC=1.

I think Cloudfare tried this for sometime IIRC.

> Is it a good idea?

No, I don't think so. There is lot of talk these days suggesting
directly using TCP for DNS due to all the issues UDP has.

A local caching resolver typically spends a lot of its time iterating
queries to domains that have medium to high popularity. TCP doubles
iteration time vs. UDP due to the connection setup. As DNS is at the
head of any network user interaction, it increases the average
turnaround time significantly. Resolvers that are not "near" the
nameservers of such domains (such as resolvers based in India with high
RTT to many parts of the world) are affected enough that this becomes
conspicuous to a user.

Have you seen "Looking up..." messages in the status bar of a browser?

Opinions vary. I think it's a bad idea to skip UDP, and not everybody
who's pushing TCP-only is in a place to appreciate it.

This also involves UDP proposals that add more roundtrips.

There are other concerns about whether network stacks and
implementations are ready to handle the onslaught of TCP-only DNS
traffic (which involves additional state). That's another topic.

		Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151018/69c31b08/attachment.sig>


More information about the dns-operations mailing list