RIPE 57

RIPE DNS WG minutes for RIPE 57, Dubai

WG: DNS
Meeting: RIPE 57, Dubai
Time-1: Tuesday, 28 October, 14:00 - 15:30
Time-2: Wednesday, 29 October, 09:00 - 10:30
Minutes: Arno Meulenkamp
Jabber:
J-Scribe: Mark Dranse
J-Script:
Audio:
WG URL: http://www.ripe.net/ripe/wg/dns/
Material:
Agenda: http://www.ripe.net/ripe/meetings/ripe-57/agendas/dns.html

--------------------------------------------------------

New actions:

57.1 RIPE NCC (Anand) to consider pros and cons of submitting the trust
anchors of zones signed by the RIPE NCC into ISC DLV

57.2 Peter Koch will document the WGs advice that the old forward DNS zone
domain objects in the RIPE DB should be deleted and liaise with the DB WG

--------------------------------------------------------

A. Administrative Matters

B. Review of Action Items

48.1 Collect experiences with lameness problems due to vanished customers
or AXFR sources

Status: with help from the CENTR secretariat a survey was performed
and it seems there isn't really an issue, TLD registries do not see a
noticable number of thrid party requests. Suggestion is to close the
action after a report of the survey is sent around, as it seems this
isn't as big a problem as was perceived.

49.2 DNS Server Migration

Status: there seems to be a lack of interest in this document, so the
suggestion is to declare this dead. The document in its current form
will be published on the mailing list by Jim Reid. If there is
interest, people can bring it back to the working group.

51.4 RIPE203bis

Status: there has not been much progress on this since the last
meeting. A draft has been published, the comments need to be
incorporated. Peter Koch will add comments to the draft before the
next meeting. The expectation is that it can be closed then.

C. ICANN/IANA Update - Kim Davies, IANA

Peter Jansen from EURid asked clarifications on the ccTLD extensions
for IDN, if there would be only one IDN or multiple? And if that would
contain full names or abbreviations. Kim Davies and Barbara Roseman of
ICANN made it clear that there wasn't one rule for all countries, but
that it would be in-country rules.

The ITAR keys for resolvers should be available by now.

Alireza Saleh from IRNIC asked about confusingly similar characters.
Kim Davies clarified that confusingly similar TLD names will be avoided
and that in such cases the first applicant will get their delegation.

D. Discussion on NTIA DNSSEC NoI

Jacob Schlyter gave a quick presentation on the options for a response.

Jim Reid argued that the RIPE community should take the opportunity
given by the NTIA for having public involvement. Olaf Kolkman
mentioned that there are several other proposals, it is not limited to
the 2 proposals that were discussed.

Lars-Johan Liman mentioned that it might be better to state that the
RIPE community communicate the properties of the solution wanted,
rather than discuss the actual proposals. After some discussion it was
decided that an impromptu group, consisting of Jim Reid, Patrik
Faltstrom Daniel Karrenberg, Peter Koch, Lars-Johan Liman and Joao
Damas would write down the concerns of the working group in a
document, to be presented during the next WG session (Wednesday).

E. Etisalat DNS Operational Experiences - Abdulla Bushlaibi, Etisalat

There were no questions after the presentation.

F. A Versatile Platform for DNS Metrics with its Application to IPv6
Penetration - Stephane Bortzmeyer, AFNIC

The site for the tool, DNSwitness is here: http://www.dnswitness.net/

Mohsen Souissi and Stephane gave some extra information after the
presentation, such as the reason for choosing python (simplicity and
the existence of a good DNS library written by nominum) and they
specifically mentioned that they are willing to share the data with
other TLD operators, in order to get a better global picture.

close of meeting 15:55

--------------------------------------------------------
Session 2

Wednesday, 29 October. 09:00-10:30
Salon I-III

--------------------------------------------------------
G. IETF WG News Update - Lars-Johan Liman, Autonomica

Update on the following:
-resilience against kaminsky attack
-rsasha256
-update of extended dns, edns0. (this draft is currently expired)
-deprecation of md5, which is considered weak. There's an issue with
registering code points and requirement levels in the IANA registry.
-A clarifying document on zone transfers, Ed Lewis will write a
document on that, but there is not much discussion currently.

Steve Crocker proposed a mechanism to signal which algorithms a server
is able to handle, there is currently no sign of adoption by the wg.

Another request is for an update to RFC1123, because it expects labels
to be alphabetical, which does not work with IDNs. There is not much
movement on this yet.

