[dnsext] draft-li-dnsext-ipv4-ipv6 comments

[Michael Graff <[e-mail]>]

I do not like this draft in its current form.  Technical issues were 
requested to be discussed here, so here goes.

(1)  The wording is confusing regarding "no new record type" but then 
using "query type" -- it is effectively a meta-query type saying "return 
A or AAAA records."  It will only be used in queries, so this seems like 
an apt definition, but it will consume rr type address space.

(2)  It is a meta-type, which makes it scary to me for a number of 
reasons.  If you ask for an A record, you get a clear yes/no answer.  If 
you ask for AAAA, you get a clear yes/no answer.  However, if you ask 
for this meta-type, you might get A, AAAA, both, or neither.  If you get 
both, you know something useful, as with neither.  If you only get one 
type, you don't really know if the other exists, or if the cache you 
asked only had one of them.

(3)  We are concerned about packet sizes, and yet here is a proposal 
that will drastically increase the size of an answer should DNSSEC be 
involved.

I believe the purpose of this is not to minimize queries, so much as 
giving the client as close to immediate response time.  That is, "give 
me what you have and I'll try to use it!"  I believe however that this 
will cause a strong bias to ipv4 since it is more likely that this 
information may be cached, and will further bias statistics on ipv6 vs 
ipv4 traffic in the wrong direction.

This can be somewhat mitigated if a recursive cache always asked for 
both types when a client asks for A or AAAA, just in case someone might 
later need it.  This will in general increase traffic per query but 
probably not so much as multiple queries.

I propose this become an EDNS option, assuming the combined query has 
merit -- which I feel it does.  That option would indicate on sending 
that even though you are asking for A records, you also want AAAA if 
available.  Perhaps this could be extended to other types, but initially 
it should be restricted to A/AAAA only.  I would write it as "additional 
types to return" so if a client asked specifically for an AAAA record, 
an AAAA+A query could be issued, while if an A was asked for, an A+AAAA 
would be issued.  This ensures progress should the option not be 
understood upstream.

The response would include an EDNS option specifying the tri-state (I 
know there is no record, I do not know if I have a record) for each type 
NOT returned in the answer section, so the client can decide if it 
should try harder if it really prefers one or the other option.

--Michael

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>