CURRENT_MEETING_REPORT_
Reported by Randy Bush/RGnet
Minutes of the DNS IXFR, Notification, and Dynamic Update Working Group
(DNSIND)
Introduction
The meeting began with a few changes to the agenda: Paul Vixie will
speak on DNSv2 and Masataka Ohta will speak on packet size extension.
The group then reviewed the charter:
o There were no volunteers to replace Randy Bush as chair.
o The namedroppers mailing list and InterNIC archive will remain for
now.
o There needs to be some restructuring of the drafts and schedules.
- The dynamic update work is coming in sooner than expected.
- The IXFR/notify document needs to be broken up, maybe as IXFR
and notify or as policy and mechanism
A lot of people seem to think that the DNS Security Working Group
(DNSSEC) has settled on a single proposal---they have not. Things like
the DNS dynamic update proposal that assume things about DNS security
will need to be updated periodically until they stabilize.
Is DNS security granularity at the level of a zone or is it finer? Note
that the dynamic update draft being presented today requires granularity
at the name level. It is rumored that the DNSSEC group has support for
unique signatures at the name-class level. (This rumor was confirmed at
a later meeting with DNSSEC.)
There was a recent post to namedroppers of a draft which proposed that
the DNS be used as the general Internet key service.
Concerning the granularity: if it is on the per-name it's all right,
but if it is on the zone it's not good. But, if it is at the name,
then, if the zone has to sign, this will require the zone signature data
to be on-line which is bad security.
Let's not get lost in the details but step back and look at the big
picture.
Incremental transfer makes things more efficient. We can update smaller
pieces. Let's wait until we can hear the dynamic update proposal.
The Dynamic Update Drafts
Sue Thomson presented the dynamic update drafts. A copy of her
presentation slides follow these minutes. The document, ``Dynamic
Updates in the Domain Name System (DNS): Architecture and Mechanism''
(draft-ietf-dnsind-dynDNS-arch-00.txt), can be found in the
Internet-Draft directories.
Her presentation was interrupted with many issues and questions.
o Why a separate expiration and not reuse TTL? TTL limits life in a
cache, expire limits life in an authoritative server. Some think
that expire for authoritative data
necessary/highly-desirable/long-overdue. Others were less
enthused, or maybe confused.
o Why not have server un-register at expire? Some feared net
partition, leaving part vulnerable to old data.
o Is there a primary server? Can a client determine which server is
primary? This is controversial, as it is not absolutely clear in
the RFCs, and there is known contradictory practice.
o For the purpose of discussion, let us presume there is a single
primary.
o If updating authority can no find/reach the primary, what is the
behavior? Partition implies high risk of violating principle of
least astonishment in processing of updates that only make sense in
their correct temporal sequence. Mechanisms discussed somewhat
lessen but do not completely remove this problem.
o If a name authority replaces data and those data expire, what
remains? A signature.
o There is considerable danger/confusion between a zone authority and
an authority at a smaller granularity. Who really has to sign an
update?
o If a query arrives when data have expired, what is returned, no
such host or no such name? No such RR.
o What happens when you replace a SOA or a SIG record?
o How does an update reach the other authoritative servers? If its
only going to one primary, use IXFR.
This should be viewed as a distributed database problem, and design the
atomic transaction. For the moment, assume that there is a single
primary, clients may update data at that primary by telling any
authoritative server, and the primary is responsible for updating other
servers in the `normal' fashion. Later, this can be expanded to
encompass multiple primaries.
Straw proposal: Pick a single primary and go. If we use the primary as
named in the SOA we can always use multiple A records if and when we
decide that there can be multiple primaries.
Status of IXFR/Notify Draft
``The dog ate my homework!'' :-) The group was warned in Seattle that
the ISI folk would not have the time to make progress before this
meeting, so the virtual dog was not a real slip. ISI does have someone
who will be able to work on this, has received some feedback from the
group and will be moving.
The need for a smaller security and update granularity can be met by
making each updatable entity its own zone.
While this is fine conceptually, in the most widely used implementation,
zones are not lightweight objects.
Masataka Ohta gave a presentation of a model using
draft-ietf-dns-lb-00.txt where there was no concept of a primary server
(or where all servers were equally primary).
Data origin --> transfer process --> (via data stream) --> secondary server
Notify and authorize can be applied to these transfers. IXFR can also
be used.
I.e. dynamic update could also be handled by the same implementation
mechanism, with no DNS protocol change.
DNSv2 Presentation
Paul Vixie gave a short DNSv2 presentation.
o Worried about everyone adding everything. Need to learn what
underlying extensions are needed.
o v2 will start to be seen in BIND alpha 4.9.4 in 60+ days.
o DNSSEC may require and coordinate with v2.
o Wants to address packet size. People keep bumping into this limit.
Some thing in about 60 days that solve packet size problem.
o If MTU discovery had been done, we would use that. So we can't.
The current plan is to let the client specify the max packet and
let the server decide use as much as it can. What to do when not
enough room? Round robin punt?
o The MTU survey got (very general) the only people concerned about
an MTU of 1500 was MILNET.
o Discussion of AppleTalk tunnels being more restrictive. Then do
not tunnel a pure IP over AppleTalk to IP. Let the client give its
max size if we are tunneling IP over AppleTalk to Apples.
o With IPNG, the current root list will overflow the MTU.
o IPNG is going to break lots of stuff. If we have to change, lets
do it right.
o BIND intends to add allowing servers to pass previously unknown RR
types without being recompiled.
o There are other enhancements, but these are the only
non-implementor stuff he was willing to discuss at that moment.
A proposal should be made to the IETF to form a working group and get
these things broken up. Response is that chances are slim, but things
can be done to better coordinate things.
General Discussion
The DNSv2 work, IXFR/notify, and the dynamic update work was presented
this evening, Susan Thomson et alia's stuff that all need coordination
with DNSSEC and each other. It's critical that we walk out of this week
with commitments to work and drafts to get these things done, so that
people feel we can get these decisions made in time for DHCP, DNSSEC,
IPng, DNSv2, etc.
So the path is DNSSEC has dependencies on DNSv2, dynamic update depends
on DNSSEC. Notification and IXFR depend (useful anyway) on dynamic
update and maybe on DNSSEC. We need an atomic update defined that
impacts IXFR, dynamic update, and notify.
There was more discussion on expire times.
It is a critical and intentional design requirement that all of this
inter-operate with current implementations. It is the intent of all of
these proposals to not break current resolvers. Servers are another
thing. If you are using a DNSv2 primary and you want to take advantage
of it, you must have DNSv2 secondaries.
Are we under any time constraints with IPng? We are under time
constraints from DHCP!
The DNS is at least as critical as SNMP, yet the latter has a
directorate, many working groups, etc. All these issues need separate
working groups. Whether or not we need separate working groups is
mostly out of the working group's hands.
General discussion on the issues needing addressing and how to move.
For the moment, assume we have what we have and let's get going as
quickly as possible this week. Yakov Rekhter volunteered Thursday's
BGP/IPIDRP slot. People were asked to get stuff ready before Thursday.
Is it the feeling that we need to go to DNSSEC and say we need signature
granularity at the level of a name. Resounding yes.
People are talking about NSAP addresses. This will create no RR entries
in the tree. If NSAPs are getting encoded in IPng, what is being done
now becomes irrelevant.
Thursday - Coordination with DNSSEC
The prevalent DNSSEC draft, Eastlake and Kaufman, does provide for
signature authority at the name/class granularity, which is what dynamic
update feels is necessary. It is not clear if Masataka Ohta's competing
DNSSEC proposal does the same. We have made our need clear to DNSSEC so
that they will watch for any problems as they progress.
The Security Area is planning to use the DNS mechanism as a general key
store for all Internet security. This implies scaling to O(users) as
opposed to the current O(hosts). Their position is that:
o They have prototyped it, and Hesiod use at MIT is also
prototypical, and it works.
o Would we rather have Internet security rely on some new and untried
mechanism, while DNS has ten years of successful deployment?
They see no need for any changed or enhanced DNS mechanisms to support
their applications.
Notify Capability - BIND
Paul Vixie described how he added the notify capability to BIND, and
plans to write up a draft. He is coordinating the new opcode with IANA.
o The transaction is
OP = NOTIFY
QCOUNT = 1
QNAME = ZONE ROOT
QCLASS = IN (or whatever)
QTYPE = SOA (or whatever)
ANCOUNT = AUCOUNT = ADCOUNT = 0
o The primary notifies each secondary (all NS where NS != SOA).
o Each notified secondary responds to notify with QR set.
o Each notified secondary then does an SOA query as if refresh limit
had been reached.
o Note that this is still pull, not push.
o Also note that there are no data in the notify packet (yet).
Enhancements to BIND
Paul also described some enhancements he plans to add to BIND, with the
help of IANA, to make RR types `soft', i.e., allow the creation of new
RR types without recompiling servers and clients. This might be done
with an ersatz root zone which described the types.
A Simplified Model of Dynamic Update
Paul Mockapetris presented his vision of a simplified model of dynamic
update.
1. The update is sent to any authoritative nameserver:
UPDATE PACKET = Atomic Transaction
add ...
delete ...
2. The receiving server sends the transaction to the master server,
which checks that the sender has sufficient authority for the data
being modified.
3. The master server logs the update.
4. The master server:
o locks the zone
o makes the detailed changes
o rationalizes the zone (serial++ etc.)
o unlocks the zone.
5. The master server propagates the update.
There was considerable discussion:
o Should (2) transactions be sent to any listed (NS) server, or maybe
they should only go to `primary'? What if primary is behind a
firewall or is intermittently connected? Suggestion of an NX RR
pointing to servers which can accept changes.
o Should the downward flow of data be the complete new zone or a list
of the transactions of which the changes are composed?
o What happens if a notify is missed? Then the refresh time will
cause an update.
Open Items
The group knowingly left the following items open:
o A group member is working on a draft of how to use in-addr.arpa for
allocations on non-byte boundaries
o SIPP-16 needs
o Boeing said in Seattle that they were working on DNS operational
requirements
o RRs, etc., which may be needed by DNSIND, security, etc., for key
services
The group felt that two sessions would be needed in San Jose, plus a
joint meeting with DNSSEC if possible.