In message <20170617024428.62388.qm...@f3-external.bushwire.net>, "Mark Delany"
writes:
> > >> DNS does not provide the sort of intelligence necessary to direct
> > >> requests to the most appropriate server
>
> > > Huh? A DNS can be as intelligent as it wants to be.
>
> > +1. For example, EDNS
> <https://ripe67.ripe.net/presentations/206-L-dnswg-Streibelt-ClientIP.pdf>
>
> Certainly edns client-subnet improves accuracy for multi-region ISPs
> and clients which use public resolvers. But really that's just a
> better input into the intelligent answer generation process of an
> auth.
>
> Unfortunately support is not wide-spread and the most popular open
> resolvers (namely google and opendns) require whitelisting before they
> will present the option to auths. That's a bit of a hurdle.
Given how poorly some authoritative servers handle unknown EDNS
options there is little wonder Google whitelists servers that it
will send ECS to. Here is how authoritative servers for Australian
zones mishandle unknown EDNS options.
https://ednscomp.isc.org/compliance/ts/au.optfail.html
https://ednscomp.isc.org/compliance/au-report.html
You have about:
0.5% of servers that just drop the queries.
1.65% of servers echo back the option.
2.5% of servers returning FORMERR.
While there are no servers return BADVERS for the sampled .AU set
they do still exist in other samples. These server could have been
ignored if were in a position to do a EDNS version increment when
RFC 6891 was issued to tighten the unknown EDNS option behaviour
but the numbers of servers that mishandle EDNS version negotiation
was much worse than those that mishandle unknown EDNS options. Over
half of the servers for .AU zones mishandle EDNS version negotiation
and it is getting worse, rather than better.
https://ednscomp.isc.org/compliance/ts/au.edns1fail.html
(without a unknown EDNS option)
https://ednscomp.isc.org/compliance/ts/au.opt1fail.html
(with a unknown EDNS option)
Firewall vendors that decided that they need to drop any DNS packet
that attempts to do EDNS version negotiation are a big part of the
problem here.
> One complaint I hear from ISPs is that client-subnet puts a lot more
> memory pressure on their caches - which makes sense. And of course
> there are very few cache implementations anyway, either open source or
> commercial. For both reasons, resolver-side support is not very
> wide-spread yet.
It does, and it isn't helped by authoritative servers that just
echo the option back without supporting ECS (why anyone would decide
to send unknown EDNS options in a response is beyond me, it definitely
doesn't meet the "be conservitive in what you send"). Doing so
just results in extra cache entries unnecessarially.
> So, all in all client-subnet is useful, but higher adoption would be
> nice.
>
>
> Going a little OT, one of the more intriguing aspects of client-subnet
> is that it help DNS queries go dark. What with DNS over HTTPS, google
> already running a public resolver and Apple announcing a DNS provider
> framework in iOS11, it's not beyond imagination that the major mobile
> OSes might well support tunnelling DNS queries to a "trusted" resolver
> in the not-to-distant future and leave local ISPs and meddling
> governments out of the loop.
>
> In this content, client-subnet lets GSLB perform accurately even when
> the query is issued from a possibly distant resolver. Otherwise,
> tunnelling queries can have way sub-optimal results when interacting
> with GSLBs.
>
>
> As an aside, a more recent reference is https://tools.ietf.org/html/rfc7871
>
>
> Mark.
> _______________________________________________
> AusNOG mailing list
> AusNOG@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog
