Ipv4 and ipv6: query results are different

553 views
Skip to first unread message

Wowa

unread,
May 30, 2017, 12:15:09 PM5/30/17
to public-dns-discuss
# dig www.aliexpress.com @8.8.8.8

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> www.aliexpress.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32773
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.aliexpress.com.            IN      A

;; ANSWER SECTION:
www.aliexpress.com.     199     IN      CNAME   areaall-akamai.aliexpress.com.
areaall-akamai.aliexpress.com. 199 IN   CNAME   areaall-akamai.aliexpress.com.gds.alibabadns.com.
areaall-akamai.aliexpress.com.gds.alibabadns.com. 119 IN CNAME us1111.alicdn.com.edgekey.net.
us1111.alicdn.com.edgekey.net. 20621 IN CNAME   e1429.b.akamaiedge.net.
e1429.b.akamaiedge.net. 19      IN      A       2.17.156.85

;; Query time: 186 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon May 29 13:14:48 EEST 2017
;; MSG SIZE  rcvd: 227

v4 - everything fine.

# dig www.aliexpress.com @2001:4860:4860::8888

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> www.aliexpress.com @2001:4860:4860::8888
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42678
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.aliexpress.com.            IN      A

;; Query time: 4059 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Mon May 29 13:17:04 EEST 2017
;; MSG SIZE  rcvd: 47

v6 - SERVFAIL.

For test, query in another domain:
# dig aliexpress.com @2001:4860:4860::8888

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> aliexpress.com @2001:4860:4860::8888
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46885
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;aliexpress.com.                        IN      A

;; ANSWER SECTION:
aliexpress.com.         585     IN      A       198.11.132.250

;; Query time: 55 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Mon May 29 13:20:45 EEST 2017
;; MSG SIZE  rcvd: 59

Success. Ip6 server cannot resolve only cname record for www, why?

Alex Dupuy

unread,
Jul 8, 2017, 6:03:22 PM7/8/17
to public-dns-discuss, wo...@gal.cv.ua
The problem is that Alibaba name servers for aliexpress.com do not properly handle EDNS client subnet records with IPv6 addresses in them, they (incorrectly) think that since they are only running IPv4, that the client data must be IPv4 as well. They are wrong.

They will probably fix this eventually, in the meantime if you care, just be sure to configure IPv4 name servers as well as IPv6 name servers, since your resolver will retry with another forwarder when it gets a SERVFAIL.



myxa...@gmail.com

unread,
Oct 12, 2017, 8:17:43 PM10/12/17
to public-dns-discuss
Sadly, no change after ~4 months. Can anyone report/has anyone reported the issue to them?

Also, google's DNS takes quite a while to respond with SERVFAIL (4 seconds at least). As a workaround for dnsmasq-serviced home network, I'll force dnsmasq to resolve all alibaba/aliexpress subdomains via v4:

Alex Dupuy

unread,
Oct 12, 2017, 8:54:54 PM10/12/17
to public-dns-discuss
Sadly, no change after ~4 months. Can anyone report/has anyone reported the issue to them?

One possibility would be to e-mail dnsa...@alibaba-inc.com (from the SOA record on those two domains) or dnsa...@hk.alibaba-inc.com (from WHOIS, probably goes to the same mailbox). Google Public DNS has now published a guideline for EDNS Client Subnet for authoritative name servers: https://developers.google.com/speed/public-dns/docs/ecs, so if you e-mail them, you can point them to this, which explains their problem (as well as others they may have), specifically the part where it says:

ECS data may contain IPv6 addresses even for IPv4-only name servers...

Also, google's DNS takes quite a while to respond with SERVFAIL (4 seconds at least). As a workaround for dnsmasq-serviced home network, I'll force dnsmasq to resolve all alibaba/aliexpress subdomains via v4:

This certainly seems like a reasonable workaround for now. For anyone coming to this thread in the future, you can also do this on MacOS systems by creating files /etc/resolvers/alibaba.com and /etc/resolvers/aliexpress containing the lines:

