[I accidentally hit "Reply", not "Reply all" earlier, and sent the below just to Duane. (mentioning because I cut and pasted into this email, and it may have mucked up quoting / formatting ]
On Thu, Feb 25, 2016 at 6:25 PM Wessels, Duane <[email protected]> wrote: > > > > On Feb 25, 2016, at 3:12 PM, John R Levine <[email protected]> wrote: > > > >> In other words, today (as a BIND user) you might only have to wait 3 hours > >> when a new TLD is added, not the whole SOA minimum. > > > > Given that new TLDs publish a 127.53.53.53 wildcard for a month to try and > > show people where they have collisions, I'd think the root's one day TTL > > would be the least of your problems. > > I don't disagree, but the document seemed to be saying that the TTL was > one day either way. Yup, the document does say that (although it words it poorly - I wrote this bit of text in a rush). > > > > > >> For implementations that treat "positive" and "negative" cache entries > >> separately, perhaps the document should say whether a validated proof of > >> non-existence should be considered "positive" or "negative." I think that implementations which treat "positive" and "negative" cache entries separately have made an implementation choice, and it is not our place to say which cache they should go in, merely the behavior that we want. I suspect that that is what you are asking for? > > > > > How could it be other than negative? It signals an NXDOMAIN to the > > ultimate client? > > > An argument could be made that the NSEC records positively exist and would be > cached for > their full TTL. Quoting the draft: > > > 3. Generating negatives responses from NSEC > > ... > > So, if a resolver generates negative answers from an NSEC record, it > will not send any queries for names within that NSEC range (for the > TTL). If a new name is added to the zone during this interval the > resolver will not know this. I think that we are having a terminology / implementation disagreement, and that the "positive" / "negative" terms are confusing. I was intended what Duane said - you do this for the TTL of hte NSEC record. So, in the case of: beer. 86400 IN NSEC bentley. NS DS RRSIG NSEC you will generate NXDOMAINs for .belkin for 86400 seconds. I had not considered (and so not specified!) the behavior if you do max-ncache-ttl. I could see us saying: 1: The NSEC record says that nothing exists *for the TTL of the record*, so do this for the TTL of the record. 2: Follow the minimum of negative cache time in the SOA / max-ncache-ttl. I was intending to say #1, but I can see a case for #2 (the root zone NSEC TTL / SOA TTL *currently* match, so the deciding factor in #2 would be max-ncache-ttl). I'm (of course) happy to put whatever people want in here. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
