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

=?gb2312?B?zuK66cn5?= samwu at dnspod.com
Mon Jun 17 08:47:47 UTC 2019


> 
> 
> Again, DNS over TCP has always been part of DNS from the day one.  The open-source DNS implementations **had** to implement many workarounds for the other parties that has violated the standards.  The DNS Flag Day initiative is all about restoring the balance and putting the costs where they belong.  If you don’t want to fully follow the existing DNS standard, fine, it’s your choice, but don’t impose the costs for the workarounds to the other parties because you chose to be non-compliant.
> 

What I mean was not about “TCP protocol”, what I mean is your behavior. 

Yes, you’re Google, you’re cloudflare, you’re IBM, you’re opendns. You have traffic, you have big big power. So you can setup your own rule, you can block any traffic as you like.

Why do we need a community? You can play yourself, We can play ourself. You don’t wanna play with us? Fine, it’s your choice, we can block you.

Guys, DNS is a Eco System, not someone’s backyard. You can't ban others irresponsibly. You should listen to more voice.

> 在 2019年6月17日,下午3:58,Ondřej Surý <ondrej at sury.org> 写道:
> 
> Hi Davey,
> 
>> On 17 Jun 2019, at 08:12, Davey Song <songlinjian at gmail.com> wrote:
>> 
>> Hi folks, 
>> 
>> I'm writing to brief you the feedback I got on the proposal of DNS Flag Day 2020. Firstly I had to say I'm the guy who most want to resolve the IP fragmentation issue.  But I still would like to ask technical questions on the proposal and discuss the justification on it. I'm curious on the technical part, but the latter is the most complains I heard. 
>> 
>> 1) How to enhance and implement the idea of making DNS over TCP support mandatory. In 2019 flag day, I know the approach is to narrow the living space of authoritative servers to get a good performance from a updated resolver if they do not support EDNS. But as to TCP,  how to enhance it? We know that UDP queries from stub-resolver only trigger resolver sending UDP queries to authoritative server. What would happen if the authoritative server does not support TCP after a flag day in 2020? Does resolver monitor the TCP-readiness of authoritative server in advance and penalized it afterwards, or it changes the received UDP queries randomly (10%) to TCP queries against targeted authoritative server? Too complicated! Can we provide positive incentive other than penalty for this case ?
> 
> The overall goal of the initiative is to reduce the overall complexity of the DNS. The next DNS Flag Day can be reduced to simple TL;DR: reduce the default EDNS Buffer Size to a level that doesn’t fragment and then follow the original DNS on how to fallback to TCP.  Yes, the DNS that has been here since RFC 1034/1035.
> 
>> 2) No matter how to implement it, it definitely exerts a huge pressure on authoritative DNS operators (huge of them) due to the performance of DNS over TCP. Did the guys who proposed this ever ask the opinion from the circle of authoritative DNS operators? Is there any vote or rough consensus from majority of them? And where? ICANN GNSO TechOps? I heard this complain because some of DNS operators feel strongly that they have been bullied even not being asked. 
> 
> Again, it seems like you are coming from the position that the next day is about switching to TCP. That has never been the case. DNS over TCP has been integral part of DNS since the day one, this is not anything new.
> 
> The switch to TCP will follow the standard DNS protocol, e.g. only when the response over UDP has been truncated (as indicated by the TC bit).  There might be slight increase in TCP connection for responses larger than the default EDNS buffer size - and I personally believe it’s fairly easy to mitigate this if you see this as a problem. Also the important part of it is, that if you are sending responses that fragment now, it’s already broken in parts of eyeball network, especially when IPv6 is involved.
> 
> IP Fragmentation is already broken, insecure and actively harmful to any UDP based protocol including DNS.
> 
>> As a technical guy, I fully understand and support the enhancement on interoperability of DNS protocol. But I'm doubt about this approach. I suggest do it by advocate the significance of the initiative, and leave enough time for the transition not by a change in a flag day.
> 
> RFC1035 Section 4.2.2 is dated November 1987, what exactly do you mean by “enough time”?
> 
>> IPv6 transition may be not a good example, but it is mad to think about asking a website to turn of IPv4 in a flag day. 
> 
> I don’t really follow this analogy.  I think you come from wrong assumptions.
> 
>> I also suggest we should continue this discussion and invite more people to join in case of giving people a bad impression as a "tyranny by the few". 
> 
> Speaking about “tyranny by the few”...
> 
>> On 17 Jun 2019, at 08:54, Sam <samwu at dnspod.com> wrote:
>> 
>> Do you guys asked for any feedbacks from Chinese operators before you pushing the proposal?
>> 
>> I will be the first one to oppose this proposal, even though DNSPod already supported TCP protocol. Any proposals without fully and widely community discussion is a rogue proposal!
>> 
>> And, do you guys know about how many users and facility will be affected in China?
>> 
>> NO, you don't.
> 
> 
> Again, DNS over TCP has always been part of DNS from the day one.  The open-source DNS implementations **had** to implement many workarounds for the other parties that has violated the standards.  The DNS Flag Day initiative is all about restoring the balance and putting the costs where they belong.  If you don’t want to fully follow the existing DNS standard, fine, it’s your choice, but don’t impose the costs for the workarounds to the other parties because you chose to be non-compliant.
> 
> Yes, the open source implementation are partly at fault by making those workaround in the first place, and part of taking responsibility for the current status is making a coordinated effort to fix the mess we are currently in.
> 
> Ondrej
> --
> Ondřej Surý
> ondrej at sury.org
> 







More information about the dns-operations mailing list