From wnagele at ripe.net Fri Mar 4 13:40:11 2011 From: wnagele at ripe.net (Wolfgang Nagele) Date: Fri, 04 Mar 2011 13:40:11 +0100 Subject: [dns-wg] Re: DNSSEC outage in e164.arpa In-Reply-To: <4D5AAA0B.1040805@ripe.net> References: <4D5AAA0B.1040805@ripe.net> Message-ID: <4D70DDAB.2000401@ripe.net> Dear colleagues, Together with our vendor, we have analysed the DNSSEC outage that occurred in e164.arpa on 15 February 2011 and have come to the conclusion that it was caused by an unknown bug in the signer system. The publication of the new DS record for e164.arpa (key tag 33067) occurred on the same day that we began rolling out our new DNS provisioning system. During that migration we had to change our serial timestamp format from YYYYMMDDNN serial number to Unix timestamp format. To do this, we had to increment serials in all of our zones twice to roll to the new values (e.g. 2011021500 -> 1297728000). This excessive re-transfer behaviour seemed to cause the system that verifies the publication of new DS records to skip this signature. As this re-transfer behavior doesn't occur during normal operations, we do not foresee this becoming an reoccurring problem in the future. However, we have decided that there is a need to increase the sanity checks performed before a zone gets published. We are now in contact with NLNetLabs and are investigating the possibility of having a zone transfer proxy that can be configured to validate a zone that comes in on one end and is only sent out on the other end if it validates against a given set of trust anchors. For more information: https://lists.dns-oarc.net/pipermail/dns-operations/2011-March/006926.html We believe this type of sanity check would benefit the community by reducing the occurrence of DNSSEC-related incidents. We would appreciate your input on what requirements should be included in a sanity checker. You can share your input with me by email, or in person at the DNS-OARC meeting in San Francisco (13-14 March). Regards, Wolfgang Nagele RIPE NCC DNS Group Manager On 2/15/11 17:30, Wolfgang Nagele wrote: > Dear colleagues, > > Our DNSSEC signer system produced a e164.arpa zone that was missing a > signature for the current KSK at approximately 13:00 UTC today. > > We resolved the error at approximately 16:30 UTC by producing a new zone > (serial 1297787668). > > We apologise for the outage and will provide more details after we've > analysed the incident. > > Regards, > > Wolfgang Nagele > RIPE NCC DNS Group Manager From kzorba at otenet.gr Sun Mar 6 11:52:44 2011 From: kzorba at otenet.gr (kzorba at otenet.gr) Date: Sun, 06 Mar 2011 12:52:44 +0200 Subject: [dns-wg] Request for Comments on IANA In-Reply-To: References: Message-ID: <20110306125244.83576a32dyy4zj3w@noc.otenet.gr> Quoting Jim Reid : An overall very interesting and informative document. How about this quote: "Paper submissions should include a three and one-half inch computer diskette in HTML, ASCII, Word or WordPerfect format (please specify version). Diskettes should be labeled with the name and organizational affiliation of the filer, and the name of the word processing program used to create the document. Alternatively, comments may be submitted electronically to IANAFunctions at ntia.doc.gov. Comments provided via electronic mail should also be submitted in one or more of the formats specified above." Three and one-half inch computer diskette? In 2011? Not to mention the acceptance of WordPerfect and lack for example of pdf. Is this a way to discourage comments? :-P Regards, Kostas > Colleagues, NTIA has just issued an RFC on IANA's operation and > governance. [No, not an IETF one!] Comments have to be in by the end > of March. Response to this RFC will help NTIA to decide about what > happens when its current IANA contract ends in September. Here's the > URL: > http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf > > It's not clear to me if this is something the WG collectively could > or should respond to. That's up you all of you to decide. However > some of you may want to submit your own responses to NTIA. > > From randy at psg.com Sun Mar 6 12:04:11 2011 From: randy at psg.com (Randy Bush) Date: Sun, 06 Mar 2011 20:04:11 +0900 Subject: [dns-wg] Request for Comments on IANA In-Reply-To: <20110306125244.83576a32dyy4zj3w@noc.otenet.gr> References: <20110306125244.83576a32dyy4zj3w@noc.otenet.gr> Message-ID: > Three and one-half inch computer diskette? In 2011? Not to mention the > acceptance of WordPerfect and lack for example of pdf. Is this a way > to discourage comments? :-P my guess is, if you're too lame to submit softcopy, the wanted a specific format that they could transform to softcopy. someone figured that, if you are too lame to upload softcopy, you probably use floppies and word perfect. randy From jim at rfc1035.com Mon Mar 7 10:42:41 2011 From: jim at rfc1035.com (Jim Reid) Date: Mon, 7 Mar 2011 09:42:41 +0000 Subject: [dns-wg] IANA RFC response media/formats In-Reply-To: <20110306125244.83576a32dyy4zj3w@noc.otenet.gr> References: <20110306125244.83576a32dyy4zj3w@noc.otenet.gr> Message-ID: <18712AA1-0DE6-4C64-A978-42E7CD4275F2@rfc1035.com> On 6 Mar 2011, at 10:52, kzorba at otenet.gr wrote: > Three and one-half inch computer diskette? In 2011? Perhaps the thinking here is if you're too young to know about 3.5 inch floppies, you're too young to be able to make meaningful comments. ie this consultation is not for the Facebook or Twitter generation. :-) I have a pile of unformatted floppies. [They're next to a selection of half-inch mag tapes at the back of a cupboard. Kids, ask your parents...] If anyone here is minded to send something to NTIA on floppy disk, please let me know. > Not to mention the acceptance of WordPerfect and lack for example of > pdf. Hey, anyone who accepts plain text can't be all bad. :-) From sbras at ripe.net Tue Mar 15 15:03:22 2011 From: sbras at ripe.net (Sandra Bras) Date: Tue, 15 Mar 2011 15:03:22 +0100 Subject: [dns-wg] Announcement: New E-Learning Module DNS Vulnerabilities Message-ID: <4D7F71AA.6070007@ripe.net> [Apologies for duplicate emails] Dear colleagues, The RIPE NCC is pleased to announce the launch of "DNS vulnerabilities", the second module of our DNSSEC E-Learning course. This module explains two common DNS security problems: "Man in the Middle" and "Kaminsky Attack". It can be viewed at: http://www.ripe.net/lir-services/training/e-learning/dnssec/dns-vulnerabilities We will be releasing more modules in the coming months, including: Module 3 DNSSEC and RIPE Database Modules. The RIPE NCC E-Learning is a free service that is available to everyone. If you have any questions, please feel free to contact us at e-learning at ripe.net. Happy learning, Sandra Br?s Trainer/E-Learning Coordinator RIPE NCC From wnagele at ripe.net Wed Mar 23 16:45:10 2011 From: wnagele at ripe.net (Wolfgang Nagele) Date: Wed, 23 Mar 2011 16:45:10 +0100 Subject: [dns-wg] DNSSEC Provisioning for ERX Space Held with ARIN Message-ID: <4D8A1586.40409@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, ARIN has just announced that they are now supporting DNSSEC-enabled delegations for their reverse space. For more information, see: https://www.arin.net/announcements/2011/20110321.html This means that RIPE NCC members with ERX space assignments in the ARIN region can now also make use of DNSSEC. To do so, please submit a domain object which includes the ds-rdata field as you would for any other DNSSEC-enabled delegation. For more information on how to do this, see: http://www.ripe.net/data-tools/dns/dnssec/procedure-for-requesting-dnssec-delegations We will enable this service for ERX space held in other RIR regions as soon as DNSSEC becomes available with those RIRs. For more information on ERX space in the RIPE NCC service region, see: http://www.ripe.net/lir-services/resource-management/erx Regards, Wolfgang Nagele DNS Group Manager, RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2KFYYACgkQjO7G63Byy8fLrwCfVa6M28DwHHk1xjgpyeFLWdKq +1wAnAk/hIkgK16fbr7iRGeWJgYHwlEM =H3jm -----END PGP SIGNATURE----- From cet1 at cam.ac.uk Thu Mar 24 15:29:31 2011 From: cet1 at cam.ac.uk (Chris Thompson) Date: 24 Mar 2011 14:29:31 +0000 Subject: [dns-wg] DNSSEC Provisioning for ERX Space Held with ARIN In-Reply-To: <4D8A1586.40409@ripe.net> References: <4D8A1586.40409@ripe.net> Message-ID: On Mar 23 2011, Wolfgang Nagele wrote: >ARIN has just announced that they are now supporting DNSSEC-enabled delegations >for their reverse space. > >For more information, see: >https://www.arin.net/announcements/2011/20110321.html > >This means that RIPE NCC members with ERX space assignments in the ARIN region >can now also make use of DNSSEC. This is excellent news. Thanks to all at RIPE NCC for their persistence with getting this on the road, >To do so, please submit a domain object which includes the ds-rdata field as >you would for any other DNSSEC-enabled delegation. > >For more information on how to do this, see: >http://www.ripe.net/data-tools/dns/dnssec/procedure-for-requesting-dnssec-delegations I was a bit surprised by this section: | These tests will only be done for "ds-rdata:" attributes using | supported digest types [1 section 5.1.3]. Currently we support | digest type 1(SHA1). | | If the "ds-rdata:" attribute uses an unsupported digest type, you | will see a warning message, however the "ds-rdata:" content will | still be copied into the parent zone. Is there some technical reason that you can't check digest type 2 (SHA-256) records? It wouldn't seem to be exactly bleeding edge technology! -- Chris Thompson University of Cambridge Computing Service, Email: cet1 at ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From wnagele at ripe.net Thu Mar 24 16:11:17 2011 From: wnagele at ripe.net (Wolfgang Nagele) Date: Thu, 24 Mar 2011 16:11:17 +0100 Subject: [dns-wg] DNSSEC Provisioning for ERX Space Held with ARIN In-Reply-To: References: <4D8A1586.40409@ripe.net> Message-ID: <4D8B5F15.7000907@ripe.net> Hi, > This is excellent news. Thanks to all at RIPE NCC for their persistence with > getting this on the road, We would also like to acknowledge the support of ARIN, without which this could not have been done. > Is there some technical reason that you can't check digest type 2 > (SHA-256) records? It wouldn't seem to be exactly bleeding edge > technology! Our DelChecker is up for renewal and this will include support for things as SHA-256. It is a bit too early for me to give a release date just yet. Please bear with us. Until then you can still publish SHA-256 trust anchors. It just means that we will not verify them before publication. A note on the bleeding edge part. While I agree that the technology is not that new, it is unfortunately still the case that on most systems crypto libraries do _not_ support it. OpenSSL on most vanilla Linux distributions is just one example. Regards, Wolfgang From denis at ripe.net Tue Mar 29 15:06:41 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 29 Mar 2011 15:06:41 +0200 Subject: [dns-wg] Deletion of Forward DOMAIN data from the RIPE Database Message-ID: <4D91D961.8070804@ripe.net> [Apologies for duplicate emails] Dear colleagues, The RIPE NCC is ready for the next stage of this clean-up process, as discussed at the last few RIPE Meetings. The RIPE Database still contains many forward DOMAIN objects, listed below. Only four TLD Registries are still actively using the RIPE Database for their whole provisioning or for a second-level dataset, .SM, .MC, .NO, .IL. These four Registries are working on alternative solutions and their data will remain in the RIPE Database until their arrangements are complete. Looking at the update logs for the last year, there has been very little activity on all the other DOMAIN data (summarised below). The occasional updates are End Users who maintain their own DOMAIN objects. Even though the activity logs show that these Registries were not actively using the RIPE Database, we still contacted them for confirmation. In some cases, we received no response. The RIPE NCC will delete all the forward DOMAIN data (except for the four active users) in the week beginning Monday, 4 April 2011. Regards, Denis Walker Business Analyst RIPE NCC Database Group List of registries with forward DOMAIN data in the RIPE Database 2 al 12 at 2 az 9 ba 2 by 2 cm 24 com 1 cx 1 dz 8 ee 2 es 56 fi 2 ga 668 gm 26 hu 8 ie 176 il 2 ir 1 jj 3 jo 1 ke 1 kg 1 kr 4 kz 1 lb 1 lc 1 lv 1 ly 1 ma 702 mc 1 mt 55 net 82 no 9 org 1 pk 99 pl 20 pt 4 ru 6 sa 2210 sm 33 tr 1 va Activity over last year 2010 1 Create Modify delete fo 34 29 12 il 0 2 0 sm 27 12 15 2010 2 Create Modify delete fo 26 21 41 md 0 2 0 pl 0 1 0 sm 18 44 12 2010 3 Create Modify delete TLD si 0 0 1 es 0 0 1 fo 34 48 24 ly 0 0 3 sm 24 23 15 2010 4 Create Modify delete fo 38 34 13 net 0 0 1 si 0 0 1 sm 26 9 13 2010 5 Create Modify delete TLD de 0 1 0 fo 32 27 13 gr 0 1 0 il 0 2 0 mc 0 1 0 org 0 1 0 sm 37 10 10 2010 6 Create Modify delete TLD dk 0 1 0 fo 3 10 2 mc 2 8 0 sm 9 5 12 2010 7 Create Modify delete TLD fo 0 1 0 fo 0 0 1 gr 0 2 0 mc 2 2 0 sm 18 8 16 2010 8 Create Modify delete TLD fo 0 3 0 fo 0 0 3109 sm 16 14 10 2010 9 Create Modify delete mc 2 0 0 sm 20 20 9 2010 10 Create Modify delete be 0 0 1 gr 0 1 0 mc 1 0 0 sm 25 16 119 2010 11 Create Modify delete be 0 0 30 bg 0 0 5 cz 0 0 3 de 0 0 1 fi 0 1 0 gl 0 0 22 gr 0 0 75 it 0 0 2 lv 0 0 62 md 0 0 15 ro 0 0 1 se 0 0 6 sm 29 15 11 tn 0 0 2 ug 0 0 1 uk 0 0 4 2010 12 Create Modify delete sm 11 272 7 2011 1 Create Modify delete mc 2 0 0 sm 22 9 23 2011 2 Create Modify delete TLD is 0 1 0 fi 0 2 0 sm 13 3 66