- dns-wg - mailman.ripe.net

dnssec statistics action point 52.2
by Brett Carr 19 Sep '06

19 Sep '06

At the RIPE 52 meeting, the DNS Working Group asked us to provide statistics on secured delegations within RIPE NCC hosted zones. At the time of this e-mail, the figures are as follows: Total number of zones hosted as a primary by RIPE NCC - 113 Total number of primary zones that are signed - 72 Total number of NS records in all zones - 521,811 Total number of DS records in all zones - 61 We are of course happy to answer any questions about these numbers. Background Information: The RIPE NCC hosts the majority of the 41 unsigned zones on behalf of third parties. We can and will continue to expand the list of signed zones. The current keys for all zones that we sign are available at: https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys-new.txt We accept signed delegations (DS records) for all in-addr.arpa zones where we are primary. We cannot currently accept signed delegations (DS records) for those zones in ERX space, where we are not primary for the zone. The two graphs attached to this e-mail show the distribution of both NS and DS records. Regards. Brett. -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8

3 3

RIPE NCC DNSSEC Key Maintenance: Preemptive Key Signing Key Rollover
by Ruben van Staveren 15 Sep '06

15 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate e-mails] Dear Colleagues, Due to the recently published weakness in PKCS 1.5 signatures in OpenSSL RSA crypto, the RIPE NCC will be performing an key signing key (KSK) rollover earlier than planned. We have completed the first phase of the procedure and have published the new Key Signing Keys (KSK's). The deprecated keys will remain valid for a maximum of three months. We recommend that you reconfigure any resolvers to use the new keys. You can download them from: https://www.ripe.net/projects/disi//keys/ripe-ncc-dnssec-keys-new.txt The DNSSEC Key Maintenance Procedure is available at: https://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html The following references may be useful: http://www.openssl.org/news/secadv_20060905.txt http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339 We thank you for your patience and apologise for any inconvenience this maintenance may cause. If you have any questions regarding this maintenance please e-mail: ops(a)ripe.net. Regards, Ruben van Staveren Operations Group RIPE NCC -----BEGIN PGP SIGNATURE----- Comment: For info see https://www.ripe.net/rs/pgp/ iD8DBQFFCVSambreNIsOKy8RAsRWAJ9jVQT++r9aZ3b0sCAl+IMFaUQLrgCfTtFb 5Az85tIv7TrWHVYoyt4Wvto= =tvtB -----END PGP SIGNATURE----- -- Ruben van Staveren RIPE Network Coordination Center Operations Group Singel 258 Amsterdam NL http://www.ripe.net +31 20 535 4444 PGP finger print 6501 4389 A675 477E DCE5 53D8 9108 49E2 DAFC 271B

3 2

Announcement DNS for LIRs Training Courses
by RIPE NCC Training Services 29 Aug '06

29 Aug '06

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Tuesday 5 September 2006 Time: 0900-1700 Location: Reykjavik, Iceland Hosted by: TM-Software http://www.t.is/ And Date: Friday 29 September 2006 Time: 0900-1700 Location: Amsterdam, Netherlands And Date: Friday 27 October 2006 Time: 0900-1700 Location: London, United Kingdom And Date: Tuesday 28 November 2006 Time: 0900-1700 Location: Rome, Italy Hosted by: CASPUR http://www.caspur.it/ Hosted by: NAMEX http://www.namex.it/ And Date: Friday 15 December 2006 Time: 0900-1700 Location: Moscow, Russian Federation The main objective of the DNS for LIRs Training Course is to provide LIRs with information about the different DNS related services the RIPE NCC has available for them. It covers reverse DNS procedures and checks, as well as giving information about DNS Monitoring (DNSMON), K-Root and anycasting. The course also covers DNSSEC and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zones. Please note that the DNS for LIRs course focuses on DNS services and procedures related to being an LIR. The course does: - NOT teach the basics of DNS - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe fully how to operate a Local Internet Registry (LIR) The course is intended for technical staff of LIRs. It is assumed that all attendees are familiar with common DNS terminology and have a practical knowledge of operating DNS servers. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/dns REGISTRATION: ============ To register for this course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

Review of IANA Root Zone Technical Checks
by Brett Carr 21 Aug '06

21 Aug '06

This may be of interest to some of the folks on here. Brett -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 > -----Original Message----- > From: owner-dnsop(a)lists.uoregon.edu [mailto:owner- > dnsop(a)lists.uoregon.edu] On Behalf Of Kim Davies > Sent: Saturday, August 19, 2006 6:39 PM > To: dnsop(a)lists.uoregon.edu > Subject: [dnsop] Review of IANA Root Zone Technical Checks > > Dear Colleagues: > > Yesterday we started a review of IANA's procedures relating to > validating NS records and glue supplied by TLD operators for insertion > into the root zone. > > The discussion paper, as well as a public forum for comments, is at: > > http://www.icann.org/announcements/announcement-18aug06.htm > > We'll run this comment period until 30 September, after which we will > use the guidance provided to draft an operational procedure on the > topic. > > Kindest Regards, > > Kim Davies > Internet Assigned Numbers Authority > > > > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

1 0

AAAA problem document
by David Malone 13 Aug '06

13 Aug '06

It seems that the AAAA problem draft is still on the agenda. I've included the current version of the document below, which includes some minor updates, clarifications and edits from the last version. There weren't too many substantial comments last time and the issue isn't changing rapidly. I'd suggest that we either go with something close to this version of the document, or close the item and point at the Internet Protocol Journal article. David. Misbehavior of DNS when faced with IPv6 or other New Query Types David Malone August 2006 Abstract This document is a short description of problems with certain DNS systems that have come to light with the deployment of IPv6 enabled software. 1. Introduction One of the services that DNS provides is a facility for mapping host names to IPv4 addresses. This is probably the most common used service that DNS provides, and is achieved by requesting a record of type "A" for the host name. Records of type A can only store an IPv4 address, and so with the introduction of IPv6, a new record type, AAAA ("quad A"), has been introduced. It is becoming increasingly common for software to first issue a request for a record of type AAAA, and if no record of that type is found then to issue a request for a record of type A. A request for a record of type AAAA causes no problems for most DNS servers, however some DNS server implementations have been found that have problems answering other queries. Some DNS implementations have problems with only new types, such as AAAA, and others have problems with any query not of type A. The end result of these issues is that connecting to a site using a problematic nameserver may be impossible, intermittent or significantly delayed. The technical details of these problems are explained in [RFC4074]. Note that these problems are not limited to hosts connected to the IPv6 Internet. Any host may look up an IPv6 address even if it does not wish to make an IPv6 connection. This might include hosts processing e-mail headers of a mail that has passed through an IPv6-capable system or a host processing log files from an IPv6-capable system. 2. Problem Extent In Q1 2004, a survey of nameservers for 24000 hostnames mentioned in web proxy logs found about 0.5-1% of nameservers seem to have to have a problem of this nature. This corresponds to about 1.8% or URLS that are impacted by the problem. For more details of this survey see [IPJMISBEHAVE]. In terms of DNS server software, DNS load balancers seem to be commonly affected. This means that high-volume sites, such as ad servers, are often victims of this problem. Due to the embedding of ad-server images in web pages, the extent of the problem may be experienced by users of other web sites displaying these ads. 3. Testing New DNS Systems To prevent introducing more DNS servers with such issues, testing of new DNS equipment should include checking that the response for records is in accordance with the RFCs (in particular [RFC1035], [RFC3597] and [RFC4074] mentioned above). As DNS load-balancing software has often fallen foul of these problems, particular care should be taken in testing and validating such systems. Simple testing can be conducted by making a query for a AAAA record using a tool such as dig. Supposing that the server has IP 192.0.2.1 and is to serve the domain example.com, queries such as the following should be made: dig AAAA exists.example.com @192.0.2.1 dig AAAA does-not-exist.example.com @192.0.2.1 dig AAAA www.subdomain.example.com @192.0.2.1 In each case the server should return the correct response. In the first case, the correct response is a number of AAAA records (0 if there are none) and a status of NOERROR; in the second case, the returned status should be NXDOMAIN; in the third case the server should return a referral to the servers for the subdomain. Even if the server is only responsible for reverse zones, where queries for AAAA records are uncommon, such tests are still useful as reverse zones may still receive queries for other new record types. A simple web-based tool for testing is available at http://www.cnri.dit.ie/cgi-bin/check_aaaa.pl This tool can detect some of the most common problems given a domain name. 4. Addressing the Existing Problem The fact that problematic nameservers exist is in itself a problem. Where these issues cause direct inconvenience to your user-base, the maintainers of the offending server and the maintainers of the DNS data should be notified to allow a normal service to be restored. However, often it is difficult for end users to identify the source of these problems (for example, where an image embedded in a web page is being served from a host with a problem hostname). It is also possible to automatically produce lists of names and nameservers that exhibit these problems. Clearly it is possible to automatically mail hostmasters or to publish lists based on such data. However, as service maintainers are usually primarily concerned about complaints from paying users, the most effective way to tackle this problem may be for these users to users to notify service maintainers. The action required to restore normal service may just require a simple software upgrade if the DNS server vendor has already addressed these issues. A DNS server vendor should be able to address these issues rapidly using the RFCs referenced in this document. 5. Related Issues There are a number of other IPv6-related DNS issues that warrant mention. 5.1 A6 Records Initially, IPv6 addresses were to be determined in the DNS using A6 records, rather than AAAA records. Nameservers that respond incorrectly to AAAA requests are also likely to respond incorrectly to A6 records. A6 queries are now considered experimental. 5.2 ip6.int vs. ip6.arpa Originally, two schemes were proposed for IPv6 reverse lookups. One used the ip6.int domain and the "nibble" format. The other used the ip6.arpa domain and the "bitstring" format. The system that has now been settled on uses the ip6.arpa domain and the nibble format. Most use of the ip6.int domain has ceased and it has been deprecated formally [RFC4159]. However, some older IPv6 clients may still issue queries in this domain. 5.3 Resolver Issues There can also be issues with DNS resolver libraries. Some resolvers may not react as expected when asked to act on unusual addresses (such as IPv6 mapped addresses). Other resolvers have had problems if a host has both IPv4 and IPv6 addresses. Still others have had problems if hosts have only IPv6 addresses. Problems have also been reported with some caching recursive resolvers included in 'home router' products, which behave incorrectly when dealing AAAA or non-A record queries. Some of these issues can be worked around by application developer, however many vendors now have software updates to address these issues. 6. Acknowledgments This work is a product of the RIPE DNS Working Group. 7. References [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RCF3597] A. Gustafsson, "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC4074] Y. Morishita and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005. [RFC4159] G. Huston, "Deprecation of "ip6.int"", RFC 4159, August 2005. [IPJMISBEHAVE] D. Malone, "Misbehaving Name Servers and What They're Missing", The Internet Protocol Journal - Volume 8, Number 1, March 2005.

1 0

Agenda Items for RIPE53
by Jim Reid 11 Aug '06

11 Aug '06

Although we're in the middle of the summer holidays, it's time to start planning RIPE53. If you have any suggestions for agenda items for the WG -- presentations, discussion topics, etc -- please let dns- wg-chair(a)ripe.net know. It is easier to allocate slots in the agenda when suggestions are made early, so your co-chairs would appreciate it if your input arrived sooner rather than later. Thanks.

1 0

The RIPE Database and DNS management system has been updated
by Katie Petrusha 08 Aug '06

08 Aug '06

Dear Colleagues, We have updated the RIPE Database and DNS management system to implement several new features. The change in the RIPE Database: - There is a new syntax for the "nserver:" attribute in the DOMAIN object to support IPv4 and IPv6 glue name servers. The changes in the DNS management system: - The management of DNS delegation in the e164.arpa (ENUM) zone has been brought under the same provisioning system as reverse DNS management. - The Delegation Checker has been updated to support glue name servers for IPv4 and IPv6 - The Web Zone Delegation Checker has also been updated You can find more details about the proposal for implementation at: http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00128.html -- Katie Petrusha RIPE NCC

1 0

Proposal to change the syntax of "nserver:" attribute
by Katie Petrusha 11 Jul '06

11 Jul '06

[Apologies for duplicate mails] Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and update the delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server without a trailing "." [ipv4_address] is an IPv4 address of the name server [ipv6_address] is an IPv6 address of the name server If [domain_name] is followed by an IP address, it must be inside the zone that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.test.net 168.0.0.1 nserver: ns1.test.net 0::0 nserver: ns1.example.com nserver: ns1.d1.example.com All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: DNS checks applicable to glue records will be added to the Zone Delegation Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html) -- Katie Petrusha RIPE NCC

