RIPE 41 - DNS WG
----------------
Chair: Ruediger Volk
Scribe: Olaf Kolkman & Daniel Diaz
Agenda
------
1 .-Welcome & agenda bashing.
2 .-Meeting Reports.
1. ICANN - O.Kolkman.
2. IETF DNSOPS&DNSEXT - Johan Ihren.
3 .IDN - Patrik Falstrom.
3 .-ENUM News - Patrik Falstrom, Cisco.
4 .-ISC News & BIND Roadmap - Lynda McGinley,ISC
5 .-Invited Talks:
1. OTDR Update - Bill Manning.
2. Vulnerabilities in the Internet - Jaap Akkerhuis, SIDN.
6. AOCB
1. WG Administrivia
2. NLnet Labs/RIPE NCC DNS testbed & Auth. Server projects.
-------------
Intro (Ruediger Volk) - 2 yrs. being the chair. Jim has helped this time
R.V. to run the meeting (WG). Preparing the agenda, etc...
Working documents missing in the agenda.
Went through the agenda. Ask for suggestions, additions to the agenda.
No new agenda points.
1st. presentation.
-------------------------------
Olaf K.(ICANN Security meeting)
-------------------------------
Report.
Asks for corrections to the crowd in case they were in the meeting.
Held in Marina del Rey.
Basic issue: 'Role for ICANN in securing the name and address allocation'.
Security specialists informed ed the audience (Olaf was one of them).
Conclusion:
-Responsibility
- ICANN's role is very small.
Span of tech control is only minimal.
Resp: IP address alloc, DNS mngmnt, Root name server mngmnt.
IP address allocation:
- S. Bellovin observed:
- IP assignment data is key to routeing sec.
- Not up to date for older assignments.
Role for ICANN and the RIRs.
DNS mngmnt - Maintained by users, ISPs, etc...
ICANN's role: Operational requirements and advisories for registries.
Securing the DNS alone will not help to secure the name allocation.
DNSSEC only offers sec for the tech side of DNS.
ICANN is only responsible for the contents of the root-zone.
Data is published by 13 root servers operated by different organisations.
They are vital to the Internet.
DNS is designed to cope with outages. (RFC2870).
Operational requirements os documented in RFC2870 and
currently Root servers follow this doc. they're different
HW, diff OS, only little variaty ini DNS SW: BIND.
It came from the meeting that MoUs would work better than contracts.
All this available at:
http://cyber.law.harvard.edu
http://www.ripe.net/disi
------------
2nd. presentation
----------------------------------
IETF 52 DNSEXT/DNSOP (Johan Ihren).
----------------------------------
The group was split between corridor talks, different
sessions, etc... which makes difficult to remember what was
said and by who.
DNSEXT
--------
Discussion about DNSSEC is picking up or bogging down.
name fragmentation issues (IPv6).
a paper on DNS threat model was introduced by Rob Austein:
------------------------------------------------------------
- it is written now (what was not written before).
- moreless finished.
- is time an additional threat vector as DNSSEC and TSIG depends
on SYNC.
DNSSEC issues at the table:
--------------------------
- Delegation signer - good and significant change on providing additional
stuff to manage delegation signing.
- Opt-in.
- APPKEY - regarding key mngmnt. howto store non-DNS (ssh, pgp,,,) keys.
Delegation signer: pros
-----------------------
- Delegation signing provides good signing ..
- Wasn't designed to sign the root, but it may be crucial for that.
- flag day: (there are significant and incompatible changes). Risks
of finding problems in the code, etc... that's the reason tests
are happening, etc... but still some undiscovered stuff could turn
up later...
OPT-IN
------
DNSEC (normal) is too expensive for operational issues.
This changes the granularity of DNSSEC sec. from 'zone' to 'owner-name'.
there are different opinions about this.
The debate about this could just go on and on and on.
DS and OPT-IN
--------------
Both are protocol changes. DS is perceived as necessary.
He guesses that both will be in.
Olaf suggested to use OPT-IN just for delegation nodes.and
keep 2535 for all auth nodes.
APPKEY: where to store application keys?.
-----------------------------------------
alternatives to storing keys in an RRset:
- Invent a new record type (APPKEY).
- A subtype of a RR. in the RDATA part like present KEY of APPKEY
per key appl.
or...
- Not in DNS at all: separate DB coding the type of key in the owner name.
SIGNING the ROOT
----------------
Splitting the key is the key ;-).
Secure Dyn. updates.
Is it worth or not?.
DNSOP
-----
Less controversial this time.
draft about unreachable addresses.
draft on taxonomy of bad dns resolvers (Matt Larson).
Is useful and looks good. Will get split into 2 docs
for clarity.
V6- (Painful corner)
--------------------
may happen that we have different info in the 2 universes (IPv4 and IPv6)
extremely bad things may happen if this is implemented.
draft (Alain Durand) dns-ops-req-03
related to name space fragmentation.
Final note: no longer serving .se from i.root-servers.net
Cheers from the attendance.
Questions: No questions.
3rd. presentation
-------------------
Explanation of ENUM (Patrik Falstrom)
-------------------
ENUM-Storage of telephone numbers in the DNS
ENUM is about putting the E.164 telephone numbers in the DNS.
What was discussed was how to map a tlf num....
It works this way:
number - arpa -> mailto > sip.
ENUM can be used in this case:(in more detail)
Guy - SIP Proxy - Proxy queries for that phone 4.3.2.1....e164.arpa?
-> DNS-SERVER responds: sip: spam@paf.se -> sip proxy call setup.
Example:
Two parts: calling part / called party.
& Internet + PSTN,....
kind of coordinate sys.
Pure VoIP
CALLED: Gets the sip-phone and registers to the sip srv
CALLER: Gets sip-phone and the phone uses sip signaling to
the sip-proxy -> DNS server.gets the sip-uri
which points to the SIP server where the called phone
has registered.
This is how the signaling is workin.
VoIP via PSTN to PSTN
SIP permits us to set up policies in the PSTN gw
Status (done)
RFC2916 published
e164.arpa delegated to RIPE NCC.
RIPE NCC appointed by IAB according to RFC2916.
- Requests sent to RIPE NCC.
- RIPE NCC announces the request
* On public mailing list.
* On web page
* To ITU TSB via electronic mail.
- Waiting period 60 day.
- If TSB say no: send request to TSB for further investigation.
TSB will contact the holder of the country code to see if they have
objections.
If TSB says no the delegation will be done. Basically everything will be
delegated to TSB.
Status (not done)
----------------
No ccs delegated yet.
Requests from approx. 7 countries.....
National issues: moving phone numbers from one operator to another...
number portability, handled differently in each country.
There could be problems for the registrar to do these changes.
Question: Countries have asked for delegations?.
ANswer: Germany, UK, China, Finland, Sweden, Norway approximately.
Q: Which kind of organisation has requested the delegation?
A: It varies: ccTLD tregistry, telco, national teleocom regulator.
4th. presentation
-----------------
IDN status (IDN) Patrik Falstrom
-----------------
What happened in the IETF WG.
This is the description of how it looks like...
DNS is not the problem.
Other protocols?
We should have 1 only character set.
UNICODE should be the only char set.
Two functions: To/From ASCII. (detailed in draft-ietf-idn-idna-06.txt).
Unicode used.
Examples shown (inputfromuser - prefixes - punycode)
punycode is what will be written down in the DNS/SMTP/... to
represent the actual string.
Changes to applications to do the reverse (decoding) of
the punycode to the actual string.
side-effects: I update my client to UNICODE, and you don't yo will
see weird things in your client. ACE format (leakage).
moving old info (names) to updated programs coul be problematic.
Non-IDN may be considered illegal or shown as nonsesnse chars.
Updating name servers
--------------------
DNS servers should check IDN names.
check is vital.otherwise ... mess.
What's next?
------------
IDNA defines how to handle internationalized domainames.
There are still some codepoints in unicode which are probably
problematic for the registers.... non-visible chars, selection chars...
There must be a recommendation created. This is not IDNA task.
It is further work.
Questions...
Q - Previous conversions before using nameprep?.
R - Yes, obviously, first to unicode and then nameprep.
Q - What's the timing to approve this draft?.
R - If no one objects 2 weeks + IAB (2 weeks)
They expect some objections though.
Coffee break
resumed at 10:55
5th presentation.
-----------------------------------------------
NEWS & BIND roadmap - Lynda McGinley - ISC
-----------------------------------------------
FUNDING HISTORY
ISC found in 1993. (funds from USENET,...)
Lot of volunteer help.
Need for stable funding. Support DHCP and INN and BIND...
they have to find the way to find some funding.
BIND Members Forum
----------
Founder members in close communication, ...
Project goals
-------------
Proposed membership benefits include:
- notification of patches through e-mail list, annual workshop in
conjunction with IETF meeting, Closer comm with ISC developers.
- Continue activities with IETF.
early warning mechanism.
Maintenance and Development
---------------------------
TODOlist
- BIND performance
- IPV6 support.
- Sec. DNS support...
...
Membership defs
---------------
- Corportions (small and large) different fees.
- Non profit and Univ.
- Individuals.
Process
-------
Application form.
...
Publicity
----------
Forum and website. Press release with charter members.
send email to lynda in case of interest.
RIPE NCC signed a contract to become a founder member of the BIND
Member's Forum (applause).
The things in the TODO list... asks for suggestions:
Questions:
Q - Members sec. info and patches?
A - Not all members will get early announce. Vendors selling
something based on BIND8/9 will get this in order to give
them the chance to fix problems before it is publicly announced.
Q- DOes thisinclude open-source developers (FReeBSD, Linux,....).
A - Lynda ... straight 'yes'.
6th presentation.
-----------------------------
BILL Manning - Operational Testing of new
DNS RR-Types (and features)
-----------------------------------------
(OTDR)
What's gonna happen...
project to determine the op. impact of new DNS feat. respect the DNS apex.
Works with and reports through RSSAC.
Why now?
-------
Labs are not wnough, can't replicate 13 machines w/5.000.000 'users'.
Persistency problems. Generally available,...
HOW?
----
Using the same database. Oriented to new capability support.
like... add A6, AAAA, SIG/KEY/...
Activities
------------
- Write reports to ICANN.
-run this activities for a certain period of time and then write a report.
- POssible future activities
- Regression testing. DIfferent resolver code, ...
- Fingerprinting - identify what exactly is runing.
- There have been proposal to do Anycast.
- Other protocol things.
- Dynamic updates
- Extendend options.
- Need help
-----------
...
Status
------
TSIC used in transactions for the Root server.
UDP/TCP transition. EDNS0/IPv6 implications on packetsize....
which kind of answers you get when?, etc...
Anycast testing winding up.
IDN discussion withkorean and chinese.
Performance issues.
DNS trust/thread model... discussed. Perspective of the server
not the resolver.
Plans
-----
-Sign the in-addr.arpa and ip6.int.tree
-IDN testing. support for KR and CN in conjunction with JET and MINC.
- OPT-IN (working with verising).
Questions?
No questions.
Where is the best place to put my services?
--------------------------------------------
Close to me?, close to the clients?. NOt to close to each other....
This is not a static arrangement:
Topology changes (grooming), clients are not static, demands change,
new features.
You have to revisit this type of things on a regular basis...
What to measure
---------------
Number of clients. Server loading (CPU, mem)...
bandwidth, latency, cache mgmnt and performance, resolver expectations.
How to measure?
---------------
- In the server
- At the client (resolver), can we put more on the client to report
stats, etc...
Some projects in play
---------------------
CAIDA - Skitter (explains way it works),
NB-UCSD - What is the perception of reachability from the diff. 13 servers.
he can track things like network outages,... server loading,...
some interesting stuff here.
Verisign - measures RTT between the root name servers.(health between the RS).
Wide/ISI - based on ideas of the Verisign model. RTT from remote sites (Mongolia, India...).
Some early discoveres
---------------------
RTT may be the most important vlue between resolver and server
RFC2870 should be revised
More work is needed.
Questions:
7th. presentation
----------------------------------
VULNERABILITIES IN THE INTERNET
Jaap Akerhuis
----------------------------------
2 stories....
Personal exp.
- Sister in Manhattan was impossible to reach by phone.
- e-mail took 7 minutes.(2 to the provider 5 to his box).
Big failure: phone system.
No news (www.cnn.com,...)
Big failure: internet.
What was going on?
- Network was out?. web problems to bear this situations.
mail is lightweight and easy to route.
Phone... was out? (8 hours).
- matrix.net (MIDS) monitors continuously (last 14 yrs).
Shows the graphs.
Effects:
WTC was a major communication hub.
Telehouse (NYIX) close to WTC.
Lots of lines went out.
Rerouting takes some time.
This knocked out some big carriers.
6% of decrease in reachibility (98 - 92).
Establishes a comparison with the AMS-IX outage (July 2001)
- 2 out of the major sites went down.
Shows the reflections by SMALL/MEDIUM/BIG ISPs an IXP on the 11th.
TLD - DNS Vulnerabilities
-------------------------
Root file analysis.... Resource records 1859. 1 SOA, 1 TXT.
255 TLDs
...
Distribution TLD/ name srv
remarkable: 44 3ns
45 2ns.
name servers serving TLDs
---------------------------
1 69
...
1 17
It is amazing the net works so well with these things.
Closing remarks
--------------
packet switched inet works.
more risk analysis is needed: @net level & DNS impl.
Probes by CERT.
--------------
CERT performed some probes....
SW versions used... (same sw same bug).
Recursion (whether or not recursion should be enabled in ns).
Consistency in delegation (Consistent NS records).
Restricting AXFRs.
Figure out if name servers for certain domains are in the same physical nets.
Shows results:
SW version
50 failures - 177 hmmm... - 27 supposedly work properly.
Recursion disabled 207-47
Restricted AXFRs: 157 -97
Consistent NS rec: 148 - 106
Authoritative Ans: 83 - 171
SOA record probs: 71 - 183
Name Server on multiple nets: 12 - 242
Conclusion: it is amazing the inet may work with all these problems going on....
Questions:
Comment: root servers have not restricted zone-xfrs
Answer: DFK- at least 2. butthis is not a problem.
Comment: Jaap's data matches B. Manning's data, if we could fix
problems in some of the major servers, the stats would change dramatically.
-------------------------------------------------------
--------------------------------------
AOCB - Any Other concurrent Bussiness
--------------------------------------
WG Administrivia. Co chair issue (R.V reminds) drive to get 2 people
co-chairing the WG. Asks for volunteers to co-chair. Jim Reid gets
elected
NEW CO-CHAIR: JIM REID (NOMINUM).
8TH.Presentation (AoB)
-------------------
Name Server Daemon
------------------- (Alexis Yushin, Ted Lindgreen).NLnet labs.
(Daniel K., Olaf Kolkman, RIPE NCC).
Asks: who is running anything else than BIND??.
only some people do.
Asks: BIND4/BIND8/BIND9.
Why & what?
-----------
Why... code diversity.
What: robustness: high performance
Full RFC compliant. and BIND like behaviour.
not doing caching, recursion, axfrs, dyn-updates....
Inmunity to DDOS attacks.
True Open Source.
How?
----
Mean and lean: no (caching, d-up, rec, forwarding, round robin and random...).
optimised for auth-servers.
Architecture
------------
Zonefile -> zone-compiler -> stored in a DB
Inet -> issuing queries -> get resolved by the server module which
deals with the DB.
Current status
--------------
Alpha version scheduled for next IETF (available).
Design and arch is fixed.
More people to look into the code and test.
Zone compiler is done in 2 ways: reference imp. in Perl.
Fast compiler in C.
Alpha testers wanted mainly from the TLDs and Root servers operators.
Internal tests will be run.
DNS Testlab
-----------
name server to test, network and observed load (tcpdump data).
mangled that suff. calculating checksums,... to replay to the
destination server.
and synthetic load (description could be enough), asks for input
in case it exists.
And... a 'Player'. issue the queries
And... a 'recorder' to record any session.
stores trace of replies.
Talks about HW specs (no rocket science).
Performance graph & IP Stacks.
Results shows Linux-2.4.10 behaves the worst, then FreeBSD4.4 and
close to it FreeBSD HiFi.
Test lab
--------
- Controlled environment.
- Reproducable tests.
- Developed tools to compare trace of replies.
- FIrst: platform is important.
Open for suggestions on synthetic. load.
QUESTIONS:
Q: will this code will be available before the testlab is there.
A: yes, as soon as it is in the way it is readable enough.
Q: What will the testbed be used for?
A: The only way you can make yourself resistant against
DDoS. Performance work... exponential backoff approach and pattern
checks, etc...
Q: Is the DB a commercial or proprietary format?
A: Yes it is precompiled packets DB....
Q: Then... changes in zone files, need to be recompiled?.
A: Yes. Maybe in future it will be possible to make it more open
regarding this.
Q: DNSSEC
A: We don't know if we're doing that in the outfar. But it will have DNS-SEC.
Q: DNSSEC, what exactly are you talking about?.
A: Not TSIG, after consensus at the IETF. (this could be a long debate).
-------------------------------
Chair asks for suggestions again for the agenda.
No input for diff. WG.
Gives thanks and closes the WG.
you are here: RIPE -> RIPE Working Groups -> DNS
