August 2005 - dns-wg - mailman.ripe.net

DNSSEC Policy Development Process
by Daniel Diaz 31 Aug '05

31 Aug '05

Hi, Afaik, the RIPE NCC has polled the Community´s opinion about securing the reverse delegation tree in different ways and occassions and again afaik, there´s always been consensus on this to go forward. Olaf and other NCC colleagues have been working on this for years now (already when I still was at the NCC). After reading the policy, procedure and documents related, I agree with it and think this is a good staring point. As randy says, I see this more as an operational experience previous to full deployment but imho it´s also the closest the RIPE NCC (or any other RIR) can/could do at the moment. I also agree with Jim in taking .arpa as starting point. Imho, 'e164.arpa." could have been a better way to start and gain operational experience first (just for the size of it and the fact, as Jim points out, that it´s managed by the NCC). Still... I agree with the current RIPE NCC plans and procedures. Looking into the documents and procedures, it could be a good idea to produce a "clueless client" oriented document to make this more available to those willing to sign their zones etc... (my 2 cents). Regards. -- Daniel.Diaz DDL14-RIPE

1 0

DNSSEC Policy Development Process
by Jim Reid 30 Aug '05

30 Aug '05

Colleagues, you may recall Olaf posted a proposal to the list a few weeks ago. It was about changes to the in-addr.arpa delegation process to accommodate DNSSEC. In other words, updates to the templates and database to allow for keying material, additional checks at the NCC, etc, etc. I'm surprised and a little disappointed that nobody has commented on Olaf's proposal. Perhaps the timing was bad. Since the proposal emerged in the run-up to an IETF during the summer holidays, maybe everyone was too busy getting a sun tan or reading the latest IETF I- Ds. :-) Olaf suggested a deadline of early August for the consultation period. There's been no response on the list, so I'm reluctant to declare consensus without some feedback from the WG. It would not be wise to presume that the WG's silence implied unqualified consent. So, following a discussion with Peter and Jaap, your WG co-chairs have decided to extend the deadline for comments until the end of August. The WG chairs have a meeting on Aug 31st, so that would be a good opportunity to take the proposed policy forward. I would like to ask all members of the WG to read Olaf's proposal and comment on it before Aug 31st, even if it's just to say that you think the proposal is fine as it is. Your comments and feedback would be greatly appreciated. Thanks.

8 16

FYI
by Jaap Akkerhuis 29 Aug '05

29 Aug '05

A new Request for Comments is now available in online RFC libraries. BCP 109 RFC 4159 Title: Deprecation of "ip6.int" Author(s): G. Huston Status: Best Current Practice Date: August 2005 Mailbox: gih(a)apnic.net Pages: 3 Characters: 5353 SeeAlso: BCP0109 I-D Tag: draft-huston-ip6-int-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4159.txt This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO(a)RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050829145515.RFC(a)RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4159 --OtherAccess Content-Type: Message/External-body; name="rfc4159.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050829145515.RFC(a)RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --NextPart--

1 0

Re: [dns-wg] Ripe NCC DNSSEC Deployment
by Brett Carr 29 Aug '05

29 Aug '05

On Mon, 29 Aug 2005, Fearghas McKay wrote: > Brett > > Would it be possible to send this as an inline text announcement rather > than an attached ascii text file ? > Certainly here you go, and apologies for anybody else who had difficulty reading it in it's original format. Brett -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today (Monday 29/08/2005) the RIPE NCC continued their DNSSEC deployment by beginning to sign the following zones: ripencc.com ripencc.net ripe-ncc.com ripe-ncc.net ripencc.org ripe-ncc.org As we are currently testing the success of this deployment step we have not yet publicly announced the keys. Please do not configure keys until they appear on http://www.ripe.net/projects/disi/keys/ The next step in our deployment plan is: During the first week of September: sign the ripe.net zone and publish the public keys for all signed zones at http://www.ripe.net/projects/disi/keys/ Regards - -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFDEyJ6P/nJBHjtetsRAldiAJ9B38xY+CnGLuZkarvgDcNwnKpROgCeO6vh t/Bf1vrYs0CAO2iGl2h7mys= =yr+J -----END PGP SIGNATURE-----

