[dns-wg] RIPE51 Minutes

[Jim Reid <]

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@localhost 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.