Questions regarding some public DNS services' clients geo-attribution

[den...@gmail.com]

Question is poorly related to gdnsd itself, but I believe that there the most worried community accumulated :)

Does anyone get a chance to get proper geo attribution for those users who used public DNS servers from this list http://www.tech-faq.com/public-dns-servers.html
Mostly interested in the most popular ones like Level3, Comodo, Norton, Verisign. Seems that all of them neither participate in "A Faster Internet" initiative nor publish locations of DNS servers per unicast IP (like Google or OpenDNS do). Even more, some local ISPs use DNS forwarding to servers of these vendors.

According to my research, all these ones cause improper GEO-attribution for 4-10% of requests. I'm just curious if there are people who solved this somehow...

[Jim Popovitch]

There is no solution, which is sad. Encourage everyone you know to
use Google or OpenDNS because at least they are aware of the problem
and doing something about it.

The "Faster Internet" initiative basically shamed Akamai, and you can
see how well that worked.

-Jim P.

[Brandon Black]

On Wed, Apr 9, 2014 at 3:58 PM, <gdnsd+noreply-APn2wQfGKkkaYfpced...@googlegroups.com> wrote:

Does anyone get a chance to get proper geo attribution for those users who used public DNS servers from this list http://www.tech-faq.com/public-dns-servers.html
Mostly interested in the most popular ones like Level3, Comodo, Norton, Verisign. Seems that all of them neither participate in "A Faster Internet" initiative nor publish locations of DNS servers per unicast IP (like Google or OpenDNS do). Even more, some local ISPs use DNS forwarding to servers of these vendors.

According to my research, all these ones cause improper GEO-attribution for 4-10% of requests. I'm just curious if there are people who solved this somehow...

The only real "solution" is to get them to implement edns-client-subnet (and I see the draft has expired yet again on ietf.org...), or get users to move away from using those recursors.  Keep in mind, however, that geographic DNS routing is always going to be an approximate heuristic.  It gets most of the users landing mostly in the right places, but it won't get every user mapped exactly where you want them on every request (if you have requirements like that, you're going to have to do app-level service discovery and redirection, and then you'd probably still do DNS-based routing just to cut down on the redirections in the common cases).  The issue in this thread only changes the percentage of users that land in sub-optimal places, but you can't fix ever get that to 100% anyways.  For most use-cases, the results are acceptable-ish today.

-- Brandon 

[den...@gmail.com]

On Thursday, April 10, 2014 5:13:05 PM UTC+3, blblack wrote:

The only real "solution" is to get them to implement edns-client-subnet (and I see the draft has expired yet again on ietf.org...), or get users to move away from using those recursors.  Keep in mind, however, that geographic DNS routing is always going to be an approximate heuristic.  It gets most of the users landing mostly in the right places, but it won't get every user mapped exactly where you want them on every request (if you have requirements like that, you're going to have to do app-level service discovery and redirection, and then you'd probably still do DNS-based routing just to cut down on the redirections in the common cases).  The issue in this thread only changes the percentage of users that land in sub-optimal places, but you can't fix ever get that to 100% anyways.  For most use-cases, the results are acceptable-ish today.

-- Brandon

It's all clear to me, originally I was asking if there are some people who maintain "nets" stanza for some popular public DNS servers. This might be a workaround in lack of client-subnet data.

Thank you for your answers.