114DNS's `edns-client-subnet` is broken.

[felixonmars]

114DNS's `edns-client-subnet` is broken.

[phoenixlzx]

+1 on this.

[lilydjwg]

That's why I thought 114DNS didn't support eDNS. It turns out that it's done a worse job than merely not supporting it.

But what can I take as a proof that a DNS server supports this correctly?

[legendtang]

@lilydjwg I can conclude it supports eDNS in a wrong way because it gives me two answer when I dig and specify the same client-subnet IP locally and remotely.

Somehow it's a bit more difficult to prove one's correctness. I've also done more testing by control variables to give a more convincing proof together with @phoenixlzx :).

We use different ISP's IP, e.g. China Telecom, China Unicom and BGP as specified +client= (use +subnet= if you are using dig >= 9.10) IP when testing with dig. @phoenixlzx provided an hostname that would resolve separately according to request's ISP. Sometimes some DNS that supports eDNS gives inaccurate answer as a result of outdated IP databases but it's okay.

[lilydjwg]

@legendtang I see.

I tried some DNS servers with +subnet=. Some of them don't have ; CLIENT-SUBNET: before ;; QUESTION SECTION:, some of them even don't have the EDNS section. Does that mean that they don't support CLIENT-SUBNET or EDNS?

[legendtang]

@lilydjwg Exactly.

[lilydjwg]

@legendtang it's amazing that only Google supports it....

[felixonmars]

I don't have a ecs-enabled dig on hand, but AliDNS is still too slow as far as I have tested for the past a few months. Is CNNIC, Baidu, or DNSPod capable for this?

[legendtang]

@lilydjwg I think AliDNS somtimes supports this kind of technology. Sometimes it return answers without EDNS header though the answer is right according to my test. You can do some testing later.

@felixonmars Unfortunately, CNNIC, Baidu, or DNSPod are not available for EDNS. Why do you think AliDNS is slow? Mine is fine.

[felixonmars]

$ time dig +tcp @223.5.5.5 www.baidu.com > /dev/null

real    0m4.954s
user    0m0.003s
sys     0m0.003s
$ time dig +tcp @223.5.5.5 www.qq.com > /dev/null

real    0m7.328s
user    0m0.007s
sys     0m0.003s
$ time dig +tcp @223.5.5.5 www.10010.com > /dev/null

real    0m7.105s
user    0m0.003s
sys     0m0.007s

compared with

$ time dig +tcp @114.114.114.114 www.baidu.com > /dev/null

real    0m0.082s
user    0m0.003s
sys     0m0.007s
$ time dig +tcp @114.114.114.114 www.qq.com > /dev/null

real    0m0.073s
user    0m0.007s
sys     0m0.003s
$ time dig +tcp @114.114.114.114 www.10010.com > /dev/null

real    0m0.073s
user    0m0.003s
sys     0m0.003s

My ISP pollutes all UDP DNS queries, so I have to use TCP. But even with UDP, two of my servers in Beijing have the same slow response problem with AliDNS. The response time varies from 0.1s to 30s, and introduces too much wait (Looking up...) for everyday use.

[legendtang]

@felixonmars I've done those tests on my server (Canton) and locally (Wuhan). On the contrary, 114DNS reponses 2 or 3 times more slowly than AliDNS, though if proceeding with TCP queries AliDNS seems to be a little slower.

More investigates needed.

[felixonmars]

:/ That's really unfortunate. 20ms or 120ms doesn't make too much difference to me, but 5s on average is too much...

[legendtang]

UPDATED 16.04.30

Status of edns-client-subnet in China

---

Table: DNS providers that support edns headers in China

DNS Provider	114DNS	DNSPod	AliDNS	Google Public DNS
IPv4-prefix support	/24 ~ /32	/24 ~ /32	/32	/24 ~ /32
Whether to reponse based on client subnet	No	Only for /32 and not accurate enough	Yes	Yes

Dilemma :/

[felixonmars]

You can still use the dnsmasq-update-china-list ali, or make SERVER=223.5.5.5 dnsmasq if you like :P

[BROBIRD]

@legendtang @felixonmars It seems that DNSPod+ now support edns-client-subnet
(119.29.29.29,182.254.116.116)，but the judgement on IP's location is less accurate than AliDNS.

[legendtang]

