draft-ietf-ipngwg-dns-lookups-04.txt

[Bob Halley <Bob_Halley@iengines.net>]

The draft is vague about just what "type A6 additional section
processing" is.  If you look at it like type A additional section
processing, then you would see if you had an A6 RRset for the target
name, and if so you would add it to the additional data section.  You
would not follow the A6 chains.

However, section 5 of the draft talks about adding "any relevant A6
records available locally".  The relevant A6 records are more than
just the A6 records for the target name; they are any A6 record in the
A6 chains for the target name.  The requestor would like to get as
much information about the A6 chains as possible, to reduce the number
of times it has to query the server.

I propose that the draft define "type A6 additional data section
processing" to mean "add all locally known data about the A6 chains
for the target name that will fit in the response".  (I'm sure someone
can come up with better phrasing that that.)

Also, in section 4.1.2, it says

    A query with QTYPE=A6 causes type A and type AAAA additional section
    processing for the QNAME, and type A6 and type NS additional section
    processing for the DNS names, if any, in the RDATA field of the A6
    records in the answer section.

Type NS additional section processing is required.  The intent is to
give a hint as to where more information about the A6 target name
might be found, saving the requestor from having to figure that out.
This kind of processing is not done for any other RR type that has
a target name (e.g. MX).

The issues I see:

	The responding server is doing type A6 additional section processing
	for the answer section A6 target names.  If it actually has these
	A6 records, then adding the NS records isn't very helpful, since the
	requestor probably won't need to use them.

	The NS records are the responder's best information about where to
	go next, but the requestor may have better-matching NS records
	in its cache.

	There is more work to generate a reply.

	The NS records are not needed by simple resolvers (i.e. those that
	always forward to a set of nameservers willing to do recursion).

I propose eliminating type NS additional section processing from the draft.

Comments?

/Bob