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

RIPE51 Minutes
by Jim Reid 28 Oct '05

28 Oct '05

Colleagues, here are the WG minutes from the sessions at last week's RIPE meeting. These will also be available from the web site in the next day or so. Please send any comments or corrections to the list. Special thanks are due to Adrian Bedford for scribing and promptly producing an excellent set of minutes. This made it very easy for your co-chairs to get the minutes published so quickly and we are grateful to him. Thanks Adrian! RIPE 51 Amsterdam DNS Working Group Session 1 - 12 October 2005 Chaired by Peter Koch Scribe: Adrian Bedford A & B - Administrative Matters: The group approved the minutes from RIPE 50 with no changes: http://www.ripe.net/ripe/wg/dns/r50-minutes.html Updates were provided for the various action points outstanding for the group. http://www.ripe.net/ripe/wg/dns/dns-actions.html 48.1: Peter Koch sent a draft to the working group mailing list before RIPE 50. After detailed feedback from Ed Lewis, the proposal is to be redrafted. Peter hopes to have made progress on this by RIPE 52. Status - Ongoing. 48.2: Måns Nilsson is negotiating on funding to revise the wording of his proposal. Although this is currently stalled, he hopes to be able to sort this out within the coming two months and provide a rough draft in time for RIPE 52. Status - Ongoing. 48.4: David Malone agreed to continue to provide updates on his work. There has been no draft circulated as yet. Status - Ongoing. 49.1: Peter is stalled on this. A proposal was sent to the NCC Services Working Group Mailing List. Peter encouraged members of the DNS WG to investigate this. Status - Ongoing. 49.2: A small group is working on this, but has not yet got too far. Jim Reid hopes to incorporate changes suggested by Fernando Garcia to a Draft RIPE Document by the end of October. Status - Ongoing. 50.1: This will be covered by a presentation at this session from Lorenzo Collitti. Status - Ongoing. 50.2: This has been completed. Jim explained the background. It appears to have come down to a misunderstanding and subsequent poor communication from the IANA. A problem with zone generation for the root zone when communicated suggested a change in IANA policy. This was in fact not the case. IANA fixed the issue and promised that greater care will be taken with future communication. All letters sent to IANA and their replies are available within the mail archive of this working group. Status - Done. C1. IETF DNS Report – DNSEXT and DNSOP Olaf Kolkman - NLnetLabs: Olaf gave updates on IETF Working Group documents for both DNEXT and DNSOP. http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- ietf-dns-report.pdf C2. IETF CRISP WG Marcos Sanz - DENIC Marcos provided an update from an IETF meeting that recently took place in Paris, looking at different documents related to the deployment of CRISP. There were no slides. AREG - The Address Registry profile for IRIS reached Version 12 and Last Call was over at the end of September. Some IESG comments will lead to a further edit and a new version will soon be available. This is close to becoming an RFC. DCHK - This is a paper dealing with a lightweight version of IRIS running on top of LWZ (A UDP transport for IRIS). Documents are advancing. XPC - There are no BEEP large-scale deployments, this meets a need for an alternative, simpler transport for IRIS. It is based on TCP with a small binary header. RREG - Routing Registry profile for IRIS. This is an individual draft and not a working group draft. It provides information about prefixes, Autonomous Systems and contacts. The purpose of the document remains unclear; maybe a mirroring mechanism is what Internet routing registries actually need. Discussion goes on, whether to adopt it into the CRISP working group. Additionally, the .br TLD registry announced their DCHK and LWZ implementations. Shane Kerr commented that those interested in the RIPE NCC deployment of IRIS should attend the Database Working Group session on Friday morning. C3. EPP – The Next Step Jaap Akkerhuis – on behalf of Scott Hollenbeck - Verisign Jaap outlined work by Scott to improve the quality of papers and move them to draft status, using the ietf-provreg(a)cafex.se mailing list. He emphasized that Scott welcomes all comments, questions and feedback from the group. http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-epp-rfc.pdf Peter Koch announced that Policy Proposal 007 (DNSSEC) had now completed its run through the formal Policy Proposal Process and the chairs of the DNS WG had decided that there had been no formal objections. They declared consensus had been reached. http://www.ripe.net/ripe/policies/proposals/2005-7.html Peter asked if the group found updates from IETF useful. He requested feedback on this after the session. Peter also let the group know that the co-chairs welcomed any suggestions of things that the group would like to see discussed or presented at future RIPE Meetings. D: Effect of anycast on K-root: early results Lorenzo Colitti – RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- anycast_k-root.pdf After the presentation, Ladislav Vobr asked about whether anycast technology had been tested before being put into production on K- root. There was interest in how testing had been done and what convinced those behind the project that it was suitable? Daniel Karrenberg, who was involved in the development, explained that the main goal was resilience. The motivation was to increase the protection against Distributed Denial of Service (DDoS) attacks. Prior to deployment, the setup underwent testing. A discussion followed about the merits of anycast and DNS over TCP, with questions asked about whether UDP would be a more appropriate protocol to investigate persistent switching and packet fragmentation. As chair of this session, Peter Koch stated that he felt that it had been discussed at length in the past and added this should be taken up out of this session, as time was limited. The previous discussion is available in the mailing list archive. It was suggested that the RIPE NCC might consider a presentation on how anycasting is working out at RIPE 52. Jim Reid picked up on the scientific paper that Lorenzo mentioned. He asked if this might be published as a RIPE Document. Lorenzo did not see any reason why it could not be. E: DNS Guru Contest Carsten Strotmann -- Men & Mice http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dnsguru-quiz.pdf Carsten encouraged everyone to log on, take the DNS Guru test, and provide feedback. Olaf Kolkman asked about prizes for those taking part. Session 2 - 13 October 2005 Chaired by Jim Reid Scribe: Adrian Bedford Carsten Strotmann announced that there was a prize for those who took part in the DNS Guru Test. He explained that there are polo shirts available to the ten people who score highest. F: DNS Restructuring Update at the RIPE NCC Brett Carr – RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-restructure.pdf Mohsen Souissi of AFNIC commented that while deploying DNSSEC, one of his servers had encountered problems. It caused some fragmentation for IPv6 when using Fedora with a Symmetrical Multi-Processor front end. AFNIC had found a workaround by switching to mono-processor that worked fine. He is still awaiting feedback on a final solution from Fedora core developers. G: Deprecation of ip6.int Andrei Robachevsky – RIPE NCC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- deprecation-ip6.int.pdf Peter Koch asked, how the date would be set and when the RIPE NCC would publicly announce it. Andrei replied that the RIRs had met to discuss this. The probable date they had settled on would be 1 June 2006. The date was set to be sufficiently far enough in the future to allow any discussion to follow the Policy Development Process (PDP). There will be no formal announcement until this date is certain. Andrei asked the group how the RIPE NCC should proceed with this. He suggested three possible courses of action: 1. Just go ahead and present this as an operational issue 2. Enter the PDP system with the suggestion 3. Wait and see Lars-Johan Liman suggested that the RIPE NCC favour the first option, this received support from those in the room and is now an action on the RIPE NCC. H: Key Rollover Paper and Tools Johan Ihren – Autonomica http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- cadr-dnssec.pdf Johan stressed that the presentation he was giving was based on his own private work with Bill Manning and was not representative of the views of Autonomica. The presentation was followed by a live demonstration of the tool. Mohsen Souissi asked how a network operator could be sure that data was correctly configured. He wondered if Johan planned to add additional features to the software to carry out further authentication checks. Johan explained that this would come down to the policy set by each registry. Each would still need to decide on appropriate policies or safeguards before accepting any changes, regardless of how they were submitted. I: RIPE NCC Secondary Service Policy Lars-Johan Liman – Autonomica http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-nodns.pdf Lars-Johan raised the issue of the future of the RIPE NCC Secondary DNS Service. Axel Pawlik asked why this was being discussed within the DNS Working Group and not within NCC Services. The reply was that an agreement was made at RIPE 50 to first float the idea in this group and discuss it before taking any concrete suggestions to the other group. Axel agreed that the proposal made by Lars-Johan made good sense. The RIPE NCC has a basic principle that it would never compete in any area where its members are offering services. Lars-Johan commented that keeping track of this must be difficult as the business plans and strategies of its members are constantly changing. Axel reiterated that he felt in this case, the situation was quite clear. Rob Blokzijl had three remarks to make. He felt that Lars-Johan had stated that the RIPE NCC should focus purely on IP Address administration and little else. He disagreed with this, adding that this was not why the RIPE NCC was created. It was set up as a permanent secretariat to RIPE with a mandate to do coordination activities for the Internet. He added that he fully agreed that the RIPE NCC should not offer a service that a member was also offering. He then wished to clarify the history behind the offering of this service. It was most likely an activity started when there were different circumstances and was valid at a time when there was no DNS industry. He personally felt that if the membership agrees that the RIPE NCC should revisit this activity, he would offer support. He warned that he felt a gradual phase out was preferable to a sudden stop. Some African ccTLDs might find it hard to move to a fully commercial service. They may need to continue using the RIPE NCC service for some time to come. In principal, Rob feels that the NCC should go through all of the ‘non paying customers’ for the service and see how they could rationalise the list. Daniel Karrenberg wished to explain why the RIPE NCC took over ns.eu.net. Whilst he fully agreed with the reasoning behind the proposal, he wanted to clarify some points made in the presentation. The RIPE NCC did not take on ns.eu.net as an ‘act of charity’. At the time when the system was in financial trouble, there was panic, both operationally and politically. There was much talk about greater regulatory powers being given to governments and the RIPE NCC acted to protect the stability of the Internet. Everyone agreed that it was a good thing for the RIPE NCC to do at the time. If ns.eu.net had collapsed, we would see a very different registration and regulatory environment to the one we have now. He felt that the three options offered at the end of Lars-Johan’s proposal needed modification. The options to do nothing or impose a fee and launch this as a RIPE NCC service, were both impractical and not worth pursuing. He favoured the idea of the RIPE NCC withdrawing from its ccTLD Secondary DNS Service, though agreed with earlier speakers that initially this could not be done entirely. He stated that we live in a world where stability and security of the DNS remains a political issue. He suggested we needed a fourth proposal. The community needed to ask the RIPE NCC to look at the obvious beneficiaries who are well able to procure the service commercially and politely ask them to leave. He did not feel that it would be wise to set any actual rules about who can stay and who should leave at this stage. He felt to do this would hamper the work of emerging ccTLDs, who may wish to stay with the RIPE NCC for a while. Daniel was recently in Africa and made the point that the service offering currently still delivered good PR and political benefits. Lars-Johan accepted the points made, but warned against starting to expect any commercial service to be out of the reach financially of emerging ccTLDs. A pricing structure would have to take account of different customer needs. He felt it should not always be seen as a bad thing to force everyone into the same business model. It could work out. Daniel Karrenberg felt that “could” was not good enough here. DNS is seen by the world as the holy grail of communication and the RIPE NCC must avoid making any unpredictable moves. He advised that any changes would need careful consideration. Carsten Schiefner commented that if the RIPE NCC stopped serving secondary servers for ccTLDs, the ccTLDs would most likely then organise something amongst themselves. It would not follow that they would all want to start paying for a service and the problem as such would not go away. Jaap Akkerhuis wished to comment on why ns.eu.net ended up at the RIPE NCC. He recalled that at the time, it was down to a toss of the coin whether the service ended up with the RIPE NCC or SIDN. He added that he agreed with what was being suggested. He also observed that the larger ccTLD registries do indeed tend to arrange things amongst themselves. Jaap pointed out that, although he cannot speak for SIDN anymore, it always had been SIDN policy to help a limited number of ccTLD nameservers (up to around 20). As far as he knows, they still have room to do so. Antoin Verschuren of SIDN confirmed this to be the case. Joao Damas stated that he did not feel that the market would simply go away by the RIPE NCC making changes. He thought it would be wrong to get rid of a competent player in the field. As a DNS user, his primary concern remained stability. He feared that if the service was no longer offered free of charge, some operators might be tempted to look for the cheapest possible solution, which may not always be an optimal one. Lars-Johan understood Joao’s concerns. He felt that the only way towards a stable system in the end would be if economical drivers converged with the needs of the community. It was, he said, important that money be funnelled in the right way. Rob Blokzijl agreed with Lars-Johan. To reach stability, he felt a sudden switch off was not the answer. He agreed with many of the other points made by speakers. He did not think that the RIPE NCC taking any action would resolve what is essentially a business problem for Lars-Johan overnight. He cautioned against any sudden moves in the current climate. Politicians could see this as rocking the boat; there remains a level of ignorance about how the Internet works. It could lead some to point fingers at the RIPE NCC for ‘selling off’ a community service. Lars-Johan again agreed. His intent was not to stop this tomorrow. He wanted to ask if this was something that should now be considered. He agreed that simply stopping this cold was not the answer; he welcomed discussion for what was likely to be a ‘long term’ solution. Jim Reid rounded up the discussion. He pointed out that stability of the DNS system was vital, but added that we needed to be aware of the political dimensions pointed out by Daniel. On the other hand, this could be seen as the RIPE NCC potentially competing with its member’s interests. He put it to the room and nobody felt it a bad idea to work further on this. Daniel Karrenberg felt that the next step would be for Lars-Johan to put together a proposal to take into the NCC Services Working Group. J: DNSSEC in Sweden Jakob Schlyter – SUNIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dnssec-se.pdf There were no questions. K: Update to RIPE 203 – Recommendations for SOA Values Peter Koch – DENIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-ripe203.pdf Olaf Kolkman asked whether Peter thought it might be an idea to put fixed values or ranges with reasons as to why anyone might choose to sit on the higher or lower end. Peter Koch felt fixed values would avoid problems with poorly aligned intervals. Gerhard Winkler felt that the group should discuss MNAME in more detail. He thought it would be useful for people to see which secondary or slave loaded from which master. Maybe different MNAME fields for different masters would make sense. Peter felt this discussion would fit better on the IETF namedroppers mailing list: http://ops.ietf.org/lists/namedroppers/ The protocol does specifically state that there should be one unique Master Name server. The document is aimed at a very particular set of zones, it does not try to give a general condition or case for the MNAME field. It is constrained to smaller, stable zones. If Gerhard had proof that these zones tended to be loaded from different databases or sources, Peter would welcome any new text. He added that it was important to take into account if this would be relevant to the target audience of the document. Talking about ripe-203, Gerhard commented that a disclaimer might help in case anyone was using the document as an authoritative source of information. Peter Koch replied that he doubted anyone should use ripe-203 as a policy document, since the subject matter had a specific focus but was not ‘set in stone’. It should not be regarded as general technical advice. He wanted to see more discussion on the wording of the document through the mailing list and see the issue of MNAME taken to the namedroppers list. Mohsen Souissi said that having read the discussion on the mailing list, felt the document should state whether having an MNAME within a zone with an RFC1918 name was good or bad practice. He noticed that recent discussion through the DNS Working Group mailing list discouraged it. Peter Koch asked Mohsen to provide some specific text. There was nobody who disagreed with the need to update the document. L: ENUM DNS Predelegation Checks Peter Koch – DENIC http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51- dns-enum-predelegation.pdf Peter explained that have been a very small number of lame or stale delegations. This appears to be largely due to human error. Along with Carsten Schiefner (co-chair of the ENUM Working Group), Peter proposed that the predelegation checks currently applied to reverse mappings by the RIPE NCC before entering a delegation into the respective IN-ADDR.ARPA zone, be applied automatically to e164.arpa delegations. The proposal was universally accepted and Carsten will now draft some text and submit it to the RIPE PDP system. Andrei Robachevsky stated he felt that inconsistencies might have come about when further changes were applied to delegations. The child zone may not be aware that it needs to change something within the parent zone. It would also be worth looking at processes in place to avoid problems in the future. Carsten replied that it might be preferable if the RIPE NCC could perform ongoing checks. This should cover both the parent zone and child zones, either by using their own or third party tools such as Zonecheck. Andrei agreed that there were several ways to do this and that there were ways in which the quality of checks could be improved. Carsten emphasized that e164.arpa downwards delegation is important and there should be some mechanism in place to provide an early heads up if there could be an issue with a zone. Andrei agreed. Niall O’Reilly wished to add his support for the suggestions made by Andrei about periodic checking. Jim Reid asked if it was a good idea to also look into signing the e164.arpa delegations. AOB Carsten Strotmann told the group that over the past three weeks, he had received several customer enquiries about the Open Root Server Network System (ORNS). He wondered if anyone had opinions about whether customers should use it or not. The issue seems to have arisen from an article in CircleID by Paul Vixie where he states he favours ORNS over the IANA root network: http://www.circleid.com/article/1219_0_1_0_C/ Joao Damas of ISC stated that Paul was speaking in his own private capacity. His request to run one of ORSN servers has nothing to do with either ISC or the operation of the F-root server. Lars-Johan Liman, speaking as a maintainer of I-root, pointed out that there is an RFC (2826) maintained by the IAB on this subject. The RFC clearly states the need for a single root. It should leave nobody in doubt that it is a good thing. The single root is currently maintained by the IANA and he feels this works well. Daniel Karrenberg supported the comments made by Lars-Johan. He suggested that if a customer asks for this service, it would be wise to ask why. Do they want a root server that almost everyone uses or one that is used by just a few? Peter Koch pointed to another CircleID piece by Milton Mueller: http://www.circleid.com/article/1227_0_1_0_C/ The article tries to make the case for ORSN being simply an alternative root. ORSN claims that it is identical to the current root, up until the point where it decides to stop being identical. This is, he feels, a precise definition of an alternative root. Claiming it is a copy of the ICANN route is just incorrect. It could also have strange consequences for DNSSEC. Daniel Karrenberg concluded the discussion by stating that a choice has to be made about whom you trust to provide information and quality of service.

