minutes of IETF44 DNSOP BoF

[Mirjam Kuehne <mir@ripe.net>]

		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'