1 0

Ripe NCC DNSSEC Deployment
by Brett Carr 29 Aug '05

29 Aug '05

1 0

Re: [dns-wg] DNSSEC Policy Development Process
by Jaap Akkerhuis 26 Aug '05

26 Aug '05

On Wed, 24 Aug 2005 09:36:18 +0100 Jim Reid <jim(a)rfc1035.com> wrote to me: > > As far as I know, at that time there wasn't a publication to refer to > > at the time that the procedure was published. There are now two: an ID > > from Sam Weiler and an articl in a Journal from Paul Vixie. It > > describes similar methods which different details. > > Hi Jaap. Any chance you could dig out the URLs and post them to the > list? In the ietf namedrop archive is an announcement (http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00807.html) which leads to Pauls paper: http://ietcom.oxfordjournals.org/cgi/content/abstract/E88-B/4/1326 and mentions the early version of Weiler's paper (S. Weiler, "Deploying DNSSEC Without a Signed Root", Technical report 1999-19, Information Networking Institute, Carnegie Mellon University, April 2004.). The draft is of course at the usual place: ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-andrews-dlv-dns-rr-…. jaap

2 1

ccTLD Mailing List
by Brett Carr 19 Aug '05

19 Aug '05

The RIPE NCC have setup a new mailing list aimed at ccTLD operators. The aim of the list is to: 1. Enable ccTLD operators to discuss DNS and other operational Internet issues. 2. Enable the RIPE NCC to communicate with many ccTLD operators in a single forum (For issues related to secondary DNS etc) If you are a ccTLD operator please feel free to sign up to the list here: http://www.ripe.net/mailman/listinfo/cctld Regards -- Brett Carr Ripe Network Coordination Centre Systems Engineer -- Operations Group Singel 258 Amsterdam NL GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8

3 5

DNS hardware
by Bobby Ölander 12 Aug '05

12 Aug '05

Hello! I'm working at a company called Com Hem AB in Sweden, we are at the moment the biggest cabelnetwork company in Sweden. I have a question that concerns the hardware in the server that should be a primary DNS (even the hardware on the secondary DNS could be nice to know about). What I wonder most about is, should the primary DNS be build with a RAID-system? Or is that not importent of the fact there is a secondary DNS? Respectfully, Bobby Ölander NOC Com Hem AB

5 6

To post to this list
by contact＠internetprogress.org 11 Aug '05

11 Aug '05

To post to this list, my emailadress : contact(a)internetprogress.org Sincerely, Guy Lombart

1 0

[pim@bit.nl: Re: [dns-wg] DNS hardware]
by Pim van Pelt 11 Aug '05

11 Aug '05

Hi, Sorry for duplicates, I group-replied and the reply seems to have went to dns-wg-chair. Here's my original response to Bobby's question: | I have a question that concerns the hardware in the server that should | be a primary DNS (even the hardware on the secondary DNS could be nice | to know about). | What I wonder most about is, should the primary DNS be build with a | RAID-system? Or is that not importent of the fact there is a secondary | DNS? It depends on the software you will be running and the amount of queries per second you plan on answering. In the case of bind(9), disk access is low because the server loads zonedata into memory. Other software products (tinydns, nsd) use mmap()ed files, so they access disk but I don't think it'll be that much, because those pages are mapped into memory if you have enough of it. For the ISP I work for [medium sized ISP in the Netherlands], we have two diskless P4 boxes and they each answer some 100qps. They are not loaded or busy at all, and happen to also serve as DNScache [using djbdns stuff at 500qps] and an SNTP service. nsauth1 up 139+08:53, load 0.17, 0.22, 0.23 FreeBSD/i386 (4.10-RELEASE-p5) nsauth2 up 139+09:09, load 0.03, 0.02, 0.02 FreeBSD/i386 (4.10-RELEASE-p5) nsauth3 up 246+14:55, load 0.05, 0.08, 0.07 FreeBSD/i386 (4.10-RELEASE-p5) The difference in load is because most of our customers use nsauth1 as caching nameserver and nsauth2/nsauth3 hardly ever gets hit. groet, Pim -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

1 0