2 1

Updated list of Action Items
by Peter Koch 21 Oct '05

21 Oct '05

Dear WG, please find the list of DNS WG action items at http://www.ripe.net/ripe/wg/dns/dns-actions.html As a result of the meeting during RIPE 51, we (your co-chairs) have closed "50.1" on the NCC to produce statistics on K-root as well as "50.2" on Jim to communicate with IANA to resolve the "multiple names" per name server problem. There are now five new action items and also five ongoing. While traditionally new items originate from face to face meetings, major parts of work can and should be done on this mailing list. -Peter

1 0

New Document available: RIPE-359
by RIPE NCC Document Announcement Service 13 Oct '05

13 Oct '05

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-359 Title: RIPE NCC DNSSEC Policy Author: RIPE NCC Date: October 2005 Format: PDF=58240 TXT=3043 Short content description ------------------------- The RIPE NCC is committed to supporting the deployment of DNS Security Extensions (DNSSEC) [1,2,3]. DNSSEC is a set of security extensions to the DNS that allows validating DNS resolvers to establish 'chains of trust' from known public keys to the data being validated. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL: http://www.ripe.net/docs/ripe-359.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-359.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-359.txt plain text version

1 0

New RIPE Document available: RIPE-352
by RIPE NCC Document Announcement Service 10 Oct '05

