DNS Future Work BOF (DNSFUTUR)
Reported by Rob Austein/Epilogue
These minutes are based on notes taken by Walt Wimer and Ed King.
For those who had not noticed, the DNS Working Group is now officially
dead. This BOF was a reading of its ``last will and testament.''
The Namedroppers mailing list is still alive, although it was
experiencing several distinct technical problems for a while. It has
been moved to a new host, with aliases left behind. The discussion list
is now Namedroppers@internic.net. To subscribe or unsubscribe send mail
to Namedroppers-Request@internic.net
Completed Tasks
The following tasks of the former DNS Working Group are either complete
or close enough that there is no longer need for a working group to get
them finished:
o DNS MIB documents: These have been approved for Proposed Standard
by the IESG and are currently in the RFC mill.
o ``Load Balancing'' effort: The Internet-Draft is now out. Since
this is intended for publication as an Informational RFC and
requires no protocol changes, the remaining issues, if any, can be
settled without needing a working group.
o DNS support for IDPR: This went to Last Call for Proposed Standard
but was withdrawn at the author's request when Last Call review
turned up problems. After talking to the IDPR and SDR people that
wanted this support, the plan is to replace the draft with two new
drafts:
1. ``How Not To Do DNS support for IDPR,'' which will document
both the proposed mechanism and its known flaws. This will be
submitted to the RFC Editor with a request to publish it as
either an Informational RFC or perhaps a Historic RFC, since we
know that we do not ever want to make this particular mechanism
a standard.
2. ``DNS Support for SDR,'' which will document the simpler case
of SDR support, where the major problems with the original
draft are not relevant. This will be transferred to the SDR
Working Group.
``Big Zone''
The chair had been under the mistaken impression that the ``big zone''
issue had died off due to working group apathy. Some twenty minutes of
discussion on this topic proved otherwise. The following appear to have
been the key points from the discussion, as recorded by our valiant
correspondent when he was not ducking to escape the flamethrowers:
o The ``big zone'' issue is really two separate issues:
1. Technical issues of how to maintain a large zone.
2. Exhaustion of the ``good'' parts of the DNS namespace.
o Issue (1), while real, is not the major problem. We know roughly
how to deal with this (incremental zone transfer or FTPing ``diff''
files or something similar) and we are working on the details.
o Issue (2) is the hard problem. There are only so many three letter
DNS names in the .com zone. First-come first-served was a viable
answer when the Internet was just a bunch of nerds, but is unlikely
to be a legally defensible answer in the future when the Internet
is a ``real'' global service.
o Making the DNS names longer makes the users unhappy. There are
already known cases of sites where the users prefer to type IP
addresses rather than DNS names, because the names are too long.
o Ultimately, we need a real White Pages service, not to replace the
DNS, but to provide a different set of services using the DNS as an
underlying global indexing system. With such a service, it might
be practical to relax the human-readability constraints on DNS
names somewhat.
o Geographically-based names, while still popular in some quarters,
are highly controversial and lead to a group of related problems.
E.g., what happens if you move, do you have to change your name?
What if you are an organization with no well-defined location?
o We need to agree on a list of requirements and at least somewhat on
their ranking before we can design or evaluate a solution.
Somewhere around this point our correspondent's pencil was hit by a
stray missile, and the chair decreed that the BOF should move on to
other topics. Discussion on this subject is strongly encouraged, and
should be conducted on the bigz@rice.edu mailing list.
Tasks Still Needing Work
The following is a list of the tasks that the former DNS Working Group
had undertaken and still need work, or that would have been brought to
the DNS Working Group for work at the 29th IETF if the working group had
not been killed:
1. ``Incremental Zone Transfer'' draft: The BOF agreed that getting
this done was the number one priority for future work. Some of the
underlying mechanisms needed here (e.g., timestamps) may be
sufficiently close to those needed by the DNS Security work that it
would be a good idea to coordinate with that group to avoid wasted
effort.
2. ``DNS Requirements'' document: This is to replace/augment section
6.1 of RFC 1123, incorporating recent work such as the series of
Informational RFCs issued last year, and trying real hard to
provide a tool that customers could use as a checklist item when
trying to obtain a decent DNS implementation from their vendors.
The BOF agreed that this was a worthwhile task, provided that
suitably motivated volunteers and a chair could be found.
3. ``DNS, subnet masks, and CIDR'' document: There is a lot of
confusion about using the IN-ADDR.ARPA tree with (sub)network masks
that are not aligned on an 8-bit boundary. This has been discussed
on Namedroppers, on and off, for years. Somebody really should
write it all up, probably as an Informational RFC.
4. Dynamic Update mechanism(s): The last attempt to do this, via SNMP
and the DNS MIBs, was (correctly) punted because the security model
was bogus. The issue has not gone away.
There are really two issues lurking here:
(a) A protocol/mechanism for changing DNS data on the fly, with a
suitable security architecture and so forth.
(b) Fast convergence of DNS data, better than the loose controls
provided by the current TTL and caching models.
Opinions vary about whether or not these issues are implicitly
related.
These issues are pretty clearly at least somewhat intertwined with
both the incremental zone transfer mechanism and the DNS Security
effort. While it is neither necessary nor desirable to hold up all
of these efforts while trying to come up with a monolithic
solution, it would be a good idea to avoid gratuitous conflicts,
too.
5. ``Operational Guidelines'' document: RFCs 1032 and 1033, while
better than nothing, do not fully cover the topic. The last time
this issue came up in the DNS Working Group, nobody was interested
in attempting to write a better document, so we punted in favor of
telling people to read the O'Reilly ``DNS and BIND'' book. This
still leaves something to be desired, so, given a motivated
volunteer, there is still a document to be written.
6. Intermittent or partitioned networks and DNS access: Several
problems that appear on the surface to be unrelated have a common
thread:
(a) Nameservers on the ``wrong'' side of dialup SLIP connections or
otherwise only intermittently connected to the main Internet.
(b) Nameservers on the ``wrong'' side of firewalls or unreachable
due to policy routing.
Problem (a) is potentially tied in with (1) and (4b), above, since
it would be much easier to handle zone transfers if the primary
could tell the secondary ``hey, I'm available now.''
Problem (b) is either a configuration error or an intentional
policy, so either this is covered by tasks (2) and (5) or is the
unavoidable consequence of a decision that is outside of our scope
of concern.
The BOF determined that tasks (1), (4), and (6a) were sufficiently
interrelated that they should be undertaken by a single technically
oriented Working Group, which would need to coordinate with the DNS
Security working group. Randy Bush volunteered to chair this group.
The BOF determined that task (2) should have its own working group. Ed
King volunteered to chair this group.
The BOF determined that task (3) does not appear to need a working
group. Mike Patton volunteered to write the document.
The BOF determined that task (5) does not appear to need a working
group. Ruediger Volk volunteered to write the document.
Incremental Zone Transfer Draft
Having finished reading the will, the rest of the BOF was devoted to
discussion of the incremental zone transfer draft and related issues.
o Several people had sent comments about the current draft to the
authors but felt that, in retrospect, the whole community should
have been involved in the discussion. The BOF agreed that the
authors of any such comments should resubmit the comments to
Namedroppers, and that any future discussion should take place
either there or on some dedicated mailing list if the
signal-to-noise ratio on namedroppers get too high.
o Jon Postel (one of the authors of the current IXFR draft) pointed
out that the current IXFR draft both proposes some general purpose
extensions to the DNS architecture and makes use of those
extensions to provide the IXFR service. It may be appropriate to
separate these two topics into two distinct papers.
o The current IXFR draft requires (or at least strongly suggests)
that the primary DNS name servers keep track of the state of the
secondary name servers. Some people think this is a bad idea; some
people do not believe that the primaries should even have to know
about all their secondaries.
o The current IXFR draft does not clearly distinguish between
protocol operations and a suggested implementation. Worse, the
draft recommends discarding an old, but still valid copy of a zone,
before obtaining a new one for reasons that turn out to depend on
assumptions about design bugs in the implementation. This needs to
be fixed.
o The current IXFR draft has the primary server knowing about its
secondaries for two distinct purposes: to send NOTIFY messages,
and to determine when the primary can discard incremental change
information (what the draft calls ``zombie records''). Some people
think that these mechanisms should be de-coupled; that is, that the
change information should not necessarily be discarded just because
all the secondary servers on the notification list have picked up
their updates, because there may be other secondary servers,
authoritative or not, which for some reason do not want or cannot
receive notifications.
o As part of the discussion of extensions to the DNS architecture,
the subject of UDP packet sizes came up. Given that the world has
changed significantly since the DNS was designed, it may make sense
to reexamine the recommended maximum packet size. The DNS Security
Working Group is running into this same issue. The real issue here
is not packet size per se but message truncation and lossy
fragmentation.
As a rough guide, it would be useful to find out what the real MTUs
are that are in common use on the Internet today. The IETF mailing
list might be a good place to ask about this.
It would be nice to make use of path MTU discovery in DNS, but the
use of UDP as a transport protocol and DNS traffic patterns combine
to make this a non-trivial problem. However, a site that is
organized to use one or two caching ``super-resolvers'' for all
outside queries might be able to do something useful with path MTU
discovery in the super-resolvers. Firewalled systems that only
allow a few resolvers to transit the firewall are another case that
might naturally lend itself to path MTU discovery.
o If/when a dynamic update mechanism falls out of this work, it may
be possible to use it to perform load balancing tasks. Whether or
not this would be a desirable thing to do is a question we probably
cannot answer until we know how dynamic update works.
Having thus completed, transferred, or punted the obligations of the
former DNS Working Group, the DNSFUTUR BOF declared victory and went
home.
Attendees
Mark Allyn allyn@netcom.com
Robert Austein sra@epilogue.com
Randy Bush randy@psg.com
Terry Davis tld5032@commanche.ca.boeing.com
Donald Eastlake dee@lkg.dec.com
Duane Harkness duaneh@atc.boeing.com
Charlie Kaufman kaufman@zk3.dec.com
Hiroshi Kawazoe kawazoe@trl.ibm.co.jp
Edwin King eek@atc.boeing.com
Kim Morla kmorla@pucp.edu.pe
Masataka Ohta mohta@cc.titech.ac.jp
Michael Patton map@bbn.com
Jon Postel postel@isi.edu
Robert Reschly reschly@brl.mil
Ruediger Volk rv@informatik.uni-dortmund.de