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.