In message <e0a42577-0984-4add-8658-91413cbe7...@fugue.com>, Ted Lemon writes:
>
> On Feb 8, 2017, at 1:02 AM, Mark Andrews <ma...@isc.org> wrote:
> > Which assumes agggressive negative caching. I'm going to make a
> > realistic assumption that it will take 10+ years for there to be
> > meaningful (>50%) deployment of aggressive negative caching.
>
> First of all, this probably isn't true, since most of the caches we care
> about are run by network operators, who tend to update more frequently
> for obvious reasons. But the solution you propose, which causes a
> SERVFAIL, involves a specially-prepared resolver. So if you get to
> _create_ the problem with a specially-prepared resolver, I get to solve
> it with a differently specially-prepared resolver. If you want queries
> to .alt not to leak, you have to preload your cache with a proof of
> nonexistence for .alt, and you have to keep it up to date. This is not
> terribly difficult to arrange.
>
> >> Leaking a query to .alt is harmless.
> >
> > Is it? What reports are we going to see over the next 20 year of
> > DITL data on *.alt.
>
> How is that relevant? Suppose we don't create .alt, and instead people
> just pick random top-level domains for their experiments, as they do now.
> Will the number of bogus queries to the root be greater, or fewer?
> Furthermore, queries for .alt are legitimate, in just the same way that
> queries for .com are. They just have a different answer.
Me, I'm trying to prevent the SERVFAIL issues the IETF has created for
.onion. In particular this from RFC7686
4. Caching DNS Servers: Caching servers, where not explicitly
adapted to interoperate with Tor, SHOULD NOT attempt to look up
records for .onion names. They MUST generate NXDOMAIN for all
such queries.
Without .onion being a insecurely delegation this results in SERVFAIL
or BOGUS being returned for .onion named when validation is performed
by any validating software that is not RFC7686 aware.
Nameserver vendors have a choice. Follow RFC7686 and have their
clients get a answer that they know cannot be validated or ignore
this clause and pretend that RFC7686 has never been written so that
their client get a validatable answer. Should the IETF have put
Nameserver vendors in this position?
At this stage we have not yet implemented this clause in BIND. We
are aware of RFC7686 and at some point someone will complain that
we don't implement this. At that point we will point out to them
that this results in SERVFAIL or bogus being returned.
Note all through the debate about .onion I raise this issue. Go
look at the archives.
Now draft-ietf-dnsop-alt-tld-07 has almost identical wording
4. Caching DNS servers SHOULD recognize these names as special and
SHOULD NOT, by default, attempt to look up NS records for them,
or otherwise query authoritative DNS servers in an attempt to
resolve these names. Instead, caching DNS servers SHOULD
generate immediate negative responses for all such queries.
This clause results in BOGUS or SERVFAIL being returned to the DNS
application if there is a validator in the return DNS path between
the caching DNS server and the application.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
