You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
55 |
Working Group: |
DNS |
Status: |
Draft |
Revision Number: |
1 |
Date: Wednesday, 24 October 2007
Time: 14:00-15:30 (UTC +0200)
Chair: Jaap Akkerhuis
Minutes: Adrian Bedford
J-Scribe: Caz Merrison
A. Administrative Matters
B. Review of Action Items
49.2 DNS Server Migration Documents - Jim Reid
This action point from RIPE 49 was to update an earlier document produced by Fernando Garcia. A small group had been formed to discuss this and although there was some useful comment, little progress was made.
Jim has already posted an updated version of the document to the working group mailing list. After initial comments, there has been no follow up. Jim suggested allowing further discussion over the coming weeks. He will work with his co-chairs to summarise the discussions and formulate a new RIPE Document. Jim will keep the working group updated through the mailing list.
There was no objection, work is ongoing.
51.4 Update on ripe-203 Discussion - Peter Koch
This action point dates from RIPE 51. Peter circulated a new draft document to the WG mailing list on 24 October. His presentation summarized the background and ways to move forward.
http://www.ripe.net/meetings/ripe-55/presentations/koch-ripe203bis.pdf pdf [ 31 KB ]
There was some input from the room although discussion is to mainly take place on the WG mailing list. The main points made were:
It is possibly worth looking at what was recommended when the RIPE NCC developed its delegation checking tool. Delchecker: for example negative TTL.
It was noted that some users fail to correctly format e-mail addresses, often forgetting to escape parts of them. It may be worth making an explicit mention of this in any future draft of the document.
A question was asked about whether it is safe to always assume that the email address encoded in the MNAME field should be reachable over the Internet.
One participant expressed the opinion that if explicit notify lists are to be used for a zone, having an absent MNAME in the form of a dot should be seen as legitimate.
Time restraints meant that the discussion was curtailed, but will continue on line through the working group mailing list.
C. Update from the RIPE NCC - Andrei Robachevsky
http://www.ripe.net/ripe/meetings/ripe-55/presentations/robachevsky-dns-update.pdf
During the presentation, Jim Reid asked about the RIPE NCC's ongoing Secondary DNS Service, pointing out that it is still being supplied to a number of domains where a commercial alternative is now available. For domains that can get this service elsewhere, it was agreed that the RIPE NCC would continue dialogue to back gracefully out where possible.
Following Andrei's presentation, there was a question about why the number of signed zones had decreased since RIPE 54. He explained that this was because some test zones were created for that meeting and have since been cleaned up. The RIPE NCC has not actually stopped signing any zones.
D. IETF Working Group News Update - Antoin Verschuren
http://www.ripe.net/meetings/ripe-55/presentations/verschuren-ietf-update.pdf
There were no questions.
E. Leftover Items from Plenary Session
This part of the agenda was left for any potential items that were left from the plenary.
The matter of progress on the letter sent to ICANN to request signing of the root zone (initially mooted at RIPE 54) was mentioned. There had been no report following the letter sent from the RIPE community.
David Conrad from ICANN was in the room and was able to confirm that IANA was almost ready technically to sign the root, .arpa, .int and others. Politics tend to get involved whenever changes are proposed for the root zone. Signing .arpa was being held up by the work involved in finding a suitable range of secondaries for the .arpa zone. He agreed to push for a response to the RIPE community approach.
Patrick Faltstrom announced that the Internet community in Sweden, backed by the Swedish government, would shortly sign a note and send it to ICANN to support the signing of the root zone.
F. DNSSEC Key Repository Task Force - Jim Reid
http://www.ripe.net/ripe/meetings/ripe-55/presentations/reid-taskforce-report.pdf
Jim asked the working group to say whether they agreed with the proposal for work suggested by the Task Force.
The overall consensus was that the task force should ask the RIPE NCC to come up with high-level specs for the service, taking into account the requirements identified by task force members. A requirements document will be circulated to the working group mailing list. One thing that the RIPE NCC was keen to stress is that this offering would not compete with other services and that it would have a clear exit strategy.
Although there was some discussion of specific details, Jim stressed that this was not the time to start thrashing out specifics. He noted that discussion should continue on dedicated mailing lists, given the time restraints of the working group session.
Minutes from the task force session at RIPE 55 are already available in an on line archive.
Jim will take this forward.
G. New DNS Technologies in the LAN - Carsten Strotmann
http://www.ripe.net/ripe/meetings/ripe-55/presentations/strotmann-mdns.pdf
There were no questions.
Date: Thursday, 25 October 2007
Time: 09:00 – 10:30 (UTC +0200)
Chair: Peter Koch
Minutes: Adrian Bedford
J-Scribe:Rob Allen
H. Community DNS - Paul Kane
http://www.ripe.net/ripe/meetings/ripe-55/presentations/kane-community-dns.pdf
There was a question asked about CommunityDNS having a copy of F-root. Paul confirmed that the root server had been cloned to allow for stable testing.
OARC Update - Keith Mitchell
http://www.ripe.net/ripe/meetings/ripe-55/presentations/mitchell-oarc-update.pdf
After the presentation, it was noted that version 1.0 of DNSCAP is now uploaded and available.
K. BIND-DLZ - Experience Providing DNS Services - Lars-Goeran Forsberg
http://www.ripe.net/ripe/meetings/ripe-55/presentations/forsberg-bind-dlz-experience.pdf
Following the presentation, there was a discussion about how BIND-DLZ compares with core DNS, seeing as it operates with all servers running as masters with no back-up slaves. Lars-Goeran replied that it offers neither advantages nor disadvantages over a more traditional set-up, but that it would be easy to subsequently use anycasting. There are also no dependencies on connectivity between servers.
When asked about running a hidden master with a hidden DLZ front end, Lars-Goeran noted that he could think of no problems with running such a configuration, but that the set-up he advocates works well for systems that require frequent bulk provisioning updates.
In answer to a question about the use of relational databases, Lars-Goeran clarified that MySQL is not a part of BIND-DLZ, it is used for provisioning due to its ease of set-up.
It was suggested that having so few variations across the board might have disadvantages. For example, if a bug occurs, it could impact the entire set-up; Lars-Goeran agreed that this was a valid point and noted that plans were already advanced for any future installations to use a range of servers, some having different firmware versions or operating systems and to provide an alternative DNS server to act as back-up for zone transfers.
There was a question about figures given in the presentation comparing BIND-DLZ with other DNS Servers. Lars-Goeran explained that the comparisons were done against published benchmarks.
Finally Lars-Goeran was asked about the motivation for using BIND-DLZ. He explained that the system was chosen for its capacity to hold records for many customers without the need to reload every few minutes.
L. Using IPv6 Name Servers in the Registration Process - Ruri Hiromi
http://www.ripe.net/ripe/meetings/ripe-55/presentations/hiromi-ipv6-name-tree.pdf
There was a short discussion where the focus was on the ongoing lack of support for running name servers on v6. A show of hands suggested that around 20 people in the room were running v6, including half a dozen TLD operators. Most had found little problem injecting glue records. Even where connectivity appears to be a problem, some v6 queries are being made, suggesting that they are not completely blocked. Registrar awareness needs attention.
It was noted that registrars and registries need to work together and understand where the obligations of each lie. There will continue to be problems with service delivery, glue and testing reachability in v6 where a lack of connectivity gets in the way. It places a registrar in a difficult position when trying to register v6 glue that cannot subsequently be reached for testing.
Ruri confirmed that she finds she faces what marketing departments call "a lack of take up". She stressed that DNS is a social infrastructure that needs to prepare better for v6 environments.
The discussion ended with an offer to Ruri from the Czech domain for registration within v6.
M. Implementing DNSSEC for .JP- Kentaro Mori
http://www.ripe.net/ripe/meetings/ripe-55/presentations/mori-jprs-dnssec.pdf
It was noted that the work was extremely valuable. A question was asked about whether the source code would be made public. Kentaro said that he hopes to make it available as open source, though doing so will depend upon his employer. Olaf suggested the most useful place to make this available would be the dnssec.net portal.
Z. A.O.B.
Olaf Kolkman of NLnetLabs asked for volunteers to join a small test group for Unbound: a recursive caching name server and DNSSEC validator.
Volunteers should contact Olaf ([email protected]) or Wouter ([email protected]).
A presentation on Unbound is promised for RIPE 56.