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!