Re: [dnsext] perhaps we should reintroduce "resimprove"

On Feb 10, 2012, at 7:23 AM, Olafur Gudmundsson wrote:
> For Credibility Greater ">"  the following options make sense
> 	Store, Replace
> 
> For Credibility Equal "="   the following options make sense
> 	Ignore, Delete
> 
> For Credibility Less "<"
> 	Ignore
> 
> If you do Replace on NS on "=" you get ghost domains, because
> NS set and Glue are the only data that resolver will see in an answer that it potentially has in cache.
> If you insist on allowing "Replace" on equal then you MUST implement "Fetch NS from child" and "Fetch all glue" to combat the ghost domains and still have Kaminsky defense.

One other option:
replace-with-min-TTL:  A replacement cache entry's new TTL is min(current TTL on the entry, new TTL).

The problem with ghosted domains is not changing the NS RRSET, its that changing the NS RRSET is also resetting the TTL.  Yet given "Newer vs older data of the same credibility", isn't newer more meaningful (apart from the stickyness problem)?

But changing "replace" with "replace-with-min-ttl" means you're conservative on timeout in the case of disagreement between old and new.

And overall, I think replace-with-min-TTL should be standardized. Because even "Credibility > replace" can have a problem:  The parent wants a deliberate shorter TTL for the NS set, but the child can override it.  

For example, .com wants a 2 day TTL, but the child overrides it with a 7 day TTL, which still gives a 7-day 'no-revocation' window for any preseeded domains.  This could be even worse for various dynamic DNS services which allow delegation.

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext