RIPE Working Groups
Minutes from RIPE 43
| RIPE Meeting: |
43 |
| Working Group: |
DNS |
| Status: |
Final |
| Revision Number: |
1 |
Please mail
comments/suggestions on:
=============================================================================
DNS WG Meeting at RIPE 43; Wednesday, September 11 14.00 - 17:30
=============================================================================
Minutes by Shane Kerr
=============================================================================
Administrivia
Meeting Reports
- IETF & DS Workshop, Olaf Kolkman
- Secure Dynamic Update tutorial, Ed Lewis
Invited Presentations
- Root Server Measurements, kc claffy
- UK ENUM Trial, Lesley Cowley
- Applications using DNSSEC, Jakob Schlyter
- DNS IPv6 Migration Issues, Johan Ihren
AOB
Administrivia
----------------------------------------------------------------------
Peter Koff (the co-chair) not able to attend
ISC did not send BIND slides
Scribe: Shane Kerr (RIPE NCC)
Action item:
WHOIS servers for TLD's; in progress, will be presented in January
----------------------------------------------------------------------
IETF Update, Olaf Kolkman
----------------------------------------------------------------------
Slides available at: http://www.ripe.net/ripe/meetings/ripe-43/presentations/ripe43-dns-ietf-update
Randy Bush: Worth framing DNS status, generally believed that DS is
operationally working, was the last major block to DNSSEC deployment.
Without DS, DNSSEC was undeployable, but now there is a document set
that completely replace the DNS specifications.
Not perfect, but the basics so you can deploy and use DNSSEC will be
there.
Olaf: Agree.
----------------------------------------------------------------------
Report on: Secure Dynamic Update, A Tutorial, Edward Lewis
----------------------------------------------------------------------
PPT presentation available at: http://www.ripe.net/ripe/meetings/ripe-43/tutorials/sdu-dns.ppt
Daniel Karrenberg: What are uses for dynamic updates?
Ed: 2 uses. First, update your A record at home to point to a laptop
at a conference. Second, with large registrars you want to support
large zone delegations to add NS records. Modify part of a zone
rather than load the entire zone.
Johan: Isn't that encouraging people to use a single server? We want
a large set of servers to make the data available.
Ed: Multiple servers for reliability rather than availability. Don't
think it will make people re-think diversity in their secondaries.
----------------------------------------------------------------------
Root Server Measurements, kc claffy
----------------------------------------------------------------------
Slides available at: http://www.caida.org/outreach/presentations/dns0209/index.html
kc: Why does A get more queries?
Bill Manning: Distribution of client resolvers, because of differences
in algorithms. Much more difficult to determine than server
distribution.
.
.
.
Bill Manning: 10000 queries/minute before transition to AS112. We saw
peaks of 80-100K queries/minute.
kc: These are updates, not queries.
Daniel Karrenberg: Queries are worse!
.
.
.
Bill Manning: Missing Latin America and Latin America from region
root-distribution graph.
kc: They are in the graph.
Bill Manning: So they're going to Asia?
kc: No, I'm not sure....
Daniel Karrenberg: This is RTT distance, not what resolvers are
actually using.
kc: Let's presume that if clients are doing anything reasonable that
they are the same.
http://www.caida.org/projects/dns-analysis/
http://www.caida.org/outreach/papers/
http://www.caida.org/cgi-bin/dns_perf/main.pl
Daniel Karrenberg: Take issue with comparing loss figures of roots and
gTLD servers.
kc: RTT, not loss.
Daniel Karrenberg: Compare TLD with root query load, there is much
more crud. So much easier for a gTLD too look good, and there is less
load.
Harvald: Is is possible to make a simple graph like the one where a
single root server is removed?
kc: No. The ones that are in the same area make this.
Harvald: Is there an equally simple graph about where to put this?
kc: That's harder, and I don't it has anything to do with measurement.
It shouldn't start with measurement. Why don't we remove the ones
that don't won't even measure themselves? Why do they even want a
root name servers?
Bill Manning: Some of this you can extrapolate without measurement
just by looking at topology. The tough question is where do you put
the next one?
Daniel Karrenberg: Doesn't take into account number of queries.
kc: Not hard to make this graph - weight it by number of queries seen.
Bruce Campbell: What is k-peer?
Daniel: Amsterdam, because the backup for K is in Amsterdam.
----------------------------------------------------------------------
UK ENUM Trial, Lesley Cowley
----------------------------------------------------------------------
Slides available at: http://www.ripe.net/ripe/meetings/ripe-43/presentations/ripe43-dns-uk-enum
Daniel: From first slide it was apparent that you want to couple
telephone numbers to ENUM. You have a verification agency at time of
delegation. How do you deal with the time when someone ceases to use
an e164 number?
Chair: Ability to set time period on duration of registration, so
there has to be a renewal, and taking account phone service being
canceled. This will persist unless the telco acts as a registrar.
There are also regulatory issues there as well.
Lesley: In the same way as domain names.
Daniel: But in domain names, there is only one thing.
Otmar Lendi: In Austrian trial, when the phone is cancelled, the ENUM
delegation has to be cancelled as well. Must work out a way for this.
Jim: Another problem is mobile phones. A pay-as-you-go mobile phone
(the drug dealer's phone of choice) can be converted to a conventional
mobile phone with a monthly subscription.
Otmar: In Austria, only for fixed numbers.
Carsten: What about the authentication agency? Does it already exist?
Is it going to be created?
Lesley: Could be anything. Originally thought about separate
agencies, but perhaps the registrar may have an agency for this as
part of the group. Can be stand-alone or bundled. These are things
that we will try to look at in the trial, but we don't want to have
one model.
Jim Reid: Because there are multiple telco providers, we have to deal
with the fact that they do not want to share customer records.
Jim: Registry will try to do only registration, because it's a
monopoly.
Otmar: What's your target price of a registration?
Lesley: Premature question. (laughter) For the trial there are no
costs. A lot of work could be done on the economic side, but we
decided to do the technical side first, because you need a model of
operation anyway.
Andrzej Bartosiewicz: Currently only telecoms can send a phone number.
With ENUM, will you allow "virtual telecoms" to participate in the
trial.
Lesley: Anyone can participate in this trial. It's been very
interesting working with telcos.
Daniel: With ENUM there is room for telephone numbers that are not
e164.
Andrzej Bartosiewicz: No. You can only get a phone number from a
telecom operator. With ENUM there might be companies who offer
telephone numbers without being a telephone operator.
Jim: To do this, you need a +44 telephone phone number.
Carsten: Is this only for experts? For a bunch of people? Is there a
broader interest? There was a meeting and people were surprised that
there was already a lot of interest for e164.
Lesley: I don't think there is a *lot* of interest - that would be
un-British. There is a commercially driven area of interest, because
the ISP market is depressed in the UK.
----------------------------------------------------------------------
Application Keys in DNS, Jakob Schlyter
----------------------------------------------------------------------
Slides available at: http://www.ripe.net/ripe/meetings/ripe-43/presentations/ripe43-dns-appkey
Daniel: Intrigued by application of bridging trust between PKI and
DNSSEC.
Jakob: If you would connect to www.ripe.net, via SSL. You could look
up the certificate in DNS, to verify that the certificate is correct.
Then you can match them. Controversial...
Daniel: Why?
Jakob: Ask Verisign.
Ed: You can use DNSSEC to insert certificate into DNS.
----------------------------------------------------------------------
DNS v6 migration isses, Johan Ihren
----------------------------------------------------------------------
Slides available at: http://www.ripe.net/ripe/meetings/ripe-43/presentations/ripe43-dns-v6-migration
Daniel: About the reverse tree. I don't buy the premise that because
there are more addresses there will be more addresses in the tree.
They are there for more structure. Number of end systems will not
increase as the number of addresses does. I'm not against having an
automatically generated reverse mapping. I'm quite happy to have
DHCP-something.ripe-meetig.ripe.net to read on my printout or HTTP log
or whatever. So I think it's a non-issue.
Johan: If we start with the number of nodes. Of course initially it
will not be higher. But the issue is the number of addresses because
of the address spots being populated. You cannot do this, which is
the reason for the wildcard proposal.
Shane Kerr: What about the proposal to run a lightweight resolver on
each host to answer name queries?
Johan: It doesn't really use the same model of who can answer a query
about reverse.
Shane: But it answers the operational issues of handling broken
clients and making the traceroute issues pretty.
----------------------------------------------------------------------
Final business: Thanks to Ruediger Volk, previous chair.
Daniel: NSD 1.0.1 is now released and considered stable and "ready for
prime time". You are invited to consider this if you are running a
authoritative server, especially if you are running a TLD. Planning
on doing this on K root before the end of the year.
We're going to do "real anycast". Meaning anycast geographically
separated. We have a backup server in Amsterdam. We are thinking of
going live with this. ISP's will need to know because the advertising
will come from different address spaces. You can talk to me about
this at any time.
Last slot before the plenary is a technical security meeting. The
only agenda point is the DNS security preject, DISI.
We have a couple of DNSSEC tutorials. Information on RIPE site under
DISI project.
http://www.ripe.net/disi/
|
you are here: 
