RIPE 46

• content to the Chair of the working group.
• format to [email protected].

====================================================
RIPE 46 Meeting
Amsterdam, the Netherlands 1 - 5 September, 2003

Date: Tuesday, 2 September 2003
Time: 16.00 - 17.30
Location: Grand Ballroom
chair: Peter Koch
WG: DN* WG
scribe: ziya
====================================================

Administrative stuff:
======================
Jaap opened the wg to excuse himself and to give the mike to Peter Koch.

Peter did the intro, explaining the DN* name. (Domain Names in Everything)

Also, he went into the agenda, that they have tried to standardize so that they
can have the same topics in the different meetings, with some topics that
happened to come up in standard "other presentation" slots.

Then the agenda for Thursday was discussed a bit. They were discussing the
charter and what the charter would be, if there was a draft (not really) and if
the agenda would be the basis, with the recurrent parts.

Agenda:
=======
- Charter, agenda bashing
- welcome speech

Daniel Karrenberg: Do we have a draft charter
Jim Reid: Peter had a draft charter 6 months ago, but it needs to be discussed anyway. Asked for feed back.

Olaf Kolkman: Shouldn't the discussions here be the basis for charter.
JR and DK:please read discussions on the mailing list and feedback.

Peter Koch: Agenda for Thursday.

PK: Asked if there are any questions.
DK: Corrected an agenda item, Peter will change that.

Andrej Bartosiewic, Experiance in Polland:
==========================================
- IDN Registration
- Sep. 11 6AM start. then first come fist served.
- There is an Internet draft describing rules
- Only Polish char. set is allowed.
- Influence on .PL
- Example EPP
- On registration website xn-- notation will be forced.
- Press releases
- Main channel will be registrars
- Schedule
- Questions:

Rob Blokzijl: Question about bills. The domain names are sent with
funny names (IDN) this may cause confusion in big companies for examples.
Andrej Bartosiewic: We expect our Registrars to send invoices with
polish characters.

Kim Davis, CENTR Activities
===========================
- what is CENTR?
- Best Practice
- IDN Deployment

Council of European National Top Level Domain Registries
The aim is to be to domain names what RIPE NCC is to IP addresses.

They are creating a document with best practices for tld's which is
likely to be seen as a minimal requirements documents.

They also work with IDN, October in Sweden and September in Poland, the tld's
are planning to go live with IDN. Trials are going on for other countries. This
is to show how it can be done and people will feel more secure about using IDN

After the intro Kim gave the mike to some of their members. Short reports from
Japan, Poland and Germany.

No questions were raised

- Registry Updates :

Japan (Yasuhiro 'Orange' Morishita)
-----------------------------------
- Topics
- Japanies Domain name .jp
- Avaliable characters
- Service Migration to IDN standards
- Schedule
- Technical updates of .jp DNS servers
- Unifying hostnames of .jp dns servers
- E.dns.jp (formerly known as ns.wide.ad.jp)
- Future plans
- Related links

In Japan it is now possible (since July 10) to register Japanese domain names
(in Japanese characters), in compliance with icann
standards. Hirogana, katakana and part of Kanji is supported. Based on
JIS (Japanese Industry Standard).

Both punycode and RACE encodings are used currently in the slow roll-over to
punycode exclusively. (after september 3)

They are checking out options of moving the .jp tld servers to their own
networks to create a more resilient environment. Anycast is one of the options
they are looking at.

- Questions:

JR: Problems with different character sets
Answer: Assured then a launch can be done smoothly

DK: I was impressed by your schedule on pnycode. The plugin update
time frame was very narrow. Didn't any one complained.
Answer: i-Nav's plugin will be upgraded automatically,

Audience: What's the percentage of ASCII vs IDN
Answer: 500K all / 50K.IDN\ so 10%

