From joe.abley at icann.org Wed Jun 9 17:45:04 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 9 Jun 2010 08:45:04 -0700 Subject: [dns-wg] Root Zone DNSSEC Deployment Technical Status Update Message-ID: Root Zone DNSSEC Deployment Technical Status Update 2010-06-09 This is the eighth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at . We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. PUBLIC NOTICE The US Department of Commerce National Telecommunications and Information Administration (NTIA) has issued a Public Notice regarding the deployment of DNSSEC in the root zone. http://www.ntia.doc.gov/frnotices/2010/FR_DNSSEC_Notice_06092010.pdf The Public Notice makes reference to the final report submitted to NTIA by ICANN and VeriSign which contains a summary of the project work to date together with a recommendation that full deployment should proceed. http://www.ntia.doc.gov/reports/2010/DNSSEC_05282010.pdf The Public Notice includes a public review period. Comments may be submitted by postal mail, fax or e-mail before 2010-06-21. Instructions for the submission of comments are included in the Public Notice. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ To come: 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) From Brett.Carr at nominet.org.uk Thu Jun 10 09:57:26 2010 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Thu, 10 Jun 2010 07:57:26 +0000 Subject: [dns-wg] RE: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <9BF6AF19-9EB8-46E7-856C-D5CE463C5763@icann.org> References: <9BF6AF19-9EB8-46E7-856C-D5CE463C5763@icann.org> Message-ID: <71969C3CA9874C4EA9CF6ED84772938624E993@wds-exc1.okna.nominet.org.uk> Joe, > Subject: [dns-operations] Root Zone DNSSEC Deployment Technical Status > Update > > Root Zone DNSSEC Deployment > Technical Status Update 2010-06-09 > > This is the eighth of a series of technical status updates intended > to inform a technical audience on progress in signing the root zone > of the DNS. > > > RESOURCES > > Details of the project, including documentation published to date, > can be found at . > > We'd like to hear from you. If you have feedback for us, please > send it to rootsign at icann.org. > > > PUBLIC NOTICE > > The US Department of Commerce National Telecommunications and > Information Administration (NTIA) has issued a Public Notice regarding > the deployment of DNSSEC in the root zone. > > http://www.ntia.doc.gov/frnotices/2010/FR_DNSSEC_Notice_06092010.pdf > > The Public Notice makes reference to the final report submitted to > NTIA by ICANN and VeriSign which contains a summary of the project > work to date together with a recommendation that full deployment > should proceed. > > http://www.ntia.doc.gov/reports/2010/DNSSEC_05282010.pdf > > The Public Notice includes a public review period. Comments may be > submitted by postal mail, fax or e-mail before 2010-06-21. > Instructions > for the submission of comments are included in the Public Notice. > > > PLANNED DEPLOYMENT SCHEDULE > > Already completed: > > 2010-01-27: L starts to serve DURZ > > 2010-02-10: A starts to serve DURZ > > 2010-03-03: M, I start to serve DURZ > > 2010-03-24: D, K, E start to serve DURZ > > 2010-04-14: B, H, C, G, F start to serve DURZ > > 2010-05-05: J starts to serve DURZ > > To come: > > 2010-06-16: First Key Signing Key (KSK) Ceremony > > 2010-07-15: Distribution of validatable, production, signed root > zone; publication of root zone trust anchor > Congratulations on the progress so far. Apologies if this question has been asked/answered before but do you have a timeline on the acceptance of DS records for publication into the root from TLD operators? Brett Carr Systems Administrator Nominet UK From anandb at ripe.net Mon Jun 14 18:05:50 2010 From: anandb at ripe.net (Anand Buddhdev) Date: Mon, 14 Jun 2010 18:05:50 +0200 Subject: [dns-wg] DNSSEC KSK Rollover Event for RIPE NCC Zones Message-ID: <4C16535E.6000500@ripe.net> [Apologies for duplicates] Dear Colleagues, On Tuesday, 23 March 2010, the RIPE NCC published new DNSSEC trust anchors. They can be found in a new location on the RIPE website at: https://www.ripe.net/dnssec-keys/ Today the RIPE NCC has started signing all of our zones with the new keys found in those trust anchor files. If you have both the old and the new keys configured you do not need to make any changes right now. On Wednesday, 16 June, we will remove the old trust anchors from our website. With today's key rollover event the RIPE NCC has completed the migration to new DNSSEC signers. We have updated our DNSSEC Policy and Practice Statement (DPS). The updated DPS can be found at: https://www.ripe.net/rs/reverse/dnssec/dps.html During the migration we did experience a small issue. Our processes failed to pre-publish the previous Zone Signing Key (ZSK) into the zones on our new signers. While our zones were propagating to the secondary servers, some validating resolvers may have fetched signed answers and DNSKEY records from different servers, and not been able to validate these answers. However, the time-to-live on the old ZSK DNSKEY record was one hour, so the window during which validation failures could have occurred is quite small. We have taken steps to ensure that this will not happen in the future. If you have any questions or comments, please send an email to . Regards, Anand Buddhdev DNS Services Manager From kzorba at otenet.gr Tue Jun 15 16:58:03 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Tue, 15 Jun 2010 17:58:03 +0300 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment Message-ID: <201006151758.03524.kzorba@otenet.gr> I guess this is a question suited for this WG. References to other technical forums that can address this, or any pointers to established or not operational guidelines, are highly welcome. The question has to do with the provisioning of the reverse DNS entries of customers of a broaband provider in an IPv6 environment (PTR records in ip6.arpa). In the IPv4 world, each user receives mainly a single IP. There are dynamic and static users and most providers (including us) have pre-populated PTR records in their allocations in in-addr.arpa. PTR records can point to different namespaces depending on the address space use (eg static. and dynamic. for static and dynamic customers respectively). In the IPv6 case the problem is obvious because of the huge IPv6 address space. Since each customer can receive a /56, this is an assignment of 2^72 possible /128 addresses which is a tremendously HUGE number. We cannot possibly have pre-populated any zone with that many entries and this is just a single customer. The main question therefore is: how can we address this issue, if we need to have reverse DNS resolution for IPv6 ranges? The first thing that comes to my mind is using wildcard records in BIND, or skipping reverse DNS alltogether. Do you know of any operational recommendations? Thanks, Kostas Zorbadelos From david.freedman at uk.clara.net Tue Jun 15 18:18:55 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 15 Jun 2010 09:18:55 -0700 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment In-Reply-To: <201006151758.03524.kzorba@otenet.gr> Message-ID: We use wildcard records and then the customer can insert any custom content to override these (but beware that the deprovisioning fairy must visit your database tables when the customer leaves in order to keep this stuff clean) Dave. On 15/06/2010 07:58, "Kostas Zorbadelos" wrote: > I guess this is a question suited for this WG. > References to other technical forums that can address this, or any pointers to > established or not operational guidelines, are highly welcome. > > The question has to do with the provisioning of the reverse DNS entries > of customers of a broaband provider in an IPv6 environment (PTR records in > ip6.arpa). In the IPv4 world, each user receives mainly a single IP. > There are dynamic and static users and most providers (including us) have > pre-populated PTR records in their allocations in in-addr.arpa. PTR records > can point to different namespaces depending on the address space use (eg > static. and dynamic. for static and dynamic customers > respectively). > > In the IPv6 case the problem is obvious because of the huge IPv6 address > space. Since each customer can receive a /56, this is an assignment of 2^72 > possible /128 addresses which is a tremendously HUGE number. We cannot > possibly have pre-populated any zone with that many entries and this is just > a single customer. > The main question therefore is: how can we address this issue, if we need to > have reverse DNS resolution for IPv6 ranges? The first thing that comes to my > mind is using wildcard records in BIND, or skipping reverse DNS alltogether. > Do you know of any operational recommendations? > > Thanks, > > Kostas Zorbadelos > ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net From jim at rfc1035.com Tue Jun 15 20:59:12 2010 From: jim at rfc1035.com (Jim Reid) Date: Tue, 15 Jun 2010 19:59:12 +0100 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment In-Reply-To: References: Message-ID: <2326DF77-B976-4330-A56B-F767779793FE@rfc1035.com> On 15 Jun 2010, at 17:18, David Freedman wrote: > We use wildcard records and then the customer can insert any custom > content > to override these (but beware that the deprovisioning fairy must > visit your > database tables when the customer leaves in order to keep this stuff > clean) Hmmmm. IMO deployment of wildcarding in the DNS is usually an indication that something has gone very wrong. It always gives me the heebie-jeebies. Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC someone (Johan Ihren?) gave a presentation at a RIPE meeting a few years ago and said it was best not to bother with any PTRs in the reverse zones for IPv6 space. I think his argument was the world was moving away from name-based access controls to things based on crypto tokens, making reverse lookups pointless. That said, my mail server does not accept inbound SMTP if the connecting host fails to have a working reverse DNS entry: this is remarkably good at spam suppression. Provisioning these IPv6 reverse zones is a problem for ISPs and I'm not sure what (if anything) is the Right Thing to do here. Perhaps this is something for the WG to consider and possibly work on: eg compare and contrast approaches, document use cases and so forth? Aside from Claranet, what are the other ISPs doing about provisioning reverse DNS for their IPv6 customers? DDNS with DHCPv6? Anyone care to share? My personal preference would be to delegate the /80 (or whatever) to the end-user/customer and leave them to choose how to provision that zone. [Your mileage may vary...] This might work fairly painlessly with the tcp-self and 6to4-self hooks to the update-policy{} clause in BIND 9.7. Though that's still messy. It also relies on well-behaved clients which is perhaps unwise. From david.freedman at uk.clara.net Tue Jun 15 21:06:11 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 15 Jun 2010 12:06:11 -0700 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment In-Reply-To: <2326DF77-B976-4330-A56B-F767779793FE@rfc1035.com> Message-ID: > Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC > someone (Johan Ihren?) gave a presentation at a RIPE meeting a few > years ago and said it was best not to bother with any PTRs in the > reverse zones for IPv6 space. I think his argument was the world was > moving away from name-based access controls to things based on crypto > tokens, making reverse lookups pointless. That said, my mail server > does not accept inbound SMTP if the connecting host fails to have a > working reverse DNS entry: this is remarkably good at spam suppression. We for one welcome our new ID/LOC split overlords :) Still, you will need locator rDNS and the locator space will still be as big... ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net From kzorba at otenet.gr Wed Jun 16 08:56:09 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Wed, 16 Jun 2010 09:56:09 +0300 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment In-Reply-To: <2326DF77-B976-4330-A56B-F767779793FE@rfc1035.com> References: <2326DF77-B976-4330-A56B-F767779793FE@rfc1035.com> Message-ID: <201006160956.09319.kzorba@otenet.gr> On Tuesday 15 June 2010 21:59:12 Jim Reid wrote: > On 15 Jun 2010, at 17:18, David Freedman wrote: > > We use wildcard records and then the customer can insert any custom > > content > > to override these (but beware that the deprovisioning fairy must > > visit your > > database tables when the customer leaves in order to keep this stuff > > clean) > > Hmmmm. IMO deployment of wildcarding in the DNS is usually an > indication that something has gone very wrong. It always gives me the > heebie-jeebies. > I can't imagine of a senario that this would be a problem, but I tend to believe you Jim :) Of course IPv6 produces a totally different world in many things and I guess reverse DNS is one of them. One of my thoughts on this is having wildcard records per customer vlan. If you chose a /56 customer assignment, that leaves you with 256 different /64 vlans. The main idea is to use them for different services (if we ever come to that many offerings). Internet access, VoIP/SIP and IPTV would be the first obvious choices in providers giving these services. > Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC > someone (Johan Ihren?) gave a presentation at a RIPE meeting a few > years ago and said it was best not to bother with any PTRs in the > reverse zones for IPv6 space. I think his argument was the world was > moving away from name-based access controls to things based on crypto > tokens, making reverse lookups pointless. That said, my mail server > does not accept inbound SMTP if the connecting host fails to have a > working reverse DNS entry: this is remarkably good at spam suppression. > My guess is that the world will take a much longer time for such a change to occur. Although reverse DNS is used as a weak authentication mechanism today (if it can be characterized like that) it is not the only use. It is very convenient to see names instead of ugly IPv6 addresses in log files for instance. > Provisioning these IPv6 reverse zones is a problem for ISPs and I'm > not sure what (if anything) is the Right Thing to do here. Perhaps > this is something for the WG to consider and possibly work on: eg > compare and contrast approaches, document use cases and so forth? This is a good idea. > Aside from Claranet, what are the other ISPs doing about provisioning > reverse DNS for their IPv6 customers? DDNS with DHCPv6? Anyone care to > share? > Now DDNS is another thought. Can you imagine that working however in an environment of multi-million mobile and consumer devices powering up often, in a secure and scalable way? I find it a challenge, though never say never :) > My personal preference would be to delegate the /80 (or whatever) to > the end-user/customer and leave them to choose how to provision that > zone. [Your mileage may vary...] This might work fairly painlessly > with the tcp-self and 6to4-self hooks to the update-policy{} clause in > BIND 9.7. Though that's still messy. It also relies on well-behaved > clients which is perhaps unwise. The hooks you are referring to in BIND are DDNS stuff? Delegating the reverse space of the assignment to the end user sounds like a good idea, provided you have fixed customers with static assignments. You also have to address the issue for mobile one-off address users. The problem is not so much the address space used for servers and network elements. The provider can populate and maintain this space prety much as it does today. Consider home equipment, PCs with Windows 7 or any other operating system with similar behaviour, which as we noticed, apart from the autoconfiguration address, produce random IPv6 addresses used in outgoing connections that change every couple of hours or so. Add to all that some DNSSEC sugar ;-) Kostas From kzorba at otenet.gr Wed Jun 16 08:57:21 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Wed, 16 Jun 2010 09:57:21 +0300 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment In-Reply-To: References: Message-ID: <201006160957.21332.kzorba@otenet.gr> On Tuesday 15 June 2010 22:06:11 David Freedman wrote: > > Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC > > someone (Johan Ihren?) gave a presentation at a RIPE meeting a few > > years ago and said it was best not to bother with any PTRs in the > > reverse zones for IPv6 space. I think his argument was the world was > > moving away from name-based access controls to things based on crypto > > tokens, making reverse lookups pointless. That said, my mail server > > does not accept inbound SMTP if the connecting host fails to have a > > working reverse DNS entry: this is remarkably good at spam suppression. > > We for one welcome our new ID/LOC split overlords :) > > Still, you will need locator rDNS and the locator space will still be as > big... > Sorry, but I understand nothing out of these phrases... Kostas > ------------------------------------------------ > David Freedman > Group Network Engineering > Claranet Limited > http://www.clara.net From BECHA at ripe.net Wed Jun 16 09:41:13 2010 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 16 Jun 2010 09:41:13 +0200 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment In-Reply-To: <201006151758.03524.kzorba@otenet.gr> References: <201006151758.03524.kzorba@otenet.gr> Message-ID: <4C188019.3000503@ripe.net> Hi Kostas, On 6/15/10 4:58 PM, Kostas Zorbadelos wrote: > I guess this is a question suited for this WG. > References to other technical forums that can address this, or any pointers to > established or not operational guidelines, are highly welcome. Some of the possible options are documented in this Internet Draft: Reverse DNS in IPv6 for Internet Service Providers: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-03 (also contains links to other relevant documents) And just for the record and for the completeness of the reference: the operational details on how to get the reverse DNS delegated to you from the RIPE NCC: http://www.ripe.net/rs/reverse/ I hope this helps, regards Vesna Manojlovic RIPE NCC trainer From kzorba at otenet.gr Wed Jun 16 11:18:41 2010 From: kzorba at otenet.gr (Kostas Zorbadelos) Date: Wed, 16 Jun 2010 12:18:41 +0300 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment In-Reply-To: <4C188019.3000503@ripe.net> References: <201006151758.03524.kzorba@otenet.gr> <4C188019.3000503@ripe.net> Message-ID: <201006161218.41939.kzorba@otenet.gr> On Wednesday 16 June 2010 10:41:13 Vesna Manojlovic wrote: > Hi Kostas, > > On 6/15/10 4:58 PM, Kostas Zorbadelos wrote: > > I guess this is a question suited for this WG. > > References to other technical forums that can address this, or any > > pointers to established or not operational guidelines, are highly > > welcome. > > Some of the possible options are documented in this Internet Draft: > > Reverse DNS in IPv6 for Internet Service Providers: > http://tools.ietf.org/html/draft-howard-isp-ip6rdns-03 > Excellent reference Vesna, thanks. Of course it is always very valuable to learn what is being deployed in the real world in Service Provider networks. > (also contains links to other relevant documents) > > And just for the record and for the completeness of the reference: > > the operational details on how to get the reverse DNS delegated to you > from the RIPE NCC: > > http://www.ripe.net/rs/reverse/ > Thanks also. We already have the reverse DNS delegation for the IPv6 address space allocated to us. Kostas Zorbadelos Greek Telecommunications Organization (OTE SA) > I hope this helps, > regards > Vesna Manojlovic > RIPE NCC trainer From jim at rfc1035.com Wed Jun 16 11:54:43 2010 From: jim at rfc1035.com (Jim Reid) Date: Wed, 16 Jun 2010 10:54:43 +0100 Subject: [dns-wg] Reverse DNS operational considerations in an IPv6 environment In-Reply-To: <201006160956.09319.kzorba@otenet.gr> References: <2326DF77-B976-4330-A56B-F767779793FE@rfc1035.com> <201006160956.09319.kzorba@otenet.gr> Message-ID: <53E70427-1D3E-4EE9-96E3-71CCFE93D509@rfc1035.com> On 16 Jun 2010, at 07:56, Kostas Zorbadelos wrote: > Of course IPv6 produces a totally different world in many > things and I guess reverse DNS is one of them. +1 > Although reverse DNS is used as a weak authentication mechanism today > (if it can be characterized like that) it is not the only use. It is > very > convenient to see names instead of ugly IPv6 addresses in log files > for > instance. I tend to agree. Though a cost/benefit analysis tends to suggest this convenience might not be worth the pain. > Now DDNS is another thought. Can you imagine that working however in > an > environment of multi-million mobile and consumer devices powering up > often, > in a secure and scalable way? I find it a challenge, though never say > never :) I imagine all sorts of things and you probably don't want to know what goes on inside my head. Really. :-) You're right to say that provisioning IPv6 PTR records for bazillions of edge devices is "challenging". In some cases it might not be worth the effort. [Would anyone care if the beer cans in my fridge had hostnames or if they got renumbered once I'd drunk them?] I think that was part of the argument that was being made about not bothering with PTRs for IPv6 addresses. Particularly for stuff that had transient or rapidly changing connectivity. >> My personal preference would be to delegate the /80 (or whatever) to >> the end-user/customer and leave them to choose how to provision that >> zone. [Your mileage may vary...] This might work fairly painlessly >> with the tcp-self and 6to4-self hooks to the update-policy{} clause >> in >> BIND 9.7. Though that's still messy. It also relies on well-behaved >> clients which is perhaps unwise. > > The hooks you are referring to in BIND are DDNS stuff? Yes. The tcp-self and 6to4-self hooks allow clients to change the PTR for their own IPv6 address without needing a TSIG or other crypto token. The dynamic updates have to be made over TCP though. > The provider can populate and maintain this space prety much as it > does today. Consider home equipment, PCs with Windows 7 or any other > operating system with similar behaviour, which as we noticed, apart > from the > autoconfiguration address, produce random IPv6 addresses used in > outgoing > connections that change every couple of hours or so. > > Add to all that some DNSSEC sugar ;-) Yes. It's delightful, isn't it? The plug and play semantics of IPv6 pretty much force us down the road of DDNS for forward and reverse lookups if name<->address mappings matter. That in turn makes DNSSEC "interesting". From daniel.karrenberg at ripe.net Wed Jun 30 18:33:50 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 30 Jun 2010 18:33:50 +0200 Subject: [dns-wg] ACTION REQUIRED: Comment to US DoC NTIA on Signing the Root Message-ID: <20100630163350.GC743@reifripenet.local> Folks, it has come to my attention that the US government is still looking for comments about the plan to sign the root. We have said we want to see this happen before, but they apparently want to hear it again. So if you want to see this happening soon, please send them a note, however short. The relavant notice is attached. Written comments may be submitted by electronic mail to DNSSEC at ntia.doc.gov. I would recommend copying Ashley Heineman at aheineman at ntia.doc.gov. If you have questions, Ashley can be reached at +1 202 482?0298. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: FR_DNSSEC_Notice_06092010.pdf Type: application/pdf Size: 51847 bytes Desc: not available URL: From daniel.karrenberg at ripe.net Wed Jun 30 18:45:26 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 30 Jun 2010 18:45:26 +0200 Subject: [dns-wg] ACTION REQUIRED: Comment to US DoC NTIA on Signing the Root In-Reply-To: <20100630163350.GC743@reifripenet.local> References: <20100630163350.GC743@reifripenet.local> Message-ID: <20100630164526.GD743@reifripenet.local> On 30.06 18:33, Daniel Karrenberg wrote: > Folks, > > it has come to my attention that the US government is still looking > for comments about the plan to sign the root. We have said we want > to see this happen before, but they apparently want to hear it again. > So if you want to see this happening soon, please send them a note, > however short. The relavant notice is attached. > > Written comments may be submitted by electronic mail to > > DNSSEC at ntia.doc.gov. > > I would recommend copying Ashley Heineman at aheineman at ntia.doc.gov. > If you have questions, Ashley can be reached at +1 202 482?0298. > > Daniel Forgot to say explicitly: Disregard the deadline mentioned. Send comments.