Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 56

RIPE Meeting:

56

Working Group:

DNS

Status:

Final

Revision Number:

1

DNS WG Session 1
RIPE 56 - Berlin
Wednesday, 7 May 2008
Burgund III, Hotel Palace, Berlin

Scribe: Adrian Bedford
Jabber Monitor: Susannah Gray
Session Chaired by: Peter Koch

Around 65-75 people attended the session.

A. Administrative Matters

Peter Koch introduced the session, went through the agenda for the two
upcoming sessions and declared the minutes from RIPE 55 final. They
will be marked as such on www.ripe.net. Nobody wished to add to the
agenda.

B. Walk Through Action Items

48.1: Wishlist for "lost" Delegations - Peter Koch

Peter noted that the problem in the reverse space is usually addressed
by the reverse delegation checks and access to the corresponding
domain: objects in the database. He feels it might be a good idea for
the TLD domain issue to be surveyed amongst fellow registries at
CENTR on their current policies. Peter would then come back and
present his findings at future RIPE Meeting and see how far the
policies could be updated and how we could learn from this research.

Lars-Johan Liman noted that it can be a problem, although it is easy
to resolve. Patrik Faltstrom asked if this was related to lameness,
Lars-Johan confirmed that it was. Patrik feels that the change of
registration details might lead to mistakes and downtime. This is
where he feels delegation issues happen.

Peter clarified that the issue does not lie with the operators, but
further up the chain. Registry policies do not allow third parties to
ask for the removal of a delegation or even a domain.

Patrik and Lars-Johan plan to work together on a paper around the issue.

In view of this, Peter suggested that the original paper should be
dropped. There was no opposition.

51.4: RIPE203bis - Peter Koch

Peter has received a few very helpful recommendations on the
text. However, the concept of the document was something short and
easy to follow. Adding in what everyone suggests would make it too
lengthy and unlikely to be useful.

Peter will continue editing and eventually produce a document for the
working group. The action point remains open.

49.2: DNS Migration Document - Jim Reid

Jim explained that the working group co-chairs feel the document has
lost focus and is not ready for publication as a formal RIPE
Document. He also suggested it has no clear audience. If the document
is to work, it will need restructuring by a strong editor.

A short discussion took place where it became clear people felt the
document should continue and did have an audience.

Bill Manning suggested the two documents discussed today sounded like
they are closely related, the two ought to be bound together. He
offered his services to work on such a document.

All interested people are asked to make contributions on the WG
mailing list. The first issue to look at is restructuring the document
then appointing an editor to take the project forward. There was a
sense that APs 48.1 and 49.2 could be merged because they cover
similar ground. Depending on the response from the list, the WG
co-chairs would review this and suggest what course of action the WG
could take.

C. Reports

C1: Results of the Trust Anchor Task Force - Jim Reid

Jim asked if people felt the letter to IANA or ICANN should be
sent. The consensus was that it should. He will make a summary report
at the Closing Plenary on Friday. It will not be a letter endorsed by
the RIPE community, rather it is a commitment from the DNS Working
Group.

C2: IETF Report - Antoin Verschuren

Peter referred Antoin to Patrik as he is working on the IDNA-bis documents.

Peter asked how many people were first time meeting attendees and how
many were for the first time in the WG. Around fifteen people raised
their hands. He asked if these people would like to provide any
feedback.

C3: IDN ccTLD Fast Track - Bart Boswinkel

There was a request for clarification that only non-Latin TLDs would
be eligible to apply. Bart confirmed this was the case. There was then
a question of whether the process would lead to IANA defining a
registry of preferred language tables. Bart said this would not be the
case, as there is already a repository for language tables documented
on the IANA website. Decision making takes part in the community
concerned and the ICANN working group on this issue is concerned only
with operational matters. In response to another question, Bart
explained that any proposed IDN-ccTLD operator has to go through a
national process, and that there is no particular favouring of the
current ccTLD operator. Any conflicts of interest would be handled
within the territory concerned.

C4: IANA DNS Update - Leo Vegoda

Peter asked how people would keep track of the IANA Trust Anchor
Repository. Leo said that when the system goes live, it would be
announced widely. ICANN/IANA is hoping for wide take-up and want it to
be easy to use.

C5: ICANN SSAC - Patrik Faltstrom

There were no questions.

D. DNAME Issues Regarding IDN TLD Implemetation - Yoneda Yoshiro

One point made after the presentation was that operators need to take
care when they enter MX and PTR records because they cannot enter the
Japanese characters. It may be hard for users. Registrants have to
maintain their DNS in a corresponding ASCII TLD zone. The name is only
in the JP zone. This needs to be made clear in documentation.

