[dns-operations] Questions on DNS Flag day 2020 proposal
Mark Andrews
marka at isc.org
Mon Jun 24 00:21:01 UTC 2019
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
More information about the dns-operations
mailing list