[Apologies for duplicate mails]
Motivation:
We plan to automate management of DNS delegation in the e164.arpa zone (ENUM).
The provisioning system, with the RIPE Database as a front end, must support
IPv6 glue records. It must also implement complete and consistent IPv4 glue
record support. This will mean making changes to the RIPE Database syntax
so that it specifies the glue record and update the delegation checks.
This proposal covers that syntax.
Proposal:
We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects
as follows:
nserver: [domain_name] /or/
nserver: [domain_name] [ipv4_address] /or/
nserver: [domain_name] [ipv6_address]
where
[domain_name] is the fully qualified DNS name of the name server without a
trailing "."
[ipv4_address] is an IPv4 address of the name server
[ipv6_address] is an IPv6 address of the name server
If [domain_name] is followed by an IP address, it must be inside the zone
that is being delegated. Any level of a glue name is supported within the
valid domain name syntax.
Multiple name server lines will need to be used to specify multiple IP
addresses for the same hostname.
Examples:
The following values would be allowed:
domain: example.com
nserver: ns1.test.net 168.0.0.1
nserver: ns1.test.net 0::0
nserver: ns1.example.com
nserver: ns1.d1.example.com
All other variants of the values will be rejected.
End-of-line comments starting with '#' will be still allowed.
Consequences for existing objects:
We will not automatically modify any existing objects. Instead we suggest
notifying the maintainers of objects that do not comply with the proposed
syntax. This will cover around 150 objects.
Consequences for the delegation checks:
DNS checks applicable to glue records will be added to the Zone Delegation
Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html)
--
Katie Petrusha
RIPE NCC
Dear DNS WG,
here are the draft meeting minutes for Istanbul. Please have a look at the
text and send comments or requests for changes to the wg chairs until
June, 17th.
You'll find the list of five new action items at the end. Please verify
the transcript, especially if you're quoted or have (been) volunteered
for an action. Thanks to Adrian for providing the minutes (in time); all
typos are mine.
-Peter
-----------------------------------------------------------------------------
DRAFT 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:dns@conference.ripe.net
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-p…>
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-an…>
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…>
George Michealson 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.…>
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-qua…>
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-dnsa…>
<http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-refl…>
<http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-enum…>
<http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-peri…>
<http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-kroo…>
<http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-dns-…>
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…>
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-…>
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 secondary service at ns*.ripe.net in case the
master (the relevant *xfr source) is not responsive and the
zone is about to expire
[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
-----------------------------------------------------------------------------
Dear Colleagues
In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"',
as a Best Current Practice document. The RFC noted that maintenance of
"ip6.int" is no longer needed and called on the Regional Internet
Registries (RIRs) to decide when to stop providing support for the
domain. The RIRs have jointly agreed to do this on 1 June 2006.
There will be a short presentation on this at the RIPE 52 Meeting in
Istanbul. You can find more information about this meeting at:
http://www.ripe.net/ripe/meetings/ripe-52/index.html
Regards
Andrei Robachevsky
Chief Technical Officer
RIPE NCC
Hi,
i have performed a little research on the effects of deploying DNSSEC,
which might be interesting to the people of this wg.
you can find it at http://www.nlnetlabs.nl/downloads/dnssec-effects.pdf
------------------------------------------------------------------
Abstract
Ripe NCC recently started signing the zones on their DNS servers. This
document presents a few measurements of the effects (if any) on the
behaviour of the resolvers sending queries to the Ripe nameservers. We
have looked at the rate of queries with the DO bit (’use DNSSEC’) set to
1, compared to those with the DO bit set to 0. We have also looked at
the number of DNS responses that were truncated.
-------------------------------------------------------------------
Jelte Jansen
NLnet Labs
Dear wg,
I have heard from Bill Manning that ARIN has requested removal of their
space from the ip6.int tree, and I'm wondering what the current point of
view is for the RIPE NCC. I would like to see ip6.int dismanteled
'correctly', ie not in the way described below:
I wrote to ipv6-ops(a)lists.cluenet.de:
> I have heard DNS operators are planning on removing ip6.int from their
> resolvers (ie by plugging ip6.int into an empty zone on their recursors).
> What are your thoughts on this? I am considering removing ip6.int also
> in the same way, because I think it can take a long time for the parent
> of .int to remove ip6 delegation (if they are even considering this is
> unknown to me) and for sure it might take a long time for the ip6.int
> folks to remove children from their zone.
>
Bill replied:
| ip6.int is ready to remove zone cuts for ARIN.
| they are the only RIR who has requested delegation removal.
| when/if the other RIRs request delegation removal, it will
| occur.
Has this been discussed before? If so, I'm sorry I missed it :) What
was the outcome in that case? I think it is a very good idea to have
RIPE NCC and APNIC request delegation removal.
--
---------- - - - - -+- - - - - ----------
Pim van Pelt Email: pim(a)ipng.nl
http://www.ipng.nl/ IPv6 Deployment
-----------------------------------------------
Dear Colleagues,
The RIPE NCC Training Services Department invites you to register for
one of our upcoming DNS for LIRs Training Courses:
And
Date: Tuesday 13 June 2006
Time: 0900-1700
Location: Riyadh, Saudi Arabia
Hosted by:ZAJIL International Telecommunications Co. W.L.L.
And
Date: Thursday 13 July 2006
Time: 0900-1700
Location: Munich, Germany
And
Date: Friday 8 September 2006
Time: 0900-1700
Location: Manchester, United Kingdom
And
Date: Friday 29 September 2006
Time: 0900-1700
Location: Amsterdam, Netherlands
The main objective of the DNS for LIRs Training Course is to provide
LIRs with information about the different DNS related services the
RIPE NCC has available for them. It covers reverse DNS procedures and
checks, as well as giving information about DNS Monitoring (DNSMON),
K-Root and anycasting.
The course also covers DNSSEC and the specific procedures set up by
the RIPE NCC to secure the in-addr.arpa zones.
Please note that the DNS for LIRs course focuses on DNS services and
procedures related to being an LIR. The course does: - NOT teach the
basics of DNS - NOT describe how to receive Internet resources from
the RIPE NCC - NOT describe fully how to operate a Local Internet
Registry (LIR)
The course is intended for technical staff of LIRs. It is assumed that
all attendees are familiar with common DNS terminology and have a
practical knowledge of operating DNS servers.
The course is free of charge. We provide lunch and printed training
materials.
We do not cover any of your travel expenses or accommodation. We give
all of our training courses in English.
You can find more information about the course at:
http://www.ripe.net/training/dns
REGISTRATION:
============
To register for this course, please use the LIR Portal or complete the
registration via our website on:
http://www.ripe.net/cgi-bin/trainingform.pl.cgi
If you have any questions please do not hesitate to contact us at
<training(a)ripe.net>.
Kind regards,
Rumy Kanis
Training Services Manager
RIPE NCC
