Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Brian Dickson <[e-mail]>]

On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews <[e-mail]> wrote:

>
> In message <[e-mail]>, Ted Lemon
> writes:
> >
> > On Feb 8, 2017, at 1:02 AM, Mark Andrews <[e-mail]> 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.
>
>
So, while technically the instruction (SHOULD NOT) applies to full .onion
names,
it is a SHOULD NOT, not a MUST NOT.

Again, technically, the bit of code to do the following, IMHO, nears the
level of "trivial":
- upon startup, do a query for "onion" (the non-existent TLD), with DO=1.
- cache the response, and as appropriate, re-query periodically.
- If a query for <anything>.onion is received, reply with the authenticated
denial of existence from the root (cached in step 2)

I believe this should prevent any SERVFAIL or BOGUS.

(I think this turns on the pedantic reading of "generate".)



> 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.
>

See above; maybe the text of alt-tld should be less prescriptive, and
instead use aggressive-negative compatible language (including use of
legitimate, signed denial of existence RRsets).

Brian



>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>