On 10/27/14 3:09 PM, Warren Kumari wrote:
On Sat, Oct 25, 2014 at 11:57 AM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
On Mon, Oct 20, 2014 at 05:26:29PM -0400,
Phillip Hallam-Baker <hal...@gmail.com> wrote
a message of 74 lines which said:
If we are going there, I would want to know how common the
configurations are.
Yes, actual numbers seen from a real resolver would be useful.
Outside this list how common are hierarchies more than 4 levels deep
in practice?
Surprisingly enough, not an insignificant number -- but this is
mitigated by what the queries are (see below)
ip6.arpa, and other infrastructure domains?
There is a long tail, but:
~51% of lookups are of length 3 (www.example.com)
~23% of lookups are of length 5 (this was surprising to me, but is
largely dominated by Akamai - www.example.com.akadns.net)
~15% of lookups are of length 4 (usually service.something.largecompany.com)
This means that lengths 3, 4, 5 account for ~89% of lookups. If you
include lengths of 1 and 2 you get >96%
Many of these (like the akamai ones, .com, etc) look like they would
cache every well...
In the long tail there are the ip6.arpa, in-addr.arpa, some dnsbls and
then a bunch of anti-virus / web-filter stuff (things like <really
long b64(?) encoded string>.sophosxl.com or <some opaque
string>.avts.mcafee.com), and some "obviously" broken queries
www.www.www.www.www.www.www.www.www.cnn.com)
So, while looking at this I stumbled across something, um, odd...
wkumari@vimes:~$ dig ns +noall +comments apple.com.akadns.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27395
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
'kay...
wkumari@vimes:~$ dig ns +noall +comments com.akadns.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3341
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
Er... wouldn't this break with qnm? (obviously fixable, but an
interesting data point). It has been a long day, so perhaps I'm
missing something as well...
Yeah, I was thinking about this same concept over the weekend.
Minimalization is definitely a privacy benefit when dealing at the root
and TLD levels, and fortunately those are the easiest cases to detect.
:) I think it's less useful when you've navigated "into" the
domain-holder's space. As y'all know that border is harder to determine
in the ccTLD space.
We already have projects that have bravely gone into these details ...
https://wiki.mozilla.org/Public_Suffix_List comes to mind of course. It
shouldn't be too difficult to code using that information as a third
alternative to "on" or "off" for qnm.
Using that kind of intelligence would go a long way towards reducing the
complaints about qnm adding inefficiency. In fact unless I'm missing
something it would largely eliminate them. There is no benefit to
sending the whole query to the root or TLD servers, and lots of privacy
benefits for not doing so. OTOH, there is a lot of benefit to sending
the whole query to the domain holder's servers, and minimal privacy
negatives. Sounds like a win-win to me.
Doug
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
