==================================================== 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 (erik@NLnetLabs.nl> ====================================== + 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.