minutes of IETF44 DNSOP BoF
Mirjam Kuehne <mir@ripe.net> Thu, 11 January 2001 15:06 UTC
Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02609 for <dnsop-archive@odin.ietf.org>; Thu, 11 Jan 2001 10:06:08 -0500 (EST)
Received: (from root@localhost) by nic.cafax.se (8.11.2.Beta0/8.11.2.Beta0) id f0BF68t01429 for dnsop-archive@lists.ietf.org; Thu, 11 Jan 2001 16:06:08 +0100 (MET)
Delivery-Date: Fri Mar 26 18:15:48 1999
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.9.1a/8.9.1) id SAA19106 for dnsop-outgoing; Fri, 26 Mar 1999 18:15:48 +0100 (MET)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nic.cafax.se (8.9.1a/8.9.1) with ESMTP id SAA19101 for <dnsop@cafax.se>; Fri, 26 Mar 1999 18:15:47 +0100 (MET)
Received: from x18.ripe.net (x18.ripe.net [193.0.1.18]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id SAA28093 for <dnsop@cafax.se>; Fri, 26 Mar 1999 18:15:46 +0100 (CET)
Received: from ripe.net (localhost.ripe.net [127.0.0.1]) by x18.ripe.net (8.8.8/8.8.5) with ESMTP id SAA19888 for <dnsop@cafax.se>; Fri, 26 Mar 1999 18:15:46 +0100 (CET)
Message-Id: <199903261715.SAA19888@x18.ripe.net>
To: dnsop@cafax.se
Subject: minutes of IETF44 DNSOP BoF
Date: Fri, 26 Mar 1999 18:15:45 +0100
From: Mirjam Kuehne <mir@ripe.net>
Sender: owner-dnsop@cafax.se
Precedence: bulk
Reply-To: dnsop@cafax.se
Domain Root Name Server BoF (DNSOP) ================================== Meeting was chaired by: Lars-Johan Liman Reported by: Mirjam Kuehne The idea is to find out if this fits into the agenda of the IETF, IETF is traditionally protocol building, not operationally. However, there is apparently a lot of interest in this subject. Lars received a lot of input since the announcement of the BoF and that was only a couple of weeks ago. 1. Randy Bush: RFC2010bis -------------------------- - draft as an attempt to update RFC2010 - the draft tries to set basic requirement for root servers Question: does the draft describe the system as it is or as it should be? Randy: both, it lists requirements, not strictly operationally Daniel Karrenberg: does not see the IETF wanting to have and having an authority to be perscriptive in this area. Randy explains that the document was meant as BCP (best current practice), not intended to set rules Jerry Scharf asks why is RFC2010 broken? Randy thinks the RFC is much too detailed, e.g. it specifies specific SW Doug Engebretson doesn't think RFC2010 is severely broken, he suggests to use the draft to update specific sections of the RFC Randy does not want to push the document through the other DNS WGs, they are concerned with protocols Lars set up a mailing list, suggests to take this discussion to the mailing list to find out if and how the document can be used to update or merge with RFC2010, expects root server operators to participate and contribute their experiences dnsop@dnsop.ops.ietf.org (domain not set up yet) dnsop@cafax.se (use in the meantime) ACTION: Lars will announce the document and the discussion to the name-droppers list 2. Peter Koch: recommenrdations for DNS SOA value -------------------------------------------------- - draft-koch-dns-soa-values-0.txt - discussion started at RIPE DNS WG - background: - RIPE NCC coordinates monthly DNS hostcount - Peter makes his own stats from the RIPE stats and made the following - observations: - up to 90% of all zones are very sparsely populated (< 10 hosts) - those zones tend to have their data not changed for a very long time (maybe once a year, mainly caused by web hosting community) - DNS is mission critical for this community, but they are otherwise not very interested - this community makes many mistakes, specially in choice of SOA values - there is SW out that recommends default values - some documents/books also mention 'wrong' or outdated and misleading examples - ideas for the design criteria for the document: - aimed for stable zones with small populations - not primarily for end-users, but for ISPs or local Internet registries - experience shows that recommended intervalls are often misunderstood - therefor recommends fixed timer values to avoid unfortunate choices - recommendations are explained and motivated in the second part of the document - this document does not try to be an intro into DNS, there are other documents which are more suitable for that Geert Jan de Groot asks what the difference is between Peters document and RFC1537 from Piet Bertema. There is also another RFC who ammended RFC1537 Peter explains that this new document is not meant to ammend, but to obsolete the old documents; in the old documents, no target audience is specified, there were intervalls mentioned as recommendations (what he wants to avoid) etc.; this document is meant for specific operators Harald Alvestrand: as a process matter, if there was a document that gave recommendations and now there is a new one, they should relate to eachother and clarify their relationship the document contains a table with the following recommentations element protocol interest Internet at large secondary. providers ---------------- -------------------- ------------------ MNAME yes (yes) yes RNAME yes SERIAL yes yes REFRESH yes RETRY yes EXPIRE yes (yes) MINIMUM yes MINIMUM field has currently two interpretations: 1. default TTL for all RRs in the zone which has no TTL values attached 2. TTL for negative caching (updated by RFC2308) at the moment there is a transition from one interpretation to the other Jerry mentions that there might be reasons to run short TTLs for small zones (to make DNS round robin more stable) there are servers who stack rather than round robin, you want them to update; this needs to be addressed in the document Peters document already mentions already that there might be reasons not to follow these documents, this one could be included table with proposed recommended SOA values: element value ------- ----- MNAME real primary value RNAME working hostmaster e-mail address SERIAL YYYYMMDDnn REFRESH 86400 (1 day) (assumed that the zone uses notify, is on by default) RETRY 7200 EXPIRE 3600000 (1000 hours) MINIMUM 172000 (2 days) (comment: for desaster recovery you want a shorter value) TTL 3600 (1 hour) particular values should be discussed on the mailing list Lars adds that it needs to be very clear on top of the document what the target audience and the target operating system is audience finds document useful Lars clarifies that there was originally one document in the RIPE DNS WG; it has been decided to break this into two: the one Peter presented and another one that lists examples (this will be published as RIPE document very soon) 3. Masataka Otha: ------------------ - multiple root name servers sharing the same IP address - let the routing system decided which one is most suitable to contact. Lars thinks that this will break the routing system (single source for AS), destablises the system, critical for root servers. It might also make life trickier when using TCP queries, where parts of a stream of packets cannot suddenly be re-routed to a different host. Randy explains why he thinks that his is not necessarily a bad idea: imagine that it is decided to place a root server at a large ISP (one AS); that AS would announce 1 /24 from swamp space, they would leak their IGP into their EGP, this can be very useful, has been used; this is technically a good solution, there are administrative problems however Jerry adds that this is currently done for redundancy on the F root server, but there are two servers next to each other there is a concern that the user would not know which operator to contact if there is a problem Daniel warns that one goes down a slippery slope when trying to do this across different operators, a good technical solution becomes a nightmare when it is distributed over different systems maianted by different operators summary: ACTION: Masataka will write down the recommendation in a way that it is not applicable for root servers only, then it will be discussed on the mailing list 4. Peter Koch: remote configuration of name servers --------------------------------------------------- imagine an ISP which cross relates secondary service with another ISP, how do they communicate configuration information, when a new customer needs to be added for example no support in the protocol at this moment, can this be solved? there is not much interest in the group and at the moment it is felt that it is not worth describing 5. Peter Koch: update of FYI27 = RFC1713 'Tools for DNS debugging' ------------------------------------------------------------------ - there was a BoF at the IETF that was related to this issue - how could this group be involved in this if it is interested: 1. produce a catalog of DNS debugging tools 2. document common DNS failures (updating already existing documents) Randy thinks that a very simple doc for the clueless is needed, existing documents only written for the clueful user/operators, they tend to remain updated anyway Daniel supports Peters suggestion to split the documennt into two parts, he thinks that the common errors document is a topic for this group Doug believes it would be better to have both topics in one document Daniel clarifies that common problems document should also have solutions in it, but the tools get outdated too quickly to be included in this document Mike is not sure if this is an IETF topic at all, there are useful web pages people can be pointed to, will always be more up-to-date, for instance the following ones: ISC BIND pages: http://www.isc.org/bind.html comp.protocols.tcp-ip.domains FAQ: http://www.intac.com/~cdp/cptd-faq/ BIND FAQ: http://www.ludd.luth.se/~kavli/BIND-FAQ.html The DNS resource directory: http://www.dns.net/dnsrd/ It is felt that it is more important to write down which things are necessary to take into account when writing a good debugging tool rather than describing the existing tools Lars summarises that tools evolve constantly and theat the IETF cannot keep this up to date. There seems to be interest in the group however to have a document that describes methods to _discover_ and determine some well known error situations, rather than just stating what they are. 6. agenda point added by Roger Fajman ------------------------------------- - standards way of providing an access control list This topic is already being handles in other IETF WGs (see the new address prefix list (APL) resource record that was suggested by Peter Koch in the DNSIND working group. See draft-ietf-dnsind-apl-rr-01.txt for more details) 7. Lars: documenting problems with large NSs -------------------------------------------- maybe not useful to have as RFC? Doug believes that this is going to change rapidly with new BIND features There is no interest in the group to work on this topic 8. Ed Luis: DNSSEC ------------------- - how will the protocol be used that is currently being deployed? - there are no clear policies yet - delegations might change with DNSSEC - how will the keys be handled? - in the interim while the protocol is still deployed, not many zones will be secured, what if one goes from a trusted to an untrusted zone? - how can the keys be used for other purposes, where will the public keys be stored in DNS? - there is a key handling draft which describes, how keys can be transferred back and force Ed would like to start a discussions going between the architects and the operators the group supports co-operation between architects and operators ACTION: Jerry offered to help with this work someone suggests to look into the efforts that have been made in RPSL, specially rpsl-auth 9. Lars: distribution of servers for 'high level services' ---------------------------------------------------------- - related to root servers and other important services - where shall the existing root name servers be placed? - how will this be determined? - what tools can be used, how can this be measured etc.? - topology vs. geography - exchanges and major ISPs vs. prominent sites - physical and operational security needs A few people in the group are interested, but is perceived as very hard work, people know how the currently operate the servers, but they are not sure if they would be able to desribe it some people have used RFC2010 as guidelines This topic should be extended into 'how to run a more robust service' Lars suggests to postpone this topic until the new document with recommendations for root server operations has been straightened out. 10. Lars & Randy: performance ------------------------------ - not much of a problem yet, but going to be - experiences with IXFR, compressed XFR? - investigate relation bewteen network quality and DNS performance - quality of data - analysis statistics Randy clarifies that he is not interested in measurements at the end-points, more interested in measurements in the middle of the net, in order to find out how many queries aof what type, of what level etc. all those things that cannot be measured in an end-point people think the results would be very useful, but don't want to put effort into this. ACTION: Randy volunteers to work on this Lars suggests to produce data first and then find out what to do with it (informational RFC for instance) one needs to look into other WGs that did similar measurements (IPPM?) 11. Y2K ------- - done - well under control - well documented already - no further actions needed in this group 12. Lars: IPv6 -------------- - IPv6 information in DNS - DNS transportation over IPv6 a comment is made that this relates to the measurement issue Randy believes that deployment testing is needed, not measurement per se Lars wonders if documentation is needed on this subject Matt Crawford reports that this is already been taken care of in IPng WG 13. Lars: zone file distribution between server ----------------------------------------------- - ftp or AXFR? It is decided to skip this topic for now, maybe discus further at another time. 14. Future work --------------- the group believes that enough interesting topics have been identified that need to be worked on to form an IETF WG ACTION: Lars volunteers to help out writing a charter ACTION: Doug, Ray, and Mike will also help The area director Harald Alvestrand welcomes this interesting BoF and says 'well done'
- minutes of IETF44 DNSOP BoF Mirjam Kuehne