RIPE Working Groups
Minutes from RIPE 45
| RIPE Meeting: |
45 |
| Working Group: |
DNS |
| Status: |
FINAL |
| Revision Number: |
1 |
DNS-WG minutes from RIPE 45
May 15, 2003 9:00-12:30
Chair: Jim Reid
Scribe: Olaf M. Kolkman
---------------------------------------------------------------------------
Agenda
A. Administrivia:
* Minutes of Last Meeting
* Matters arising
B. IETF Report & News
Lars-Johan Liman, Autonomica
C. BIND News
Joao Damas, ISC
D. Invited talk: Mitigating Junk DNS Traffic, How the AS112 Project Can Help
John Brown, Chagres Technologies
(cancelled)
E. Invited Talk: DNS RTT Measurements: ccTLDs compared with roots/gTLDs
Nevil Brownlee, CAIDA
F. Delegation and Lame Server Checking
ZoneCheck: DNS zone checking tool
Stephane D'Alu, AFNIC
Fixing Lameness - A Registry Perspective
Ed Lewis, ARIN
New Tools for Lameness and Delegation Checking
Patrik Faltstrom, Cisco Systems
Panel Session on Delegation and Lame Server Checking
Stephane D'Alu, Ed Lewis & Patrik Faltstrom
G. AOB
---------------------------------------------------------------------------
A. Administrativia
Slightly modified above.
- The chair expanded on the fact that the working-group is intended to
do some work and that the delegation check panel discussion may end
up as a work item for this group; a policy document.
- Minutes where approved.
- Issues arising:
+ Andrei Robachevsky on delegation from 2002.ip6.arpa:
2002 space and reverse delegation. Delegation does not scale, it is
mapped to /32 in IPv4 space. The issue is currently discussed in the
IAB where the decision about delegation to the RIRs is made. After a
positive decision a proposal will come to the RIRs and the community
will need to work on the policies.
Next step in this process in is a meeting between RIR and IAB in
Vienna.
Remark: Currently only 3 delegations requests.
Chair: After gauging consensus: Due to little interest working on a
policy is not to become a WG item just yet.
+ DNS WG and DNR Forum overlap
Rob Blokzijl: Its becoming more and more complicated to explain the
differences between the DNS-WG and DNR Forum. It is difficult to
find out for participants to go where and for the chairs to find out
where a presentation belongs. Confusion is the result.
The proposal is to combine the meetings of the two groups and
allocate 3-4 slots and have the combined meeting chaired by the
DNS-WG and DNR-Forum chairs. As a next step the groups may be
merged.
Comments are:
- Let's get on with technical work.
- Giving the efficiency combining meetings are good.
- There are advantages scheduling DNR issues early in the week, close
to the CENTR technical meeting.
- There are worries about the amount of time allocated to the
combined groups. Rob Blokzijl answered that the amount of slots is
allocated by the amount of agenda items, early agendas will help a
proper slot allocation.
---------------------------------------------------------------------------
B. IETF Report & News
Lars-Johan Liman, Autonomica
Slides available at:
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-ietf.pdf
Lars-Johan gave an update IETF developments.
In the DNSEXT working group:
- the details of "Jakob's bug", a DNSSEC related development
- IPv6 support in the root.
- LLMNR (Link Local Multicast Name Resolution); a protocol for
resolving names when there are no external DNS servers.
- Clarification of the wildcard processing; few implementations do it
correct.
- 6DNAR IPv6 Domain Name Auto Registration.
- DNSSEC docs, these are under rewrite; some details need to be
decided on.
- DS draft changes
In DNSOP
- New chairs Rob Austein and Dave Meyer.
- 6to4 delegations; does not follow allocation tree.
- .local zones problems: Queries that are supposed to remained in a
limited 'scope' leak out. There are a number of solutions.
- Response sizes of delegation records. The size of an answer is a
function of the query name; how to make sure one receives glue
[Quote of the day: "This one is quicker and bigger than your pointer"]
---------------------------------------------------------------------------
C. BIND News
Joao Damas, ISC
Slides available at:
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-bind.pdf
Joao described developments:
- BIND8
8.4.0 (in RC1): has IPv6 transport and bug fixes.
8.3.5 same as 8.4.0 without IPv6
- BIND9
9.3.0 no release date defined
9.2.2 DNSSEC _not_ defined at compile time.
9.2.3 bug fix release
- BIND developments
GSS-TSIG to be incorporated in 9.3 and performance increase.
- BIND Forum
The forum is a source of funding for BIND development and support.
Members have CVS access to bind9 code.
Increase of membership is needed to achieve stability.
- OpenReg: reference implementation of an EPP based registry system.
- F-ROOT: Anycasting on a large number of local nodes.
Joao concluded with expressing gratitude for RIPE NCCs contribution to
the BIND forum.
---------------------------------------------------------------------------
D. Invited talk: Mitigating Junk DNS Traffic, How the AS112 Project Can Help
John Brown, Chagres Technologies
Cancelled due to illness.
---------------------------------------------------------------------------
E. Invited Talk: DNS RTT Measurements: ccTLDs compared with roots/gTLDs
Nevil Brownlee, CAIDA
Slides available at:
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-nevil.pdf
Nevil does passive measurements of DNS traffic and presented a talk
similar to the EOF presentation on Monday though tailored towards
ccTLDs.
He stressed that this is on-going work and that he is interested in
feedback on what aspects are interesting for ccTLDs to measure.
Nevil went into the details of measurements made in the first week of
May and demonstrated how certain effects in his plots can be explained
by congestion close to the probe or the server, daily load effects,
route changes, &c, &c.
He demonstrated some of the differences in the measurements of
Root/gTLD and ccTLDs. One remarkable observation is that the Suriname
(SR) TLD seems to be a very popular TLD among the measurement sites.
Comments on SR being 'that popular'
+ Liman notes that this may be a bug.
+ Faltsrom did some tests: SR seems to have a lame delegation to one
of the servers that returns a SERVFAIL for some queries. This may cause
an increase of traffic.
Nevil further showed slides with details about a number of ccTLDs and
explained the congestion patterns.
More NeTraMet meter sites for DNS monitoring ar needed.
following the "Setting up a NeTraMet meter" on http://www.caida.org/~nevil
Chair's Question: Could you give recommendations, using this data, to
ccTLD operators.
Answer: willing to collaborate if there is interest.
Chair's Question2: Maybe looking at the semantic content can be useful for
understanding what is going on.
Answer: There are limitations, line rates only allow to look at the
first cell currently. With new interface cards looking at DNS content
might become possible.
---------------------------------------------------------------------------
F. Delegation and Lame Server Checking
F.1 ZoneCheck: DNS zone checking tool
Stephane D'Alu, AFNIC
Slides available at:
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-zonecheck.pdf
Tool available at http://zonecheck.nic.fr/v2/
For testing contact zonecheck@nic.fr
Stephane presented the 2nd version of ZoneCheck.
Highlights:
+ Checks on:
o DNS RRs: SOA, NS, A, AAAA, MX,
o Consistency: SOA serials and content
o Flags: recursion and authority.
+ Modular build so other checks can be build in.
(RFC compliant checking tool)
+ monitoring: http://tac.eureg.org/mon/
+ Strengths of the tool
Answer to a question about languages: Both French and
English are available.
Faltsrom: Test on open relay reports false positive
Answer bug.
F.2 Fixing Lameness - A Registry Perspective
Ed Lewis, ARIN
Presentation at
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-testing-lameness/
Ed presents the impact on the ARIN engineering department for doing
lameness tests. The goal is to give references to those
engineers who want to do lameness tests too.
This work is based on a policy described in
http://www.arin.net/policy/2002_1.html
He discussed a number of issues that one has to consider:
o why do you want to do lameness tests (save the net or save the
DNS).
o How do you store your registry data against you want to check
(how do you perform the mapping).
o When and how do you contact a registrant.
o Taking into account the change in the db based on your
feedback.
o Staging your test (in line with your testing policy):
o Training your first line support staff
o What kind of statistics do you keep and present
o What is best practice and what is "allowed" practice; how far do
you go into improving data.
o How do you share information with other registries.
Comments by George Michealson: There is an emerging policy in
the APNIC DNS-SIG. There are questions like what are definitions
of lameness and what are the procedures to be followed. He
welcomes feedback.
George comments on the differences in his personal opinion on some
of the choices made by ARIN and his own ideas on lameness: e.g.
a 60 days timeout should be considered consistently lame.
Jim Reid asked what kind of response you get from customers.
Ed answers that the responses were positive and reactive.
F.3 New Tools for Lameness and Delegation Checking
Patrik Faltstrom, Cisco Systems
Slides available at:
http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-check/
Patrik presented 'dnscheck' (http://dnscheck.paf.se). He gave a
life demonstration. The tool reports errors where an error is
defined as not getting relevant data back. i.e. if only one of
the nameservers does not return a proper answer.
The tool concentrates on 'parent-child' relation ships.
The .SE zone returns 22% errors. 41% lame, 14% missing A, 14%
TCP, 6% non-functioning email in SOA, 5% illegal CNAME in MX, 4%
has less than 2 NS RRs. Only a small fraction of the zones have
combined errors.
Patrick poses questions; how come? what are the requirement,
what are the recommendations? Is this a WG issue?
Tool at http://dnscheck.paf.se discussions on
dnscheck@lists.paf.se.
Question by Jim Reid: Are the tests cached so one can tell that
things are improved.
Answer: Tests are not being stored for more than the tests that failed
during the latest one.
Question Bernard Tuy: is there IPv6 support
Answer DNSSEC and IPv6 are on the stack.
Question Winkler: How do you check the consistency at the
root. What is the authoritative information. The delegation NS
set or the TLD NS set.
Answer: First the root delegation NS set is requested, it is
checked for consistency in the NS RR set in the TLD, then the
glue is verified against the addresses in the DNS.
Remark by George Michaelson: The trends seem flat.
Answer: The data is only been collected for a month.
2nd Remark by George Michaelson: An authoritative NXDOMAIN hurts the
end-users most.
F.4 Panel Session on Delegation and Lame Server Checking
Stephane D'Alu, Ed Lewis & Patrik Faltstrom
Andrei Robachevsky and George Michealson
Chair explains that this is a mixture of technology and policy and
that there may a working item for this working group.
Daniel Karrenberg: The quality of the DNS lameness seems to have
been constant. The DNS remains working. Do we want to play protocol
police?
Will there be an impact on the registry operators?
Randy Bush: If you delegate zones you are responsible for the
technical quality. The availability of tools helps. DNS breakages
effect end users e.g. microsofts delegation not observing RFC 2881
recommendations. Let us not wait for fatal breakage.
Patrick Faltsrom: Big DNS operators seem to be able to do a better
job. This may be due to the availability of better tools. (General
availability of tools, also for smaller DNS operators, is good)
Mohsen: Lame delegation happens after the delegation. Regular checks
are good.
Akkerhuis: Most complaints are not about being lame but more that
registrants have moved domains and old ISPs have not removed their
zones from the old zones. (Karrenberg suggests that with tools that
keep history you can actually check this)
Karrenberg: It is a good thing that zone administrators checking
what happens in their zones but are the mechanism used correct?
Reid: How do we do this; which tools do we need, what policy statements.
Randy: Since there is no increased error rate. Do not confuse RIPEs
job with the job of the ccTLDs.
Michaelson: Lameness is not well defined. We probably need a good
common understanding. Faltsrom refined that we should be careful to
not to have statements about lameness into quality statements.
The chair gauged if there is consensus for working on this lameness
issues in particular with respect to practices on the reverse tree.
Reid, Faltsrom and Michaelson volunteered further discussion on the
mailinglist.
---------------------------------------------------------------------------
AOB:
A patent was granted to Verisign for multiple simultaneous domain
name searches.
|
you are here: RIPE -> RIPE Working Groups -> DNS
