- dns-wg - mailman.ripe.net

IANA proposal for changing TLD delegations
by Jim Reid 25 Jun '04

25 Jun '04

IANA has published a proposal on how it plans to deal with changes in the root zone for TLD delegations. It's at http://www.iana.org/procedures/delegation-data.html. I would recommend that people read this and comment on it. TLD owners in particular might want to pay special attention to the part headed "IANA Procedures for Removing Problematic Delegation Data ". Unfortunately the closing date for comments was June 21st -- I've only just seen this document. However a revised version is promised for June 28th, so there may still be an opportunity to comment on the current one.

3 2

Re: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Jim Reid 16 Jun '04

16 Jun '04

Not having seen the whole discussion thread, it's a bit hard to make sense of what's been said. However it appears to be that someone is saying that the need for anycasting (and more specifically special address allocations for anycast name servers) can be discounted if ENDS0 was more widely used. This is a flawed argument IMO. As Peter has said, resolvers that aren't EDNS0-aware will still be pounding on the parent zone's name servers. [They're also much more likely to be the resolvers that are misconfigured to go to the root to reverse lookup RFC1918 addresses, don't implement negative caching and so on....] Simply adding more NS records and glue in the parent zone's delegation for a child zone is no help. For one thing, most name server implementations have a limit on the number of name servers they can handle for a delegation. Adding extra NS records is even less help when those servers have IPv6 addresses => yet bigger DNS payloads. In fact adding extra servers and/or IPv6 addresses may be worse because there's an increased likelihood of truncated responses getting sent to these non-EDNS0 resolvers, resulting in retried queries over TCP. Nasty. Aside from these DNS protocol issues, there are plenty of other good reasons for deploying anycasting for important DNS infrastructure. That's why lots of the root and TLD name server operators are doing this already. Ironically, these include the NCC's root name server. Anycasting provides increased robustness, extra redundancy, improved performance, better scalability, extra capacity/throughput, defence in depth from DDoS attacks, etc, etc. Anycasting isn't going to go away even if all the world's DNS software implemented EDNS0. Anycasting is a fact of life. And it will become more prominent in future. So if the address policy WG is reluctant to endorse special address allocations for DNS anycasting, I'd ask them to reconsider. If it helps, we could ask the DNS WG to discuss the issue and perhaps make a recommendation to the address policy WG.

2 1

Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation
by Peter Koch 15 Jun '04

15 Jun '04