nameserver 8.8.8.8
nameserver 8.8.4.4


myxa...@gmail.com

unread,
Oct 13, 2017, 11:47:14 AM10/13/17
to public-dns-discuss

On Friday, 13 October 2017 02:54:54 UTC+2, Alex Dupuy wrote:
One possibility would be to e-mail dnsa...@alibaba-inc.com (from the SOA record on those two domains) or dnsa...@hk.alibaba-inc.com (from WHOIS, probably goes to the same mailbox). Google Public DNS has now published a guideline for EDNS Client Subnet for authoritative name servers: https://developers.google.com/speed/public-dns/docs/ecs...
 
Thanks for finding that out, the first address bounced with 554 - no such account, the second one looks to have gone through so far...
 
This certainly seems like a reasonable workaround for now...

For anyone interested in this solution, the list of domains is actually more extensive. Watching for SERVFAIL responses in wireshark (filter "dns.flags.rcode == 2"), this is what I got from just making logging in and going to support chat work:

MZ

Michal Zatloukal

unread,
Oct 24, 2017, 7:20:31 AM10/24/17
to public-dns-discuss
Hm, are we certain this problem is on Alibaba's side? I just tested resolving www.aliexpress.com via OpenDNS' IPv6 servers (2620:0:ccc::2), and it works without issues - returns the same result as 8.8.8.8

MZ

--
--
========================================================
You received this message because you are subscribed to the Google
Groups "public-dns-discuss" group.
To post to this group, send email to public-dns-discuss@googlegroups.com
To unsubscribe from this group, send email to
public-dns-discuss+unsub...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/public-dns-discuss
For more information on Google Public DNS, please visit
http://developers.google.com/speed/public-dns
========================================================
---
You received this message because you are subscribed to a topic in the Google Groups "public-dns-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/public-dns-discuss/Vz2nRZKGRds/unsubscribe.
To unsubscribe from this group and all its topics, send an email to public-dns-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alex Dupuy

unread,
Oct 24, 2017, 7:55:57 AM10/24/17
to public-dns-discuss
Michal wrote:
Hm, are we certain this problem is on Alibaba's side? I just tested resolving www.aliexpress.com via OpenDNS' IPv6 servers (2620:0:ccc::2), and it works without issues - returns the same result as 8.8.8.8

Yes, this is Alibaba's problem. You can confirm this by sending queries with EDNS Client subnet data containing IPv6 addresses to their authoritative name servers.

OpenDNS' IPv6 servers don't do EDNS Client Subnet (ECS), nor their own content filtering (they do appear to support DNSCrypt). I don't know if it's also true for the commercial Cisco Umbrella version, but the free OpenDNS IPv6 implementation is (in their own words) a "Sandbox" and one of the comments (by another user, not by them) on their community forum recommends using their IPv4 resolvers' mapped IPv6 addresses (::ffff: prefix) if you want the "enhanced features like content filtering and logs and stats."

Anyhow, as you can see below, if you use IPv6, OpenDNS does not forward any ECS data to the authoritative resolvers (in this case, the ns*.google.com resolvers, which report the resolver source IP address and ECS option IP address when you query for o-o.myaddr.l.google.com):

$ dig -6 +nocmd +nostats TXT o-o.myaddr.l.google.com @publicdns.goog
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55480
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;o-o.myaddr.l.google.com.       IN      TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 59     IN      TXT     "74.125.44.137"
o-o.myaddr.l.google.com. 59     IN      TXT     "edns0-client-subnet 2620:0:1099:1007::/64"

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43938
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;o-o.myaddr.l.google.com.       IN      TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60     IN      TXT     "208.67.217.67"

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52651
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;o-o.myaddr.l.google.com.       IN      TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60     IN      TXT     "208.67.217.73"
o-o.myaddr.l.google.com. 60     IN      TXT     "edns0-client-subnet 104.99.34.0/24"

