EditorŐs note: These minutes have not been edited DNS IXFR, Notify, and Dynamic Update WG IETF 35, Thu, Mar 7, 1996 Administrivia Pontification by the chair: WG has exceeded time limit in charter, turned left and right in search of truth. Time is running out. IXFR draft has already gone to IESG, some folks now want to change it to be aligned with dynDNS and notify drafts. Proposal: ask IESG to delay reviewing IXFR draft, WG will progress dynDNS and notify drafts to where they can be submitted to the IESG, bringing all three drafts into alignment (or not), by 4/15/96. AD then held WG's feet to the fire, stating that the WG needs to finish current, chartered drafts before entertaining new topics. Drafts for discussion during WG meeting: M Ohta draft-ietf-dnsind-ixfr-06.txt (Standards track) P Vixie draft-ietf-dnsind-dynDNS-07.txt (Standards track) draft-ietf-dnsind-notify-06.txt (Standards track) R Elz draft-ietf-dnsind-serial-01.txt (Informational track) draft-ietf-dnsind-clarify-00.txt (Standards track) draft-ietf-dnsind-2ndry-00.txt (Best Common Practice track) M Patton draft-ietf-dnsind-expires-00.txt (Standards track) + draft-ietf-dnsind-ixfr-06.txt Draft was not discussed, since it has already been submitted to IESG. + draft-ietf-dnsind-dynDNS-07.txt New semantics require that opcode be examined first in order to correctly decode remainder of the packet; older RFCs do net specifically state this; goal is to find a new wire format that supports the new semantics yet retains backwards compatibility; e.g. Network General Sniffer does not look at opcode before decoding contents of DNS packets. Changes to draft for next version (-08): - add rcode for zone error (from discussion on mailing list) - forwarding loops: possibilities exist for loops in forwarding updates; language will be added to draft to recognize this and warn DNS administrators. Some discussion about whether the DNS admin can do this easily, to be continued on the list. A suggestion was made to use an additional RR field to prevent looping. New ideas are to be discussed on the list, before 4/1/96. Interaction with DHCP requires the ability to expire individual RRs, with expiration time tied to DHCP lease time, therefore, need to pass expiration time in dynanimic update. WG chair noted that the request had been heard, and would be discussed on the list, WG will attempt to resolve it by 4/15/96 deadline if possible. A DHCP imlementor stated that he can live without this ability, but really needs to see completion of dynamic update specification. It was noted that the class field is overloaded in the current draft, i.e. the proposed format is not purely 103x. It was noted that there has been a change in granularity; what apears to the user as a single transaction has become two transactions, raising the possibility of an intervening transaction and potential conflicts. Seemed to be consensus that this is not the case. There were questions about updates to glue records; there was general agreement that issues exist, in particular there are possible problems with secure DNS; need to solve these by 4/15/96. + draft-ietf-dnsind-notify-06.txt Changes have been suggested on namedroppers, Vixie wants to make the changes and post the next version. + draft-ietf-dnsind-serial-01.txt Minor editorial changes have been suggested. There were no comments from the WG, consensus from the WG is to go forward with the draft. + draft-ietf-dnsind-clarify-00.txt Discussion of problems related to getting an answer from a different address than was used in the query. It was noted that the server cannot identify when a query was sent to a {multi,any}cast address, therefore when a client sends a query to a {multi,any}cast address, the client should accept reply from any address. Servers should reply from an address that clients can use for subsequent, follow-on queries. Difficulties interpreting TTLs on RRsets were discussed. It was stated that all RRs in an RRset should have the same TTL; it was noted that this could be effectively achieved by using the minimum TTL of the RRs in the RRset. Some details need to be elaborated in the draft. Difficulties can arise when RRsets with different TTLs are merged; WG sentiment is to not merge RRsets from different sources and to specify rules for choosing between old and new RRset data. Vixie has list of clarifiactions that need to be incorporated into the draft; this work will continue on the mailing list. + draft-ietf-dnsind-2ndry-00.txt No substantial discussion in the WG, draft was punted to Bush for progress as a BCP. + draft-ietf-dnsind-expires-00.txt Suggestion to use a bitmap to allow simultaneous expiration of multiple RRs. Counter-suggestion was made to change the type field allow qtypes, including "any" in an expire record; general agreement that counter- suggestion is preferable. It was then noted that expiration of entire RRset as a unit is not sufficient, need the ability to expire individual RRs, it's preferable to have the expiration data in each RR. This can be done with creation of a new, extended query (new qtype), then need a new zone-xfer protocol to handle this; DHCP implementor stated he can deal with difficulties caused by not providing RR-specific expiration, again he just wants dynDNS spec to be done. There was agreement to not hold up the current draft, and deal with this issue later. The question was raised, does SOA serial number change when a record goes away? It was decided that this is a contentious issue, therefore the draft is put on hold until the three required drafts are completed; then to be discussed on the list. The chair stated his intention to aggressively discourage discussion on list of the Elz and Patton drafts until required drafts are submitted to IESG. + discussion of AXFR wire format, BIND's perversion of it, the problems caused thereby, to get some ideas about how to proceed. Older versions of BIND don't handle multiple RRs in AXFR properly, may dump core. Want to include as many as 16K RRs in a single message in the interest of efficiency (compression). DiG makes assumption that if answer count is not 0, it must be 1; similar problems exist throughout the BIND code, Vixie has fixed many of these and continues to do so. Vixie is pleased with improved performance of new AXFR ("LONGAXFR"), but is worried about effects on older server implementations. "Insane" proposal to implement new qAXFR allowing multiple RRs. Consensus was to provide a 4.9.3p? that will not dump core, wait a few months, then release 4.9.4 that causes older servers to break. It was noted that this may not be such a wide-spread issue, since it will only happen when secondarys are not updated before primaries. Next version of BIND will support LONGAXFR by default, with option to use older" AXFR. Discussion of CERT Advisory warning of gethostbyaddr being fed an arbitrary string with newline. There was consensus that appropriate protection needs to be in gethostby{name,addr}. Existing sendmails need to be relinked (or upgraded to current version) + Frank Kastneholz (AD) asked for indications of future directions for DNS work. Answers from the WG: o Marker RR needs work. o Indirect A records, to renumber a large set of hosts, changing only a few records. o DNS for autonomous systems. o DNS equivalent of host requirements spec o Extended queries o Breaking the packet size barrier. o Investigate how DNS will scale for the next 10 years o Multiparty update of domains o Something like what drums is doing for mail o Clarify usage of CNAME records Thanks to Ken Lindahl for the minutes!