<div dir='auto'>hi Mark<div dir="auto"><br></div><div dir="auto">the problem has been fixed.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2019年6月29日 上午11:33，吴洪声 <samwu@dnspod.com>写道：<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Mark, <br>
<br>
Thanks for mention. Our crews are working on it. I will let you know when we fixed. <br>
<br>
> 在 2019年6月24日，上午8:21，Mark Andrews <marka@isc.org> 写道： <br>
>  <br>
> Well it would help if wechat.com actually responded to well formed DNS <br>
> queries.  STD 13 says to return FORMERR to requests that you do not <br>
> understand.  It would also help if the servers didn’t return NXDOMAIN <br>
> for the nameservers.  This is basic DNS from 1987 that is going wrong. <br>
>  <br>
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @101.89.19.165 <br>
>  <br>
> ; <<>> DiG 9.15.1 <<>> ns1.wechat.com @101.89.19.165 <br>
> ;; global options: +cmd <br>
> ;; connection timed out; no servers could be reached <br>
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @101.89.19.165 +nocookie <br>
>  <br>
> ; <<>> DiG 9.15.1 <<>> ns1.wechat.com @101.89.19.165 +nocookie <br>
> ;; global options: +cmd <br>
> ;; Got answer: <br>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21680 <br>
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 1 <br>
> ;; WARNING: recursion requested but not available <br>
>  <br>
> ;; OPT PSEUDOSECTION: <br>
> ; EDNS: version: 0, flags:; udp: 4096 <br>
> ;; QUESTION SECTION: <br>
> ;ns1.wechat.com. IN A <br>
>  <br>
> ;; ANSWER SECTION: <br>
> ns1.wechat.com. 7200 IN A 157.255.246.101 <br>
> ns1.wechat.com. 7200 IN A 101.89.19.165 <br>
> ns1.wechat.com. 7200 IN A 183.3.226.207 <br>
>  <br>
> ;; AUTHORITY SECTION: <br>
> wechat.com. 7200 IN NS ns3.wechat.com. <br>
> wechat.com. 7200 IN NS ns4.wechat.com. <br>
> wechat.com. 7200 IN NS ns1.wechat.com. <br>
> wechat.com. 7200 IN NS ns2.wechat.com. <br>
>  <br>
> ;; Query time: 410 msec <br>
> ;; SERVER: 101.89.19.165#53(101.89.19.165) <br>
> ;; WHEN: Mon Jun 24 10:02:20 AEST 2019 <br>
> ;; MSG SIZE  rcvd: 159 <br>
>  <br>
> [beetle:bin/tests/system] marka%  <br>
>  <br>
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @101.89.19.165 +nocookie aaaa <br>
>  <br>
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @101.89.19.165 +nocookie aaaa <br>
> ;; global options: +cmd <br>
> ;; Got answer: <br>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49739 <br>
> ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 13 <br>
> ;; WARNING: recursion requested but not available <br>
>  <br>
> ;; OPT PSEUDOSECTION: <br>
> ; EDNS: version: 0, flags:; udp: 4096 <br>
> ;; QUESTION SECTION: <br>
> ;ns1.wechat.com. IN AAAA <br>
>  <br>
> ;; AUTHORITY SECTION: <br>
> ns1.wechat.com. 86400 IN NS ns-cmn1.qq.com. <br>
> ns1.wechat.com. 86400 IN NS ns-tel1.qq.com. <br>
> ns1.wechat.com. 86400 IN NS ns-cnc1.qq.com. <br>
> ns1.wechat.com. 86400 IN NS ns-os1.qq.com. <br>
>  <br>
> ;; ADDITIONAL SECTION: <br>
> ns-cmn1.qq.com. 3600 IN A 121.51.32.102 <br>
> ns-cmn1.qq.com. 3600 IN A 121.51.129.28 <br>
> ns-cmn1.qq.com. 3600 IN A 182.254.52.55 <br>
> ns-tel1.qq.com. 600 IN A 183.2.186.153 <br>
> ns-tel1.qq.com. 600 IN A 123.151.66.83 <br>
> ns-cnc1.qq.com. 600 IN A 111.161.107.195 <br>
> ns-cnc1.qq.com. 600 IN A 223.167.83.104 <br>
> ns-cnc1.qq.com. 600 IN A 58.251.103.109 <br>
> ns-os1.qq.com. 600 IN A 203.205.177.39 <br>
> ns-os1.qq.com. 600 IN A 184.105.206.121 <br>
> ns-os1.qq.com. 600 IN A 203.205.220.26 <br>
> ns-os1.qq.com. 600 IN A 203.205.144.156 <br>
>  <br>
> ;; Query time: 504 msec <br>
> ;; SERVER: 101.89.19.165#53(101.89.19.165) <br>
> ;; WHEN: Mon Jun 24 10:10:20 AEST 2019 <br>
> ;; MSG SIZE  rcvd: 325 <br>
>  <br>
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @121.51.32.102 +nocookie aaaa <br>
>  <br>
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @121.51.32.102 +nocookie aaaa <br>
> ;; global options: +cmd <br>
> ;; connection timed out; no servers could be reached <br>
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @121.51.129.28 +nocookie aaaa <br>
>  <br>
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @121.51.129.28 +nocookie aaaa <br>
> ;; global options: +cmd <br>
> ;; Got answer: <br>
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21536 <br>
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 <br>
> ;; WARNING: recursion requested but not available <br>
>  <br>
> ;; OPT PSEUDOSECTION: <br>
> ; EDNS: version: 0, flags:; udp: 4096 <br>
> ;; QUESTION SECTION: <br>
> ;ns1.wechat.com. IN AAAA <br>
>  <br>
> ;; AUTHORITY SECTION: <br>
> wechat.com. 300 IN SOA ns-tel1.qq.com. webmaster.qq.com. 1357634004 300 600 86400 300 <br>
>  <br>
> ;; Query time: 302 msec <br>
> ;; SERVER: 121.51.129.28#53(121.51.129.28) <br>
> ;; WHEN: Mon Jun 24 10:11:06 AEST 2019 <br>
> ;; MSG SIZE  rcvd: 100 <br>
>  <br>
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @121.51.129.28 +nocookie a <br>
>  <br>
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @121.51.129.28 +nocookie a <br>
> ;; global options: +cmd <br>
> ;; connection timed out; no servers could be reached <br>
> [beetle:bin/tests/system] marka% dig ns1.wechat.com @121.51.129.28 +nocookie a <br>
>  <br>
> ; <<>> DiG 9.15.1+hotspot+add-prefetch+marka <<>> ns1.wechat.com @121.51.129.28 +nocookie a <br>
> ;; global options: +cmd <br>
> ;; Got answer: <br>
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1670 <br>
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 <br>
> ;; WARNING: recursion requested but not available <br>
>  <br>
> ;; OPT PSEUDOSECTION: <br>
> ; EDNS: version: 0, flags:; udp: 4096 <br>
> ;; QUESTION SECTION: <br>
> ;ns1.wechat.com. IN A <br>
>  <br>
> ;; AUTHORITY SECTION: <br>
> wechat.com. 300 IN SOA ns-tel1.qq.com. webmaster.qq.com. 1357634004 300 600 86400 300 <br>
>  <br>
> ;; Query time: 241 msec <br>
> ;; SERVER: 121.51.129.28#53(121.51.129.28) <br>
> ;; WHEN: Mon Jun 24 10:12:52 AEST 2019 <br>
> ;; MSG SIZE  rcvd: 100 <br>
>  <br>
> [beetle:bin/tests/system] marka%  <br>
>  <br>
>  <br>
>> On 22 Jun 2019, at 2:33 am, 吴洪声 <samwu@dnspod.com> wrote: <br>
>>  <br>
>> Actually, as Chinese operator, we don’t usually using email to discussing topics. Even many of us has not join the DNSop group. <br>
>>  <br>
>> Similarly, in China, we also giving up use BBS to discuss topics. <br>
>>  <br>
>> Instead, we have WeChat group. Almost Chinese operator discuss in the group everyday. WeChat is more effective, we can response & take action immediately.  <br>
>>  <br>
>> If you like to get connection with us, try WeChat. <br>
>>  <br>
>>> 在 2019年6月21日，下午5:00，Petr Špaček <petr.spacek@nic.cz> 写道： <br>
>>>  <br>
>>> Hello, <br>
>>>  <br>
>>> On 17. 06. 19 8:54, Sam wrote: <br>
>>>> Do you guys asked for any feedbacks from Chinese operators before you <br>
>>>> pushing the proposal? <br>
>>>  <br>
>>> For the record, we tried to invite everyone, not only Chinese operators: <br>
>>>  <br>
>>> a) Discussion about past and future flag days was held in public at DNS <br>
>>> OARC 30 conference, held in Bangkok. Live video streaming and Jabber <br>
>>> room for asking questions was available to anyone on the Internet. <br>
>>>  <br>
>>> b) This mailing list got invitation for the discussion, see archives: <br>
>>> https://lists.dns-oarc.net/pipermail/dns-operations/2019-May/018721.html <br>
>>> Feedback was basically zero. <br>
>>>  <br>
>>> c) I've personally invited major "broken" operators to talks about the <br>
>>> next flag days, and they promised in e-mail to participate in IETF dnsop <br>
>>> WG and DNS OARC conference ... and then they did not show up without a <br>
>>> single word of notice. <br>
>>>  <br>
>>> Personally I feel we have done as much as we could to attract attention <br>
>>> and do not know what else to do. If you have specific constructive <br>
>>> suggestions let's hear them. <br>
>>>  <br>
>>> Petr Špaček  @  CZ.NIC <br>
>>>  <br>
>>>  <br>
>>>>  <br>
>>>> I will be the first one to oppose this proposal, even though DNSPod <br>
>>>> already supported TCP protocol. Any proposals without fully and widely <br>
>>>> community discussion is a rogue proposal! <br>
>>>>  <br>
>>>> And, do you guys know about how many users and facility will be affected <br>
>>>> in China? <br>
>>>>  <br>
>>>> NO, you don't. <br>
>>>>  <br>
>>>> 2019年6月17日 下午2:12，Davey Song <songlinjian@gmail.com>写道： <br>
>>>>  <br>
>>>>   Hi folks, <br>
>>>>  <br>
>>>>   I'm writing to brief you the feedback I got on the proposal of DNS <br>
>>>>   Flag Day 2020. Firstly I had to say I'm the guy who most want to <br>
>>>>   resolve the IP fragmentation issue.  But I still would like to ask <br>
>>>>   technical questions on the proposal and discuss the justification on <br>
>>>>   it. I'm curious on the technical part, but the latter is the most <br>
>>>>   complains I heard. <br>
>>>>  <br>
>>>>   1) How to enhance and implement the idea of making DNS over TCP <br>
>>>>   support mandatory. In 2019 flag day, I know the approach is to <br>
>>>>   narrow the living space of authoritative servers to get a good <br>
>>>>   performance from a updated resolver if they do not support EDNS. But <br>
>>>>   as to TCP,  how to enhance it? We know that UDP queries from <br>
>>>>   stub-resolver only trigger resolver sending UDP queries to <br>
>>>>   authoritative server. What would happen if the authoritative server <br>
>>>>   does not support TCP after a flag day in 2020? Does resolver monitor <br>
>>>>   the TCP-readiness of authoritative server in advance and penalized <br>
>>>>   it afterwards, or it changes the received UDP queries randomly (10%) <br>
>>>>   to TCP queries against targeted authoritative server? Too <br>
>>>>   complicated! Can we provide positive incentive other than penalty <br>
>>>>   for this case ? <br>
>>>>  <br>
>>>>   2) No matter how to implement it, it definitely exerts a huge <br>
>>>>   pressure on authoritative DNS operators (huge of them) due to the <br>
>>>>   performance of DNS over TCP. Did the guys who proposed this ever ask <br>
>>>>   the opinion from the circle of authoritative DNS operators? Is there <br>
>>>>   any vote or rough consensus from majority of them? And where? ICANN <br>
>>>>   GNSO TechOps? I heard this complain because some of DNS operators <br>
>>>>   feel strongly that they have been bullied even not being asked. <br>
>>>>  <br>
>>>>   As a technical guy, I fully understand and support the enhancement <br>
>>>>   on interoperability of DNS protocol. But I'm doubt about this <br>
>>>>   approach. I suggest do it by advocate the significance of the <br>
>>>>   initiative, and leave enough time for the transition not by a change <br>
>>>>   in a flag day.  IPv6 transition may be not a good example, but it is <br>
>>>>   mad to think about asking a website to turn of IPv4 in a flag day. <br>
>>>>  <br>
>>>>   I also suggest we should continue this discussion and invite more <br>
>>>>   people to join in case of giving people a bad impression as a <br>
>>>>   "tyranny by the few". <br>
>>>>  <br>
>>>>   Comment please. <br>
>>>>  <br>
>>>>   Best regards, <br>
>>>>   Davey <br>
>>>>  <br>
>>>>   Some reference links of DNS flag day 2020； <br>
>>>>   https://www.zdnet.com/article/dns-flag-day-2020-dns-servers-must-support-both-udp-and-tcp-queries/  <br>
>>>>   https://dnsflagday.net/    <br>
>>>>  <br>
>>>>  <br>
>>>>  <br>
>>>> _______________________________________________ <br>
>>>> dns-operations mailing list <br>
>>>> dns-operations@lists.dns-oarc.net <br>
>>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations <br>
>>>> dns-operations mailing list <br>
>>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations <br>
>>>  <br>
>>> _______________________________________________ <br>
>>> dns-operations mailing list <br>
>>> dns-operations@lists.dns-oarc.net <br>
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations <br>
>>> dns-operations mailing list <br>
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations <br>
>>  <br>
>> _______________________________________________ <br>
>> dns-operations mailing list <br>
>> dns-operations@lists.dns-oarc.net <br>
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations <br>
>> dns-operations mailing list <br>
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations <br>
>  <br>
> --  <br>
> Mark Andrews, ISC <br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia <br>
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org <br>
>  <br>
<br>
</p>
<p dir="ltr">_______________________________________________ <br>
dns-operations mailing list <br>
dns-operations@lists.dns-oarc.net <br>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations <br>
dns-operations mailing list <br>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations <br>
<br>
</p>
</blockquote></div><br></div>