Subject: Issue: Add a new QTYPE

From: "CTO WEI Renxiang" <[email-masked]>
Date: Wed, 19 Nov 2003 10:09:52 +0800

> issue: Propose to add a QTYPE to support dual-stack host.
> 
> name: Renxiang Yan
> email: [email-masked]
> date:   2003-11-18
> Type: T
> Priority: F
> 
>      Currently, the DNS resolver libraries on  a dual-stack host have to initiates two DNS query 
> for a specific host, one with QTYPE AAAA(or A6), the other with QTYPE A. The disadvantages are: 
>      1. increasing the delay in communication.
>      2. waste network bandwidth.
> 
>     Also, while DNS resolver libraries get two record, it have to decision to filter or order DNS results,
> and this process  have not been specified. 
> 
>     I suppose in this mail to:
>     1. add a new QTYPE ( which could be named "DS", means Dual Stack") to indicate both AAAA (A6) 
> and A record. DNS resolver libraries can initiate just one DNS query to get both IPv4 and IPv6 DNS
> record from DNS server.
>    2.  To promote the IPv6 deployment, DNS results for a dual-stack host returned by DNS resolver
> is suggested to be ordered in IPv6-IPv4.
> 
> R.G.
> Renxiang Yan
>

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 19 Nov 2003 11:21:51 -0800

>   | my strong recommendation is still that we include A RR's in the
> additional
>   | data section of any response to AAAA.
> 
> That might work, if we can get enough servers to actually implement
it.
> But it is a short term hack, which we'd need to eradicate eventually,
> and that's one reason I don't think it is a good idea.

We actually discussed and rejected the additional processing suggestion
-- it was present in the original draft of 1886. The argument was pretty
much the one Robert just gave: we will have to remove the processing
requirement eventually. It was also not clear that it would be useful in
most cases.

OTOH, I don't believe that the protocol police will jail you if you
actually return the A records in the additional section of an AAAA
query, especially if the AAAA record set is empty.

-- Christian Huitema

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Nov 2003 19:31:38 +0000

> requirement eventually. It was also not clear that it would be useful in

i believed i had shown during the debate over 1886, and i believe i have
shown again here today, that the lifetime of the data will be the same
as the lifetime of its usefulness.  this really is not a bad idea, folks.

> query, especially if the AAAA record set is empty.

isc has sometimes been accused of "legislating from the bench" by using
the power of the bind installed base to get things into the protocols
that ietf did not otherwise think was a good idea.  we won't be doing
that here.  unless there's consensus that adding A RR's as additional
data for AAAA responses (empty or not) is non-harmful, it won't happen,
or at least, it won't happen in bind.

---

From: Peter Koch <[email-masked]>
Date: Wed, 19 Nov 2003 20:53:14 +0100

> when a recursive server has no AAAA and so forwards the AAAA query to
> an authority, if that authority includes A as additional data then it
> will land in the same recursive cache as the AAAA.

sure, but if there's no AAAA you learn that from the cache, provided the
NODATA is there. If it is, the A-RRs may be put into the answer packet (out of
the cache) or the application has to query again. Local traffic, no problem.

Now, if there's neither an AAAA (maybe it really doesn't exist) nor a NODATA
(which has expired), you can only learn the NODATA from an authoritative server.
NODATA will expire frequently, so you'll have to ask an authoritative server
again and again, although the A RR will still sit in your cache.

If you first check your cache and use whatever is in there and only ask for
AAAA if the cache is empty (i.e. has neither A nor AAAA), there's lesser RTT
and lesser queries. Obviously for this to work positive TTLs for A and AAAA
need to be the same.

Maybe we should stick AAAA RRs in the additional section for A responses
instead.

-Peter

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Nov 2003 23:12:05 +0000

> I'd rather that we just defined a QTYPE of "all" which just returns
> everything. Given IPSECKEY and SSHKEY and other possible stuff, this
> just makes sense to me. Particularly for the client stub resolver to do.
> 
> Special rules about A/AAAA just seem short-sighted to me.

check the working group minutes from DNSIND, where an EDNS1 proposal
was shot down on the basis of complexity around this exact issue.  if
you think we're ready to move forward on multiple qtype matches where
the cache may have only seen one qtype even though others exist, such
that an RRD flag is required to force a fetch against the authority
server, then you're living in a dream world.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 26 Nov 2003 01:16:07 -0600

Paul Vixie wrote:

> if RD=1 QTYPE=* meant what you wish it meant, then this would be used all 
> the time, by applications whose authors "wanted to be certain".

If RD=1 were interpreted as it usually is, the cache would answer from the
results of a previous qtype=* query. So it wouldn't really be useful for
'get me the latest' because the normal behavior would only get the cached
results, not the authoritative data.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/