Ben Tasker

unread,
Oct 24, 2017, 1:55:25 PM10/24/17
to Alex Dupuy, public-dns-discuss
Hi

On Tue, Oct 24, 2017 at 12:55 PM, 'Alex Dupuy' via public-dns-discuss <public-dn...@googlegroups.com> wrote:
Michal wrote:
Hm, are we certain this problem is on Alibaba's side? I just tested resolving www.aliexpress.com via OpenDNS' IPv6 servers (2620:0:ccc::2), and it works without issues - returns the same result as 8.8.8.8

Yes, this is Alibaba's problem. You can confirm this by sending queries with EDNS Client subnet data containing IPv6 addresses to their authoritative name servers.

OpenDNS' IPv6 servers don't do EDNS Client Subnet (ECS),

This isn't technically correct.

OpenDNS have made the choice (based on an overly strict reading of the RFC) to make ECS opt-in only. If you want to receive ECS data from them, you need to contact their support with details of your nameservers (or, alternatively, the affected zones) and a brief explanation of why you want that data.

 
Anyhow, as you can see below, if you use IPv6, OpenDNS does not forward any ECS data to the authoritative resolvers (in this case, the ns*.google.com resolvers, which report the resolver source IP address and ECS option IP address when you query for o-o.myaddr.l.google.com):


See above :)

If you've not specifically asked OpenDNS to send the data, they won't.

Below is a test with a (redacted) domain that I've specifically asked them to enable ECS for

dig -6 +nocmd +nostats A xxxxxx resolver1.opendns.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48585
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;xxxxxx. IN A

;; ANSWER SECTION:
xxxxxx. 4 IN A 172.217.32.135
xxxxxx. 4 IN A 192.161.144.145

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4875
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:

;; ANSWER SECTION:
resolver1.opendns.com. 610 IN A 208.67.222.222


I'm not sure I agree with their decision to make it opt-in only, but that's the way it is - if you want to receive ECS data from their resolvers you must first request it. They do seem to respond relatively quickly in my experience.

HTH

Ben

 -- 
--
========================================================
You received this message because you are subscribed to the Google
Groups "public-dns-discuss" group.
To post to this group, send email to public-dns-discuss@googlegroups.com
To unsubscribe from this group, send email to
public-dns-discuss+unsub...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/public-dns-discuss
For more information on Google Public DNS, please visit
http://developers.google.com/speed/public-dns
========================================================
---
You received this message because you are subscribed to the Google Groups "public-dns-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-dns-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Alex Dupuy

unread,
Oct 24, 2017, 2:30:32 PM10/24/17
to public-dns-discuss
Ben Tasker wrote:
OpenDNS' IPv6 servers don't do EDNS Client Subnet (ECS),

This isn't technically correct.

OpenDNS have made the choice (based on an overly strict reading of the RFC) to make ECS opt-in only. If you want to receive ECS data from them, you need to contact their support with details of your nameservers (or, alternatively, the affected zones) and a brief explanation of why you want that data.

It is true that you have to get whitelisted, but they whitelisted the ns*.google.com resolvers (authoritative for much of google.com, youtube.com, etc.) from Day 1.

Anyhow, as you can see below, if you use IPv6, OpenDNS does not forward any ECS data to the authoritative resolvers (in this case, the ns*.google.com resolvers, which report the resolver source IP address and ECS option IP address when you query for o-o.myaddr.l.google.com):

If you look at the dig traces I posted, the ns*.google.com resolvers do receive ECS data (as shown in the TXT response) for queries through resolver[12].opendns.com (IPv4 only), but do not receive ECS data for queries through resolver[12].ipv6-sandbox.opendns.com

 
Below is a test with a (redacted) domain that I've specifically asked them to enable ECS for

dig -6 +nocmd +nostats A xxxxxx resolver1.opendns.com

