[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minuts from Seattle DNSFUTUR BOF
================================================================
Minutes of the DNS Future Work BOF (DNSFUTUR)
29th IETF, Seattle, 1 April 1994
Reported by Rob Austein (Epilogue), based on notes taken by Walt Wimer
(CMU) and Ed King (Boeing).
For those who hadn't noticed, the DNS WG is now officially dead. This
BOF was a reading of the Last Will and Testament of the DNS WG.
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. New addresses:
Discussion: Namedroppers@internic.net
(Un)subscribe: Namedroppers-Request@internic.net
- - - - - - - - - - - - -
The following tasks of the former DNS WG are either complete or close
enough that there is no longer need for a WG 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 don't 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
aren't relevant. This will be transferred to the SDR WG.
The Chair had also been under the mistaken impression that the "Big
Zone" issue had died off due to WG 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 wasn't 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 an White Pages
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.
Eg, what happens if you move, do you have to change your name?
What if you're 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.
- - - - - - - - - - - - -
The following is a list of the tasks that the former DNS WG had
undertaken and still need work or that would have been brought to the
DNS WG for work at the 29th IETF if the WG had not been killed:
1) "Incremental Zone Transfer" draft: The BOF agreed that getting
this done this was the number one priority for future work. Some
of the underlying mechanisms needed here (eg, 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 issues 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's a lot of confusion
about using the IN-ADDR.ARPA tree with (sub)network masks that
aren't 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 hasn't 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'd 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 WG, 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's 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's outside our
proper 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.
- - - - - - - - - - - - -
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 got 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 should keep track of the state
of the secondary name servers. Some people think this is a bad
idea. Some people don't 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 don't want or
can't 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 WG 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's 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 can't answer until we know how dynamic update works.
- - - - - - - - - - - - -
Having thus completed, transferred, or punted the obligations of the
former DNS WG, the DNSFUTUR BOF declared victory and went home.
================================================================