[dns-wg] DNS Lameness Checking Proposal

Ed,
   sorry for the late reply on this.

> -----Original Message-----
> From: Edward Lewis [mailto:Ed.Lewis at neustar.biz]
> Sent: Tuesday, August 08, 2006 8:21 PM
> To: Brett Carr
> Cc: dns-wg at ripe.net
> Subject: Re: [dns-wg] DNS Lameness Checking Proposal
> 
> At 3:37 PM +0200 8/8/06, Brett Carr wrote:
> >As per the dns-wg Action point 52.3 from RIPE 52
> >
> >"post questions and proposal to wg mailing list on how to deal with
> >lame delegations when either the NCC is responsible for maintaining
> the
> >parent or for running a (secondary) server for the child that is or is
> >about to become delegated lame due to an unavailable *xfr source."
> >
> >Please find attached "dnslamecheckAug2006.txt" a proposal on how the
> >RIPE NCC should test for lameness and what the resulting actions could
> be.
> >
> >Your feedback and discussion on this proposal is welcomed.
> 
> I can't resist dwelling in lameness.
> 
> I'll throw out a few ideas at a non-detail level.
> 
> One is that I'd like to see a plan to measure the success of the
> efforts.  More or less, how big is the problem and what dent is being
> made.  This will help decide if the work is worth the payoff.

I have added to the document that we will assess the effectiveness of the
checks periodically. I didn't think it was appropriate for this document to
state any more detail than that for now.

> 
> Two is to clear up "one email per server."  The average number of zones
> per server is higher in the reverse space than forward space (a /20
> translates into a bunch of /24's).  I think you should look at what you
> want to present to an admin from their point of view.  Not just for
> their benefit, but also to make interactions more manageable for you.
> 

I've also clarified this a little more in version 2 of the document,
hopefully available next week.

> I think is it beneficial to just observe and report lameness, maybe
> there's no need to remove lame delegations for this to have a benefit.
> I don't see any mention of what the plan is for zones that remain lame.
> Do you just want to let them be, or do you want to "enforce" non-
> lameness?
> 
> Three is remove any specificity about "A or AAAA" - just call them
> address records.  And make it clear that the testing is network-layer
> protocol independent.
> 

Also noted and taken care of in version 2.

> Four is what do you do about failed lookups of address records for name
> servers?  Like, no response as opposed to NXDOMAIN?  Without an IP
> address, you may still have to track a lame NS record, as opposed to a
> lame NS-A[AAA] combination.
> 

We will still attempt to contact the admin of the server (hopefully from
contact information in the SOA record of the domain) if the domain no longer
exists at all then I think we will only be able to report this to the owner
of the delegation.

> Five, what about anycasted servers?  It's possible that a zone may have
> no available servers in some regions (because of routing effects), but
> be okay in other locations.  Will all testing be done from one
> location?

I've added something about anycasting to the new document aswell. Initially
at least all testing will be done from Amsterdam, of course we can consider
expanding this in the future if the need and demand is there.

Regards

--
Brett Carr                              RIPE Network Coordination Centre
Systems Engineer -- Operations Group    Amsterdam, Netherlands
GPG Key fingerprint = F20D B2A7 C91D E370 44CF  F244 B6A1 EF48 E743 F7D8