15 35

List of DNS WG Action Items updated
by Peter Koch 03 Jul '06

03 Jul '06

Dear WG, with the meeting minutes for the DNS WG meeting at RIPE 52 now being final, the action item list at <http://www.ripe.net/ripe/wg/dns/dns-actions.html> has been updated accordingly. Items 51.2 and 51.5 are now "done". -Peter

1 0

Final RIPE 52 DNS WG minutes
by Peter Koch 29 Jun '06

29 Jun '06

Dear DNS WG, here are the final edited meeting minutes for Istanbul. There were no comments received for the draft version posted in <http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00111.html>, so the changes are a typo and a clarification of action item 52.3 only. Thanks again to Adrian for the minutes and to Susannah and Caz for acting as jabber proxies. -Peter ----------------------------------------------------------------------------- RIPE DNS WG minutes for RIPE 52, Istanbul ----------------------------------------------------------------------------- WG: DNS Meeting: RIPE 52, Istanbul Date-1: Thursday, 27 April 2006 Time-1: 11:00 - 12:30 (UTC +0300) Chair-1: Peter Koch Minutes-1: Adrian Bedford Jabber: xmpp:dns@conference.ripe.net J-Scribe-1: Susannah Gray J-Script-1: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/dns.txt Audio-1: http://www.ripe.net/ripe/meetings/ripe-52/podcasts/dns-01.mp3 WG URL: http://www.ripe.net/ripe/wg/dns/ Material: http://www.ripe.net/ripe/meetings/ripe-52/presentations/index.html Agenda: http://www.ripe.net/ripe/meetings/ripe-52/agendas/dns.html ----------------------------------------------------------------------------- 0) Administrivia To remove the need for changeover between presenters, Andrei asked that items 4 and 5 be switched. The WG agreed to this. There were no other changes to the agenda. ----------------------------------------------------------------------------- 1) Status Reports o IANA Overview (David Conrad, IANA) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-iana.pdf> Daniel Karrenberg commented on the proposed new IANA website, he was interested to see it was a draft and that feedback was encouraged. Jim Reid asked about the IDN testing and wondered if this would happen within the root zone or if there would be a test bed. David replied that this would be discussed in more depth in the next slot. If it were to happen within the root zone, IANA would be involved; otherwise they would not have a role in this. o IETF - DNSEXT, DNSOP and Others (Olaf Kolkman, NLnetLabs) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-ietf.pdf> Ed Lewis asked about experiences people had with split view DNS. Around 15 people said that they had. He also wondered if people who had inherited systems found them confusing. His questions lead him to ask how important the IETF documents were on this topic. Although the particular draft (draft-krishnaswamy-dnsop-dnssec-split-view) was more than a year old, there had been little comment. Olaf replied that there is a need for people to commit to work with the DNSEXT and DNSOP working groups and review papers. If there are not five people willing to do this, then the work is stalled. Carsten Schiefner asked if there was any relationship between the nameserver ID flag (draft-ietf-dnsext-nsid) and Host Identity Protocol (HIP). Olaf explained there was no relationship. Daniel Karrenberg commented that if using split DNS, it is vital to review your work regularly. The deployments out there use different nameservers to make for easier debugging. He added that maybe there is no current solution to the problem. o DNSSEC News/Statistics from the NCC (Brian Riddle, RIPE NCC) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-dnssec-p…> Daniel Karrenberg suggested the RIPE NCC prepare a presentation on the causes of the extra network traffic (in excess of the predicted growth) for the next RIPE Meeting. This was accepted as an action item. Jim Reid asked what might be causing the additional 4% of CPU cycles. Brian promised to investigate and report back. Ed Lewis asked about registration activity and requested that the RIPE NCC report on how many signed zones and how many signed delegations exist in the NCC maintained reverse tree. Brian agreed to look into this and report back either through the working group mailing list or at the next meeting. Olaf commented that when writing ripe-352, the authors promised to look at the effects of DNSSEC on the amount of due queries. A paper on this is ready for publication on the NLnetLabs website. (post meeting hint: <http://www.nlnetlabs.nl/downloads/dnssec-effects.pdf> ----------------------------------------------------------------------------- 2) Action Item Review (Peter Koch) <http://www.ripe.net/ripe/wg/dns/dns-actions.html> 48.1 This is still to be written up - ongoing 48.2 Mans had made some progress, he will continue the work, including a SIG(0) approach and hopes to complete the work by the next RIPE Meeting - ongoing 49.1 This is on hold as a presentation is being made to the NCC Services Working Group. 49.2 Some work has been done. Jim will circulate a draft to Fernando and the DNS WG co-chairs in the coming weeks. - ongoing 51.1 see plenary presentation on K-root 51.2 see (4) 51.3 Liman has still to write this up. It will possibly be handed over to the NCC Services Working Group. For now it will stay with this group until there is further clarification on the proposal. - ongoing 51.4 - ongoing 51.5 see (6) ----------------------------------------------------------------------------- 3) Anycast on K-Root (Lorenzo Colitti, RIPE NCC) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-kroot-an…> Daniel Karrenberg noted that he hoped everyone was happy with how the RIPE NCC was running K. Andrei later amplified this and outlined a few plans to deploy a further global node on the west coat of the US and then gradually more local nodes. They would look at where successful local nodes existed. He wanted to know that the community supported these plans. Comments were made that local nodes tended to have greater impact when deployed in places where there were no global nodes and in more remote locations. Daniel thanked him for these comments, but wished to point out that global nodes are paid for by the RIPE NCC as the operator, local nodes have a contribution made by local hosts. There was a question about whether the RIPE NCC could look into doing some work to compare experiences and impacts gained by other root operators and look at different set-ups in use. Lorenzo said he would personally find this interesting. Daniel Karrenberg backed this by saying he felt it would be useful work. He asked that anyone with suggestions should contact Lorenzo directly. Randy Bush wished to state that he was happy with how the service had been running so far. He had reported a bug and was encouraged by the response from the RIPE NCC to resolve the issue. ----------------------------------------------------------------------------- 5) Reverse DNS Quality (Brian Riddle, RIPE NCC) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-lame_dns…> George Michaelson commented that it was interesting that Brian felt the difference in measure might come down to methodology. He added that it might just be that APNIC have a higher level of lameness than the RIPE NCC. He attributed some of this to stronger admission controls within the domain update process. APNIC have discussed both tightening and weakening their rules. He concluded by saying that the reason that APNIC had 13% lame, compared with 9% in RIPE, came down to better running of the DNS. Olaf asked what definition was used of lames. Brian replied that a record was seen as lame whenever there was no authoritative answer for the SOA. Jim Reid observed that lameness will always be with us. We need to look at ways of dealing with it rather than keep trying to eliminate it completely. He did feel that we needed to do something from a point of view of operational impact and the resultant load that lameness placed on servers. It would be a good step to alleviate problems rather than just keep insisted to everyone that they should keep their DNS in good order. This presentation, he added, was follow-on from an incident that Jim noticed and flagged to the RIPE NCC. There was a lame delegation caused by a master being unathoritative for an extended period of time. There is a need to look at the issues around the progression of a slave secondary service, a part of doing this job responsibly is having some kind of policy and escalation mechanism for flagging lame master servers. This would make sure something is done before a zone expires on the slave servers. Carsten Schiefner said he would like to see some measures in place to check whether the nameserver set of the parent exactly matches the nameserver set announced by the master of the zone. People can change their configuration all the time and there can be nothing on the master server of the child zone. He felt that monitoring this exact match would be an issue, particularly if these changes are also to be applied for ENUM zones. Peter Koch declared this out of scope for this discussion. Ed Lewis asked what would be done when something is lame and gives no response, should it be taken out of DNS and remove the NS record. Brian asked for the community to give guidance on this. Peter Koch suggested that there be an action on the RIPE NCC to post their questions and write up a proposal and question to submit to the working group mailing list. This would be discussed further offline and formulated as action point. ----------------------------------------------------------------------------- 4) IP6.INT Phase Out (Andrei Robachevski, RIPE NCC) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-ip6-int.…> There was a short discussion about the best way forward with this. A major concern was that all RIRs should coordinate their work to ensure that all IP6.INT delegations are pulled at the same time. David Conrad commented that as maintainer of the .INT domain he had asked about the impact of simply pulling IP6.INT through various mailing lists. He had seen little in the way of significant negative implications suggested if this happened. He was backed up on this by George Michealson, who commented that he had spent some time trying to find any IP6.INT queries without success. Joao and Daniel noted that if something serves no purpose, then it should go. There was a note of caution sounded by David Conrad. RIRs must work together and agree on a date for this to happen. David Kessens commented that it would be useful to discuss this topic further in the IPv6 Working Group later today. ----------------------------------------------------------------------------- 6) Proposal to Bring ENUM Zone Management in Line with the Reverse DNS (Andrei Robachevski, RIPE NCC) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-enum-qua…> Carsten Schiefner commented that he welcomed this proposal. Jim Reid stated that care was needed when it came to the top delegations under E164.ARPA concern national resources. There are issues of sovereignty and national interests. If we are going to report errors in the delegations, we need to handle it with a degree of sensitivity. It could impact on other things that are not directly connected with the RIPE NCC. Andrei replied that it was equally dangerous to keep errors in the delegation. Appropriate checks will stop the errors from propagating into the system. Daniel Karrenberg stressed that the RIPE NCC was sensitive to the issues, but the priority had to be to keep things working. The IAB would be informed as the party responsible for E164.ARPA. Carsten felt the actions remained unclear and that it was up to the group to define the actions. 51.5 was changed to 52.5 to work together to put forward a semi proposal, or a pre-formal proposal on this and the ENUM WG lists and coordinate between the two groups. Andrei saw two parts of the proposal. One side involved automating and making the existing system less error prone, this is just a call to improve the system. The other side was to look at doing regular lameness checks and looking at how the RIPE NCC should act on these. An action was put on Carsten to come up for a more formal proposal for discussion at working group level, it was felt this should not yet be put forward at the more formal level of the RIPE Policy Development Process. Andrei asked for consensus that this should go through to the Database Working Group to have the RIPE NCC automate checks. There was no objection. ----------------------------------------------------------------------------- Date-2: Thursday, 27 April 2006 Time-2: 16:00 - 17:00 (UTC +0300) Chair-2: Jaap Akkerhuis Minutes-2: Adrian Bedford J-Scribe-2: Caz Merrison J-Script-2: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/dns.txt Audio-2: http://www.ripe.net/ripe/meetings/ripe-52/podcasts/dns-02.mp3 ----------------------------------------------------------------------------- 7) Plenaries Followup <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-dnsa…> <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-refl…> <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-enum…> <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-peri…> <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-kroo…> <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-dns-…> Time was given to discussions that followed on from presentations that happened during the plenary. There were several DNS related presentations in the plenary, of which "Security and ENUM" had been discussed in the ENUM Working Group. There was no feedback or questions from the room on any of those presentations. ----------------------------------------------------------------------------- 8) ICANN IDN guidelines & IDN Future (Marcos Sanz, DENIC) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-ican-idn…> During the presentation Patrik Fältström asked about the issue that arises when, for example, URLs such as deutschebank.de and deutsche-bank.de occurs. He wondered if this was the end of the problem. Marcos replied that he did not feel it was. Rob Blokzijl commented that although the presenter started out by saying it was unwise to look at domain name labels as words, he went on to talk about the confusion that occurs when this happens. Marcos agreed, pointing out that he was talking merely about the ICANN guidelines. There are assumptions made about what is in a domain name and he felt this was not the right direction to follow. Rob noted that language is a very rich thing and trying to constrain it in domain names was unwise. He did not feel that any rules or regulations would help. Olaf encouraged everyone to take a look at the IAB document which touched on the same type of issues raised here. It will be published after 17 May 2006. ----------------------------------------------------------------------------- 9) Dynamic Registry Updates (John Dickinson, Nominet) <http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-dynamic-…> Jaap Akkerhuis asked if the work mentioned was available for public use. John replied that it was. Jim Reid asked if tools had been used to inspect the contents of journal files. John replied that this area had been left alone. He also wondered what type of sanity checking was in place when managing the updates. John replied that currently, all existing information was removed from zone files and then the updates made within the same transaction to avoid any errors or duplicate entries. Peter Koch asked for clarification on the point made that updates ran in batches of 500. John explained that updates happened every minute. Whatever was there was automatically updated, if there was less than 500, it would run anyway, if there were more than 500, they would be processed in consecutive batches of a maximum of 500 updates. The discussion then moved onto reliance on transfer methods, John stressed that backup methods were in place where there were potentials for communication errors. It was stressed that this was not to be seen as real-time dynamic updating. The TTL and SOA values had not been adjusted and there were no plans to do this. ----------------------------------------------------------------------------- X) I/O with other WGs ENUM related issues were already covered under (6). ----------------------------------------------------------------------------- Y) AOB Peter Koch wished to follow up on a discussion in the Plenary. An Internet Draft will soon be published addressing both reflection and amplification attacks. He encouraged everyone here to read this and comment on it through both the DNS WG Mailing List and also through the IETF DNSOP List. A show of hands suggested a need to cross post the announcement about the draft. ----------------------------------------------------------------------------- Z) Wrap-Up & Close Jaap summarized the action items: 52.1 RIPE NCC: investigate causes for extra DNSSEC network traffic (in excess of the predicted growth) and extra CPU cycles 52.2 RIPE NCC: report number of signed zones and signed delegations in the reverse tree 52.3 RIPE NCC: post questions and proposal to wg mailing list on how to deal with lame delegations when either the NCC is responsible for maintaining the parent or for running a (secondary) server for the child that is or is about to become delegated lame due to an unavailable *xfr source. [this is related to 48.1, but differs in that it should suggest ways forward for ns*.ripe.net] 52.4 RIPE NCC: automate and streamline the process for ENUM delegations, including checks similar to those applied to the reverse tree 52.5 Carsten Schiefner: [continued from 51.5] write a proposal for performing regular lameness checks in E164.ARPA and actions to follow -----------------------------------------------------------------------------

1 0