10 Oct '05

New RIPE Document Announcement -------------------------------------- A new RIPE Document is available from the RIPE Document store. Ref: ripe-352 Title: Measuring the resource requirements of DNSSEC Author: Olaf Kolkman RIPE NCC / NLnet Labs Date: October 2005 Format: PDF=5367108 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- We measured the effects of deploying DNSSEC on CPU, memory and bandwidth consumption of authoritative name servers. We did this by replaying query traces captured from ns-pri.ripe.net and k.root-servers.net in a controlled lab environment. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/ripe/docs/ripe-352.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf PDF version Kind Regards, RIPE NCC Document Announcement Service

1 0

RIPE's MNAME recommendation
by Paul Herman 04 Oct '05

04 Oct '05

Hello dns-wg list! SUMMARY: In short, in a SOA RR of ours we have an MNAME that corresponds to a primary master server which has a private IP address. This is causing problems with many RIPE member registrars. PROBLEM: Using the language described in Section 2.1 of [RFC 1996], we have a primary master DNS server and two slave DNS servers. The primary master has a private [RFC 1918] IP address and the Slaves have public IP address, are named in the NS RRs for the zone and use zone transfer to recieve the zone from the primary master. Furthermore, in accordance with [RFC 1996], [RPC 1035] and [RIPE1] I have named the primary master as the original/primary source of the data for the zone. Here is an example zone file from what I'm talking about: example.com. 3600 SOA dns.private.example.com. hostmaster.example.com. ( 1999022301 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 172800 ) ; minimum ( 2 days) NS slave1.example.com. NS slave2.example.com. slave1 A {public-ip} slave2 A {public-ip} dns.private A 10.11.12.13 So far so good. Our zone appears to be fully RFC compliant. However, the problem arises when I try to transfer, say, the ownership of a ".de" zone using DENIC, because [RIPE1] additionally recommends that this be a valid address of the primary master, "valid" being the key word here. This is a problem, because many RIPE member registrars are indeed enforcing this policy. I gather, however, from more recent messages from Mr. Koch (who authored [RIPE1]), that the "MNAME field need not be part of the NS RRSet and need not be accessible." [ICANN-FORUM]. BTW, to my knowledge this is also neither enforced by IANA nor ICANN. Is it possible that RIPE could consider relaxing this "recommendation" that causes problems for RFC compliant zones? How do you, the DNS community, feel about this? Thank you for your attention in this matter. With kindest regards, Paul Herman Network Architect cleverbrige AG www.cleverbridge.com REFERENCES: ---------- [RFC 1035] Mockapetris,P., "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RFC 1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. "Address Allocation for Private Internets." February 1996 [RFC 1996] Vixie,P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996 [ICANN-FORUM] http://forum.icann.org/lists/iana-del-data-comments/msg00004.html [RIPE1] Koch,P., "Recommendations for DNS SOA Values", ripe-203, http://www.ripe.net/ripe/docs/ripe-203.html , June 1999

11 18

RIPE NCC Service Interruption on 29 September
by Ruud de Kooter 04 Oct '05

04 Oct '05

Dear Colleagues, As we announced on 29 September, there was an unexpected disruption to our whois and web services between 05:10 and 06:00 UTC. Our investigations have shown that the problem was caused by an increasing traffic load and a growing number of peers on one of our routers. We made some configuration changes to improve load balancing between our border routers. This should prevent any similar problems from occurring in the future. We apologise for any disruption or delay this may have caused. If you have any further questions about this matter, please send an e-mail to <ops(a)ripe.net>. Regards Ruud de Kooter RIPE NCC

1 0