From jaap at NLnetLabs.nl Mon Apr 5 23:37:43 2010 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 05 Apr 2010 23:37:43 +0200 Subject: [dns-wg] RIPE-60 coming up Message-ID: <201004052137.o35Lbh8J016828@bartok.nlnetlabs.nl> Now everyone has recovered most of the eastern eggs from this year and he left-overs from last year I would remind you that there is a RIPE meeting coming up. There is still space on the agenda so we welcome suggestions. Remember, it is your WG meeting. jaap From emile.aben at ripe.net Wed Apr 7 12:11:44 2010 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 07 Apr 2010 12:11:44 +0200 Subject: [dns-wg] Slight Increase in DNS Resolvers Doing Priming Queries after .arpa Signing - Why? Message-ID: <4BBC5A60.5040404@ripe.net> [Apologies for duplicates] In the latest blog on RIPE Labs, we discuss priming queries to K-root: http://labs.ripe.net/content/slight-increase-dns-resolvers-doing-priming-queries-after-arpa-signing-why We have seen a slight increase in the number of sources that issue priming queries to K-root since 18 March, the day after the signed .arpa zone was rolled out. This increase is visible on three out of five global nodes and seems to be caused primarily by resolvers that are not EDNS capable. While this is not causing any significant operational strain on K-root, and we don't believe a significant number of clients have problems with DNS resolution, we still want to know what is going on. We plan to further characterise this (look at TTLs) and hopefully isolate some sources that caused this increase. If you have any insight on this, or have suggestions on what we should look into, please let us know. Best regards, Emile Aben Research Engineer RIPE NCC From jakob at kirei.se Mon Apr 12 22:21:24 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 12 Apr 2010 22:21:24 +0200 Subject: [dns-wg] TCR Approach to DNSSEC Root Key Management now online References: <7347A199-F04F-4D9B-9A00-54083F202327@kirei.se> Message-ID: Greetings RIPE DNSWG members, I'd just like to inform you that the Trusted Community Representatives Approach to DNSSEC Root Key Management is now online and statements of interests may be submitted via http://www.root-dnssec.org/tcr/. See also the ICANN announcement at http://www.icann.org/en/announcements/announcement-12apr10-en.htm. jakob From joe.abley at icann.org Thu Apr 15 01:19:15 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 14 Apr 2010 16:19:15 -0700 Subject: [dns-wg] Root Zone DNSSEC Deployment Technical Status Update Message-ID: <9D2E5864-0FBC-4B66-88D0-229722F1A630@icann.org> This is the fourth 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 http://www.root-dnssec.org/. We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. DOCUMENTATION The following draft document was recently published: - Resolver Testing with a DURZ - TCR - Proposed Approach to Root Key Management ICANN has begun the process of formally soliciting expressions of interest for volunteers from the technical community to act as Trusted Community Representatives. These volunteers will witness cryptographic key ceremonies and also carry out various important roles relating to KSK key management. For more information, see: http://www.icann.org/en/announcements/announcement-12apr10-en.htm Expressions of interest can be submitted here: http://www.root-dnssec.org/tcr/ DEPLOYMENT STATUS KSR exchanges continue between production platforms at VeriSign and ICANN. Build-out of KSK Key Ceremony facilities at ICANN continues, and both facilities (east- and west-coast USA) are expected to be ready on schedule. The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately Unvalidatable Root Zone (DURZ), and subsequently by a conventionally signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. Twelve of the thirteen root servers have now made the transition to the DURZ. No harmful effects have been identified. Some early analysis of packet captures from many root servers surrounding each event was recently presented at the IETF meeting in Anaheim, CA, USA and can be found with other presentation materials at . 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 To come: 2010-05-05: J starts to serve DURZ 2010-07-01: 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.) A more detailed DURZ transition timetable with maintenance windows can be found in the document "DNSSEC Deployment for the Root Zone", the most recent draft of which can be found on the project web page at . From anandb at ripe.net Mon Apr 19 11:38:19 2010 From: anandb at ripe.net (Anand Buddhdev) Date: Mon, 19 Apr 2010 11:38:19 +0200 Subject: [dns-wg] Reverse DNS Delegations to Name Servers in the .YU Domain Message-ID: <4BCC248B.6010003@ripe.net> [Apologies for duplicates] Dear colleagues, On 1 April 2010, IANA removed the delegation of the .YU domain from the root zone. You can read more about this here: http://www.iana.org/reports/2010/yu-report-01apr2010.html With this removal, all names ending in .YU stopped resolving. Berislav Todorovic has informed the RIPE NCC about reverse DNS delegations to name servers in the .YU domain. These reverse delegations are now partially or completely lame. We would like to encourage all users using these name servers to update their delegation information in the RIPE Database to ensure that their reverse delegation continues to work properly. For more information on requesting reverse delegation, please see our 'how to': http://ripe.net/rs/reverse/reverse_howto.html Regards, Anand Buddhdev, DNS Services Manager, RIPE NCC From jaap at NLnetLabs.nl Mon Apr 26 15:37:12 2010 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 26 Apr 2010 15:37:12 +0200 Subject: [dns-wg] "Final" Draft agenda DNS-WG Message-ID: <201004261337.o3QDbCYR031028@bartok.nlnetlabs.nl> And it is packed as usual jaap DNS WG, Thursday May 6th 11:00-12:30, Morning Session A. Administrative matters o Welcome o Scribe selection/introduction o Jabber selection/introduction o Microphone Etiquette o Finalise agenda B. Matters arising from RIPE-59 Minutes C. Review of Action items (No open items) D. IETF Reports - Matthijs Mekking What expired on the DNSEXT & DNSOP meetings during the IETF E. IETF report ire & regops - Ed Lewis "At the Corner of Registration Operations and DNS Operations" F. The RIPE-NCC DNSmon service - Franz Schwarzinger G. DNS operations at RIPE-NCC - Anand Buddhdev K-root's preparations and experiences of the DURZ roll-out, updates about our new reverse DNS infrastructure, and plans for changes in the provisioning software. H. The DNSSEC Testbed in DE - Peter Koch I. Joe Abley - IDNs on the fast track ___________________ DNS WG, Thursday May 6th 14:00-15:30, Afternoon Session K. An OARC Update - Wayne MacLaurin OARC's new executive director will provide an update on OARC. L. DNSSEC-Support by Home routers - Thorsten Dietrich M. News from Opendnssec - Matthijs Mekking N. DNSSEC for Humans - Joao Damas O. Ondrej Surnic - A Firefox DNSSEC Validator plug-in P. Dave Knight - Signing ARPA's children Q. Jaromir Talir - Anycast IPv4+IPv6 DNS in .CZ Z. AOB (Any Other Business) Dave Knight - Last Root server DURZed. Did the sky dropped? If you have another AOB thingy, let the chair person know in advance so some time might be reserved for that From wnagele at ripe.net Tue Apr 27 18:31:24 2010 From: wnagele at ripe.net (Wolfgang Nagele) Date: Tue, 27 Apr 2010 18:31:24 +0200 Subject: [dns-wg] PGP Key signing Party at RIPE 60 Message-ID: <4BD7115C.8080107@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, During RIPE 60[1] in Prague, I would like to organise a PGP key signing party[2] to take place after the working group sessions on Thursday and before the RIPE Dinner. We will meet at the elevators on the first floor on Thursday, 6 May 2010 at 18:00. The process for the signing will be: 1. Add your public key to the keyring[3]. In order for me to be able to print the list, the deadline for this is Thursday, 6 May 2010 at 12:00. 2. You will be provided with a printout of the keyring. It is important that you verify your own fingerprint on it with a trusted copy of your key fingerprint. 3. After we are all gathered, we will take it in turns to read our own key fingerprint so everyone else can verify it on the printout provided. It is best to check off the fingerprints you have verified on the list. 4. Next we will verify the identity of the key owner by using a legal document (passport, driver's license, etc.). For each identity you have verified you can add another checkmark on the printout. 5. Now the official part of the party is finished and once you get back home you can download the keyring[3] and sign each key that you validated. It is easy to identify those by having two checkmarks on the printout. You should then provide the owner of that key with your signed version and possibly upload it to a key-server. If you have any questions or problems, please feel free to contact me. You may also spread the word through other information channels. Regards, Wolfgang Nagele System Engineer DNS Services RIPE NCC [1] http://www.ripe.net/ripe/meetings/ripe-60 [2] http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html [3] http://biglumber.com/x/web?keyring=9155 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvXEVwACgkQjO7G63Byy8e4rgCgn1PzPuCLMiAgPbi9RhElO6sm 2ngAoJ4602nIjEohgKo5GA40nALiObpv =gjDI -----END PGP SIGNATURE-----