Polland (Andrej Bartosiewic)
----------------------------
- There is an Internet draft for pl TLD.
- Remarks from registrars: polish registrars had problems about
developing sw. German registrars had no problems.
- During January RIPE meeting ISO Quality Certificate. It is possible
to get an ISO9001 for the registry. We had an preliminary
Administration/Technical audit. If any body wants to learn about our
experiences, please let me know.

- ENUM registrars will be telecoms by law
- Planning to sign agreements with Secondary name server operators

DK: Any discussion about ENUM?
Answer: ISPs generally no t interested. In 1st October there will be a
regulation, and only Telecoms will be only authority.

DK: Are there ISP to provide services.
Answer: No interest from ISP

Carsten Schiefner: It is hard to understand the regulation.
Answer: Regulators thinks Telecoms should do it only.

Carsten: Any reason?
DK: Don't shoot the messenger!
Answer: Some operators put pressure on registration authority, and
there are authentication concerns.

Carsten: How would that comply with European regulations, but thats
another story.
Answer: I agree. There is a new minister for this now. Now we are
hoping there will be an other solution.

Summary:

Poland they used EPP, they started with 15 registrant and are now working with
the next 60. They adapted EPP to the Polish situation, there was a presentation
about it in the DNR forum previously.

There are some German registrars, they were sent the standards and there have
been no problems.

They are trying to get the quality of the DNS servers up so they are
secondarying for some organisations.

The bigger ISP's are not so interested in ENUM, number portability will be
possible in October in Poland and that is more important atm.

Telcom operators are interested in ENUM though, although not too much either.

Germany (DENIC: Andreas BaB - Board member)
-------------------------------------------
- ENUM
- Trying to push people to use ENUM
- IDN
- IPv6
- DNS Improvements
- Developed an appliance to collect statistics.
- Realtime Registry
- Provide some thing like the RIPE model, with email and LIRPORtal

DK: What is realtime registry?
Answer: Providing online interface to register domains apart from email.

- No other questions.

Summary:
ENUM, the german domain has been delegated and now the legal documents
have also been signed. They want to bring ENUM users and developers
together at their 23rd of September meeting.

IDN; they are registering the IDN, but they are working on a testbed
now to get it to work. They also need to change the software for all
the registrars.

IPv6, they are adding AAAA glue in Q4/2003. Checks and the option for everyone
should appear in 2004.

They are starting to implement anycasted nameservers.

They are working on "realtime registry" which should speed up delegation of
domains. (instant domains!)


