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

["Blacka, David" <[e-mail]>]

On Feb 10, 2012, at 3:08 PM, Olafur Gudmundsson wrote:
>> 
>> 
>> 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)?
>> 
> TTL stretching was a REAL BAD idea, and must be stamped out.

What do you mean by "TTL stretching"?  Are you inventing new DNS terms?

> 
>> But changing "replace" with "replace-with-min-ttl" means you're conservative on timeout in the case of disagreement between old and new.
> 
> I prefer that resolver perform Delete rather than this, that forces the resolver to reevaluate the delegation.

So, every time a zone operator modifies the apex NS RRset, resolvers around the world instantly (as they query the zone for positive answers) invalidate the cached NSs and go back to the parent.  That seems like suboptimal behavior to me.

> In the case of resolver that does "Fetch NS" upon seeing the referral and adheres to RFC2181 credibility rules, it will always ignore NS set in authority section.

Fair enough, but why do I have to do that extra query in order to solve this problem?

> If a zone wants changes to propagate quickly it should use a smaller TTL. Resolvers should implement a MAX TTL both to purge old data faster, and to adopt faster to changes.

Agreed.  However, I don't think there is any advice what a good max TTL value should be.  2 days? 7 days?

>> 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.
>> 
>> 
> well in the case of TLD's the TTL on referrals ranges from 600 (10min) to 345600 (4 days)  with 1 day as the median value and most common one.
> Based on a sample of 180 google.<TLD> domains out of 310 TLD's.
> 
> Do you want everyone that has a parent with 600-3600 TTL on parent side NS records to force that policy on all their children?

I don't, at least.  I'd like to preserve as much of the current DNS behavior here as we can (thus, I really don't like the bailiwick rule that the paper authors recommend, since it will force all zones to be parent-centric, which is a major change to current behavior.)

I would think that if the rule was:

Credibility >
   Replace, update TTL
Credibility ==
   Replace, keeping existing TTL

then you would get the desired behavior.  That is, the first NS RRset from the child would update the RRset as normal, allowing the child to have a different NS RRset and whatever TTL they choose.  And when the child changes their NS RRset, it propagates at the same speed it does today (faster than the TTL expiration).  But the resolver will always revaluate the parent delegation after at most 2 TTL intervals.

--
David Blacka                          <[e-mail]> 
Principal               Verisign Infrastructure Engineering

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext