Dear working group members, I apologize for sitting a bit too long on Vesna's draft minutes for the Budapest session. Vesna did a really good job; please find the draft below. I'll wait for comments until Sept. 30th. So the draft is expected to become final on October 1st. I'm sorry that some problems in my day job escalated yesterday evening in ways so that today in the early morning it turned out that there would be no way to make the planned trip to Amsterdam safely and in time. (There is a down side to having the conference locally - or "within short driving distance":-( I hope those attending the current meeting do have a good time; looking forward to see you again at future meetings. Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv@NIC.DTAG.DE Phone: +49 251 7985 200 fax: +49 251 7985 109 DNS Working Group RIPE #36, Budapest 18 May 2000 Chair: Rudiger Volk Scribe: Vesna Manojlovic Agenda: 0. Agenda bashing 1. David Conrad, ISC: BIND 9 2. Bill Manning: Preparing for DNS evolution -=- coffee break -=- 3. Report from CENTR DNSSEC workshop 4. IETF - Randy Bush 5. AOB 5.1. Fernando - Document about re-delegation 5.2. RIPE documents published since the previous meeting 1. David Conrad gave quick update of current status of BIND BIND9 * complete rewrite of code * includes support for everything - full IPv6 support - DNSSEC support - not supporting EDNS1 - multi-lingual support - MS interoperablity * RFC compliant (first time, cheers from the audience :) - first time it has lots of documentation :) * 1.2 mil $ to develop * release - 30.6. * availability now - beta David was asking the audience for help : - to support INN (BIND and DHCP are supported by Nominum) - from people with NT experience to debug NT port of BIND 8.2.3 - to test BIND9 - performance - IPv6 support in BIND 9 - DNSSEC 2. Bill Manning -- Wither DNS? PPT presentation available on http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ Current assumptions: - constant MTU - ASCII - BIND (UNIX based) - single authority (server) - hierarchy - zone management - static behaviour (client) - merged server and resolver - reachability: reliable network (up, end-to-end) On the horizon: DNSsec IPv6 dynamic DNS integration with other applications - database back-end (LDAP,Oracle,mail) I18N (internationalisation) DNS version diffusion survey Q&A session: Q: how is this taken? A: exhaustive search of inaddr tree. Q: is it biased? A (audience): it is security biased! they are not responding if they are security conscious => shows higher % of vulnerable Q: how big is the percentage of the servers that are blocked by firewall and therefore not included? A: few years ago - 20%. recently - 25% Conclusion: people are moving into new code but not (as) fast (as ... ) Discussion about IPv6 inverse tree Randy Bush: Is IPv6 inaddr tree going to be set-up separately? (rfc 2826) Bill: That is the suggestion (to use separate set of root nameservers) Randy: That would cause technical and other problems. Other possibility is to take one of existing root servers. -= coffee break =- 3. Report from DNSSEC workshop Workshop was initiated by CENTR, held in NLnet labs in Amsterdam. One report was already done by Jaap Akkerhuis in CENTR DNR-wg; technical report - here. The goal was to check resources needed for introducing DNSSEC on the level of TLD zones. Result of the previous previous attempts was: it is still hard work, not feasible at this time. This new workshop gave different results. In Europe, .de tld zone is chosen as the worst case. Experiment was done with off-the-shelf PC, with extra large memory. "Signer" software was provided by Nominum. Two test runs were done: 1. on original data signing -- ~ 14 hours CPU time expansion factor of 4.4 (of adding all the dnssec data) 2. modified zone (taken out mx & A records; left just ns) runtime -- 3.2 hours of CPU time 117 mb -> 380 mb, so expansion factor a bit lower (3.2) for smaller base data Conclusion: you need some resources, but it's within the reach of current hw and sw. the few people with much larger zones will have more work - but it can be assumed they'll have more revenues. Q: Does it mean a recommendation to DEnic to get rid of mx only domains? A: yes Q: Compared with Swedish workshops? Liman: different, smaller results. Bigger times & data. Used signer from bind8. Q: What do you consider normal zones? A: Less then a million records. (.de = 3,000,000 RR) Liman: Does it make a difference if you have to include ns or mx/a records? David: Not significant. David: Wildcards in the sign zone makes signing 2 orders of magnitude more difficult. We don't support them! Liman: Only in DNSSEC? David: Yes, only if you try to sign them; we either ignore them or generate an error. 4. Randy Bush: DNS from IETF perspective What features are important? For a log time, specifications were stable, code was fairly unstable. Now we are in period when specifications are fairly stable, and the code is little unstable. The increased features that are being specified will cause code instability that will last forever (you can't have all this sugar and not be unhealthy). Main new features: security / DNSSEC & multi-lingual support / IPv6 Security problem: For example: the size of the root zone sign becomes larger then bits in the MTU of the standard UDP packet and therefore all the sessions will fall back to TCP and cause 6 times bigger amount of traffic. Multi-lingual problem: It's not really the DNS problem, but application problem - what is my web browser going to be able to read. i like to call it not internationalisation but localisation, which can cause that our customers not able to do e-commerce with Japanese customers David: stability of the code: bind9 _designed_ and not _evolved_ ; therefore more stable. architectured much better. Bill: operational community has to find the way to provide the feedback to engineering community. this forum might be a right place for it. Randy: yes - we need operators back in ietf. protocols became designed without taking a consideration operational issues. David(?): ietf is quite large cumbersome. having smaller groups of operational people come to some consensus, and then having spokesperson is probably a better solution. Chair: in communities like this there is opportunity to keep information flow in both directions. The survey was conducted by Bill to check who is using which version of BIND. Results: [ ] 5.1. Document about re-delegation Draft paper on how to help re-delegation was presented in RIPE #33 in Vienna by Fernando [ ]. Paper was describing the case of DNS transfer of customers from one ISP to another - how that can be done without losing the service, how to minimise problems, including variations of cases of (non)cooperating ISPs. Help is needed about transfer procedures in ccTLD zones other then .es . Question from the audience: Wouldn't CENTR think they should take part in it? Since large amount of these re-delegations problems are from ccTLD registrars. Chair: Indication of involvement should come from CENTR. However, administrative procedures in many registrars are much worse then they should be; we should push CENTR in the right direction. Liman: There should be one document describing technical issues (in which order what.. ), which are the same all over the world; then, what are the implications of administrative models; and in the different part of the same document, point to possible pitfalls. ACTION on Fernando to sent index/draft to the DNS-WG mailing list; make appendix about procedures in the registries/registrars that we know about. 5.2. RIPE documents published since the previous meeting - Recommendations for DNS SOA Values (RIPE-203) - Simple DNS Configuration Example (RIPE-192) There is work in progress on more detailed documentation. Peter Koch was encouraged to work more on it. Chair invited everyone to express their need for new documents. Q: There is confusion about old and new minimum value in bind4 and bind8. Liman: Dummy guide is meant for "the newest version of BIND". Comments about other versions are welcome, but should be published as separate document. --==_Exmh_9077542070--