CURRENT_MEETING_REPORT_ Reported by Randy Bush/RGnet Minutes of the DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND) First Session The meeting began with an introduction of one of the new Internet Area co-Directors, Frank Kastenholz. Agenda bashing: o Main items: - Dynamic update - Notify - IXFR o Schedule adjusted for IPv6 meeting conflicts The group had hoped this would be the last meeting, but it does not look likely. The last meeting is now expected to be at the Stockholm IETF. More DNS issues may be assigned to the group and the charter must be re-written if so. DNSSEC is inactive and the draft is out. Masataka Ohta -- IXFR o In AXFR: UDP SOA query-response, followed by TCP SOA AXFR. o In IXFR: UDP IXFR query, server responds with unrecognized, or UDP SOA answer, or UDP zone transfer. If UDP SOA answer, follow with TCP IXFR for update. Can client initiate with TCP IXFR? Answer: no, need a UDP query first. Should be able to start with TCP, due to possible UDP fragmentation (no fragmentation in v6). Opinion: TCP may be too expensive for every query. RFC 1034 states UDP must be tried first. o IXFR answer formats: 1. Just current SOA. 2. Same as AXFR (current SOA, followed by full zone data, followed by current SOA). 3. Current SOA, followed by data to remove, followed by new SOA, then data to add. o Each IXFR requires an SOA change, unlike dynamic update which may not update SOA until several queries later. o Masataka, Sue and Paul should meet to hash out packet formats. o IXFR should be similar to dynamic update format (do not have two different formats for similar things). o Why do you want UDP for IXFR? Answer: it might avoid the need for TCP in some cases (you need UDP SOA query for AXFR anyways). Also, if UDP is good enough for initial SOA in AXFR, it should be good enough for IXFR. o Language will be modified -- need only packet format settled before floating it as Proposed Standard. Do we need an implementation first? The consensus was to delay going to RFC until implementation -- approve at Stockholm if no problems. o If server determines UDP checksumming turned off, send an SOA so that TCP is used Masataka Ohta -- Idea For IPv6 o Already have AAAA records for full address. o Propose XXXX record that has prefix pointer plus a host number. o Prefix pointer has a separate record to get list of prefix numbers. o Could this be done through a front-end, rather than the protocol? o It also allows one-record IXFR if provider changes. Paul Vixie -- DNS Notify (And Others) o Notify now in draft status. o BIND 4.9.3 has code -- would not enable it. o LOC RR -- encode geographic location, use WGS84 reference spheroid (same as GPS), BIND 4.9.3 conforms to draft. o SRV RR: There is a problem with ``ftp.yoyodyne.com''-type hosts with asymmetric A/PTR RRs. SRV RRs -- sort of like MX RRs (FTP on one host, WWW on another). Can also provide primitive load balancing. Somewhat controversial -- should it be in this working group? Remember what happened to WKS RRs. Can multiple PTRs solve the problem? (Paul says he's still getting hate mail for making this work.) Where should this go? o Back to Notify -- changes: Primary Master has the external data source, must be listed in SOA MNAME and be one of NS RR. Slave: uses AXFR/IXFR to fetch zone data, must be in NS RR. Master: AXFR/IXFR server to other slaves. Note: Slaves can also be Masters! Lurker (?): AXFR/IXFR client but is not in NS RR. Server must receive and send data on DNS port. Is there a reason why a ``lurker'' should be authoritative? (Lurkers should be notified by default?) Bill Simpson: IPv6 Address-to-Name Mapping o Host should answer its own queries for a hostname. o Uses ICMP. o Couple points raised: useless for multicast. o Logging? Bill: inverse tree is not reliable either, IPv6 will be much more dynamic (hosts and prefixes). o Both inverse DNS and direct-to-host queries are needed. o Some preference for UDP due to some implementation issues w/protection in UNIX (non-prived processes cannot ICMP). o Should protocol be same as DNS (similarity vs. complexity)? o Inverse DNS tree is not as rotten in Paul's experience as Bill thinks. Some people use inverse DNS for authentication. Second Session Susan Thomson -- Dynamic Update The goal is to try and make the next draft the last. Topics and Open Issues: o Add name new, add name exist, add operations o No support for recursion, referrals o Ordering of update requests o Implementing mutual exclusion o Name server technology o DNSSEC Update is atomic transaction consisting of sequence of operations on multiple names and types in a single zone. Atomic against just primary, or everywhere? Answer: cannot be everywhere, since secondaries may be out-of-date -- that is inherent in DNS. Can primary be inconsistent? Answer: difference between visibility of data and atomicity of transactions. Operations: delete, add, add name new, add name exist. Add name new only works if name does not exist - ensures uniqueness Add name exist -- only works if name does exist. NXD records? Server should automatically fix these? (The answer seems to be yes.) Update is defined to be asynchronous, but server may make it synchronously anyways. Updated data may not be visible right away -- there was much discussion on this. Those in favor say that it allows for flexibility on the server side; secondaries are going to cause a problem with complete visibility anyways. Those against it say that the client needs to have data visible; cannot read consistent view of the world. A possible solution might be to return a delta time as to when an update will be visible. (This seemed to be accepted.) Zone serial number updated at discretion of primary. Client can send request to any name server authoritative for zone. (Statically-configured lurkers also allowed? Answer: yes) Only primary can update zone. Secondary forwards synchronously to primary. No support for recursion or referrals. Duplicate detection is needed to protect against replay (malicious or accidental). Ordering is required to make sure earlier requests do not succeed later ones. Problem: what do we use? SOA serial number: concurrency issue (it is on the whole zone). Need something more. Use SIG ``time signed'' timestamp? Or new RR per node? In general: some sort of serial number (not necessarily SOA's). Cannot use absence of something as generic locking mechanism - so don't. There was consensus that all three types of adds should be present. Name server terminology should be consistent between all three drafts. DNSSEC: SIGs apply across all RRs for a given name. To update a SIG, you must read all RRs first. But what about delayed visibility? Authorization issues -- must have SIG signed by all affected by an update? Current update definition does not have a wrapper -- Susan and Donald Eastlake will work one out. There are still some concerns about visibility -- where is the right tradeoff? This will be hashed out on the mailing list.