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

[Petr Špaček]

Hello,

On 17. 06. 19 8:54, Sam wrote:
> Do you guys asked for any feedbacks from Chinese operators before you
> pushing the proposal?

For the record, we tried to invite everyone, not only Chinese operators:

a) Discussion about past and future flag days was held in public at DNS
OARC 30 conference, held in Bangkok. Live video streaming and Jabber
room for asking questions was available to anyone on the Internet.

b) This mailing list got invitation for the discussion, see archives:
https://lists.dns-oarc.net/pipermail/dns-operations/2019-May/018721.html
Feedback was basically zero.

c) I've personally invited major "broken" operators to talks about the
next flag days, and they promised in e-mail to participate in IETF dnsop
WG and DNS OARC conference ... and then they did not show up without a
single word of notice.

Personally I feel we have done as much as we could to attract attention
and do not know what else to do. If you have specific constructive
suggestions let's hear them.

Petr Špaček  @  CZ.NIC


> 
> 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.
> 
> 2019年6月17日 下午2:12，Davey Song <songlinjian at gmail.com>写道：
> 
>     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 ?
> 
>     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.
> 
>     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.  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 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".
> 
>     Comment please.
> 
>     Best regards,
>     Davey
> 
>     Some reference links of DNS flag day 2020；
>     https://www.zdnet.com/article/dns-flag-day-2020-dns-servers-must-support-both-udp-and-tcp-queries/ 
>     https://dnsflagday.net/   
> 
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations