[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
[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:
;; ANSWER SECTION:
;; 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:
;; ANSWER SECTION:
;; 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
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?
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 SHOULDretry 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.
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.
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).