On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews <ma...@isc.org> wrote: > > 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. > > 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: +61 2 9871 4742 INTERNET: ma...@isc.org >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
