Re: Single-key rollover

2012-06-19 Thread Mark Andrews
In message , Alexander Gurvitz writes: > > > > > > That paragraph from 4.1.4 is just plain wrong and following it will > > lead to cached data that can't be validated once retrieved. > > > > Lets say that all data in the zone has a TTL of 3600. > > > > At T - 3500 you have retrieved the DNSKEY wh

Re: Moving DNS out of non-cooperative provider

2012-06-19 Thread John Miller
Thanks to everyone for their help with this, and I didn't even start the thread! I definitely hadn't considered the issue of external CNAMES or their ramifications. RCN's now returning SERVFAIL for us, which is still a bit weird (most everyone answers with REFUSED for other people's domains),

Re: Moving DNS out of non-cooperative provider

2012-06-19 Thread Barry Margolin
In article , Tony Finch wrote: > Mark Andrews wrote: > > In message <4fdf631a.4060...@brandeis.edu>, John Miller writes: > > > > > > We've actually run into this before. Once upon a time, RCN cable used > > > to run some slave servers for us, but we've long since moved away from > > > them, in

Re: Moving DNS out of non-cooperative provider

2012-06-19 Thread Tony Finch
Mark Andrews wrote: > In message <4fdf631a.4060...@brandeis.edu>, John Miller writes: > > > > We've actually run into this before. Once upon a time, RCN cable used > > to run some slave servers for us, but we've long since moved away from > > them, including zone transfers. We yanked them from o

Re: Moving DNS out of non-cooperative provider

2012-06-19 Thread Alexander Gurvitz
> > 3282. [bug] Restrict the TTL of NS RRset to no more than that > >of the old NS RRset when replacing it. >[RT #27792] [RT #27884] > Just to clarify - does this rule applies also while replacing parent NS records with (more credible) ch

Re: Moving DNS out of non-cooperative provider

2012-06-19 Thread Alexander Gurvitz
Mark, > 3282. [bug] Restrict the TTL of NS RRset to no more than that >of the old NS RRset when replacing it. >[RT #27792] [RT #27884] "TTL of the old NS RRset" here means the current "remaining" TTL, or the original TTL value as recei

Re: Single-key rollover

2012-06-19 Thread Alexander Gurvitz
> > > That paragraph from 4.1.4 is just plain wrong and following it will > lead to cached data that can't be validated once retrieved. > > Lets say that all data in the zone has a TTL of 3600. > > At T - 3500 you have retrieved the DNSKEY while validating a MX RRset. > At T - 100 you lookup a A re

Re: Moving DNS out of non-cooperative provider

2012-06-19 Thread Phil Mayers
On 06/19/2012 04:18 AM, Barry Margolin wrote: Didn't this used to be a problem? When the caching server queries the cached nameservers, the response would include the old NS records in the Authority section. The caching server would then replaced the cached NS records with these records, reset