From Ed.Lewis at neustar.biz Mon Oct 5 16:52:06 2009 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 5 Oct 2009 15:52:06 +0100 Subject: [dns-wg] DNSSEC - DS RR provisioning Message-ID: I have a short time slot to discuss these slides on Thursday, http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads/presentations/Thursday/DNS%20WG%2011:00/Lewis-Topic_DNSSEC_Ops_Problem_SEP_Provisioning.IvCH.pdf 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. From paf at cisco.com Mon Oct 5 18:32:57 2009 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 5 Oct 2009 17:32:57 +0100 Subject: [dns-wg] DNSSEC - DS RR provisioning In-Reply-To: References: Message-ID: On 5 okt 2009, at 15.52, Edward Lewis wrote: > In case you don't want to go through the slides, True,...sorry... > 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.) As a registrar, via a home-brew protocol. netstring encoded json structures. Simpler than the epp extensions. > 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? For the TLDs I am a registrar, via epp. For other TLDs, via some protocol to the registrar of the domain. > 3. If you operate a recursive server, where to do plan to get DNSSEC > public keys (for example, ISC's DLV)? Not a question for me. paf From bmanning at vacation.karoshi.com Mon Oct 5 22:00:03 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Oct 2009 20:00:03 +0000 Subject: [dns-wg] DNSSEC - DS RR provisioning In-Reply-To: References: Message-ID: <20091005200003.GB1900@vacation.karoshi.com.> On Mon, Oct 05, 2009 at 03:52:06PM +0100, Edward Lewis wrote: > I have a short time slot to discuss these slides on Thursday, > > http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads/presentations/Thursday/DNS%20WG%2011:00/Lewis-Topic_DNSSEC_Ops_Problem_SEP_Provisioning.IvCH.pdf > > but I want to try to get comments from people ahead of time. i would have commented earlier, but they were presented in an even more propritary format than PDF. comments forthcoming. > 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.) SYNC protocol. > 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? yes - using SYNC. > 3. If you operate a recursive server, where to do plan to get DNSSEC > public keys (for example, ISC's DLV)? the authoritiatve servers. > > 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. From mansaxel at besserwisser.org Tue Oct 6 09:06:09 2009 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Tue, 6 Oct 2009 09:06:09 +0200 Subject: [dns-wg] DNSSEC - DS RR provisioning In-Reply-To: References: Message-ID: <20091006070609.GC5006@besserwisser.org> Subject: [dns-wg] DNSSEC - DS RR provisioning Date: Mon, Oct 05, 2009 at 03:52:06PM +0100 Quoting Edward Lewis (Ed.Lewis at neustar.biz): > 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.) N/A > 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? Manually. I sign the zones and publish the DS via to customer who is responsible for DS submission. Not good, I agree, but for now will have to do. > 3. If you operate a recursive server, where to do plan to get DNSSEC > public keys (for example, ISC's DLV)? I keep up with SE manually and otherwise am waiting for ".". -- M?ns Nilsson From Antoin.Verschuren at sidn.nl Tue Oct 6 13:30:14 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Tue, 6 Oct 2009 13:30:14 +0200 Subject: [dns-wg] DNSSEC - DS RR provisioning References: Message-ID: <850A39016FA57A4887C0AA3C8085F9490131C50C@KAEVS1.SIDN.local> > -----Original Message----- > From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of > Edward Lewis > Subject: [dns-wg] DNSSEC - DS RR provisioning > > 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. I First have a remark on the assumptions that many have about the registry-registrar-registrant model, that is implemented differently in various TLD's. When the RRR model was introduced in .nl in 1996, it was meant to only solve the administrative hurdles of a registry having to talk to many registrants, which was a practical communication matter. There is a difference in a thin and thick registry here, but the RRR model was never meant to solve the technical relationship between a parent and child that exists by definition. My answers are made with this background. > 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.) As a registry, I would like to receive technical updates to the DNS trough a secure channel, directly from, or in sync with the child zone. Since a secure channel does not exist during bootstrapping, I would accept the bootstrapping through the initial administrative channel (EPP or any other administrative initiation) and I would like the updates to use the fastest possible secure channel without manual intervention. I would like the DNS tree under my TLD to be correct. I would not allow interception of the technical updates due to business rules if that would make the DNS less stable or reliable. I would like to implement an update method that could be universally deployed to facilitate any DNS-operator operator of a child zone to use for as many parents as possible. As a general parent, (DNS-operator), not being a TLD, I would like this syncing to be done the same, with a single standard, preferably in the DNS protocol, and not over any EPP or extra external protocol I might not be using. So I would like the update to use the DNS protocol, and I would accept updates directly from the child zone if it has a secure delegation. I would accept DS, NS and glue updates. > 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? As a registrant and DNS-operator, I would like to send updates of my zone directly to the parent without manual intervention. Configuring where to send my updates for a given zone during zone creation will be less work for me than to manually send every update through a RRR interface. As a pure registrar, not being a DNS-operator, I couldn't be bothered less about technical updates. They don't bring in money, don't require communication, but I'm obliged to do work. The only reason for a registar to intercept and pass through technical updates is to be able to control business rules: "If you don't pay, I won't relay your update." Since this is often prohibited by registration rules anyway, I don't see this as a valid reason for interception. > 3. If you operate a recursive server, where to do plan to get DNSSEC > public keys (for example, ISC's DLV)? > "." Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ From paf at cisco.com Tue Oct 6 15:39:04 2009 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 6 Oct 2009 14:39:04 +0100 Subject: [dns-wg] DNSSEC - DS RR provisioning In-Reply-To: <850A39016FA57A4887C0AA3C8085F9490131C50C@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F9490131C50C@KAEVS1.SIDN.local> Message-ID: <81FF51FE-A4E3-4234-B1C4-E054CECA07F4@cisco.com> On 6 okt 2009, at 12.30, Antoin Verschuren wrote: > So I would like the update to use the DNS protocol, and I would > accept updates directly from the child zone if it has a secure > delegation. > I would accept DS, NS and glue updates. Can you expand on this? Using SIG(0) where the public key is signed and in the child zone (for example)? paf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From Antoin.Verschuren at sidn.nl Tue Oct 6 15:54:38 2009 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Tue, 6 Oct 2009 15:54:38 +0200 Subject: [dns-wg] DNSSEC - DS RR provisioning References: <850A39016FA57A4887C0AA3C8085F9490131C50C@KAEVS1.SIDN.local> <81FF51FE-A4E3-4234-B1C4-E054CECA07F4@cisco.com> Message-ID: <850A39016FA57A4887C0AA3C8085F9490131C526@KAEVS1.SIDN.local> > -----Original Message----- > From: Patrik F?ltstr?m [mailto:paf at cisco.com] > Subject: Re: [dns-wg] DNSSEC - DS RR provisioning > > * PGP Signed by an unknown key > > On 6 okt 2009, at 12.30, Antoin Verschuren wrote: > > > So I would like the update to use the DNS protocol, and I would > > accept updates directly from the child zone if it has a secure > > delegation. > > I would accept DS, NS and glue updates. > > Can you expand on this? Using SIG(0) where the public key is signed > and in the child zone (for example)? When there is an existing chain of trust between the parent and child zone, that chain can be used to authenticate changes in the child zone to the parent. So the child signals the parent to query the child zone for changes to the DNSKEY, NS or glue records. Since these records are signed, and the parent can trust the signed content in the child zone, it can update the parent zone with any record that needs to be in there. Syncing the content in the child zone with the content in the parent zone. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren at sidn.nl xmpp:antoin at jabber.sidn.nl http://www.sidn.nl/ From paf at cisco.com Tue Oct 6 16:21:19 2009 From: paf at cisco.com (=?WINDOWS-1252?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 6 Oct 2009 15:21:19 +0100 Subject: [dns-wg] DNSSEC - DS RR provisioning In-Reply-To: <850A39016FA57A4887C0AA3C8085F9490131C526@KAEVS1.SIDN.local> References: <850A39016FA57A4887C0AA3C8085F9490131C50C@KAEVS1.SIDN.local> <81FF51FE-A4E3-4234-B1C4-E054CECA07F4@cisco.com> <850A39016FA57A4887C0AA3C8085F9490131C526@KAEVS1.SIDN.local> Message-ID: On 6 okt 2009, at 14.54, Antoin Verschuren wrote: > So the child signals the parent to query... Any thinking on how that should be done technically? I.e. I like your idea. I just want to know all details :-) Patrik From Holger.Zuleger at hznet.de Tue Oct 6 19:16:25 2009 From: Holger.Zuleger at hznet.de (Holger Zuleger) Date: Tue, 06 Oct 2009 19:16:25 +0200 Subject: [dns-wg] DNSSEC - DS RR provisioning In-Reply-To: References: Message-ID: <4ACB7B69.3070903@hznet.de> > 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.) SIG(0) authenticated DNS updates > 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? I would like to use the same method as above. The initial public key exchange should be done via EPP/RRI or web frontend. > 3. If you operate a recursive server, where to do plan to get DNSSEC > public keys (for example, ISC's DLV)? The manually configured root key where key rollover is handled via RFC5011. From Ed.Lewis at neustar.biz Thu Oct 8 19:23:17 2009 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 8 Oct 2009 18:23:17 +0100 Subject: [dns-wg] a historical perspective on DNS lameness Message-ID: 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-lameness/) 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. From jim at rfc1035.com Fri Oct 9 11:30:26 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 9 Oct 2009 10:30:26 +0100 Subject: [dns-wg] WG response to root scaling studies Message-ID: 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. From bortzmeyer at nic.fr Fri Oct 9 12:02:10 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 9 Oct 2009 11:02:10 +0100 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: References: Message-ID: <20091009100210.GA14408@laperouse.bortzmeyer.org> On Fri, Oct 09, 2009 at 10:30:26AM +0100, Jim Reid wrote a message of 25 lines which said: > I didn't get a sense that the WG was coalescing around a particular > point of view. Indeed. As a matter of process, it is important to keep in mind that many people were not able to speak, for lack of time (we even shortened the coffee break) and queue occupancy by the usual suspects. I had, personally, many things to say. More on that later. > [1] Do you think we should try to send some sort of statement to > ICANN that could be fed into its decision-making machinery? No. > [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? Congratulate the authors of reports where there was actual measurements and data? More hard data is always fine. In the second report, for instance, I learned a lot about the root (the vegetable). From jim at rfc1035.com Fri Oct 9 12:23:02 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 9 Oct 2009 11:23:02 +0100 Subject: [dns-wg] microphone protocol at the WG In-Reply-To: <20091009100210.GA14408@laperouse.bortzmeyer.org> References: <20091009100210.GA14408@laperouse.bortzmeyer.org> Message-ID: <6CEFB2BF-F016-4E6C-9482-126D6A87A952@rfc1035.com> On 9 Oct 2009, at 11:02, Stephane Bortzmeyer wrote: > Indeed. As a matter of process, it is important to keep in mind that > many people were not able to speak, for lack of time (we even > shortened the coffee break) and queue occupancy by the usual suspects. Stephane, everyone at the WG yesterday had the opportunity to go to the microphone. Nobody was turned away or got cut off for lack of time, even though the sessions over-run. So I'm surprised by your complaint/observation. While I accept that others may have wanted to speak, it can hardly be considered a failure of process if they didn't take their turn to queue at the microphones. From jaap at NLnetLabs.nl Fri Oct 9 12:32:50 2009 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Fri, 09 Oct 2009 12:32:50 +0200 Subject: [dns-wg] WG response to root scaling studies In-Reply-To: References: Message-ID: <200910091032.n99AWogp007660@bartok.nlnetlabs.nl> Note thet ICAMM has established a forum area for comments on the report. Be the first to write a comment! jaap From bmanning at vacation.karoshi.com Fri Oct 9 12:43:33 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 9 Oct 2009 10:43:33 +0000 Subject: [dns-wg] WG response to root scaling studies In-Reply-To: References: Message-ID: <20091009104333.GA7632@vacation.karoshi.com.> On Fri, Oct 09, 2009 at 10:30:26AM +0100, Jim Reid wrote: > > 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. > perhaps it is worthwhile to try and note the differences btween the two reports/presentations. OARC did an empirical study - based on snapshots of a given state for -ONE- operators architectural design. RSST crafted their study more along the lines of a Risk Analysis Tool for the root system overall, not just a server instance. Both are useful/needed. The second study alluded to a problem that will be much more visible in the next nine months, the impact of a much larger response size on the ability of nodes to get a response to a priming query. While not a risk per se to the root system, the collateral damage to the rest of the Internet is real and should not be lightly dismissed by those who have been waiting patiently for many years to see the root zone signed. If the WG decided to do anything wrt sending a note to ICANN, it should include some text about the known risk and making the changes anyway. This is a clearly destabilizing event. --bill From brettlists at gmail.com Tue Oct 13 16:55:02 2009 From: brettlists at gmail.com (B C) Date: Tue, 13 Oct 2009 15:55:02 +0100 Subject: [dns-wg] a historical perspective on DNS lameness In-Reply-To: References: Message-ID: <5c494b510910130755i45d11206s6999630b84b983d7@mail.gmail.com> Ed, On Thu, Oct 8, 2009 at 6:23 PM, Edward Lewis 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-lameness/) > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Tue Oct 13 19:03:41 2009 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 13 Oct 2009 13:03:41 -0400 Subject: [dns-wg] a historical perspective on DNS lameness In-Reply-To: <5c494b510910130755i45d11206s6999630b84b983d7@mail.gmail.com> References: <5c494b510910130755i45d11206s6999630b84b983d7@mail.gmail.com> Message-ID: At 15:55 +0100 10/13/09, B C wrote: >I'm not sure I really understand your point here The message was in reaction to Shane Kerr's presentation at RIPE 59. Temporary URL: http://www.ripe.net/ripe/meetings/ripe-59/presentations/uploads//presentations/Thursday/DNS%20WG%2014:00/Kerr-Falling_Trees_or_If_a_DNS_Server_is_Lame_but_Nobody_Queries_It_Why_Send_Mail_.8ADr.pdf J. Lame Delegation Analysis for the RIPE Region - Shane Kerr, ISC - 25' Falling Trees (or If a DNS Server is Lame but Nobody Queries It, Should I Get an Email?) Queries to the RIPE NCC server for reverse DNS were recorded and compared against which name servers are lame. Based on this, we can see which queries are affected by lameness, and how badly. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brettlists at gmail.com Thu Oct 15 10:56:39 2009 From: brettlists at gmail.com (B C) Date: Thu, 15 Oct 2009 09:56:39 +0100 Subject: [dns-wg] a historical perspective on DNS lameness In-Reply-To: References: <5c494b510910130755i45d11206s6999630b84b983d7@mail.gmail.com> Message-ID: <5c494b510910150156i78161714pb33277029fe765b5@mail.gmail.com> On Wed, Oct 14, 2009 at 5:05 PM, Edward Lewis 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Fri Oct 16 12:11:50 2009 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 16 Oct 2009 12:11:50 +0200 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: <20091009100210.GA14408@laperouse.bortzmeyer.org> References: <20091009100210.GA14408@laperouse.bortzmeyer.org> Message-ID: <20091016101150.GA25986@nic.fr> On Fri, Oct 09, 2009 at 11:02:10AM +0100, Stephane Bortzmeyer wrote a message of 29 lines which said: > I had, personally, many things to say. More on that later. OK, apparently, I had less time than anticipated. Anyway, a few comments on the whole "root zone scaling studies" thing: * I liked a lot the OARC report because it is mostly made of hard facts and figures, actual measurements, not vague guesses "This thing could go wrong". * The terms set by ICANN (for instance ) mixes up completely different things, such as: * IPv6 (already done, and working fine despite the FUD that delayed the entry of AAAA records in the root for a long time) * IDN (zero technical consequences for the root, off-topic for a "root zone scaling" report) * DNSSEC (real technical issues) * more TLD (may be a false problem or not, depending on the actual number. I was shocked at the DNS meeting to hear a participant making repeated references to one million TLD, a ridiculous number, that could never be reached, due to ICANN constraints ). So, there is little a technical WG like the DNS WG could say about these reports. The question is so badly phrased that noone can really reply to it. From jim at rfc1035.com Fri Oct 16 13:06:48 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 16 Oct 2009 12:06:48 +0100 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: <20091016101150.GA25986@nic.fr> References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> Message-ID: On 16 Oct 2009, at 11:11, Stephane Bortzmeyer wrote: > * more TLD (may be a false problem or not, depending on the actual > number. I was shocked at the DNS meeting to hear a participant > making repeated references to one million TLD, a ridiculous number, > that could never be reached, due to ICANN constraints Stephane, it's very unwise to make this claim. Yes, 1 million TLDs is ridiculous and very probably unattainable under the current ICANN system. However there was an ICANN paper that last year said "if .com can have ~100M delegations, so can the root". See http://www.icann.org/en/topics/dns-stability-draft-paper-06feb08.pdf . On p4 under "II Capacity of the Root Zone", it says "At a minimum, the DNS should be able to function at its current level with at least 60 million TLDs. This allows significant room for large-scale expansion without concerns about a negative effect on stability." I wonder who wrote that... Now us technical people realise those claims are beyond ridiculous. But when these are presented to non-technical people, the consequences are not pretty. I also stumbled across the comment below (from a French government official BTW) at http://syd.icann.org/files/meetings/sydney2009/transcript-root-zone-scaling-22jun09-en.txt "For, once again, people who are outside of the technical environment, one of the arguments that is often used to say you can have an unlimited number of TLDs is that, basically, it's not that different from the management of a very big registry like dot com that has 80 million domain names. Can you very briefly or point to something that can explain to a relatively layperson, the major difference between the two systems and in particular whether in terms of the rates of updates and the number of distribution of replication of the file, a dot com manager does, how applicable is the analogy or not? Because it's an analogy that we hear a lot in the policy environment." The mindset that ".com can be replicated in the root" is taking root (excuse the pun) in certain ICANN circles. If that view prevails, it's very likely ICANN will get railroaded into devising a TLD creation mechanism to accommodate millions of TLDs. The current proposals for new gTLDs point the way here. The gNSO effectively said "let there be thousands of gTLDs". ICANN management then pretty much said "The community has spoken. We will do what the process determined.". So if/ when the gNSO says "let's have millions of TLDs: we have an ICANN paper which says it's feasible and won't create instability", I would not bet against ICANN staff trying to devise a process to make that happen. From drc at virtualized.org Fri Oct 16 17:35:29 2009 From: drc at virtualized.org (David Conrad) Date: Fri, 16 Oct 2009 08:35:29 -0700 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> Message-ID: Jim, On Oct 16, 2009, at 4:06 AM, Jim Reid wrote: > Yes, 1 million TLDs is ridiculous and very probably unattainable under the current ICANN system. However there was an ICANN paper that last year said "if .com can have ~100M delegations, so can the root". See http://www.icann.org/en/topics/dns-stability-draft-paper-06feb08.pdf. On p4 under "II Capacity of the Root Zone", it says "At a minimum, the DNS should be able to function at its current level with at least 60 million TLDs. This allows significant room for large-scale expansion without concerns about a negative effect on stability." I wonder who wrote that... The paper is not saying that because COM has tens of millions of names that the root MUST have tens of millions of names, rather it is stating that the root, like any other zone in the DNS, can scale to tens of millions albeit there would be operational impact. Two sentences above the quote you provided is the following: "Even if not all of these names are actually propagated to the zone, the size of the .COM zone indicates that it is technically possible to have a zone that has registrations numbering in the tens of millions." > Now us technical people realise those claims are beyond ridiculous. Actually, no. It _is_ technically possible to have tens of millions of names in the root (or any other zone). Given the current system, it would be a stunningly bad _operational_ idea and would require changes to many aspects of root management (e.g., the provisioning side of root zone management would have to be completely replaced, root servers would have to be upgraded to hold 64GB RAM, bandwidth to far off root instances would have to be upgraded, etc.), but it really is _technically_ possible. In fact, the paper you reference specifically states: "The staff has made a distinction between technical instability (that causes direct adverse impact to the DNS) and operational impacts which may not be harmful to the Internet technically, but do impose operational challenges in the management and operation of the DNS." > The current proposals for new gTLDs point the way here. The gNSO effectively said "let there be thousands of gTLDs". ICANN management then pretty much said "The community has spoken. We will do what the process determined.". Can you provide a reason (other than "because I don't like it") that ICANN shouldn't abide by the decision of the open, bottom-up policy development process of the GNSO? > So if/when the gNSO says "let's have millions of TLDs: we have an ICANN paper which says it's feasible and won't create instability", I would not bet against ICANN staff trying to devise a process to make that happen. Two points: 1) many folks in the technical community refuse to get involved in ICANN policy deliberations because they believe it's that icky non-technical political stuff. Unfortunately, this can lead to a lack of technical input into those deliberations, resulting in decisions that can be skewed towards business or political considerations. If the technical community believes a certain outcome would be sub-optimal, I would strongly encourage members of that community to get more involved in policy discussions. 2) ICANN's Bylaws states: "Section 2. CORE VALUES In performing its mission, the following core values should guide the decisions and actions of ICANN: 1. Preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet. ..." Any action by ICANN management is constrained by ICANN Bylaws. The point of the root scaling study was to determine where growth of the root zone would have negative impact on "operational stability, reliability, security, and global interoperability". If the addition of millions of TLDs can be demonstrated to negatively impact operational stability, reliability , security, and/or global interoperability, ICANN staff would _not_ make it happen. Regards, -drc From jim at rfc1035.com Fri Oct 16 18:35:24 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 16 Oct 2009 17:35:24 +0100 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> Message-ID: <95BF2A46-C217-45FB-BB92-4E1F419E4385@rfc1035.com> On 16 Oct 2009, at 16:35, David Conrad wrote: >> Now us technical people realise those claims are beyond ridiculous. > > Actually, no. It _is_ technically possible to have tens of millions > of names in the root (or any other zone). Given the current system, > it would be a stunningly bad _operational_ idea and would require > changes to many aspects of root management (e.g., the provisioning > side of root zone management would have to be completely replaced, > root servers would have to be upgraded to hold 64GB RAM, bandwidth > to far off root instances would have to be upgraded, etc.), but it > really is _technically_ possible. David, you're playing with words. Your argment here is like saying it's technically possible to eliminate world hunger if we gave everyone on the planet enough food. Yes, I suppose anything is technically possible, given infinite amounts of money. And compliance with the laws of physics. But we both know full well that the resources needed to operate the DNS root with millions of TLDs are simply not available. Even if they were, there are plenty of other technical constraints which are not DNS operational considerations on making a root zone of that size. For example: the IANA/NTIA/Verisign three-way handshake or IANA managing communications with million of Sponsoring Organisations, even if these things were fully automated. Of course it's possible to have a zone with millions of delegations. These exist already. Nobody disputes that. At least I hope not. But the stuff you mention above goes nowhere near a complete description of the technical and operational revolution that would be needed to bring about a root with millions of TLDs. From jim at rfc1035.com Fri Oct 16 18:43:44 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 16 Oct 2009 17:43:44 +0100 Subject: [dns-wg] loadsaTLDs and the ICANN policy-making process In-Reply-To: References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> Message-ID: <0F73C9A9-A3CF-4205-83A6-8093B932C0E6@rfc1035.com> On 16 Oct 2009, at 16:35, David Conrad wrote: > Can you provide a reason (other than "because I don't like it") that > ICANN shouldn't abide by the decision of the open, bottom-up policy > development process of the GNSO? You answer that question yourself David. See 1) below. > Two points: > > 1) many folks in the technical community refuse to get involved in > ICANN policy deliberations because they believe it's that icky non- > technical political stuff. Unfortunately, this can lead to a lack > of technical input into those deliberations, resulting in decisions > that can be skewed towards business or political considerations. If > the technical community believes a certain outcome would be sub- > optimal, I would strongly encourage members of that community to get > more involved in policy discussions. What's the point in engaging in a policy discussion about new gTLDs now? That debate appears to be over. You seem to be implying that the decision about that has already been taken -- ie ICANN abiding by the decision the gNSO has reached. Or are you saying that if the technical community says to ICANN (how?) "we think it's a Bad Idea to have lots of new TLDs", ICANN will be receptive to those representations? I think it's not unreasonable to say that although the ICANN processes try to be open, they made/make it difficult for the technical community to participate in a meaningful way. BTW this was one of the reasons why RIPE's "sign the root" declaration in 2007 was sent as a letter to the ICANN CEO and Chairman. There was no obvious ICANN forum which could receive it or act on it. I've been to more ICANN meetings than I'd care to admit to and, apart from Suzanne's board postition, have trouble remembering any DNS operators or implementers who attended them. [Mind you, the copious amounts of beer needed to get through those weeks may have been a contributing factor.] The few technical people who do engage with ICANN on a regular basis usually have their hands tied in one way or another: say membership of an ICANN committee/task force or their employer has a vested interest in seeing new TLDs. Speaking personally, I knew there was no point in advancing a case for fewer new TLDs (not zero) at the gNSO because (a) I'd get shouted down; (b) the other side of the debate could string things out with a battle of attrition until I gave up or ran out of funding; (c) the day job wouldn't allow me to spend time on unproductive and resource- draining ICANN participation. If it was a choice between paying the mortgage and walking around ICANN meetings wearing a sign saying "kick me!", what would you do? From drc at virtualized.org Fri Oct 16 19:41:58 2009 From: drc at virtualized.org (David Conrad) Date: Fri, 16 Oct 2009 10:41:58 -0700 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: <95BF2A46-C217-45FB-BB92-4E1F419E4385@rfc1035.com> References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> <95BF2A46-C217-45FB-BB92-4E1F419E4385@rfc1035.com> Message-ID: Jim, >>> Now us technical people realise those claims are beyond ridiculous. >> Actually, no. It _is_ technically possible to have tens of millions of names in the root (or any other zone). > David, you're playing with words. You referenced a paper written by ICANN staff, implying that in that paper ICANN staff was saying "let's move COM to the root". All I was saying is that that was not what the paper said. I even pointed out that the paper makes a distinction between what is technically feasible and what is operationally feasible. Regards, -drc From drc at virtualized.org Fri Oct 16 20:05:01 2009 From: drc at virtualized.org (David Conrad) Date: Fri, 16 Oct 2009 11:05:01 -0700 Subject: [dns-wg] Re: loadsaTLDs and the ICANN policy-making process In-Reply-To: <0F73C9A9-A3CF-4205-83A6-8093B932C0E6@rfc1035.com> References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> <0F73C9A9-A3CF-4205-83A6-8093B932C0E6@rfc1035.com> Message-ID: Jim, Not really sure this is relevant to DNS-WG, but... On Oct 16, 2009, at 9:43 AM, Jim Reid wrote: > What's the point in engaging in a policy discussion about new gTLDs now? You're suggesting policies can never change once decided? > Or are you saying that if the technical community says to ICANN (how?) "we think it's a Bad Idea to have lots of new TLDs", ICANN will be receptive to those representations? Of course they will, provided they are backed up with data instead of just unsubstantiated opinion. I know it is hard for some folks to believe, but ICANN staff really does take the "ensure security and stability" aspect of what ICANN does quite seriously. > I think it's not unreasonable to say that although the ICANN processes try to be open, they made/make it difficult for the technical community to participate in a meaningful way. I won't bother trying to refute this as you appear to have your mind made up that ICANN wants to destroy the Internet. I will say that if you have any constructive suggestions on how to improve the ability for the technical community to provide input, I'd be interested in hearing them. Regards, -drc From jim at rfc1035.com Fri Oct 16 20:16:49 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 16 Oct 2009 19:16:49 +0100 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> <95BF2A46-C217-45FB-BB92-4E1F419E4385@rfc1035.com> Message-ID: <1BB09C89-B6A3-4248-9254-319C747DFA4D@rfc1035.com> On 16 Oct 2009, at 18:41, David Conrad wrote: > You referenced a paper written by ICANN staff, implying that in that > paper ICANN staff was saying "let's move COM to the root". I did no such thing David. In fact I asked who did write those sections because I didn't know. I still don't. The document's provenance is uncertain. Thanks for explaining that it was written by ICANN staff. This is not explained in the document itself. I do admit to saying the document lends credence to the "let's move .com to the root" concept. From jim at rfc1035.com Fri Oct 16 20:50:00 2009 From: jim at rfc1035.com (Jim Reid) Date: Fri, 16 Oct 2009 19:50:00 +0100 Subject: [dns-wg] Re: loadsaTLDs and the ICANN policy-making process In-Reply-To: References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> <0F73C9A9-A3CF-4205-83A6-8093B932C0E6@rfc1035.com> Message-ID: <0D445FAB-F348-427C-8427-1C70ACEBB62E@rfc1035.com> On 16 Oct 2009, at 19:05, David Conrad wrote: > Not really sure this is relevant to DNS-WG, but... You're probably right. At least we can agree on something. :-) >> What's the point in engaging in a policy discussion about new gTLDs >> now? > > You're suggesting policies can never change once decided? No, of course not. However it's hard to believe that the policy can be changed now when there appears to be a fait accompli for adding lots of TLDs. Besides, what's the point of adopting a policy of "no more TLDs" after "too many" have already been added? I doubt that sort of policy u-turn could withstand a challenge in the courts or an anti- trust action on competition or restraint of trade grounds. > I know it is hard for some folks to believe, but ICANN staff really > does take the "ensure security and stability" aspect of what ICANN > does quite seriously. A document from ICANN staff which in paraphrase says "it's possible to move .com to the root" (and will be taken out of context by others to advance those arguments) kind of contradicts what you just said David. I am sure you and your colleagues are sincere when you talk of taking security and stability very seriously. However the document we're discussing does raise reasonable doubts here. I have no problem with anyone producing this sort of text, *provided it's put in the proper context*: ie "with sufficient thrust pigs will fly". Saying it's technically possible to put .com in the root without properly explaining why this was impractical was/is irresponsible. Sorry. We have to agree to disagree here. You said on this thread "Given the current system, it would be a stunningly bad _operational_ idea" to move .com to the root. It's a pity that February 08 document didn't say something similar, perhaps in more diplomatic terms. > I won't bother trying to refute this as you appear to have your mind > made up that ICANN wants to destroy the Internet. Now you're being silly. I'm very disappointed that you resorted to an ad hominem attack to what were reasonable comments. > I will say that if you have any constructive suggestions on how to > improve the ability for the technical community to provide input, > I'd be interested in hearing them. I'd be glad to do that and have already been thinking about this. From drc at virtualized.org Sat Oct 17 03:18:57 2009 From: drc at virtualized.org (David Conrad) Date: Fri, 16 Oct 2009 18:18:57 -0700 Subject: [dns-wg] Re: loadsaTLDs and the ICANN policy-making process In-Reply-To: <0D445FAB-F348-427C-8427-1C70ACEBB62E@rfc1035.com> References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> <0F73C9A9-A3CF-4205-83A6-8093B932C0E6@rfc1035.com> <0D445FAB-F348-427C-8427-1C70ACEBB62E@rfc1035.com> Message-ID: <98349361-E472-4653-9BE9-0DFE0A66C8E2@virtualized.org> Jim, On Oct 16, 2009, at 11:50 AM, Jim Reid wrote: >>> What's the point in engaging in a policy discussion about new gTLDs now? >> You're suggesting policies can never change once decided? > No, of course not. However it's hard to believe that the policy can be changed now when there appears to be a fait accompli for adding lots of TLDs. "It ain't over until the fat lady sings". I suppose a lot depends on the definition of "lots of TLDs". > Besides, what's the point of adopting a policy of "no more TLDs" after "too many" have already been added? I doubt that sort of policy u-turn could withstand a challenge in the courts or an anti-trust action on competition or restraint of trade grounds. The proposal out of the root scaling study that appears to have universal acceptance (although some may quibble about the definition) is that an "early warning system" should be deployed to ensure that any changes that could result in instability would be detected prior to instability being caused. >> I know it is hard for some folks to believe, but ICANN staff really does take the "ensure security and stability" aspect of what ICANN does quite seriously. > > A document from ICANN staff which in paraphrase says "it's possible to move .com to the root" (and will be taken out of context by others to advance those arguments) kind of contradicts what you just said David. [...] Sorry. We have to agree to disagree here. Guess so. > You said on this thread "Given the current system, it would be a stunningly bad _operational_ idea" to move .com to the root. It's a pity that February 08 document didn't say something similar, perhaps in more diplomatic terms. "Operational challenges are a limiting factor, ..." would seem pretty diplomatic to me. Regards, -drc From drc at virtualized.org Sat Oct 17 03:25:11 2009 From: drc at virtualized.org (David Conrad) Date: Fri, 16 Oct 2009 18:25:11 -0700 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: <1BB09C89-B6A3-4248-9254-319C747DFA4D@rfc1035.com> References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> <95BF2A46-C217-45FB-BB92-4E1F419E4385@rfc1035.com> <1BB09C89-B6A3-4248-9254-319C747DFA4D@rfc1035.com> Message-ID: On Oct 16, 2009, at 11:16 AM, Jim Reid wrote: > On 16 Oct 2009, at 18:41, David Conrad wrote: >> You referenced a paper written by ICANN staff, implying that in that paper ICANN staff was saying "let's move COM to the root". > I did no such thing David. In fact I asked who did write those sections because I didn't know. I still don't. Sorry, I assumed you were being rhetorical. Yes, the document was written by staff. I thought that was fairly clear from the references to staff in the document. Apologies for the misinterpretation. Regards, -drc From jim at rfc1035.com Mon Oct 19 11:26:06 2009 From: jim at rfc1035.com (Jim Reid) Date: Mon, 19 Oct 2009 10:26:06 +0100 Subject: [dns-wg] Thanks for RIPE 59 Message-ID: <5451887F-BDF9-4B5F-97C8-F7AF67AD09B6@rfc1035.com> 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. From fweimer at bfk.de Wed Oct 21 11:41:52 2009 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 21 Oct 2009 09:41:52 +0000 Subject: [dns-wg] Re: WG response to root scaling studies In-Reply-To: <20091016101150.GA25986@nic.fr> (Stephane Bortzmeyer's message of "Fri\, 16 Oct 2009 12\:11\:50 +0200") References: <20091009100210.GA14408@laperouse.bortzmeyer.org> <20091016101150.GA25986@nic.fr> Message-ID: <82ljj5t76n.fsf@mid.bfk.de> * Stephane Bortzmeyer: > * more TLD (may be a false problem or not, depending on the actual > number. I was shocked at the DNS meeting to hear a participant > making repeated references to one million TLD, a ridiculous number, > that could never be reached, due to ICANN constraints Similar comments must have been made about TLDs, and the hosts file before that (they were right for the host files), but I wasn't around back then. > So, there is little a technical WG like the DNS WG could say about > these reports. The question is so badly phrased that noone can really > reply to it. That, in itself, would be a comment. "In our humble opinion, the report you commissioned is not adequate technical input for future policy discussions, and will likely lead to wrong conclusions" doesn't read very nice, but it's certainly a message the WG should send if it reaches consensus on it. (Disclaimer: I haven't read the report, and your list of conflated issues doesn't make me want to.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From denis at ripe.net Thu Oct 22 15:22:57 2009 From: denis at ripe.net (Denis Walker) Date: Thu, 22 Oct 2009 15:22:57 +0200 Subject: [dns-wg] New rules for reverse domain object creation in the RIPE Database Message-ID: <4AE05CB1.4060503@ripe.net> 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. From shane at time-travellers.org Thu Oct 22 19:58:27 2009 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 22 Oct 2009 19:58:27 +0200 Subject: [dns-wg] Solving lameness in the reverse zones Message-ID: <1256234307.5184.1263.camel@shane-asus-laptop> 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 From he at uninett.no Thu Oct 22 23:59:38 2009 From: he at uninett.no (Havard Eidnes) Date: Thu, 22 Oct 2009 23:59:38 +0200 (CEST) Subject: [dns-wg] Solving lameness in the reverse zones In-Reply-To: <1256234307.5184.1263.camel@shane-asus-laptop> References: <1256234307.5184.1263.camel@shane-asus-laptop> Message-ID: <20091022.235938.09909249.he@uninett.no> > 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. One interpretation could be "pull the delegation to the lame name server, but leave the working ones in place". Do note, though, that if the zone itself still lists the lame server in its NS RRset, that RRset will override the NS RRset received from the delegating zone, since the latter is non- authoritative information, and recursive name servers may think it's a good idea to validate the NS RRset from one of the authoritative name servers. So... It's not a given that removing the delegation record for the lame name server will actually make much of a difference. Or perhaps you meant "remove the entire delegation"? It sounds kind of drastic... Regards, - H?vard From mgraff at isc.org Fri Oct 23 00:22:36 2009 From: mgraff at isc.org (Michael Graff) Date: Thu, 22 Oct 2009 17:22:36 -0500 Subject: [dns-wg] Solving lameness in the reverse zones In-Reply-To: <20091022.235938.09909249.he@uninett.no> References: <1256234307.5184.1263.camel@shane-asus-laptop> <20091022.235938.09909249.he@uninett.no> Message-ID: <4AE0DB2C.5030903@isc.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Havard Eidnes wrote: >> 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. > > One interpretation could be "pull the delegation to the lame name > server, but leave the working ones in place". Or, notify and stop. Are lame delegations really such a problem that we need to take drastic action? How often would this be checked, and how much liability would be here in modifying what is published? I'd hate to see the papers when a large content provider lost due to a temporary outage on one name server... - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrg2ywACgkQ+NNi0s9NRJ2LdQCfacCLIVOMjBBMxw4anm0soiiq TgUAnRGX99ldmU3MPMn1BdIA8h+ZcLpB =GD/r -----END PGP SIGNATURE----- From Woeber at CC.UniVie.ac.at Fri Oct 23 10:44:10 2009 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 23 Oct 2009 08:44:10 +0000 Subject: [dns-wg] Solving lameness in the reverse zones In-Reply-To: <1256234307.5184.1263.camel@shane-asus-laptop> References: <1256234307.5184.1263.camel@shane-asus-laptop> Message-ID: <4AE16CDA.7050108@CC.UniVie.ac.at> Shane Kerr wrote: > All, > > DNS Lameness Philosophy > ----------------------- > There are two fundamentally different philosophies about lameness in > reverse DNS. Well, my perception is that reverseDNS is not well-understood by a big portion of all the players involved. On top of that, the built-in redundancy and resilience of DNS tend to hide structural problems from the "consumers" till the very last moment. Having many organisations out-source management of network services cerainly does not help. My feeling is that we should consider an information campaign first, and then think about technical measures how we can improve the service. Btw, the same problem is there on the lower levels of the delegation chains. Sigh.... Wilfried. From shane at time-travellers.org Fri Oct 23 12:09:33 2009 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 23 Oct 2009 12:09:33 +0200 Subject: [dns-wg] Solving lameness in the reverse zones In-Reply-To: <20091022.235938.09909249.he@uninett.no> References: <1256234307.5184.1263.camel@shane-asus-laptop> <20091022.235938.09909249.he@uninett.no> Message-ID: <1256292573.5184.2191.camel@shane-asus-laptop> H?vard, Thanks for your reply. Clearly some additional thinking is necessary... On Thu, 2009-10-22 at 23:59 +0200, Havard Eidnes wrote: > > 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. > > One interpretation could be "pull the delegation to the lame name > server, but leave the working ones in place". Yes, that is the idea I was going for. Apologies for being unclear. > Do note, though, that if the zone itself still lists the lame > server in its NS RRset, that RRset will override the NS RRset > received from the delegating zone, since the latter is non- > authoritative information, and recursive name servers may think > it's a good idea to validate the NS RRset from one of the > authoritative name servers. So... It's not a given that > removing the delegation record for the lame name server will > actually make much of a difference. You bring up a very good point. AFAIK the lameness checking at the RIPE NCC only looks at things from the parent point of view. There is a different class of error, which you touch on here, which is mismatch between parent NS RRSET and child (authoritative) NS RRSET. This has not been discussed. NS RRSET Mismatches ------------------- A mismatch can be one of three types: 1. NS in parent not in child 2. NS in child not in parent - server is not lame 3. NS in child not in parent - server is lame The first case is a sort of lameness, and actually quite easily detected. I think that it can be covered exactly as any other sort of lameness. (It is possible for a name server listed in the parent to answer correctly even though it is not listed in the NS set of the child; this may happen during a migration for example. I don't think that affects this discussion, but I thought I would mention it.) The second case is not lameness, but is an incorrectness at the parent. Again, if data accuracy is our goal (and for this proposal we assume that it is), then we must fix it, somehow. I propose the same algorithm as for removing lame delegations: warn, warn, update. Except in this case "update" means adding the appropriate NS. The third case is the tricky one. We have no good solution here. If we cared about user experience, then we would eliminate the NS from the parent RRSET, because that will result in a slightly better average query pattern. However, we do not care about users, we care about data, so it is difficult to say what the best way forward is. (See more below.) > Or perhaps you meant "remove the entire delegation"? It sounds > kind of drastic... It is drastic, but in the 3rd case we have no good options. Since we care about data accuracy, we may need drastic measures. We have two possible approaches: * We follow the normal lameness process for the lame server: warn, warn, delete. Then we must spam the administrator every time we re-run our check until the zone is fixed. Yes, it is annoying and not likely to get things fixed, but for the sake of the data, it is necessary that we try. * Otherwise, yes, we simply remove the entire delegation. One could argue that "we have killed the patient to cure the disease", but please keep in mind that data consistency is the goal. If I was the administrator for the child zone, I would actually prefer the second option (spam is annoying). It is also better because it results in a correct parent zone. But I leave it up to the working group to decide. Thankfully there is no glue in the reverse tree, so we can ignore that class of mismatch. :) But I am reminded of another missing point in our quest for correctness: NS with partial lameness. NS with Partial Lameness ------------------------ In this case, we have something like this: 2.0.192.in-addr.arpa NS ns1.example.net. ns2.example.net. ns1.example.net A 192.0.2.0 ; working server A 192.0.2.1 ; broken server What we have here is lameness caused by a NS record with multiple addresses, only some of which are answering properly. Since we have no control over this NS to A/AAAA mapping, we have the same options as case #3 above: we can pester continuously or we can pull the entire delegation. Reading my proposals here, one might get the idea that I don't support the idea of data correctness as the correct philosophy for DNS lameness checking. You are correct. In a sense, this is a sort of reducto ad absurdum discussion: http://en.wikipedia.org/wiki/Reductio_ad_absurdum If you begin with the premise that data quality is important as an end goal, rather than starting with the premise that data quality is important only when it helps people, you have no way to measure when a technique for improving data quality is simply not worth the bother. HOWEVER, I do accept the possibility that the community may say "damn the torpedoes, full speed ahead!"(*) If we're going to go for data quality, lets not be half-assed(**), lets get it right this time. :) -- Shane (*) Excuse the Americanism, but it seems somehow appropriate: http://tinyurl.com/damn-the-torpedoes (**) Another Americanism, also equally appropriate IMHO: http://www.urbandictionary.com/define.php?term=half-assed From shane at time-travellers.org Fri Oct 23 12:11:56 2009 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 23 Oct 2009 12:11:56 +0200 Subject: [dns-wg] Solving lameness in the reverse zones In-Reply-To: <4AE0DB2C.5030903@isc.org> References: <1256234307.5184.1263.camel@shane-asus-laptop> <20091022.235938.09909249.he@uninett.no> <4AE0DB2C.5030903@isc.org> Message-ID: <1256292716.5184.2200.camel@shane-asus-laptop> Michael, On Thu, 2009-10-22 at 17:22 -0500, Michael Graff wrote: > Are lame delegations really such a problem that we need to take drastic > action? How often would this be checked, and how much liability would > be here in modifying what is published? I'd hate to see the papers when > a large content provider lost due to a temporary outage on one name > server... This approach is based on the assumption that lameness is in itself a problem, and must be fixed. Also note that we are talking about the reverse DNS in this case, so nobody is going to lose revenue if we a delegation is removed. -- Shane From shane at time-travellers.org Fri Oct 23 12:14:51 2009 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 23 Oct 2009 12:14:51 +0200 Subject: [dns-wg] Solving lameness in the reverse zones In-Reply-To: <4AE16CDA.7050108@CC.UniVie.ac.at> References: <1256234307.5184.1263.camel@shane-asus-laptop> <4AE16CDA.7050108@CC.UniVie.ac.at> Message-ID: <1256292891.5184.2210.camel@shane-asus-laptop> Wilfried, On Fri, 2009-10-23 at 08:44 +0000, Wilfried Woeber, UniVie/ACOnet wrote: > Shane Kerr wrote: > > > All, > > > > DNS Lameness Philosophy > > ----------------------- > > There are two fundamentally different philosophies about lameness in > > reverse DNS. > > Well, my perception is that reverseDNS is not well-understood by a big > portion of all the players involved. > > On top of that, the built-in redundancy and resilience of DNS tend to > hide structural problems from the "consumers" till the very last moment. In my mind, this means that there is no problem, and that most attempts to solve the non-existent problem are doomed to be more expensive than the benefit they bring. I think my lightweight proposal (include lameness in an annual report about the state of delegations per LIR, notify the top offenders) is the right way forward. It should provide the most benefit for the least annoyance. -- Shane From uhlar at fantomas.sk Fri Oct 23 13:57:43 2009 From: uhlar at fantomas.sk (Matus UHLAR - fantomas) Date: Fri, 23 Oct 2009 13:57:43 +0200 Subject: [dns-wg] Solving lameness in the reverse zones In-Reply-To: <1256292716.5184.2200.camel@shane-asus-laptop> References: <1256234307.5184.1263.camel@shane-asus-laptop> <20091022.235938.09909249.he@uninett.no> <4AE0DB2C.5030903@isc.org> <1256292716.5184.2200.camel@shane-asus-laptop> Message-ID: <20091023115743.GA28227@fantomas.sk> > On Thu, 2009-10-22 at 17:22 -0500, Michael Graff wrote: > > Are lame delegations really such a problem that we need to take drastic > > action? How often would this be checked, and how much liability would > > be here in modifying what is published? I'd hate to see the papers when > > a large content provider lost due to a temporary outage on one name > > server... On 23.10.09 12:11, Shane Kerr wrote: > This approach is based on the assumption that lameness is in itself a > problem, and must be fixed. > > Also note that we are talking about the reverse DNS in this case, so > nobody is going to lose revenue if we a delegation is removed. well, there are still servers and services requiring reverse resolution... -- Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. REALITY.SYS corrupted. Press any key to reboot Universe. From jim at rfc1035.com Tue Oct 27 11:11:28 2009 From: jim at rfc1035.com (Jim Reid) Date: Tue, 27 Oct 2009 10:11:28 +0000 Subject: [dns-wg] RIPE 59 minutes Message-ID: 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: ripe59minutes Type: application/octet-stream Size: 23850 bytes Desc: not available URL: -------------- next part --------------