using 'dig @8.8.8.8 +subnet', edns0-client-subnet not working

[gezh...@gmail.com]

Hi. We are planing to set up a forwarder name server which delegates clients' DNS query to 8.8.8.8.

I suppose, using EDNS0-client-subnet, the DNS query can take the client source IP with it to get to 8.8.8.8  and get tailored responses back;

but 8.8.8.8 does not seems to take my ECS option.

I dig at 

- 8.8.8.8

- DYN public dns (216.146.35.35) 

- my authority name server (vip1.alidns.com.)

8.8.8.8 seems to not take my ECS option, while the other two responsed as expected.

Is there any ECS conformity issue on my authority DNS service provider that leads to this? 

I notice there is /0 scope mask in the response from 8.8.8.8 while the other two have /27. 

Thanks to your kindly help.

[gezhaozhi@bogon:/Users/gezhaozhi]
$dig www.bytedancer.club. +subnet=212.118.241.33 @8.8.8.8


; <<>> DiG 9.10.6 <<>> www.bytedancer.club. +subnet=212.118.241.33 @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46396
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 212.118.241.33/32/0
;; QUESTION SECTION:
;www.bytedancer.club. IN A


;; ANSWER SECTION:
www.bytedancer.club. 599 IN A 9.9.9.9


;; Query time: 444 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 16 20:11:15 CST 2018
;; MSG SIZE  rcvd: 76




[gezhaozhi@bogon:/Users/gezhaozhi]
$dig www.bytedancer.club. +subnet=212.118.241.33 @216.146.35.35


; <<>> DiG 9.10.6 <<>> www.bytedancer.club. +subnet=212.118.241.33 @216.146.35.35
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28404
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
; CLIENT-SUBNET: 212.118.241.33/32/24
;; QUESTION SECTION:
;www.bytedancer.club. IN A


;; ANSWER SECTION:
www.bytedancer.club. 600 IN A 7.7.7.7


;; Query time: 388 msec
;; SERVER: 216.146.35.35#53(216.146.35.35)
;; WHEN: Tue Oct 16 20:11:23 CST 2018
;; MSG SIZE  rcvd: 76




[gezhaozhi@bogon:/Users/gezhaozhi]
$dig www.bytedancer.club. +subnet=212.118.241.33 @vip1.alidns.com.


; <<>> DiG 9.10.6 <<>> www.bytedancer.club. +subnet=212.118.241.33 @vip1.alidns.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13743
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 212.118.241.33/32/24
;; QUESTION SECTION:
;www.bytedancer.club. IN A


;; ANSWER SECTION:
www.bytedancer.club. 600 IN A 7.7.7.7


;; Query time: 35 msec
;; SERVER: 140.205.1.1#53(140.205.1.1)
;; WHEN: Tue Oct 16 20:12:07 CST 2018
;; MSG SIZE  rcvd: 76

my setting on authority name service provider:
www.bytedancer.club -> 7.7.7.7, for clients from Europe
www.bytedancer.club -> 8.8.8.8, for clients from North America

www.bytedancer.club -> 9.9.9.9, for other geolocation

212.118.241.33 is an IP located in England, using +subnet=204.117.214.10 (North America) to repeat the former 3 tests we can still see 8.8.8.8 not taking the ECS option.

[Alex Dupuy]

Some services which send client IP addresses to authoritative name servers don't accept client-provided ECS. This is true as a matter of policy for OpenDNS (which correctly returns a response without ECS to indicate this).  Google Public DNS does accept client provided ECS but for technical reasons is not able to do so at many locations. If you use DNS over HTTPS, either directly or through the interactive dns.google.com web page, you can see the results for queries from the specific addresses, if all you need to do is confirm proper operation of ECS from your authoritative server.

From my checks, it appears that we are sending ECS to most AliDNS authoritative servers from most (but not all) locations.

[George Ge]

Before posting this, I wondered at OpenDNS's behavior for quite some time. It does not  even give a ECS options back.

Your reply help me to be clear with this. Thanks a lot, Alex. 👍

I tested it using another domain name hosted by another auth service provider, the result seems to be the same.

8.8.8.8 seems to not take my explicit ECS options in the query.

Is it some network problem that navigate me only to a 8.8.8.8 node that do not take clients' ECS option? Can you offer a little further explanation on that, Alex?

[gezhaozhi@bogon:/Users/gezhaozhi]

$dig demostic.grzz.me @119.29.29.29 +subnet=120.52.147.40

; <<>> DiG 9.10.6 <<>> demostic.grzz.me @119.29.29.29 +subnet=120.52.147.40

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59642

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

; CLIENT-SUBNET: 120.52.147.40/32/14

;; QUESTION SECTION:

;demostic.grzz.me. IN A

;; ANSWER SECTION:

demostic.grzz.me. 600 IN A 22.22.22.22

;; Query time: 303 msec

