[dns-operations] is www.qq.com a zone?

Fri Jul 1 23:16:42 UTC 2016

This company (QQ inc) always does what they think, ignore technology 
standards.

For example, once their MX records were CNAMEs.
And even now, their official MX for email hosting are not good.

$ idig ads8.com mx
ads8.com.               575     IN      MX      5 mxbiz1.qq.com.
ads8.com.               575     IN      MX      10 mxbiz2.qq.com.

$ idig mxbiz1.qq.com
mxbiz1.qq.com.          254     IN      A       183.57.48.34
mxbiz1.qq.com.          254     IN      A       183.60.15.245

$ idig mxbiz2.qq.com
mxbiz2.qq.com.          918     IN      A       183.60.15.245
mxbiz2.qq.com.          918     IN      A       183.57.48.34

mxbiz1 and mxbiz2 are exactly the same, which breaks RFCs IMO.

Thanks.

> Which is all fine until it doesn't work.  Is www.qq.com supposed
> to work over IPv6 because the chances of getting a AAAA addresses
> from a cache are close to zero.  If you ask for the A record first
> or ~300 seconds after asking for the A record the AAAA will not be
> returned.
>
> As far as I can tell the is a web server at the IPv6 address
> configured for www.qq.com as curl with the right set of arguement
> returns the page using IPv6 but I had to resort to manually putting
> is the literal IPv6 address to check as 'curl -6' doesn't find a
> AAAA address.
>
> curl --connect-to www.qq.com:80:[240e:e1:8100:28:0:0:2:16]:80 http://www.qq.com
>
> Note you need to protect the command from the shell (not shown).
>
> So if you are IPv6 only and there are no clients asking for A records
> from the recursive server you will see the AAAA records.
>
> % telnet 240e:e1:8100:28::2:16 80
> Trying 240e:e1:8100:28::2:16...
> Connected to 240e:e1:8100:28::2:16.
> Escape character is '^]'.
> ^]
> telnet> q
> Connection closed.
> %
>
> % dig www.qq.com aaaa
> ;; BADCOOKIE, retrying.
>
> ; <<>> DiG 9.11.0a3 <<>> www.qq.com aaaa
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21394
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: c43e0a0a9f177f2e6de350185776da14c546f347647edc7f (good)
> ;; QUESTION SECTION:
> ;www.qq.com.			IN	AAAA
>
> ;; ANSWER SECTION:
> www.qq.com.		295	IN	CNAME	qq.com.edgesuite.net.
> qq.com.edgesuite.net.	20994	IN	CNAME	a1574.b.akamai.net.
>
> ;; AUTHORITY SECTION:
> b.akamai.net.		417	IN	SOA	n0b.akamai.net. hostmaster.akamai.com. 1467406282 1000 1000 1000 1800
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sat Jul 02 07:01:08 EST 2016
> ;; MSG SIZE  rcvd: 188
>
> % dig www.qq.com @ns-cmn1.qq.com aaaa +nocookie
>
> ; <<>> DiG 9.11.0a3 <<>> www.qq.com @ns-cmn1.qq.com aaaa +nocookie
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19578
> ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.qq.com.			IN	AAAA
>
> ;; ANSWER SECTION:
> www.qq.com.		300	IN	AAAA	240e:e1:8100:28::2:16
>
> ;; Query time: 415 msec
> ;; SERVER: 182.254.32.107#53(182.254.32.107)
> ;; WHEN: Sat Jul 02 07:01:15 EST 2016
> ;; MSG SIZE  rcvd: 67
>
> %
>
> Mark
>
> In message <C8EA6FCA-60EA-4B25-85FC-1C8F67CBDC8B at icann.org>, Edward Lewis writes:
>> Answering because once I was perplexed by this.  Then I learned to stop worrying...
>>
>> www.qq.com resolves to an address.  I mean, my web browser pops up with a page and I can read some of it.
>>
>> But, on the way there, the DNS resolver has to deal with some non-standard/unexpected behaviors.
>>
>> Walking down the DNS tree, when the resolver is asking the qq.com name servers for www.qq.com for an A record, ther
>> e's a referral given to www.qq.com name servers.  That "works".  If you ask the qq.com name servers for the www.qq.
>> com name servers, it gives them back as an answer (not a referral) - but, why would you (thinks the operator)?  Unl
>> ess someone is quickly switching configurations at their end, they servers for qq.com aren't following the document
>> ed DNS protocol - in a way, the answers you get are compliant with the protocol if you assume the operator is behav
>> ing in a certain way.  (So - this isn't about complying with the protocol, it's about...well you maintaining your s
>> anity.)
>>
>> When you query name servers for www.qq.com and ask for an SOA record (which indicates being a zone, not just a subd
>> omain), you get one.  When you ask for anything else (almost anything else), you get a CNAME record.  When you ask
>> for ANY, to help you restore your sanity, you get RCODE=NOTIMP.  One might point out that the protocol doesn't work
>>  when a name owns an SOA record and a CNAME record - but, recall the end of the last paragraph.  It's not about the
>>  operator following the protocol, it's about you maintaining sanity.  And, why are you asking for the SOA anyway?)
>>
>> The lesson here is - whomever is running www.qq.com has built a system so minimal that it only will result in addre
>> ss records in normal queries.  Any hunting and poking will just frustrate you.
>>
>> Why do they do this?  I wouldn't try to answer that without calling up the operator and asking.  Intent is not well
>>  conveyed in the DNS protocol.  I never cared enough to follow up.  But they have been doing this for years and the
>> y are still in business and paying the bills.  Well, someone is.
>>
>> It "works" for the operator.  The URL gets hits, enough to rank.  They just aren't fully deploying the DNS protocol
>> .  They don't need to .... unless they ever decide to roll out DNSSEC or other features that rely on a more solid p
>> rotocol base.  Which may never happen.
>>
>>
>>
>> _______________________________________________
>> 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