A document will be written on dynamic zones and DNSSEC. Mark Andrews
is looking for help on creating this document.

More resilience work, with wg chair urging adoption of new measures that
only just passed draft status. And there is discussion on dns 0x20
(hex20) which would increase "randomness", as an extra defence against
the Kaminsky attack.

{The the power came back, but no network...}

After the presentation, there was a quick update from the IDNAbis wg.
They are trying to update the IDNA standard.
Both docs are stable and there is consensus they are
done. There is still some discussion on the protocol doc and what
standards track it should go into. These issue are about to be
clarified.

No questions.

H. RIPE NCC Update - Anand Buddhdev, RIPE NCC
09:30

There was a question about how to get the trust anchors for the RIPE
NCC domains. Anand explained that they could be found on the secure
website <https://www.ripe.net/projects/disi//keys/index.html>.
Anand was asked to look into DLV, which would make
keeping track of key rollovers easier.

ACTION: NCC (Anand) to consider DLV for the Trust Anchors maintained by the NCC

I. Discussion on Stale Domain Objects - Peter Koch, DENIC
09:49

There are forward DNS zone domain objects in the RIPE DB. There was
some question on what to do with those. Since enough time had passed
since TLDs had been told that the RIPE DB was not the right place for
those objects the WG decided that the old objects should be deleted.

around 25 hands in favour of deleting
no one against deletion

ACTION: Peter will document the WGs advice that the old forward DNS zone
domain objects in the RIPE DB should be deleted.

J. .org's Next Steps with DNSSEC - Lance Wolak, PIR

Shane added some info on the deployment. Most inhouse things are
ready, work now on customer facing interfaces. This is a NSEC3
deployment, which is interesting, BIND can only now do NSEC3. NSD is
also used, it can do NSEC3 for a while. This deployment is probably
one of the first NSEC3 deployments, so odd things might happen. It
will be put on the live servers in the next few weeks. People that
want to take part in the beta can configure the keys and such in their
verifier. Contact Shane for more info.

K. IDN GCC Trial Project - Amani Mohammed Bin Sewaif, Etisalat

Olaf Kolkman wondered if it was an interim solution or more
permanent. Amani explained that it was a trial and that it showed a
need and that it was actually working and that the next step would be
actual deployment.

L. Followup on NTIA DNSSEC NoI
10:40

The impromptu group produced the following set of points for
consideration as the WG or RIPE response to NTIA:

a: DNSSEC is about data authenticity and integrity and not about control.

b: The addition of DNSSEC to the root zone must be recognised as a
global initiative.

c: Addition of DNSSEC must be done in a way that the deployment of DNS
is not at risk.

d: Deployment should be done in a timely but not hasty manner.

e: Any procedural changes introduced by DNSSEC should be aligned with
the process for coordinating changes to and the distribution of the
root zone.

f: Policies and processes for signing the root zone should make it
easy for TLDs to participate.

g: There is no technical justification to create a new organisation to
oversee the process of signing of the root.

h: No data should be moved between organisations without appropriate
authenticity and integrity checking.

i: The public part of the KSK must be distributed as widely as
possible.

j: The organisation that creates the zone file must hold the private
part of the ZSK.

k: Changes to the entities and roles in the signing process must not
require a change of keys.

l: The solution has to balance various concerns, but must provide for
a maximally secure technical solution and one that provides the trust
promised by DNSSEC

There weren't many concerns for point a, b, d, e, f, h, j and l,
though some felt the ordering or priorities of these points needed to
be re-arranged.

At point c:

There was some discussion on how to not use too strong a language and
that it should not focus on just resolvers.

For point g:

There was some discussion of whether the point was necessary at all, as
it mentioned certain organisations. The main feeling was that adding
DNSSEC shouldn't change the current model. The introduction of a new
entity should be separated from the current discussion.

On point i:

There was some discussion on the word "minimal", as DNSSEC is not a
small change. Again, the point was to reiterate that the introduction
of DNSSEC should not cement the current model and that changing the
current model is orthogonal to adding DNSSEC.

At point k:

Not everyone was happy with this point. It basically talked about
principals, not about something concrete. There was no agreement on
how to change the text.

With that, WG decided that the text could go to the plenary for
possible endorsement as a statement on behalf of the RIPE
community. If no consensus was reached there, the statement would be
submitted to NTIA on behalf of the WG.

Z. A.O.B./General Discussion

No AOB

End of session 11:10