October 2009 - dns-wg - mailman.ripe.net

DNSSEC - DS RR provisioning
by Edward Lewis 17 Nov '09

17 Nov '09

I have a short time slot to discuss these slides on Thursday, http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads/presentatio… but I want to try to get comments from people ahead of time. The presentation is trying first collect requirements, not present a solution to a problem in DNSSEC management. Most of the discussion I have had on this is with a smallish circle of people involved in TLD registry operations which I fear is not inclusive enough. In case you don't want to go through the slides, I'd like to ask these questions: 1. If you are planning to receive DS records for any reason, how do you plan to do it? (You don't have to be a TLD to need to do this.) 2. If you are operating DNS for people and are considering DNSSEC, have you thought about how the DS record will be passed to your customers' zones parents? 3. If you operate a recursive server, where to do plan to get DNSSEC public keys (for example, ISC's DLV)? Although I have just 15 mins to run through the 35-odd slides, I really want to get input from various people while RIPE is in session - or via email. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.

10 13

RIPE 59 minutes
by Jim Reid 27 Oct '09

27 Oct '09

Here are the draft minutes from the Lisbon meeting. Thanks to Emil for taking comprehensive notes from the extensive discussions which took place. Please get in touch if you have corrections or updates to the minutes. And, as always, any comments are welcome.

1 0

Solving lameness in the reverse zones
by Shane Kerr 23 Oct '09

23 Oct '09

All, DNS Lameness Philosophy ----------------------- There are two fundamentally different philosophies about lameness in reverse DNS. The first (mine): DNS misconfiguration - lameness in this case - is bad when it causes operational problems for a human being somewhere. This may be a network administrator, or a system administrator, or an end user. The second: Lameness is bad because the maintainers of the zone data (the RIPE NCC and the administrator of the reverse domain) have a responsibility to keep this information correct. Proposals Based on Reducing User Pain ------------------------------------- Because I wrongly assumed that there was only one way to think about lameness, I made a set of proposals to how we deal with lameness in the reverse delegation at the RIPE meeting in Lisbon: 1. Stop mass-mailing to lame delegations 2. Include lameness information in an annual report to LIRs (possibly a good thing to have along with the annual bill anyway) 3. Perhaps check for the lame delegations causing the worst problems and send targeted mails based on those These suggestions were based on my philosophy that lameness is bad only inasmuch as it causes problems for actual human beings. So, that is one set of proposals. Proposal Based on DNS as a Platonic Form ---------------------------------------- I thought about it, and if we as a community decide that the 2nd philosophy is more appropriate, then our current strategy of asking people nicely to please fix the problems is ridiculous. A lame delegation is at best worthless, and often harmful. We can find lame delegations with very high certainty. The delegation is the responsibility of the parent as well as the child. So, I propose we modify the current process to work something like this: 1. Tell users that their delegations are lame. 2. Wait, then tell them again if not fixed. 3. Wait, then PULL THE DELEGATION if not fixed. If having clean data is important, lets stop with these half-measures, and do it right. Speaking only if we decide that we believe in clean data as a goal, of course. :) -- Shane

5 7

New rules for reverse domain object creation in the RIPE Database
by Denis Walker 22 Oct '09

22 Oct '09

Dear Colleagues, Please find below a proposal for additional checks on creating reverse delegation DOMAIN objects. Regards, Denis Walker Business Analyst, Database Group RIPE NCC Introduction ------------ At RIPE 59 in Lisbon, it was suggested to the DNS Working Group to extend the rules covering the creation of reverse delegation DOMAIN objects. The proposed additional rules are very simple: - If a parent (less specific) DOMAIN object exists at any level, do not allow creation of a child DOMAIN object. - If a child (more specific) DOMAIN object exists at any level, do not allow creation of a parent DOMAIN object. Apply these rules to both in-addr.arpa and ip6.arpa DOMAIN objects. Consequences ------------ If the parent exists, there is no benefit in creating child objects. So we keep the RIPE Database clean and free of objects that have no operational benefit. If the child exists, it is not possible to simply create a parent object and overrule the child object, maybe without even realising it exists. The child object will have to be deleted before the parent object can be created. In the event that an existing child object prevents the creation of a parent object, causing operational problems, the RIPE NCC will assist LIRs to resolve the issue. Cleanup ------- Currently, there are approximately 15,000 child objects that have an overruling parent object. These child objects have no operational effect. We propose to delete these child objects. Maintainers will be notified of the intention to delete the objects. The objects will then be deleted one month later. In order to allow simple searching up and down the address space, any DOMAIN objects for IPv4 /8s and IPv6 equivalents that currently exist in the RIPE Database will be deleted. Again, these objects have no operational benefit. Results ------- The RIPE Database will only contain reverse delegations for allocations and assignments at LIR and End User levels. There will be no overlaps or hierarchies. All DOMAIN objects will be operationally effective.

1 0

WG response to root scaling studies
by Jim Reid 21 Oct '09

21 Oct '09

<WG co-chair hat on> Colleagues, we're on the brink of some major changes to the root server system. ICANN may well take some landmark decisions on this at their meeting at the end of the month. My personal opinion is there is a short (and closing) window for the WG to influence the decisions that may be taken in Seoul. Although yesterday's discussion on the root scaling studies at the WG raised a number of issues, I didn't get a sense that the WG was coalescing around a particular point of view. So here are my questions: [1] Do you think we should try to send some sort of statement to ICANN that could be fed into its decision-making machinery? Should this be done for the Seoul meeting? [2] If the answers to [1] are "yes" what sorts of things should be in that statement? [3] If the answers to [1] are no, is there anything that this WG should be doing about making some response to the scaling study reports? Please note too that some of the usual suspects amongst the WG members may be unable/unwilling to comment publicly because of potential conflicts of interest. <WG co-chair hat off>

6 16

Thanks for RIPE 59
by Jim Reid 19 Oct '09

19 Oct '09

Colleagues, I have to say thanks to the people who gave presentations at the DNS WG in Lisbon and who participated in the discussions. The WG sessions in Lisbon were particularly lively. This wouldn't have been possible without the contributions. So thanks are due to them. Thank you.

1 0

Re: [dns-wg] a historical perspective on DNS lameness
by B C 15 Oct '09

15 Oct '09

On Wed, Oct 14, 2009 at 5:05 PM, Edward Lewis <Ed.Lewis(a)neustar.biz> wrote: > At 15:55 +0100 10/13/09, B C wrote: > > I'm not sure I really understand your point here, >> > > I forget if I answered this, it's been very busy at home since I returned - > the context of my post was a follow up to Shane's presentation on RIPE-400 > at the last RIPE DNS WG meeting. > > Aha, I wasn't at the meeting and couldn't catch the webcast, I'll take a look at the replay. Thanks for the clarification Ed. Brett

1 0

Re: [dns-wg] a historical perspective on DNS lameness
by B C 13 Oct '09

13 Oct '09

Ed, On Thu, Oct 8, 2009 at 6:23 PM, Edward Lewis <Ed.Lewis(a)neustar.biz> wrote: > 1. RFC 1912 has this definition: > > A lame delegations exists when a nameserver is > delegated responsibility for providing nameservice for a zone (via NS > records) but is not performing nameservice for that zone (usually > because it is not set up as a primary or secondary for the zone). > > I would agree with the definition, I'm not sure whether I would 100% agree with the 'usually because' I think it can be for a number of reasons and I don't think anybody has looked into this in an detail. Misconfiguration or communication issues could equally be to blame as 'no configuration' > Note - a remote party can only detect the situation if the server in > question responds to a query, that is, if: > > the server has no IP address, > the IP address is unreachable, > the query drops on the way there, > the response drops, > the server simply won't answer, > or etc., > the remote party does not have the evidence to conclude lameness. > > A common confusion made is that misconfigured delegations are lame, but > that is not the case. The distinction will be important later on. > > 2. There is no specified protocol response to indicate that a server is not > set up to answer the question, nothing in the RFC's, You can say this is > the root cause of the failure - an old, old version of BIND decided to > return a referral "upwards" (as to the root or maybe the TLD) to be kind of > helpful. This kind act turned out to be the problem when... > > 3. An implementation of an iterative resolver was released that "believed" > the upwards referral and would follow it. (The implementation was widely > distributed, legend said it was a MS release in about 2000. But I can't > confirm that.) What this meant is that a lot of resolvers would query the > root, then a TLD, then a SLD and then be referred back to the root and keep > on cycling. That was the operational impact that lead to... > > 4. ARIN policy 2002-1 which told ARIN staff to go off an stamp out lame > servers. (This is where I came into the picture.) The purpose was to stop > this cycle of activity, but by the time the policy got in place the software > was patched pretty much out of existence and the operational pain lessened. > Thats quite interesting I had no idea that was the reason behind the ARIN policy I thought it was for a similar reason to the RIPE one which basically was a desire to ensure the reverse tree was as clean and functional as possible. > > 5. At RIPE 45 I presented ( > http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-testing-…) > which has some interesting bullets and slides that are still pertinent today > on the process of dealing with lameness. When I presented this, ARIN had a > high lame rate and RIPE a low one, due largely to early registration mishaps > and the difference in the timing of ARIN and RIPE "cutting" a delegation for > a new assignment. > > 6. At some time RIPE adopted a lame inspection policy. I don't have a > personal recollection of this. http://www.ripe.net/ripe/docs/ripe-400.htmlis the policy definition, I had left ARIN by then and wasn't as aware of > what was going on then in the RIPE region. > > Indeed I was the author of said document (following input from the RIPE community of course) I do seem to remember discussing this with you at the time the policy was going through the WG, but I think it was more related to what methodology you had used to detect the lameness rather than the reason for doing it. > So - what perspective I am trying to say here is - "lame" per se refers to > name servers that led software into a loop which is why they were a problem > for ARIN. This is why today you probably won't measure the impact of > "misconfigured" delegations (which is what RIPE-400 calls lame) by > inspecting traffic. The question of the value of RIPE-400 then turns into > being one of database cleanliness. > > I'm not sure I really understand your point here, If an LIR has entered some data into the DB which it believes to be correct but it (or its friends) have misconfigured (or not configured) the servers then I would regard the DB to be clean and that the server's need fixing. Either way I would regard notification of the problem to the LIR to be a good thing. Brett >

2 1

a historical perspective on DNS lameness
by Edward Lewis 08 Oct '09

08 Oct '09

1. RFC 1912 has this definition: A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone). Note - a remote party can only detect the situation if the server in question responds to a query, that is, if: the server has no IP address, the IP address is unreachable, the query drops on the way there, the response drops, the server simply won't answer, or etc., the remote party does not have the evidence to conclude lameness. A common confusion made is that misconfigured delegations are lame, but that is not the case. The distinction will be important later on. 2. There is no specified protocol response to indicate that a server is not set up to answer the question, nothing in the RFC's, You can say this is the root cause of the failure - an old, old version of BIND decided to return a referral "upwards" (as to the root or maybe the TLD) to be kind of helpful. This kind act turned out to be the problem when... 3. An implementation of an iterative resolver was released that "believed" the upwards referral and would follow it. (The implementation was widely distributed, legend said it was a MS release in about 2000. But I can't confirm that.) What this meant is that a lot of resolvers would query the root, then a TLD, then a SLD and then be referred back to the root and keep on cycling. That was the operational impact that lead to... 4. ARIN policy 2002-1 which told ARIN staff to go off an stamp out lame servers. (This is where I came into the picture.) The purpose was to stop this cycle of activity, but by the time the policy got in place the software was patched pretty much out of existence and the operational pain lessened. 5. At RIPE 45 I presented (http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-testing-…) which has some interesting bullets and slides that are still pertinent today on the process of dealing with lameness. When I presented this, ARIN had a high lame rate and RIPE a low one, due largely to early registration mishaps and the difference in the timing of ARIN and RIPE "cutting" a delegation for a new assignment. 6. At some time RIPE adopted a lame inspection policy. I don't have a personal recollection of this. http://www.ripe.net/ripe/docs/ripe-400.html is the policy definition, I had left ARIN by then and wasn't as aware of what was going on then in the RIPE region. So - what perspective I am trying to say here is - "lame" per se refers to name servers that led software into a loop which is why they were a problem for ARIN. This is why today you probably won't measure the impact of "misconfigured" delegations (which is what RIPE-400 calls lame) by inspecting traffic. The question of the value of RIPE-400 then turns into being one of database cleanliness. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.

1 0