Jim Reid stressed that although a formal test bed would be useful, at
the very least a website or mailing list should be set up to share
experiences and knowledge. Yoneda agreed.

It was noted that Autonomica is already testing DNAME on request from
ICANN and that DNAME is under revision, so the JPRS feedback will be
useful.

E. PIR DNSSEC Survey - Jakob Schlyter

There was a question about whether PIR's deployment of DNSSEC on .org
depends on the survey. Jakob said that it will go ahead anyway, it is
not dependant on this survey.

He added that a summary of the results will be published to the community.

DNS WG Session 2
RIPE 56 - Berlin
Thursday, 8 May 2008
Burgund III, Hotel Palace, Berlin

Scribe: Adrian Bedford
Jabber Monitor: Fergal Cunningham
Session Chaired by: Jim Reid

Around 80 people attended the session.

Jim welcomed meting attendees to the second session of the DNS working
group at RIPE 56 and outlined the remaining agenda items.

F. Update From The RIPE NCC - Anand Buddhdev

Anand was asked to clarify the domains on which the lameness checks
run. He confirmed that they are run against all /8s (and under)
allocated to the RIPE NCC from IANA.

G. Unbound: A DNSSEC Validating Resolver - Wouter Wijngaards

A question was asked about whether Unbound could handle DLV, if IANA
were to set one up. Wouter noted that DLV does not scale well, so it is
not currently implemented, but depending on developments, it may be
considered at a later stage.

There was a question about the performance graphs shown by Wouter,
with someone wanting to ask if investigation was done into the
background of performance loss. Wouter said that it had been traced to
a device driver issue.

On the subject of Source Address Randomization (SAR), Wouter was asked
to consider what might happen if anycast is used, is it possible to
configure for SAR? Wouter replied that this is possible; queries can
originate from different source addresses causing SAR to kick in.

A final observation was on the difference between lab testing and what
happens in the wild, where 60% of queries might, in fact, come from
cache. Wouter agreed that things may be different, but felt that the
results would allow a fair idea of what might happen.

H. Progress on DNSSEC for .CZ and 0.2.4.e164.arpa - Ondrej Sury

Ondrej was asked about why hashing is done on the box or card, rather
than through software. He replied that he felt card hashing would be
quicker.

There was a question about signing policies in the .cz zone. In
particular delays that can happen between master and slave
synchronization. Ondrej confirmed that the policies are based on what
is observed as best common practice at this time. Current
documentation is in Czech, but will most likely be produced in
English. It was noted that these would be useful to store centrally to
eventually produce a single BCP document based on the policies used by
TLDs.

Ondrej was asked to clarify whether NSEC3 is an issue. He confirmed
that it was a concern for .cz, but not for ENUM.

I. DNS Issues in New Microsoft Operating Systems - Carsten Strotmann

There was a question about why the interface doesn't allow for
entering DNAMEs, although the command line and GUI allow this. Carsten
confirmed that there is only limited support - with no support for
server-created zone files. He also felt it didn't support A6 record,
although it does support AAAA. He noted that in seven years, he has
not seen a single request for DNAME or A6 from his commercial user
base.

Carsten was asked about whether an authoritative server would take a
mixed group of zones or service types and serve them. He replied
that it would serve them as caching resolving name servers, but when
it came to working as an authoritative name server in a cluster, it
would need testing. It was noted that the system is targeted towards a
Microsoft-only DNS cluster not allowing mix with UNIX in the same
cluster.

A question was asked about what was meant by saying the server is IDN
compliant. Carsten replied that is goes somewhat deeper. It can look
up names entered in Unicode and correctly translate them. Carsten was
asked how he verified that it was an accurate translation. This was a
discussion that will continue offline.

Finally, Carsten was asked about the separating of recursive and
authoritative servers. The speaker wished to know if he could now
restrict recursing to particular address space. Carsten felt this was
probably not possible.

J. TCPDUMP Filter Rules for Capturing DNS Traffic - Shane Kerr

Lars asked if possible to do away with casing problems by masking out
the case bit in the tcpdump ruleset. Shane felt it would probably lead
to a longer rule.

He was asked if he had run into any problems with IPv6 packet headers.

The latest version of the code for dnscap is available on the ISC
website and feedback is welcome to the DNS Operations mailing list.

Shane was asked about how the data is gathered. He replied that
although he is running a logging and capture machine, the data is in
fact obtained from all DNSMON style traffic, written to a file and
then analysed later. This allows all the queries arriving on the
machine to be examined even when they might not be captured in real
time by dnscap.

Peter Koch's proposed presentation on changing a TLD server's address
will be presented at RIPE 57, due to time constraints.