[dns-operations] Questions on DNS Flag day 2020 proposal
吴洪声
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: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190629/c429cb9a/attachment.bin>
More information about the dns-operations
mailing list