=============================================================================
DNS WG Meeting at RIPE 42; Thursday, May, 2nd 09:00 - 12:30 MEDT
=============================================================================
Minutes by Olaf Kolkman & Daniel Diaz, compiled by Peter Koch & Jim Reid
=============================================================================
0 - Welcome & agenda bashing
1 - IETF Reports
1.1 - DNSEXT & DNSOPS - Lars-Johan Liman
1.2 - IDN & ENUM - Patrik Falstrom
1.3 - DNSSEC - Roy Arends
2 - Documentation
2.1 - SRV/Whois - Marcos Sanz
3 - DNS Damage: root server - k claffy
4 - Authoritative Servers - Alexis Yushin
5 - DNS Server Analysis - Daniel Karrenberg
6 - WG Administrivia
7 - AOB
=============================================================================
0 - Welcome & agenda bashing [09:00]
- -------------------------------------------------------
WG Chair Jim Reid encourages the attendees to give feedback about
the WG direction etc.
Minutes of last meeting were approved.
Chair asks for AOB. None.
=============================================================================
1 - IETF Reports
- ----------------
1.1 - DNSEXT & DNSOPS - Lars-Johan Liman [09:30]
- -------------------------------------------------------
For DNSSEC related material see Roy's presentation
APPKEY: Where to store application keys (non-DNS keys)?
- Key RR designed to carry other types of keys.
When records have the same type and are put in the
same record set, you sign the whole RRset, so, in
case there's any change within the RRset, you need to
sign it again.
Keys may be under different administrative domains.
The problem comes when you change this in your zone,
and your parent zone needs to resign anytime there's
any little change in your zone.
- 3 possible solution to move appkeys away:
+ Use new RR for each type of key (PGP, WEB, ...)
+ 1 new RR type (APPKEY) for all types of key.
+ subtyping using the owner name (like SRV)
No consensus is reached on this yet.
Probably do not want to do this in DNS at all.
---------------------------------------------------------------------------
Secure dynamic updates.
- Sharing information in an ad-hoc environment.
- Documented on http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html
---------------------------------------------------------------------------
There's also a draft which specifies that you shouldn't
put unreachable addresses on public DNS servers:
draft-ietf-dnsop-dontpublish-unreachable-XX.txt
Will get published as a BCP RFC
---------------------------------------------------------------------------
v6 induced name space fragmentation
draft-ietf-dnsop-v6-name-space-fragmentation-XX.txt
IPv6 transport servers may lead to a situation where a node
is unreachable because the IPv6 client can not talk to an IPv4
server at a delegation point.
Guiding principle: Coherence, same answer regardless of transport
layer.
Ugly solutions:
+ 'tough luck': Goto IPv6 if you want to see the server
+ Mandate IPv4 on each dnssec server (bad way as it sticks to v4)
+ DNS NAT/Bridges; will not scale and cannot be removed
---------------------------------------------------------------------------
Final note:
i.root-servers.net no longer servers "SE"
has following zones: root zone, "GOV", "IN-ADDR.ARPA", "ARPA", "EDU"
---------------------------------------------------------------------------
Question:
There's no real solution for the v6 frag. problem?.
Liman: No, think about it and come with a solution.
Randy: The client has to do stuff.
Liman: the resolvers... We're really looking for a better solution.
Jim: let's have the WG really do some work: explore practical problems
with IPv6 deployment
1.2 - IDN & ENUM - Patrik Faltstrom [09:05]
- -------------------------------------------------------
ENUM status report
Working on updating RFC2916 (current draft: draft-ietf-enum-rfc2916bis-00.txt
)
Next week new version.
Pls send comments to Patrik.
New stuff:
- Old serv. field: service+E2U
- New serv. field: E2U+service1+service2+...
- Service fields need to be specified in a RFC.
We are all waiting for ITU-T to do something (since Jan 2001).
---------------------------------------------------------------------------
IDN (Internationalized Domain Names) status report
"People seem to understand what this is about now ;-)."
The problem is not in DNS but in the application layer.
Use of other characters than ASCII in labels.
IDNA (bettwen the Application and the communication layer)
Changes input to ASCII 'hostname syntax' encoding using nameprep
Input from user -> Apply nameprep -> Apply punycode
Application change:
- Prepare name using nameprep
- Apply an ACE
- Send encoded name to resolver
Status:
IETD IDN WG Consensus on documents.
Area director may come back with comments this week.
Wants the actual char tables to be moved from nameprep to stringprep
The IDNA algorithm should be operating on a label, not on a hostname
(difficulty finding the boundary between two labels).
Difference between Stringprep and Nameprep:
- Stringprep is a generic framework
- It specifies functions like: Case folding, Normalization,
Prohibition of codepoints and versioning (of Unicode).
- Used in various protocols: IDN, iSCSI, Kerberos
Changes: The profiles themselves include de mapping table used
for case folding.
IESG want the map table as part of the stringprep to minimize the risk that
different protocols use different tables
1.3 - DNSSEC: DS & Opt-In - Roy Arends [09:15] (20 minutes)
- -------------------------------------------------------
DS and OPT-IN are two major changes recently made to RFC2535
Why DS (Delegation Signer)?
+ Keymanagement is difficult with current protocol;
many interaction between the parent and child during key-rollover.
Imagine doing this changes every week.
Keys are rolled over regularily due to lack of key revocation
mechanism
+ DS RR reduce number of interactions.
+ DS introduces concept of key-signing key.
There's a master key: this will not change in a regular case.
This key signs the keyset.
In the parent zone you just have a link to the key not the key itself.
Only interaction with parent if the key-signing key changes.
+ DS difficulties
Introduction of DS is not backwards compatible, flag date needed.
Current secure resolvers need to be upgraded.
DS is through last call has full concensus.
---------------------------------------------------------------------------
OPT-IN
NXT RRs are painful for large zones ("COM",...). For any delegation there
you need a NXT record for child zones which are not secure.
DNSSEC has little initial deployment. NXT RRs have high generation costs
for ordering, signing, distribution.
OptIn only changes one bit in NXT RR
2535 vs OPT-IN
2535 NXT: authenticated denial of existance of names.
OPT-IN: authenticated denial of signed names.
2535 NXT: will say the unsigned name exists (crypto verif).
OPT-IN: will say it exists (not crypto verif).
+ Semantics changes from Authenticated denial of existence of
names (RFC2535) to Authenticated denial of existence of *signed*
names (OPT-IN). Opt-In allows for unsigned names.
+ Positive side effects of NXT records (NXT chaining no longer shows
whole zone)
+ A chain of secure delegations is posible without the requirement
to sign the whole zone.
Opt-In has been through last call, still under discussion.
"consensus" for doing OptIn for delegations only
=============================================================================
2 - Documentation
- -----------------
2.1 - SRV/Whois - Marcos Sanz [09:47]
- -------------------------------------------------------
Using SRV records to locate Whois servers
Locating Whois servers for domain lookups
Initiative from Gerhard Winkler (ACONET).
This is not a redefinition of the whois protocol, but a plug-in to any
existing whois service
It is not a recommendation on the behaviour of whois clients.
Trying to reach a whois service for a 'example.si' may be difficult.
You may be lucky and include a referral in the whois.ripe.net database.
What if not?
Use SRV RR: (RFC 2052 obsoleted by RFC 2782), supported in bind since 4.9.5
Specifies location of servers for a specified protocol and domain.
example:
_whois._tcp IN SRV 0 0 43 whois.nic.example.
Draft has been circulated on the list. Please contribute to the discusssion
on the list.
This is a private initiative and proposal, not an IETF internet draft.
QUESTION: What if I want to know which whois server serves a.b.c.d?
ANSWER: Need to look at d. then c.d. then b.c.d. then a.b.c.d.
Suggestions from the audience to do the search bottom up.
Suggestions from audience to take into account IETF work on revised
whois protocol (presentation by Leslie Daigle in DNR Forum) and
LDAP/whois combination (draft-hall-ldap-whois-XX.txt)
ACTION: [authors] Incorporate comments and resubmit updated draft
ACTION: [all] Discuss draft on WG mailinglist
=============================================================================
3 - DNS Damage: root server - k claffy [10:06]
- -------------------------------------------------------
DNS Damage: Measurements at a Root Server
Invited talk by kc claffy, CAIDA (Analysis by Evi Nemeth)
An analysis of the DNS traffic at f.root-servers.net
Caida does active and passive measurements
Active: best topology for root-servers for RSSAC
Passive: listening to name-server traffic and measuring response time
(work by Nevil Brownlee)
f.root-servers.net is one of 13 root name servers.
Query rates at the root servers range from 5000 q/s at "F" to
12.000 q/s at "A". "A" saw 38.000 q/s during a DOS attack (saturated
incoming bandwidth). "F" is two DEC alphas load-balanced by a Cisco router.
Too many root servers concentrated on the US. (Mainly in California).
Lot of traffic generated by bogus queries issued mainly by:
- queries from RFC1918 addresses.
- W2k boxes trying to update the root zone.
- Windows98 and OSX wrong programmed resolvers.
- Involunteer errors (inexistent/wrong domain names...).
- DDoS or DoS attacks.
Microsoft's 4 authoritative nameservers visible to the outside world
were on the same subnet. When they disappeared, this affected the root
system ("F" had a load increase of 25%).
- Bogus A queries: 14%
- Bogus TLDs queries: 20%
Negative caching could help. BIND8 and BIND9 both include this.
KC showed (shocking) details in lightning speed: See paper on caida website.
If you want to get graphs: http://www.caida.org/cgi-bin/dns_perf/main.pl
=============================================================================
coffee break [10:34]
=============================================================================
4 - Authoritative Servers - Alexis Yushin [11:05]
- -------------------------------------------------------
Authoritative Servers: specifics, problems and techniques
Auth Only Servers: gives only authoritative answers. No recursion,
all the information there statically.
No updates schedule needed. No caching. We know all the
answers beforehand. It's all given. Root servers is a typical case.
NSD - Name Server Daemon
Requested by RSSAC for several reasons:
- Performance issues.
- Code diversity.
Why Auth Only servers?.
- Separate cached & authoritative data.
- Simplify the software and avoid bugs and security flaws.
- All the existing DNS software had to adapt to any new DNS feature:
dynamic updates, DNSSEC,...
- It has separate cached and authoritative data.
- Simplifies the software and increases performance, security and this
makes it more robust.
How did we do this?
- Setting requirements ->
- There are grey areas on how to deal/response to queries out of your
authority (your data).
- All the answers precompiled.
- This leads us to separate the daemon and the zone compiler (this is the
software which takes the zones in the format defined in the RFC and
translates them into the answers).
- Makes use of pre-name compressed packets.
- No dynamic updates, or other features which are not required
in this type of server.
The NSD design:
Zone-files -> Zone compiler -> Answers -> DB -> Daemon -> Queries & responses
- The zone compiler
Goes through the zone in memory and puts all the possible answers in
the DB. All the answer logic is in the zone-compiler.
QUESTION: Do you really mean a DB or just "some storage"?
ANSWER: Have both options
The daemon does not know anything about the zone files itself.
All the slow things happen off-line (compiling the zone-file).
- The daemon itself
Network transport (I/O from/to the net).
A little resolver algorithm: to fetch in the DB the right answer.
Name compression.
Truncation (this can't be done in advance).
Optionally EDNS(0) OPT insertion.
- Answers DB
On global DB for all zones.
The domain aname and RR type is the key.
pre made packet and list of pointers in core database
nmap() or malloc() + read() used
either hash or rbtree -> little difference in performance
The way the answers are for DNSSEC is different than for regular
DNS, so, it is necessary to have AXFR & DNSSEC in separate databases
- Name Compression
In the following cases:
- Owner names, in RDATA, complete answers, delegations, wildcards,
case insensitive, glue records.
- We can do name compression based on the answers, but we cannot
compress efficiently against the question, because that's obviously
unknown beforehand.
- Answering queries:
Receive query -> Resolve it -> Update pointers ->
|
|--No-> Truncate -> send answer
|__Yes -> Send answer.
- The resolving algorithm:
Parsequery -> Lookup -> match? ->yes -> answer
|no
v
-> NS? ->yes -> answer delegation
|no
v
-> SOA? ->yes -> answer NXDOMAIN
|no
v
-> Wildcard->yes-> asnwer.
|
v
no
strip leftmost label -> Empty? -> No -> Lookup again
|
-> yes -> srv failure.
missconfig.
Policy decissions (NSD):
- Query filters
- Exponential delays for bogus queries
maybe a good idea.
- AXFR off-band
NSD doesn't do AXFR as of now.
will implement outbound AXFR, inbound is better done offline
due to compiler
- What to do with the bad queries?
NSD does not need a config file, so it'seasy to manage
Results NSD:
3 times faster than conventional design.
Extra record (DS) affects zone compiler. We need separate DB for DNSSEC.
It is necessary to walk down the tree (can't use hash)
http://www.nlnetlabs.nl/nsd
QUESTION: AXFR with TSIG?
ANSWER: Yes, we always consider AXFRs with TSIG. Other way it doesn't make
any sense.
=============================================================================
5 - DNS Server Analysis - Daniel Karrenberg [11:38]
- -------------------------------------------------------
A Comparison of Answers and Performance beween NSD and other DNS Server
Implementations
This presents the results of extensive testing work performed
during the validation and tuning of NSD. It compares the
answers of various implementations to DNS queries observed in
actual Internet operations at a root server and a number of
TLD servers. The talk describes and classifies notable
differences in the answers observed and gives an overview on
the responsiveness of various implementations under different
load conditions.
To compare the implementations a special lab was designed and
implemented: Domain Name Server TEsting Lab - DISTEL
motivation: regression testing of NSD
performance evaluation of root server components
since no realistic traffic generators available
simulation and analysis of abnormal query loads
sooner or later (maybe): general functionality testing
and performance evaluation
what is it: present a reproducible load to a server
synthetic
observed (tcpdump traces)
@varying speeds
Record the answers(!)
extract information
- performance
- functionality
regression testing (compare different runs)
DISTEL is made of 2(3) machines running FreeBSD connected
by 2 nets (test & control), uses off the shelf open source tools and
a "hacked" tool: tcpreplay.
There's also special purpose software (in perl and C).
The software set is not yet finished and it's not a packaged set of
software, since that would require lots of work for documentation and
packaging itself
How does it work?
(graph:player -> DNS server -> recorder)
regression testing
compare different runs
after mods to software
different implementations
high volume
typically ~900k queries per run
cannot compare manually
efficiency of nsd name encoding: in .46% answer is same,
but encoding is less efficient (due to precompiled answers, which cannot
take into account query section as compression target 100% efficiently)
other case: answer section identical, but overall response differs
(truncated additional section)
found no answer(!) truncation in any test run
Did tests not only for root zone, but also "NL" and "DE"
Differences were 30% and 15%, but none critical
had to fix (hack) the timing (microsecond sleep in traffic replayer
didn't work well) in tcpreplay
=============================================================================
6 - WG Administrivia [12:20]
- -------------------------------------------------------
Chair thanked Ruediger Volk for his efforts leading the WG during the
past years
Peter Koch has stepped forward to assist chair
Should the WG do some 'work'?
Possible fields:
- How to do IPv6 related DNS stuff
- Recomendations on DNSSEC
- IDN
- The idea is to do workshops or to produce documents.
- Inviting feedback on effectiveness of the meetings .
- Show of hands for future directions:
Who are you?
DNS operators 80%
heavily loaded servers: about 10%
forward: <10%
reverse: <10%
forward and reverse: most
having played with IDN: ~5%
having played with A6: ~50%
having played with DNSSEC: ~30%
DNSSEC in production systems: ~5%
have DynUpd in production: 5%
would like to learn DynUpd? 5%
are from registrar: 2
are from registry: 40%
have direct contact to end customers: 30%
Suggestions to: dns-wg-chair@ripe.net
ACTION: [chair] Analyse results and take into account for future agendas
=============================================================================
adjourn [12:30]
=============================================================================
you are here: RIPE -> RIPE Working Groups -> DNS