Hello, {I'm copying this to the DNS wg list, since the protocol issues may probably be better discussed there. Hey, I *love* these [tags] :-(} [address allocation for anycast of DNS nameservers] Havard Eidnes <he(a)uninett.no> wrote: > > ------------ snip ------------ > > "Operators providing DNS for a zone served by a number of name servers > > such that the total response size when including the list of > > nameservers for the zone is close to the UDP packet size limit may > > Hm, it's not "the UDP packet size limit", it is "the packet size limit > for DNS over UDP without the application of EDNS.0". I may not have > followed things too closely, but it makes me sort of wonder why a push towards EDNS.0 is not being advocated instead of polluting the routing > space to compensate for people who have not yet upgraded their > software... Of course, people may still dream up configurations which Isn't then the parent of those trying to do anycast suffering from those resolvers unaware of EDNS0? In other words: what could the applicant do? -Peter

1 0

reverse delegation of a /16 doesn't work with new interface
by Marc Pauls 17 May '04

17 May '04

Hello, trying to setup a reverse delegation for a /16 (where ns.ripe.net is required) through the new mnt-domains based interface at auto-dbm(a)ripe.net doesn't seem to work. After trying several times I decided to send the delegation mail to the old auto-inaddr(a)ripe.net and it worked fine. When creating a new delegation of a /16 I always thought that the mandatory ns.ripe.net becomes a delegated nameserver itself by passing it as one of the nserver: entries in the domain template. e.g: domain: 222.111.in-addr.arpa ... nserver: ns1.customer-ns nserver: ns2.customer-ns nserver: ns.ripe.net ... That always worked with auto-inaddr(a)ripe.net but doesn't with auto-dbm(a)ripe.net. The error messages given by the database: ***Warning: (related to ns2.coustomers-ns) The nameserver ns.ripe.net was found listed for the zone at ns2.comstomers-ns (10.10.10.10), but was not one of the delegated nameservers (ns2.customers-ns, ns1.customers-ns). Only the delegated nameservers should be listed anywhere for the zone. ***Warning: (related to set) Only 2 delegated nameserver(s) ns2.customers-ns, ns1.customers-ns. There should be at least 3. ***Warning: (related to set) The RIPE NCC nameserver exactly one was not present in the list of delegated nameservers for this zone (ns.ripe.net) This is required by the RIPE NCC for this type/size of zone. Of course the NS-entries in the zones are all okay and contain ns.ripe.net of course... how I wrote... with auto-inaddr(a)ripe.net it worked. All in all that means that ns.ripe.net doesn't become authorative itself by passing it to a new /16 delegation through the new interface and so the database returns error messages. kind regards, Marc.

3 2

DNSSEC road map development meeting during RIPE
by Jaap Akkerhuis 28 Apr '04

28 Apr '04

This is a synopsis of an announcement which might be interesting for those people planning to come to the Ripe meeting. The full invitation will be published the web site: http://www.sdl.sri.com/other/dnssec/ where some more info is available. If you want to come, please register via this site (and ignore the deadline). jaap ------- An Invitation: Building a Road Map for DNSSEC Deployment Steve Crocker (steve(a)shinkuro.com) Russ Mundy (russ(a)tislabs.com) April 2004 Synopsis What has to be done to move DNSSEC from the specification to deployment? It's time to build a road map and identify any difficulties that have to be overcome. The next step is for prospective vendors, network operators and large users to get involved. We are holding a pair of one day meetings, Monday, May 3 in Amsterdam in conjunction with the RIPE meeting, and Sunday, May 23 in San Francisco in conjunction with the NANOG meeting. These meetings will be small, interactive workshops to extend the DNSSEC community and identify the hurdles. We invite interested parties to come to one or both meetings. These meetings have put together on short notice and we recognize that not everyone who is interested will be able to come. These meetings are just a first step. Notes from the meeting will be posted and other meetings will take place over the next several months. This is a community based, international effort. These meetings are being organized with the support of the U.S. Department of Homeland Security, the U.S. National Institutes of Standards and ICANN. Sponsorship will expand over the next several months. This work is open and will be reported on the net at http://www.sdl.sri.com/other/dnssec/

1 0

K-root mirror instance deployed in Athens
by Dave Knight 27 Apr '04

27 Apr '04

Dear Colleagues, The RIPE NCC is pleased to announce the deployment of a new mirror instance of the K-root Internet root name server in Athens, Greece on April 26 2004. This node has been sponsored by the Greek Research and Technology Network (GRNET) and is located at the Athens Internet Exchange. The announcement can be found at: http://www.ripe.net/ripencc/kroot-athens-20040427.html Kind regards, Dave Knight RIPE NCC

1 0

New Policy and Procedures for Reverse DNS Requests
by Olaf Kolkman 26 Apr '04

26 Apr '04

Dear Colleagues, (Apologies for duplicate messages) The RIPE NCC has implemented a number of changes in the policy and procedures for requesting reverse delegation. This follows the effort to streamline reverse DNS operations [1] and make it easier for network administrators to manipulate related DOMAIN objects. You should be aware of the following changes: When users want to update their reverse DNS information, they send an e-mail to <auto-dbm(a)ripe.net> (formerly this mail was sent to <auto-inaddr(a)ripe.net>). The database update program will verify the DNS information and update the RIPE Database. The information will appear in the DNS after a short delay. The policy constraints have been reduced. Previously only space assigned to End Users could be reverse delegated in DNS. This caused administrative burden to LIRs, as every time space was assigned, reverse DNS had to be set up for that space. Now reverse DNS can be set up for an entire allocation. Documentation that details the new setup and authorisation can be found at: http://www.ripe.net/reverse/ More details on these developments is provided below. * The reverse DNS policy as proposed in [3] is published as ripe-xxx. The main change to the policy is the removal of the requirement for valid assignments. Reverse delegations can also be requested by non LIRs if an appropriate "mnt-domains:" attribute is in place in the corresponding INETNUM/INET6NUM object, when submitting requests to <auto-dbm(a)ripe.net>. * The <auto-inaddr(a)ripe.net> interface will be deprecated as of 1 July 2004. To allow for a graceful transition, the "mnt-domains:" based authorisation mechanism has not been implemented for the <auto-inaddr(a)ripe.net> interface. This will continue to use reg ID based authorisation. The "mnt-by:" attribute will become mandatory. However, the existence of the "mnt-by:" attribute in DOMAIN objects is not enforced when the object is submitted through the <auto-inaddr(a)ripe.net> interface. Please contact <inaddr(a)ripe.net> if you have further questions. Olaf Kolkman New Projects, RIPE NCC Can Bican Software Engineering Dept., RIPE NCC ---------------------------------------------------------------------- References: [1] Original RDNS Project Proposal http://www.ripe.net/reverse/proposal.html [2] "mnt-domains:" Attribute Proposal http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00007.html [3] Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region http://www.ripe.net/ripe/docs/rev-del.html [4] Webupdates http://www.ripe.net/perl/webupdates.pl [5] http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00008.html

1 0

draft for revised DNS wg charter
by Peter Koch 15 Apr '04

15 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Dear DNS wg members, during the last couple of meetings we have exercised the merger of the former DNR Forum and the DNS working group. It seemed that both audiences had significant overlap and obviously have been interested in each other's work and topics. So, at the end of the last meeting slot at RIPE 47 the people in the room were in favour of combining the efforts into a single working group covering all issues around the DNS and domain names. The dns wg's charter as it currently is documented on the wg's homepage http://www.ripe.net/ripe/wg/dns/ is too narrowly focused anyway, so the chairs would like to suggest the following text as a basis for discussion for our new working group charter: The DNS Working Group discusses current DNS related issues in technology and operations. The WG supports deployment of DNS and DNS-related protocol components by collecting experience and documenting current practice and recommendations. It therefore provides a mechanism for exchanging practical and operational experience with organisations like CENTR and the IETF. The WG discusses DNS software implementations, especially security and scalability aspects as well as performance and interoperability considerations. DNS quality and other factors that may affect the stability of the DNS system are also discussed by the WG. The DNS WG provides a forum for the Registry and Registrar community. It discusses the technical and operational issues arising from registration policies with a specific focus on the deployment of new and emerging features. The charter is intended to reflect what the WG has been doing during the last couple of RIPE meetings. Please send in feedback! You are invited to comment and/or suggest changes and if you're just happy with it - please say so, too. Given that a holiday season is approaching for many of us, the comment period will *end* at 2004-04-19. - -Peter -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: ascii iQCVAgUBQGxfABePjvYGi6TZAQG8pwQAlD+Q7rAxgPzmRAcQZg38RsGHB7dZxcm4 khPrBFWgI7zsqwreCJSjBYnAXANBio4j63YjdGad8ZmopT0MtC94FY1mrx47Yqs2 dn7L58/uFFiYufEQJ8c62bIViltOMKvxsqOngWOYbCyr0Dmaqs3f5ccY4lcAMRap bduAwQID4uw= =MART -----END PGP SIGNATURE-----

1 1

Change in Reverse Zone File Generation
by Olaf M. Kolkman 06 Apr '04

06 Apr '04

Dear Colleagues, Apologies for any duplicate messages. This message about our zone file generation process is for your information, there is no action required on your part. We have completed the cleanup of a number of DOMAIN objects in the Whois Database and NS Resource Records in the DNS files [1, 2 and 3]. We have verified that data within zone files generated from the Whois Database matches the data currently in our zone files. We will start generating our zone files from the Whois Database on Tuesday 13 April 2004. >From a DNS point of view this change will be transparent. DNS delegations will not change and there will be no interruptions in DNS service. The change in the method of zone generation allows us to migrate to a new interface for submission of reverse delegation requests. We plan to have the new interface available by the end of April, an announcement to the <dns-wg(a)ripe.net> and <ncc-services-wg(a)ripe.net> mailing lists will be sent. We hope we have informed you sufficiently, do not hesitate to contact us if you have further questions. --Olaf Kolkman New Projects, RIPE NCC References: [1] Original RDNS Project Proposal http://www.ripe.net/reverse/proposal.html [2] Cleanup Proposal http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html [3] RDNS Project Page: http://www.ripe.net/reverse/rdns-project/

1 0

EOF, Amsterdam, May - Call for Presentations
by Daniel Karrenberg 25 Mar '04

25 Mar '04

[apologies for duplicates, hint: they have the same message-id] Hi Network Operations Folk, NOW is the time to consider making a presentation at the European Operators Forum (EOF) to be held during the 48th RIPE meeting in Amsterdam on Monday 3rd and Tuesday 4th of May 2004. We would like to have as many practical, hands-on presentations as possible this time. Remember: They do not have to be long. We prefer an stand-up interesting 10 minute presentation over a well prepared 90 minutes explanation of something not so interesting to operators. Find some information about presenting below and think about all those experiences this year that might be interesting to other operators. Should you have questions, please do not hesitate to contact me by e-mail at any time. Thanks Daniel -------------------------------------------------------------------------- Information about the EOF and presenting there: http://www.ripe.net/ripe/meetings/ripe-48/eof.html Information about the meeting in general: http://www.ripe.net/ripe/meetings/ripe-48/index.html -------------------------------------------------------------------------- Guidelines for submitting abstracts: We expect to finalise the program in shortly. We will get back to you then with scheduling details. In the meantime please provide the information below. We place special emphasis on the abstract which should contain references to related material already available if possible. Please send this to eof-coord at-sign ripe.net. - Author(s) - Speaker - (Working) Title - Abstract - Draft Presentation (if available) - Relation to other known work and/or presentations if known - Time Requested It would be helpful if the abstract was written such that potential attenders will learn what to expect from the presentation, i.e. "The presentation will describe our experiences with the Red Packet Washer (http://www.netdet.net/RPW/) We have been using the device for half a year now. It helps us deliver more hygienic datagrams to our customers and peers. We will discuss problems with packet discolouring as well as increased throughput to our upstreams due to decreased clogging by dirty micrograms. We will compare performance with the hand-scrubbing of packets which we used previously. Currently we are optimising device management and getting bugs resolved. We will strive to include the latest experiences in our report." is much better than "The presentation will describe the Red Packet Washer made by Network Detergents."

1 0