You meant to run dig -6 +nocmd +nostats A xxxxxx @resolver1.opendns.com (with an @ before the target name server) Omitting that just caused you to query for A records for xxxxxx and resolver1.opendns.com via IPv6 from your default resolver, whatever that is). However, with the missing @, it fails:

$ dig -6 +nocmd +nostats A example.com @resolver1.opendns.com
dig: couldn't get address for 'resolver1.opendns.com': not found

Indeed, there is no IPv6 address for resolver1.opendns.com:

$ dig +nocmd +nostats AAAA resolver1.opendns.com @resolver1.opendns.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49982
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;resolver1.opendns.com.         IN      AAAA

;; AUTHORITY SECTION:
opendns.com.            1653    IN      SOA     auth1.opendns.com. noc.opendns.com. 1508855643 16384 2048 1048576 2560

If you run dig -6 +nocmd +nostats A xxxxxx @resolver1.ipv6-sandbox.opendns.com :

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44876
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            796     IN      A       93.184.216.34

However, the presence or absence of a response says nothing about whether they sent ECS data to the authoritative servers, so I'm not even sure what your example would prove by itself. But you could look in your query logs and see if there was an ECS option with your IPv6 address. You won't find it.



Ben Tasker

unread,
Oct 24, 2017, 2:57:53 PM10/24/17
to Alex Dupuy, public-dns-discuss
On Tue, Oct 24, 2017 at 7:30 PM, 'Alex Dupuy' via public-dns-discuss <public-dn...@googlegroups.com> wrote:
Ben Tasker wrote:
OpenDNS' IPv6 servers don't do EDNS Client Subnet (ECS),

This isn't technically correct.

OpenDNS have made the choice (based on an overly strict reading of the RFC) to make ECS opt-in only. If you want to receive ECS data from them, you need to contact their support with details of your nameservers (or, alternatively, the affected zones) and a brief explanation of why you want that data.

It is true that you have to get whitelisted, but they whitelisted the ns*.google.com resolvers (authoritative for much of google.com, youtube.com, etc.) from Day 1.

snip 
 
However, the presence or absence of a response says nothing about whether they sent ECS data to the authoritative servers, so I'm not even sure what your example would prove by itself.

Yeah sorry, I should have explained what that record is :)

The reply is one or 2 A records. One is the IP of the downstream resolver, the second is the received ECS subnet (which is obviously absent if no ECS data was included in the request).

But you're right - I bounced it off the wrong resolver


 
But you could look in your query logs and see if there was an ECS option with your IPv6 address. You won't find it.



--
--
========================================================
You received this message because you are subscribed to the Google
Groups "public-dns-discuss" group.
To post to this group, send email to public-dns-discuss@googlegroups.com
To unsubscribe from this group, send email to
public-dns-discuss+unsub...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/public-dns-discuss
For more information on Google Public DNS, please visit
http://developers.google.com/speed/public-dns
========================================================
---
You received this message because you are subscribed to the Google Groups "public-dns-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-dns-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

myxa...@gmail.com

unread,
Apr 3, 2018, 4:52:46 AM4/3/18
to public-dns-discuss
It seems Alibaba finally fixed the problem:

$ dig www.aliexpress.com @2001:4860:4860::8888

; <<>> DiG 9.9.5-3ubuntu0.17-Ubuntu <<>> www.aliexpress.com @2001:4860:4860::8888
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64023
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:

;; ANSWER SECTION:
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Tue Apr 03 10:12:19 CEST 2018
;; MSG SIZE  rcvd: 228

MZ

On Tuesday, 24 October 2017 13:55:57 UTC+2, Alex Dupuy wrote:
Michal wrote:
Hm, are we certain this problem is on Alibaba's side? I just tested resolving www.aliexpress.com via OpenDNS' IPv6 servers (2620:0:ccc::2), and it works without issues - returns the same result as 8.8.8.8

Yes, this is Alibaba's problem. You can confirm this by sending queries with EDNS Client subnet data containing IPv6 addresses to their authoritative name servers.
<snip>
Reply all
Reply to author
Forward
0 new messages