CURRENT MEETING REPORT

Reported by Ken Lindahl, University of California, Berkeley

Minutes of the DNS IXFR, Notify, and Dynamic Update Working Group (dnsind)

Administrivia

The working group has exceeded the time limit in the charter. Time is running out. The IXFR draft has already gone to IESG, but some participants now want to change it to be aligned with dynDNS and notify drafts. It was proposed that the group ask the IESG to delay reviewing IXFR draft. The working group will then 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.

The area director then held the working group's feet to the fire, stating that the group needs to finish current, chartered drafts before entertaining new topics.

Drafts for discussion during the working group meeting included:

draft-ietf-dnsind-ixfr-06.txt was not discussed, since it has already been submitted to IESG.

New semantics require that opcode be examined first in order to correctly decode remainder of the packet; older RFCs do net specifically state this and the 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) include adding 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 will 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. The working group chair noted that the request had been heard, and would be discussed on the list. The working group will attempt to resolve it by a 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. There seemed to be consensus that this is not the case.
There were questions about updates to glue records. There was general agreement that these issues exist, in particular that there are possible problems with secure DNS. The group needs to solve these by 4/15/96.

Changes have been suggested on namedroppers. Vixie wants to make the changes and post the next version.
Minor editorial changes have been suggested. There were no comments from the working group. Consensus from the working group is to go forward with the draft.

There was 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. Working group sentiment is to not merge RRsets from different sources and to specify rules for choosing between old and new RRset data. Vixie has a list of clarifiactions that need to be incorporated into the draft. This work will continue on the mailing list.

No substantial discussion in the working group. The draft was punted to Bush for progress as a BCP.
There was a 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. There was general agreement that counter-suggestion is preferable. It was then noted that expiration of entire RRset as a unit is not sufficient, there needs to be the ability to expire individual Rrs. It is preferable to have the expiration data in each RR. This can be done with creation of a new, extended query (new qtype), then there needs to be a new zone-xfer protocol to handle this. A DHCP implementor stated he can deal with difficulties caused by not providing RR-specific expiration, and again he stated that 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. Discussion will cintinue on the mailing 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.

Older versions of BIND don't handle multiple RRs in AXFR properly, may dump core. We 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 widespread 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.
There was a 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 (Internet Area Director) asked for indications of future directions for DNS work. Answers from the working included: