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

=?gb2312?B?zuK66cn5?= samwu at dnspod.com
Sat Jun 29 03:33:30 UTC 2019


Hi Mark,

Thanks for mention. Our crews are working on it. I will let you know when we fixed.

> 在 2019年6月24日,上午8:21,Mark Andrews <marka at isc.org> 写道:
> 
> Well it would help if wechat.com actually responded to well formed DNS
> queries.  STD 13 says to return FORMERR to requests that you do not
> understand.  It would also help if the servers didn’t return NXDOMAIN
> for the nameservers.  This is basic DNS from 1987 that is going wrong.
> 
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @101.89.19.165
> 
> ; <<>> DiG 9.15.1 <<>> ns1.wechat.com @101.89.19.165
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @101.89.19.165 +nocookie
> 
> ; <<>> DiG 9.15.1 <<>> ns1.wechat.com @101.89.19.165 +nocookie
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21680
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ns1.wechat.com.			IN	A
> 
> ;; ANSWER SECTION:
> ns1.wechat.com.		7200	IN	A	157.255.246.101
> ns1.wechat.com.		7200	IN	A	101.89.19.165
> ns1.wechat.com.		7200	IN	A	183.3.226.207
> 
> ;; AUTHORITY SECTION:
> wechat.com.		7200	IN	NS	ns3.wechat.com.
> wechat.com.		7200	IN	NS	ns4.wechat.com.
> wechat.com.		7200	IN	NS	ns1.wechat.com.
> wechat.com.		7200	IN	NS	ns2.wechat.com.
> 
> ;; Query time: 410 msec
> ;; SERVER: 101.89.19.165#53(101.89.19.165)
> ;; WHEN: Mon Jun 24 10:02:20 AEST 2019
> ;; MSG SIZE  rcvd: 159
> 
> [beetle:bin/tests/system] marka% 
> 
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @101.89.19.165 +nocookie aaaa
> 
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @101.89.19.165 +nocookie aaaa
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49739
> ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 13
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ns1.wechat.com.			IN	AAAA
> 
> ;; AUTHORITY SECTION:
> ns1.wechat.com.		86400	IN	NS	ns-cmn1.qq.com.
> ns1.wechat.com.		86400	IN	NS	ns-tel1.qq.com.
> ns1.wechat.com.		86400	IN	NS	ns-cnc1.qq.com.
> ns1.wechat.com.		86400	IN	NS	ns-os1.qq.com.
> 
> ;; ADDITIONAL SECTION:
> ns-cmn1.qq.com.		3600	IN	A	121.51.32.102
> ns-cmn1.qq.com.		3600	IN	A	121.51.129.28
> ns-cmn1.qq.com.		3600	IN	A	182.254.52.55
> ns-tel1.qq.com.		600	IN	A	183.2.186.153
> ns-tel1.qq.com.		600	IN	A	123.151.66.83
> ns-cnc1.qq.com.		600	IN	A	111.161.107.195
> ns-cnc1.qq.com.		600	IN	A	223.167.83.104
> ns-cnc1.qq.com.		600	IN	A	58.251.103.109
> ns-os1.qq.com.		600	IN	A	203.205.177.39
> ns-os1.qq.com.		600	IN	A	184.105.206.121
> ns-os1.qq.com.		600	IN	A	203.205.220.26
> ns-os1.qq.com.		600	IN	A	203.205.144.156
> 
> ;; Query time: 504 msec
> ;; SERVER: 101.89.19.165#53(101.89.19.165)
> ;; WHEN: Mon Jun 24 10:10:20 AEST 2019
> ;; MSG SIZE  rcvd: 325
> 
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @121.51.32.102 +nocookie aaaa
> 
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @121.51.32.102 +nocookie aaaa
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @121.51.129.28 +nocookie aaaa
> 
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @121.51.129.28 +nocookie aaaa
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21536
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ns1.wechat.com.			IN	AAAA
> 
> ;; AUTHORITY SECTION:
> wechat.com.		300	IN	SOA	ns-tel1.qq.com. webmaster.qq.com. 1357634004 300 600 86400 300
> 
> ;; Query time: 302 msec
> ;; SERVER: 121.51.129.28#53(121.51.129.28)
> ;; WHEN: Mon Jun 24 10:11:06 AEST 2019
> ;; MSG SIZE  rcvd: 100
> 
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @121.51.129.28 +nocookie a
> 
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @121.51.129.28 +nocookie a
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @121.51.129.28 +nocookie a
> 
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @121.51.129.28 +nocookie a
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1670
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ns1.wechat.com.			IN	A
> 
> ;; AUTHORITY SECTION:
> wechat.com.		300	IN	SOA	ns-tel1.qq.com. webmaster.qq.com. 1357634004 300 600 86400 300
> 
> ;; Query time: 241 msec
> ;; SERVER: 121.51.129.28#53(121.51.129.28)
> ;; WHEN: Mon Jun 24 10:12:52 AEST 2019
> ;; MSG SIZE  rcvd: 100
> 
> [beetle:bin/tests/system] marka% 
> 
> 
>> On 22 Jun 2019, at 2:33 am, 吴洪声 <samwu at dnspod.com> wrote:
>> 
>> Actually, as Chinese operator, we don’t usually using email to discussing topics. Even many of us has not join the DNSop group.
>> 
>> Similarly, in China, we also giving up use BBS to discuss topics.
>> 
>> Instead, we have WeChat group. Almost Chinese operator discuss in the group everyday. WeChat is more effective, we can response & take action immediately. 
>> 
>> If you like to get connection with us, try WeChat.
>> 
>>> 在 2019年6月21日,下午5:00,Petr Špaček <petr.spacek at nic.cz> 写道:
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> 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
>> 
>> _______________________________________________
>> 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
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3916 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190629/c429cb9a/attachment.bin>


More information about the dns-operations mailing list