[dns-operations] Questions on DNS Flag day 2020 proposal

Davey Song songlinjian at gmail.com
Mon Jun 17 08:23:13 UTC 2019


Reply in line

On Mon, 17 Jun 2019 at 14:56, Jerry Lundström <jerry at dns-oarc.net> wrote:

>
> I'm mostly reading this as you think the proposal is "DNS over TCP only"
> and my understanding is that it's not like that.
>

NO. I understand it is proposed to support both UDP and TCP for DNS. I make
a misleading analogy by turn off IPv4. Sorry. What I really want to discuss
is:  Do we really need a flag day to threaten people who may confront a
service outage or performance degradation.

I really don't think we should add penalty. The majority of DNS will still
> be over UDP, _but TCP **MUST** work!_


I understand the TC bit mechanism behind. AFAIK the concerns is the
increasing traffic of TCP in future for authoritative server and TCP
traffic as a DOS vector for resolver.

The fear of penalty exists from the saying : "According to this group,
starting with February 1, 2020, DNS servers that can't handle DNS queries
over both UDP and TCP may be pushed out of the DNS ecosystem and stop
working."  And also in 2019 Flag Day it was threatened that "Sites hosted
on incompatible authoritative servers may become unreachable through
updated resolvers. "

>From the perspective of resolver, I can guess the UDP-only resolvers are
penalized without the ability of TCP fallback, because they will get more
Truncated response after the flag day. Because before the flag day, there
are large chance for them to survive by receiving a large response (> 1220
octets).

But for authoritative server, if there is no penalty for them as you said,
how do DNS-flag-day people enhance this plan on authoritative server ? I'm
curious about the technical detailed because I have been often asked on
this.

Best regards,
Davey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190617/b14adbb5/attachment.html>


More information about the dns-operations mailing list