Dear DNS WG,
here's an updated draft agenda for the upcoming meetings on Thursday next week.
Changes include an extra slot for discussion of K-Root anycast. DNSSEC
status updates were merged into the general reports item.
-Peter
# $Id: RIPE52agenda,v 1.6 2006/04/20 11:14:44 pk Exp $
#############################################################################
D R A F T
#############################################################################
DNS-related presentations in the EOF/plenary:
TUE, 2006-04-25:
Reflector Attacks Using DNS Infrastructure (Joao Damas)
DNS amplification attacks (Matsuzaki Yoshinobu)
Security Issues in ENUM (Gerhard Schröder)
WED, 2006-04-26:
Perils of Transitive Trust in the Domain Name System (Emin Gun Sirer)
The Impact of anycast on Root DNS Servers.
The Case of K-root (Lorenzo Colitti)
DNS in Turkey (Attila Ozgit)
#############################################################################
2006-04-27 1100 - 1230, DNS WG slot I [90 min]
#############################################################################
0) Administrivia
[chairs][ 5 min]
- scribe, jabber, minutes
- agenda bashing
1) Status Reports
[][30 min]
- IETF dnsext, dnsop and others
[Olaf Kolkman][18 min]
- IANA Overview
[David Conrad][ 7 min]
- DNSSEC News/Statistics from the NCC
[][ 5min]
2) Action Item Review
[chairs][15 min]
<http://www.ripe.net/ripe/wg/dns/dns-actions.html>
48.1
48.2
49.1
49.2
51.1: see (3) and plenary presentation on K-root
51.2: see (4)
51.3: see also <http://www.ripe.net/news/review-secondary-dns.html>
51.4
51.5: see (6)
3) Anycast on K-Root
[Lorenzo Colitti, RIPE NCC][10 min]
4) IP6.INT phase out
[Andrei Robachevski, RIPE NCC][10 min]
5) Reverse DNS Quality
[Brian Riddle, RIPE NCC][10 min]
6) Proposal to bring ENUM Zone Management in line with the Reverse DNS
[N.N., RIPE NCC][10 min]
#############################################################################
2006-04-27 1600 - 1700, DNS WG slot II [60 min]
#############################################################################
7) Plenaries Followup
[chairs][15 min]
Discussion of details postponed from plenary presentations (see above),
including identification of potential work for the WG
8) ICANN IDN guidelines & IDN Future
[Marcos Sanz][20 min]
<http://www.icann.org/topics/idn/implementation-guidelines.htm>
[may also touch draft-iab-idn-nextsteps-05.txt]
9) Nominet's Dynamic Updates
[Jay Daley][15 min]
X) I/O with other WGs
[chairs][ 4 min]
Y) A.O.B.
[chairs][ 4 min]
Z) Wrap-Up & Close
[chairs][ 2 min]
#############################################################################
Dear WG,
find below the draft agenda for our two sessions during the upcoming meeting
in Istanbul. Please send comments to the chairs.
-Peter
# $Id: RIPE52agenda,v 1.5 2006/04/13 15:06:05 pk Exp $
#############################################################################
D R A F T
#############################################################################
DNS-related presentations in the EOF/plenary:
TUE, 2006-04-25:
Reflector Attacks Using DNS Infrastructure (Joao Damas)
DNS amplification attacks (Matsuzaki Yoshinobu)
Security Issues in ENUM (Gerhard Schröder)
WED, 2006-04-26:
Perils of Transitive Trust in the Domain Name System (Emin Gun Sirer)
The Impact of anycast on Root DNS Servers.
The Case of K-root (Lorenzo Colitti)
DNS in Turkey (Attila Ozgit)
#############################################################################
2006-04-27 1100 - 1230, DNS WG slot I [90 min]
#############################################################################
0) Administrivia
[chairs][ 5 min]
- scribe, jabber, minutes
- agenda bashing
1) Status Reports
[][25 min]
- IETF dnsext, dnsop and others
[Olaf Kolkman][18 min]
- IANA Overview
[David Conrad][ 7 min]
2) DNSSEC Status and Deployment Reports
[][20 min]
- SE Experiences
[][]
- DNSSEC Deployment WG
[][]
- News/Statistics from the NCC
[][]
- Other
3) Action Item Review
[chairs][10 min]
<http://www.ripe.net/ripe/wg/dns/dns-actions.html>
48.1
48.2
49.1
49.2
51.1: see plenary presentation on K-root
51.2: see (4)
51.3: see also <http://www.ripe.net/news/review-secondary-dns.html>
51.4
51.5: see (6)
4) IP6.INT phase out
[Andrei Robachevski, RIPE NCC][10 min]
5) Reverse DNS Quality
[Brian Riddle, RIPE NCC][10 min]
6) Proposal to bring ENUM Zone Management in line with the Reverse DNS
[N.N., RIPE NCC][10 min]
#############################################################################
2006-04-27 1600 - 1700, DNS WG slot II [60 min]
#############################################################################
7) Plenaries Followup
[chairs][15 min]
Discussion of details postponed from plenary presentations (see above),
including identification of potential work for the WG
8) ICANN IDN guidelines & IDN Future
[Marcos Sanz][20 min]
<http://www.icann.org/topics/idn/implementation-guidelines.htm>
[may also touch draft-iab-idn-nextsteps-XX.txt]
9) Nominet's Dynamic Updates
[Jay Daley][15 min]
X) I/O with other WGs
[chairs][ 4 min]
Y) A.O.B.
[chairs][ 4 min]
Z) Wrap-Up & Close
[chairs][ 2 min]
#############################################################################
Hi!
May be a bit offtopic here, but could be interesting ;)
.RU now have a DNSSEC signed view as well as secure delegations. Details are
on the http://www.dnssec.ru/
Now it is beta stage. Any comments/suggestion are wellcome.
BIG THANKS to RIPE and especially RIPE NCC DNS/DNSSEC training courses that
explained me DNSSEC infrastructure and give me an idea to make DNSSEC
signed .RU domain!
--
WBR,
Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
[Apologies for Duplicates]
Dear Colleagues,
The RIPE NCC changes the Key Signing Keys (KSKs) for its signed zones twice
each year. We have today published new keys for all zones. Old keys will
continue to function until the second stage of the rollover on 3 July 2006.
We recommend that you reconfigure any resolvers to use the new keys before
then. You can download them from:
https://test-www.ripe.net/projects/disi//keys/ripe-ncc-dnssec-keys-new.txt
The DNSSEC Key Maintenance Procedure is available at:
https://test-www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html
If you have any questions about this, please send an e-mail to
<ops(a)ripe.net>.
Regards,
Brett Carr
RIPE NCC
Hi!
Where can I find the list of signed domains and their open keys to set up my
DNS resolver? Which zones are signed now (exept RIPE's ones)?
--
WBR,
Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
I've dusted off the Misbehavior of DNS document, cleaned it up a
bit, added comments based on what was said on the mailing list when
I last posted it (including some of the related issues mentioned).
Do people think this is worth perusing as a RIPE document? Is the
related issues section useful? Are the comments on testing useful?
David.
Misbehavior of DNS when faced with IPv6 or other New Query Types
David Malone
February 2005
Abstract
This document is a short description of problems with certain DNS
systems that have come to light with the deployment of IPv6 enabled
software.
1. Introduction
One of the services that DNS provides is a facility for mapping
host names to IPv4 addresses. This is probably the most common used
service that DNS provides, and is achieved requesting a record of
type "A" for the host name. Records of type A can only store an
IPv4 address, and so with the introduction of IPv6, a new record
type, AAAA has been introduced. It is becoming increasingly common
for software to first issue a request of type AAAA, and if no record
of that type is found then to issue a request for a record of type
A.
A request for a record of type AAAA causes no problems for most DNS
servers, however some DNS servers implementations have been found
that have problems answering other queries. Some DNS implementations
have problems with only new types, such as AAAA, and others have
problems with any query not of type A. The end result of these
issues is that connecting to a site using a problematic name server
may be impossible, intermittent or significantly delayed.
The technical details of these problems are explained in [RFC4074].
2. Problem Extent
In Q1 2004, a survey of nameservers for 24000 hostnames mentioned
in web proxy logs found about 0.5--1% of name servers seem to have
to have a problem of this nature. This corresponds to about 1.8%
or URLS that are impacted by the problem. For more details of this
survey see [IPJMISBEHAVE].
In terms of DNS server software, DNS load balancers seem to be
commonly affected. This means that high-volume sites, such as ad
servers, are often victims of this problem. Due to the embedding
of ad-server images in web pages, the extent of the problem may be
experienced by users of other web sites displaying these ads.
3. Testing New DNS Systems
To prevent introducing more DNS servers with such issues, testing
of new DNS equipment should include checking that the response for
records is in accordance with the RFCs (in particular [RFC1035],
[RFC3597] and [RFC4074] mentioned above). As DNS load balancing
software has often fallen foul of these problems, particular care
should be taken in testing and validating such systems.
Simple testing can be conducted by making a query for a AAAA record
using a tool such as dig. Supposing that the server has IP 192.0.2.1
and is to serve the domain example.com, queries such as the following
should be made:
dig AAAA exists.example.com @192.0.2.1
dig AAAA does-not-exist.example.com @192.0.2.1
dig AAAA www.subdomain.example.com @192.0.2.1
In each case the server should return the correct number of AAAA
records (0 if there are none) and a status of NOERROR. Even if the
server is only responsible for reverse zones, where queries for
AAAA records are uncommon, such tests are still useful as reverse
zones may still receive queries for other new record types.
A simple web-based tool for testing is available at
http://www.cnri.dit.ie/cgi-bin/check_aaaa.pl
This tool can detect some of the most common problems given
a domain name.
4. Addressing the Existing Problem
The fact that problematic nameservers exist is in itself a problem.
Where these issues cause direct inconvenience, the maintainers of
the server and the maintainers of the DNS data should be notified
to allow a normal service to be restored. However, often it is
difficult for end users to identify the source of these problems,
(for example, where an image embedded in a web page being served
from a host with a problem hostname).
It is also possible to automatically produce lists of names and
nameservers that exhibit these problems. Clearly it is possible to
automatically mail hostmaters or to publish "hall of shame" lists
based on such data. It is unclear if such actions would achieve any
useful effect, as service maintainers are usually primarily concerned
about complaints directly from paying users!
The action required to restore normal service may just require a
simple software upgrade if the DNS Server vendor has already addressed
these issues. A DNS server vendor should be able to address the
issues using the RFCs referenced in this document.
5. Related Issues
There are a number of other IPv6 related DNS issues that warrant
mention.
5.1 A6 Records
Initially, IPv6 addresses were to be determined in the DNS using
A6 records, rather than AAAA records. Name servers that respond
incorrectly to AAAA requests are also likely to respond incorrectly
to A6 records. A6 queires are now considered experimental.
5.2 ip6.int vs. ip6.arpa
Originally, two schemes were proposed for IPv6 reverse lookups. One
used the ip6.int domain and the "nibble" format. The other used the
ip6.arpa domain and the "bitstring" format. The system that has now
been settled on uses the ip6.arpa domain and the nibble format.
While some use of the ip6.int domain continues, it has been deprecated
by [RFC4159].
5.3 Resolver Issues
There can also be issues with DNS resolvers. Some resolvers may not
react as expected when asked to act on unusual addresses (such as
IPv6 mapped addresses). Other resolvers have had problems if a host
both IPv4 and IPv6 addresses. Still others have had problems if
hosts have only IPv6 addresses.
Some of these issues can be worked around by the application
developer, however many vendors now have software updates to address
these issues.
6. Acknowledgments
This work is a product of the RIPE DNS Working Group.
7. References
[RFC1035] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987
[RCF3597] A. Gustafsson, "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4074] Y. Morishita and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4159] G. Huston, "Deprecation of "ip6.int"", RFC 4159, August 2005.
[IPJMISBEHAVE] D. Malone, 'Misbehaving Name Servers and What They're
Missing', The Internet Protocol Journal - Volume 8, Number
1, March 2005.