@BROBIRD As is stated above, DNSPod+ does support its header and support /32 only but according to my research it even fails to judge China Telecom and China Unicom.

I haven't found a case gives even one accurate result. You may post yours.

[xunfan]

@lilydjwg because Google invented it and Google is the one who actively pushes this technique to IETF to standardize it.

Google created the problem (pubic resolvers mess up DNS latency) and then created a solution for it (EDNS client subnet).

[xunfan]

@legendtang "114DNS does support CLIENT-SUBNET header. However, it only returns with answers judged by requestor's IP rather than specified CLIENT-SUBNET IP. This would give bad routes from internal CDNs, "

I believe Google public DNS does the same thing, at least 1.5 year ago. They have reasons not to forward ECS (EDNS Client Subnet) query for clients (I noticed in your table, you said they were support it on Apr 30th. I am actually surprised by that). I would expect they just put the requestor's IP (instead of IP provided in ECS field from that requestor) in the edns-client-subnet field and send that to the authoritative DNS servers of the requested domain.

Can you elaborate on "This would give bad routes from internal CDNs" ? Or why do you want to ask public DNS resolvers to give you the answer that is not for your own (requestor) IP but a third IP?

In the standard case, public DNS resolvers will send the ECS query with the client IP to the authoritative name server of the requested domain, and it's up to that authoritative name server to provide the best IP for the client. So the logic is actually at the authoritative name server end, not public resolver. Example would be the 115.com case, if 115.com's authoritative name server doesn't support ECS, then no matter whether the public resolvers support it or not, the answer won't be optimized. I believe at least for google public DNS, it needs the authoritative name server of each individual domain to also support ECS, otherwise, it doesn't work. (Maybe things are different in China, correct me if I am wrong.)

So if you believe 115.com's authoritative name server supports ECS, then you can try send your query directly to their autho name server instead of public resolver like 114 or 8888.

However, there are cases that the authoritative name servers of CDNs only serve ECS from whitelisted IPs. Example, if you are 8.8.8.8 then akamai will honor the client IP in the ECS query from you. But if you are somebody Akamai doesn't know, it will just ignore the ECS field of your query.

So back to the 115.com in your test. A few things to check:

1. Do public resolvers forward your ECS query?
2. Does 115.com authoritative name server support ECS?
3. If 2 is true and 1 is false, you can directly send the ECS query to 115.com authoritative name servers to see if they honor it.

[legendtang]

@xunfan

Can you elaborate on "This would give bad routes from internal CDNs" ? Or why do you want to ask public DNS resolvers to give you the answer that is not for your own (requestor) IP but a third IP?

The project dnsmasq-china-list is not just for personal usage. It has enabled the ability to create unpolluted public DNS server. However, here is the problem. The requestor's public IP varies from different ISPs and areas. By default, one's public DNS server would not forward and send ECS query unless your DNS solution supports the technique. At that case, your public DNS server would not send ECS query but as we know most well-known public resolvers are anycast servers, so your upstream DNS would still give you best result based on your server IP, probably not the best for requestor's IP. But one's individual public server cannot be anycast one, so we need to forward client IP, which is a third-party IP indeed.

Fortunately, popular open source DNS solutions have implemented EDNS standard, which let us profit from ECS query forward. Even requestor is from worldwide, one can still get accurate result from a DNS server that supports EDNS. That why we need upstream resolvers to give correct ECS query result.

However, there are cases that the authoritative name servers of CDNs only serve ECS from whitelisted IPs. Example, if you are 8.8.8.8 then akamai will honor the client IP in the ECS query from you. But if you are somebody Akamai doesn't know, it will just ignore the ECS field of your query.

You are right. But our own DNS server is not a authoritative name server. Only thing it has to do is to forward ECS query and give back the EDNS result. And whitelist doesn't not exist anymore. Google would automatically detect it now.

Here is the answer to your checklist.

1. Do public resolvers forward your ECS query?

Yes, check this part.

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 59.172.176.0/32/0
;; QUESTION SECTION:

2. Does 115.com authoritative name server support ECS?

115.com is not a very good example but makes sense. One of its authoritative name server is ns1.dnsv5.com. Check the CLIENT-SUBNET section.

 dig 115.com @ns1.dnsv5.com +subnet=59.172.176.0/32

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 115.com @ns1.dnsv5.com +subnet=59.172.176.0/32
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8263
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 59.172.176.0/32/14
;; QUESTION SECTION:
;115.com.                       IN      A

