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

[Davey Song]

Hi Ondřej,

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.

Reply inline.

On Mon, 17 Jun 2019 at 15:58, Ondřej Surý <ondrej at sury.org> wrote:


> 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.
>

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:

   A good compromise may be the use of an EDNS maximum
  payload size of 4096 octets as a starting point.

   A requestor MAY choose to implement a fallback to smaller advertised
   sizes to work around firewall or other network limitations.  A
   requestor SHOULD choose to use a fallback mechanism that begins with
   a large size, such as 4096.

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.


> 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.
>

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.


>
> 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.
>

I know it well. And I'm so keen to hear if there is a solution for it.

I don’t really follow this analogy.  I think you come from wrong
> assumptions.
>

Sorry. I make a wrong analogy. My focus is on the flag day approach...

Speaking about “tyranny by the few”...
>

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.

> 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.
>

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?

>
> 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.
>

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.

I feel sorry about it.

Davey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190617/b214bc8e/attachment.html>