;; SERVER: 119.29.29.29#53(119.29.29.29)

;; WHEN: Thu Oct 18 16:30:05 CST 2018

;; MSG SIZE  rcvd: 73

[gezhaozhi@bogon:/Users/gezhaozhi]

$dig demostic.grzz.me @8.8.8.8 +subnet=120.52.147.40

; <<>> DiG 9.10.6 <<>> demostic.grzz.me @8.8.8.8 +subnet=120.52.147.40

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21370

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

; CLIENT-SUBNET: 120.52.147.40/32/0

;; QUESTION SECTION:

;demostic.grzz.me. IN A

;; ANSWER SECTION:

demostic.grzz.me. 599 IN A 33.33.33.33

;; Query time: 233 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Thu Oct 18 16:30:13 CST 2018

;; MSG SIZE  rcvd: 73

[Alex Dupuy]

George wrote:

I tested it using another domain name hosted by another auth service provider, the result seems to be the same.

8.8.8.8 seems to not take my explicit ECS options in the query.

Is it some network problem that navigate me only to a 8.8.8.8 node that do not take clients' ECS option? Can you offer a little further explanation on that, Alex?

UDP queries to the 8.8.8.8 and other anycast addresses land at Google Public DNS in a location that is close to the query source (this isn't a problem) but it does mean that for most users' locations their client-provided ECS data will be ignored (although it will still be used in the response, it won't be sent to authoritative name servers). DNS-over-HTTPS avoids this problem since the addresses used for this are unicast addresses (that are usually further away) but which will accept client-provided ECS for most domains.

Over the course of 2019, we expect to address the way we handle ECS, and in addition to accepting client-provided ECS at many more locations, we may also be able to switch to a more RFC compliant way of handling client-provided ECS, by sending REFUSED responses when we cannot use the client-provided ECS. In the following sections of the RFC, I have highlighted the SHOULD directives that we currently do not follow, but hope to do so in the future

RFC 7871 section 7.1.1:

   FAMILY and ADDRESS information MAY be used from the ECS option in the
   incoming query.  Passing the existing address data is supportive of
   the Recursive Resolver being used as the target of a Forwarding
   Resolver, but could possibly run into policy problems with regard to
   usage agreements between the Recursive Resolver and Authoritative
   Nameserver.  See Section 12.2 for more discussion on this point.  If
   the Recursive Resolver will not forward FAMILY and ADDRESS data from
   the incoming ECS option, it SHOULD return a REFUSED response.

RFC 7871 section 7.1.2:

   A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0.  It MAY include
   FAMILY and ADDRESS data, but should be prepared to handle a REFUSED
   response if the Intermediate Nameserver that it queries has a policy
   that denies forwarding of ADDRESS.

RFC 7871 section 7.3:

   ... a client of a Recursive Resolver SHOULD
   retry after receiving a REFUSED response because it is not
   sufficiently clear whether the REFUSED response was because of the
   ECS option or some other reason.

RFC 7871 section 7.3.2:

   o  If there was an ECS option with an ADDRESS, the ADDRESS from it
      MAY be used if the local policy allows.  The policy can vary
      depending on the agreements the operator of the Intermediate
      Nameserver has with Authoritative Nameserver operators; see
      Section 12.2.  If the policy does not allow it, a REFUSED response
      SHOULD be sent.  See Section 7.5 for more information.

RFC 7871 section 7.5:

   An Intermediate Nameserver MAY forward ECS options with address
   information.  This information MAY match the source IP address of the
   incoming query, and MAY have more or fewer address bits than the
   nameserver would normally include in a locally originated ECS option.
   If an Intermediate Nameserver receives a query with SOURCE PREFIX-
   LENGTH set to 0, it MUST NOT include client address information in
   queries made to resolve that client's request (see Section 7.1.2).

   If, for any reason, the Intermediate Nameserver does not want to use
   the information in an ECS option it receives (too little address
   information, network address from a range not authorized to use the
   server, private/unroutable address space, etc.), it SHOULD drop the
   query and return a REFUSED response.  Note again that a query MUST
   NOT be refused solely because it provides 0 address bits.

   Be aware that at least one major existing implementation does not
   return REFUSED and instead just processes the query as though the
   problematic information were not present.  This can lead to anomalous
   situations, such as a response from the Intermediate Nameserver that
   indicates it is tailored for one network (the one passed in the
   original query, since the ADDRESS must match) when actually it is for
   another network (the one which contains the address that the
   Intermediate Nameserver saw as making the query).

I will let the last paragraph pass without comment.

[George Ge]

Thanks for the explanation and RFC snippets, Alex.

It all makes sense to me now. Knowing your future plan also helps a lot. We can have that in mind while managing our forwarder DNS.

You have my sincere gratitude. 😊

在 2018年10月16日星期二 UTC+8下午10:00:06，George Ge写道：