I am one of those companies running a recursive DNS service, DNSFilter.com
We are not advertising driven. OpenDNS cut the ads a few years ago.
We do not run open resolvers, we just have paying customers who wish to use our service.
The DNS extensions you are referring to are the EDNS0 Client Subnet extension. It is in wide use by authoritative servers for major CDNs and is supported by a number of recursive DNS providers. See the spec here: https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-sub... Section 11 addresses your concerns about IP addresses being shared: It is encouraged to provide only as much granularity as is necessary based on network architecture. At no time is there a reason to share the last octect of an address (since Internet BGP routing is limited to a /24)
We do not run an authoritative DNS service, yet are working to improve encrypted communications... in coordination with industry authoritative partners. Very early stages, but we are driven to protect our customers and the Internet at large. Every time I hear someone misunderstanding what DNSSEC is, and why they think they want it, I'm encouraged to work on solutions such as dnscrypt or DNS over TLS: https://tools.ietf.org/html/rfc7858
Thanks for your hard work.
My client embeds information I need into the host part and the custom DNS server always returns NXDOMAIN.
So it's suggested that DNS providers and ISPs use only a portion of the IP address but they aren't forced to do so (and how could they be forced anyway?). Then it says that users that don't want to send their IP address should configure their software accordingly, but again only "if possible" so again no guarantee that it would be possible. Now a question: I don't see why a DNS packet would contain the client's IP address and a (I admit too quick) look at the draft didn't provided any information. Could you please elaborate on the supposed advantages of this practice?
Here is some background and setup instructions:
https://markbrown778.wordpress.com/2014/08/08/dns-privacy-us...
"But .. caching", well, the performance of resolvers is perhaps not as clear cut as that. Performance would suffer for some, but they can clearly handle it, and does it really matter?
Some real world testing would surely be beneficial. In the mean time, I'm not sure about solutions to the resolver data leak problem. It is a solution to a problem we should not have.
Or the ability to accurately direct users to the nearest POP.
After that, there are many options. But the GP was specifically mentioning a valid use case where this is applicable and not shady.
This was the original.
Other than having to modify their ksh script, it is painless to set up.
In my opinion, authoritative nameservers, and therefore DNSCurve forwarders like CurveDNS, are more important than recursive resolvers/caches such as OpenDNS and DNSCrypt.
A recursive resolver should be authoritative for nothing. They are middlemen. Companies that offered this "service", such as OpenDNS, had to pander to advertisers, or were run by advertising companies themselves, e.g., Google.
The "rules" of DNS are easily broken. This applies to caches. One does not need to look very far to find resolvers that someone has designated as "authoritative". dnsq: "weird ra". This often means an open resolver IME.
A while back some companies including the ones named above if I am not mistaken were pushing for extensions in DNS to put at least part of user IP addresses into DNS packets so cache operators could track them. The reason? Advertising. (Although maybe they would cite other reasons.) Not sure what ever happened with that. BIND had started to implement it. Thankfully djbdns will never support this garbage.
This kind of nonsense is why I cannot get excited about the latest extensions to internet protocols anymore.
Too often they are for the benefit of web companies and advertisers, not users.
The "encrypted DNS revolution", if it ever comes, is not going to be initiated by companies running recursive resolvers. (Unless they also run authoritative nameservers.)
Note: When the user runs their own cache on localhost there is no need to determine nearest POP.