RIPE 52

• content to the Chair of the working group.
• format to [email protected].

--------------------------------------------------------
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:[email protected]
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-pr.pdf

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-anycast.pdf

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.pdf

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.pdf

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-quality.pdf

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-dnsamp.pdf
http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-reflector_attacks_using_dns_infrastructure.pdf
http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-enum-security.pdf
http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-perils-transitive-trust-dns.pdf
http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-kroot-anycast.pdf
http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-dns-turkey.pdf

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.pdf

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-updates.pdf

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