DNS Lameness Checking Proposal
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. Brett Carr. -- 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
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. 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 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. 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. 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? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America.
Ed, sorry for the late reply on this.
-----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Tuesday, August 08, 2006 8:21 PM To: Brett Carr Cc: dns-wg@ripe.net Subject: Re: [dns-wg] DNS Lameness Checking Proposal
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
At 3:37 PM +0200 8/8/06, Brett Carr wrote: 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
Brett,
Your feedback and discussion on this proposal is welcomed.
If a server fails this test, it will be retried five times over ten days before it is deemed to be 'lame'. Make these tests (and document it accordingly) at different times of the days, to minimize coinciding with (periodical) name server reloads. Regards, Marcos
-----Original Message----- From: Marcos Sanz/Denic [mailto:sanz@denic.de] Sent: Friday, August 18, 2006 3:47 PM To: Brett Carr Cc: dns-wg@ripe.net Subject: Re: [dns-wg] DNS Lameness Checking Proposal
Brett,
Your feedback and discussion on this proposal is welcomed.
If a server fails this test, it will be retried five times over ten days
before it is deemed to be 'lame'.
Make these tests (and document it accordingly) at different times of the days, to minimize coinciding with (periodical) name server reloads.
Regards, Marcos
Duly noted and added to version 2 of the document. I will send this to the dns-wg next week. Thanks -- 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
participants (3)
-
Brett Carr -
Edward Lewis -
Marcos Sanz/Denic