Daniel Karrenberk(http://dnsmon.ripe.net/)
==========================================

DK: Who has seen DNS mon?
20% raised hands.

60 locations try each of the root servers 1 time per minute and they report how
well the servers did.

If a root cannot be reached from different locations, there is probably
something wrong, If only from one of 2, it is probably a location dependent
problem.

Info is available on http://dnsmon.ripe.net/

- Presenting a plot graph.
- It is about monitoring DNS servers.
- Started from a press release which wasn't reflecting the facts.
- We have TTM all over the planet so we can use them for DNS probes as well
- on the plot Checking K-root
- response times are ploted, 55 measurements put in a plot.
- You can also plot loses.
- What you can see is vertical strikes shows problems

- Another plot in terms of loses.
- All 13 root servers
- This is the biggest aggregation we have
- You can see if the problem is global or local
- B-root servers loses yesterday 6 o'clock demonstrated.

- Going back to general picture
- B, D, E (All in US) are effected, K an I not effected so it must be
the transatlantic connection problem.

- Talking about Measure of the quality of DNS service
- You might say looking at the plot you might say where loses are a
lot but that might not be right, because only one server is enough
to run DNS

- What I really want to discuss in the wg is what are the thresholds
in this measurements so we can judge the service.

- I would like this as a work item:
- If you want to know more about the server see me.


Audience (from Viena Univ.): An Idea to more abstract aggregation of
the plot. so we can have a frame on the plot and watch the curve and
when pattern is changed then you can go and see if there is a problem

DK: Good idea. However this is only one of the ways.

PK: when is it going to be a beta site.
DK: hopefully soon.
PK: There are more servers then just only roots.
DK: yes there are 7 other domains and there is more to come. If you
want to be monitored ask me.

PK: Did you research the anycast effects.
DK: there is no effect. because basically it is a user. It just counts
responses. No influence from instances.

PK: Coloring might be misleading.
DK: This is the way it is for now.

Audience: Do you do any correlation on software.
DK: There is just just graphical presentations. no statistics. But I can
provide the raw data if wanted.

Q: does anycasting change the data?
A: no, because we just try reachability, so we don't care which instance
responds, we just check if there is a response.

Q: any correlation between other aspects, like server software and such?
A: we could, but we don't at this moment.

JR: There are other studies. Did you make any comparing.
DK: Defenetly. But first I want to finish this web site. But if there
is a feeling if priorities should change let me know.

DK: BTW. The site is called Alpha. Data collection is Production quality.


END:
====
PK: See you Thursday morning.


====================================================
RIPE 46 Meeting
Amsterdam, the Netherlands 1 - 5 September, 2003

Date: Thursday, 4 September 2003 Time: 09.00 - 12.30 Location: St. Johns II
WG: DN* WG

Chair: Patrik Fältström
scribe: ziya
====================================================

Charter / Agenda Bashing / Goals etc
Leader of the discussion: Patrik Fältström
Help from co-chairs: Jim Reid, Peter Koch and Jaap Akkerhuis.
0.1 Agenda
0.2 Charter
0.3 What are we doing here anyway?

Patrik's opening speech:

There was only one comment from the mailing list.
Maybe there is no interest from RIPE, then we should close the wg.
We cannot say this is what DNS wg should do. We need your feedback.
We have to come up with new charter.

(Agenda for today explained)

Before we want to talk about what we want to do in this wg. Please
provide input.

Lars: (To the audience) Why are you here? My intention is how things should go.

Quin Collier, BT: just checking things out, finding out what is going on. This
is my second RIPE meeting. I might participate later.

Audience(from nic.at): Want to here about ENUM. I want updates on
ENUM, plus updates on what else is going on

Gert Doering: I came today to get up to date on stuff not in my direct field.

Olaf: RIPE NCC has DNS stuff and policies and they need to be reviewed by this
WG. I'll present in the services WG a proposal to change the procedures, the
details will be in this wg though.

Rob Blokzijl: RIPE has always had DNS in its interest since for ISP's DNS is a
service to customers, so we are interested in developments in the field. This
was the historic reason for the WG, even though we don't care about the naming
policies.

Jim Reid: another area that the wg could and should be looking at are
best practices, things to do for good name server maintenance. I am
disappointed in the number of documents coming out of this wg. I don't
think in this room people need to be told how to configure a
nameserver, but for the community it will be quite useful.

Patrik summirised:
1 People want to know what is going on
2 Policy stuff for RIPE NCC
3 And how to run dns services.

Rob: nice to here reports from isps

Jim: It would be beneficial to publish server configuration best practices.

Lars-Johan: May be we should change our working model. I expected
these comments from the usual faces, I had hoped that some new faces
would say the same thing. If that is not wanted though, maybe we
should change the wg into review and reporting more then a working
group.

Patrick: Can the people in here that run DNS servers hum? (loud
humming) Who does not run servers (much less humming) ok. It seems
the group wants reports, this is what we can do, of course, where the
things are then made outside, I don't know.

Patrik summarized again:
1 Seems like people want to know DNS relater reports.
2 Second thing is RIPE NCC want us to do policy reviews: We can do
that when they are published.
3 How to run a DNS server. Or can be documented else where and
reviewed by us. That's fine too.

Jim: if we can identify the deliverables and time-lines for work items
then we can go and do that and report on them during RIPE meetings.

Patrick: yes, we talked about that, but no one stepped forward to be the person
that wanted to be responsible for a particular action. And when I asked for
actions, no one actually came back with anything.

Lars-Johan: how many would want a BCP document? (quite a few hands)
Would you be willing to work on this? (not so much enthusiasm)

Lars-Johan: how many people are interested in running DNSSEC (pretty
much everyone) Would you be willing to work on a document that puts
down the issues with it and how to (possibly) solve it? (still some
hands)

Jim: If people can come up with their problems then we can help.

Peter: Community is interested in having advice. We don't have to
write detailed instructions.
+ Quality
+ Tests i.e. pre delegation tests
+ Test evaluations
may be users and registries are interested in those areas.

Jaap: CENTR is doing it from a political PoV, not technical,maybe we
can do things from that PoV.

Audience(from nic.at): We don't need configuration guidelines. There
are books for that. (some disagreement from the room)

Patrik: How many people are interested writing such a doc.
Raised hands: 5%

Olaf: in the DNS-OP in IETF we are working on a document describing what to do
for DNSSEC, I can present the document in the next meeting.

Patrik: I want to have a someone to take the token about this
issue. who wants to take on the task of organising such document?

Jaap: I'll do it.

Patrick: people should tell Jaap what they want for a document and
they should also let him know if they can help out.

----------------------------------------
[1] Topics with deliverables

1.1 Quality of the DNS
Agenda item 1: topics with deliverables
----------------------------------------

Jaap: lot of people look at one server if it is up or not, I want to
look at zones more then servers, how to do this, how to get a more
holistic view? there may be ways to look at the whole problem. What is
the min requirement.

That's what I'm interested in. That's it for now.

Bill Manning: There are groups of people looking at this. Maybe
Quality is equal to 'is DNS running'. When IPv6 takes off (shout: 6
months!) then using numbers becomes harder, so we must make sure DNS
is working well.

Olaf: how many people type in numbers now? (quite a few hands)

-----
John Brown wasn't present. His presentation skipped.
-----

2.2.1 DNSEXT (Olaf Kokman)
====================================
IETF57 DNS.

The report is about the different documents that the DNSEXT wg is
working on. Focusing mostly on DNSSEC, Olaf being quite optimistic
that it will be done soon now finally.

- Administrivia
- Work recently processed
Briefly explained proposals.
- More documents
Ietf-ipv6-name-auto-reg
Lar: What does that mean not supported
Olaf: Not going to be taken to ietf

Olaf stated that wcard is important.

- Hot ongoing item
Made a call and asked especially to implementors to review these
documents (rewrite efforts). Assured that next two months we might
have a draft

Jim: Observations: A lot of people might be confused about IETF
procedures. Can you clarify.

Olaf: roughly;
-Someone has an idea
-he writes it down in a draft (drafts have a lifetime of 6 months)
-if a wg is interested, they will take over editing of the doc.
-if the working group thinks it is ok, doc goes to last call
-wg needs consensus that the doc is ready
-then they send to IESG who does another review.
-then it becomes rubber stamped and goes in the process of getting
official numbers/addresses/designations (goes through RFC editor Then
IANA can assigne numbers etc.
-Then becomes an RFC

Jim: The mentioned drafts. When are they going to become an RFC.
Olaf: RCF editor queue is on line. There you can get the best info
about it.

-More hot ongoing work
Olaf's Personal observation: IETF might start a key management group


DNSOP @ IETF 57 (Lars-Johan Liman)
============================================================
Lars mentioned that there are new chairs.

Slides:
* dead drafts
* wg last call drafts
* Active drafts
* expired drafts
* individual drafts: they are not seen as very important. WG have not
decided to adopt them
* WG drafts
* Ipv6 DNS discovery
Discussions about importance
* Ipv6 DNS discovery 2
* Ipv6 DNS Discovery 3
* Ipv6 DNS Discovery 4
* Discussions
Difference to DynDNS. Personal opinion: Why do you need the names.?
* Discussion 2
* Discussion 3
* Discussion 4
There was no consensus. Will be discussed
* the .LOCAL tld
* the .LOCAL tld 2
* Ipv6 DN Issues Draft
* DS Update inparent

Questions:
none

2.2.3.2 SSHFP
Jakob Schlyter
==============================
Within the SSH WG they defined an rr type which defines the
fingerprint of the key used by a host. Upcoming OpenSSH release will
have the option to do this. (once the doc is rfc)

Liman: Has the rrtype been assigned a typecode number?

Jakob: It is requested. But it wont be assigned before it passes the
RFC Editor.

Patrik: (Added) When doc published iana and rfc editor works synchronously.



2.2.3.3 ENUM
Patrik Faltstrom
==========================================
I checked the ID checker and I saw that the IESG thought the doc needs to be
changed, so now I'm trying to sort it out.

The wg is working on the various registrations of service codes (sip, 833?),
those docs are more or less ready, as far as the wg is concerned.

There is a doc about fax and enum, from the fax wg.

Also some discussions on EPP and how it relates to enum.

People who are interested should read them and provide feedback.

A question came from CRISP: They asked whether the ENUM group should
discuss WHOIS related issues. WG's answer was we can review but do
not want to do it.

A few security issues are being discussed as well.

Enum wg is mostly done, we are thinking of shutting down the wg.



2.2.3.4 PROVREG
Jaap Akkerhuis
==============================

Basically we are done.

We were waiting for the xml spec, since EPP uses it. It took a while. 1,5 week
ago the doc was approved by IESG, so now we check the queue length for the RFC
Editor (6 of our docs are waiting at the RFC Editor queue). In a month
or so they might become RFC.

We don't know what happens then. We might go into hibernation.

Interop testing is still being done.

====================
BREAK
====================

Reports from from root servers:

2.4.1 B-Root
Bill Manning
========
+ (slide) status

B has moved from one machine to several machines behind a load balancer
(and they are trying different load balancers, foundries and others). They
enabled v6. They have proposed renumbering (for anycast among other reasons)

Jaoa: What load balancing?
Bill gave no clear answer!

+ (slide) plans

Patrik: Will you publish anything about load balancing? I get very
different answers from different sw/hw users.
Bill: Will talk to Patrik in private.

Patrik: (Asking again) will you publish?
Bill: Internally yes, probably to the root server community, then well
see about public


2.4.2 F-Root
Joao Damas
=====================
+ Goals
+ f-root anycast technical setup
setup is on the web http://www.isc.org/tn/isc-tn-2003-1.txt
No different from others.
We coordinate with ISPs as well
No IXP in Mexico!
+ Typical node
this is kind of the ideal design
+ Global nodes
San Fransisco and Palo Alto have global nodes.
+ Nodes out there

Questions:
no questions


2.4.3 I-Root
Lars-Johan Liman
=========================================

IMPORTANT: 192.36.148.0/24 will change to AS29216

+ Current sites and nearest plans
+ Finance

I-root is now also operational in Finnland (anycast, local to Finland)
New ASN is used for I.

Stockholm and helsinki up and running, soon london and milano, johannesburg and
moscow planned.

'We need transits' message given.

Patrik: question to all root server operators: is there coordination between
which sites are picked?

Lars: There is some. We basically use our common sense. But of course
there is cooperation between root name server operators.

Joao: it is not a bad thing to have more then 1 root at a location

Bill: all the good places are gone (sarcasm), there are still a lot of good
places to put the roots.

Jim: About anycast. Are you using the same kind of equipment.

Lars: No, currently its very different. We are about to retire system
in stocholm. I think we will use the same servers but different
routers.

Jim: Do you have list of requirements for anycats sites

Lars: It is a good idea. We should publish one.

Jakob: are you using identification
Lars: Yes.

2.6 DNSSEC deployment / experience
2.6.1 DNSSEC status
Sam Weiler
=====================================
+DNSSEC
+ Whhat can you do with it?
+ Last Six Months
no new code!
+ Delegation signer (DS)
resolvers needs to be updated
+ type code roll
+ Whats the catch.
There is no API to get information.
You can't do anything useful at this moment.
+ How to help.
Protocol is stable
You can use the old code to start with.
Questions:

Jim: A problem I see is getting data from resolvers. The end-client
will need an improved resolver that can do validation, or tsig to the
real resolver. What do you think the best way forward is?

Sam: I have seen proposals. At the moment there is no API or a way to
get that.There are some efforts to get more info to the stub, but I'd
also like the validator in the programs (like in Mozilla) so that the
programs can give you better info.

K.root anycast
Dave
=======
+ History Motivation
+ Status
A cold spare in amsterdam
In london using ospf load bal.
+ Current Query load
+ Future plans
+ More information
Questions:

Joao Damas , BIND Update
======================================
+ Current versions
rc1 incorporated bug fixes
+ Ongoing work
finance from 3 big unix vendors.

BIND's got gss-tsig! (interoperability with MS dns server)

Joao Damas , OpenReg Update
==========================================
Nothing new.

NSD Erik Rozendaal ([email protected]>
======================================
+ Version number update
+ Historical
+ historical (cont)
+ Currentls
+ Planning
DNSSEC upgrades
Questions:
none

2.9.1 Adding IPv6 glue to the root zone
Ronald van der Pol
(IPV6 mesurements)
====================
+ Problem statement:
+ The experiment
+ Lab setup
+ Lab setup (cont)
+ adding Ipv6 NSs with AAAA RR
+ current Ipv6 NS result
+ adding glue per TLD
there is effect on .de and .com.
for K and L root
+ Conclusions
+ Verifying result
This is the plan to do.
Do tests with bind 8

Notes:
When v6 is added some glue may be removed because of packet size limits. This
was tested to see if there was a problem.

Some AAAA records will be ok, but more then one or two, it will take out some
glue. (idea: anycast servers, but use less, packet smaller, more v6 can be
added)

Questions:

Joao: these conclusions can also be used for gtld's? They have names that are
the same length. We thought we could add 2?
Ronald: I can send data and it should be the same.

Peter Koch: what about Rumania? They are big
Ronald: didn't check them. But I can include them as well.

Peter: Did you measure average queue length? Might be interesting.
Ronald: not yet.

Lars: Can you publish this.
Ronald: Yes

Lars-Johan: Will this be officially published? WG notified?
Ronald: yes, that's the plan.


4.2 The status of the rs.net testbed:
Bill Manning
CN & JP tlds registered punycode entries
KeyMgmt issues w/ persistant DNSSEC testbeds
Precursors for IPv6 tlds & glue in the root zone
=========================================================
RS.net

+ history
There is a test bed
+ questions
+ Rough Draft
+ First pass (Ipv6) lessons
Registies should accept AAAA
+Moving targets
+ Bad things
+ Testbed interoperability (not always v6)
+ Winner
edns0 fast enough (Joao confirmed)
+ Mind the gap
+ DNSSEC
+ Weaknesses
Key management can be a serious problem.
DNSSEC is not PKI
+ Lessons
+ IDN

Bill: If you are running a tld let me know we will include you.

Questions:
None.


4.3 SYN flood like patterns on nameserver due to firewall issues?
Peter Koch
====================================================================
Fun with firewalls
DNS SYN Flood
--------------------
+ Earlier this month
+ Attacks on Port 53
+ Evil DNS over TCP
+ So What happened?
+ Finding the culprits
+ Lessons learned
Questions:

Sam: DNSSEC? (dnssec will have more queries with tcp..)

Peter: Yes, the server operators will have more pain. So watch this
within the next 6 months


End
===

Patrik:
Reminded to contact Jaap.