<div dir="ltr"><div>Hi Ondřej,</div><div><br></div><div>Thanks for your reply. I had to say some of comments I left in previous mails are from other's complains, like the saying “tyranny by the few”. I know it is a little exaggerated. I just take this chance to speak it out for them.</div><div><br></div><div>Reply inline.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Jun 2019 at 15:58, Ondřej Surý <<a href="mailto:ondrej@sury.org">ondrej@sury.org</a>> wrote:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.  <br></blockquote><br>OK. It's fine. I understand the background and agree to make changes on the specification of EDNS Buffer Size. My question is how do we achieve this? Because in rfc6891#section-6.2.5, it says: </div><div class="gmail_quote"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_quote">   A good compromise may be the use of an EDNS maximum </div><div class="gmail_quote">  payload size of 4096 octets as a starting point.<br><br>   A requestor MAY choose to implement a fallback to smaller advertised<br>   sizes to work around firewall or other network limitations.  A<br>   requestor SHOULD choose to use a fallback mechanism that begins with<br>   a large size, such as 4096. <br><br><div>If we are saying honoring RFC7766(Proposed Standard), should we honoring RFC6891(Internet Standard) in first place. Or Shall we think of updating the section-6.2.5 of RFC6891 before we propose a flag day?  People pay more attention to IETF and honor IETF consensus than a project of Vendors.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div> </div><div>Yes it is not new on IETF document just as IPv6 is not new. We both know it and wish we can change over one night. But it is new for the operation reality for at least some registries who serve a huge population. So I suggest we take care to make any decision which may impact them. Or at least we should invite them to this discussion. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br>
<br>
IP Fragmentation is already broken, insecure and actively harmful to any UDP based protocol including DNS.<br></blockquote><div><br></div><div>I know it well. And I'm so keen to hear if there is a solution for it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I don’t really follow this analogy.  I think you come from wrong assumptions.<br></blockquote><div><br></div><div>Sorry. I make a wrong analogy. My focus is on the flag day approach... </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Speaking about “tyranny by the few”...<br></blockquote><div><br></div><div>I heard it from a feadback. I disagree on that saying as well but it give some people the impression if a big decision is made and has not been well circulated. I think a good example is ICANN's KSK rollover. They took a lot of effort for communication. But for flag day 2019, the communication is not sufficient. It sounded like a direct order. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On 17 Jun 2019, at 08:54, Sam <<a href="mailto:samwu@dnspod.com" target="_blank">samwu@dnspod.com</a>> wrote:<br>
> <br>
> Do you guys asked for any feedbacks from Chinese operators before you pushing the proposal?<br>
> <br>
> 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!<br>
> <br>
> And, do you guys know about how many users and facility will be affected in China?<br>
> <br>
> NO, you don't.<br>
<br>
<br>
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.<br></blockquote><div><br></div><div>Again. If you guys hope make changes on existing practice suggested by IETF (RFC6891 in this case), I think an initiative is OK to start the communication, but only a initiative project is not enough because it impacts others' business. I suggest we go IETF and get broader consensus on it. Why not?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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.<br></blockquote><div> </div><div>The big merit of open source is that you can choose whether to join and contribute to your own best interets. No matter what's your choice, your situation are not becoming worse (penalty design in side of it) by your choice. However, DNS Flag Day "threathen" pepole to join or lose. I don't think it is in an open-source spirit.</div><div> </div><div>I feel sorry about it.</div><div><br></div><div>Davey</div></div></div>