;; ANSWER SECTION:
115.com.                600     IN      A       119.147.156.111
115.com.                300     IN      A       119.147.156.110
115.com.                300     IN      A       119.147.156.109

;; AUTHORITY SECTION:
115.com.                86400   IN      NS      ns1.dnsv5.com.
115.com.                86400   IN      NS      ns2.dnsv5.com.

;; Query time: 7 msec
;; SERVER: 183.60.57.192#53(183.60.57.192)
;; WHEN: Sat May 07 14:53:55 CST 2016
;; MSG SIZE  rcvd: 150

I think I've made it clear. 114DNS's response just igores the ECS IP. Google and AliDNS do good job.

[xunfan]

@legendtang

Thanks for your reply!

So this dnsmasq-china-list will be used as a public resolver? Then the DNS lookup is actually going through two resolvers. Take 115.com and google as example, we have:

1. requestor
2. dnsmasq-china-list resolver
3. Google public DNS
4. 115.com authoritative DNS
   Then, the DNS lookup goes 1->2->3->4.

What I don't understand is why not just 1->2->4 or 1->3->4?

[legendtang]

@xunfan
1->2->4 requires a large amount of extra effort to maintain the supported domain list and its authoritative DNS IP. That would be extremely hard for a open source project.

As for 1->3->4, Google DNS's reachibility is in bad shape in China, and polluted thus untrusted. Other DNS providers in China are also polluted. If a user use dnsmasq locally in Linux / Unix, he / she can skip the step 2.

[xunfan]

@legendtang
oh, so even using Public resolver, the answer can be polluted?
How is it polluted? Is it just bogus NXDomain or other kinds of pollution?
And also who pollutes it? Public DNS servers themselves (they probably can give bogus NXDomain) or requestors' local ISP?

Back to 1->2->3->4, how does 2 help prevent pollution if it gets answer from 3 which can be polluted already?

Thanks!

[legendtang]

@xunfan

How is it polluted? Is it just bogus NXDomain or other kinds of pollution?

Some are NXDomain and others are deliberate for some purpose.

And also who pollutes it? Public DNS servers themselves (they probably can give bogus NXDomain) or requestors' local ISP?

The majority mainly involves two kind of entities: ISP itself and the authority. ISP only puts some NXDomain. But the latter pollutes on the domestic egress traffic so that any queries on selected domains will return with fake result.

Back to 1->2->3->4, how does 2 help prevent pollution if it gets answer from 3 which can be polluted already?

In step 2, only domain listed in this project will be proceeded with internal DNS such as 114DNS, DNSPod+, etc. For other domains, we use unpolluted upstream resolvers or some other secured query method.

[xunfan]

@legendtang

OK, so the best use case is when 2 is deployed outside of mainland China. Then, when 1 is inside mainland China, 1 can get unpolluted DNS records for foreign websites; and if 1 is outside of mainland China, 1 can get better DNS records for Chinese websites listed in this project.

If 2 is deployed in mainland China, then the benefit is just filtering out bogus NXDomain? Thanks!

[legendtang]

@xunfan No, 2 forwards two different kind of resolvers, one for listed domains and the other for the rest. The benefits could be ensured. Deploying 2 abroad is not recommended since we need the DNS to maintain high availability. Any routes to somewhere abroad could be interfered.

[xunfan]

OK, I am confused again... I kind of figured out that there is another resolver in addition to 1, 2, 3, 4, as you mentioned you only use 3 for listed domains. let's say there is
5. unpolluted upstream resolver ( or secured query method)

So what is this 5 when both 1 and 2 are domestic? I used to think it's just the local DNS resolver from ISP of 2, but apparently not. are there any domestic resovlers that are unpolluted?

Also what is the secured query method? DNSSEC, DNS over https or some other ones?

[legendtang]

@xunfan Indeed, this is the complete structure:

1->2->3->4
        ->5-/

Apparently 5 is not domestic but through anycast so that we can tolerant the query speed. Using non-standard port for DNS query is fine; you can also try with DNScrypt as most domestic public resolver don't support DNSSEC for now, and won't support I think.