Subject: Resolving names, AAAA and A query

From: Markku Savela <[email-masked]>
Date: Fri, 26 May 2000 17:41:32 +0300 (EET DST)

I suppose following has been discussed to the death in the dawn of
IPNG, but ...

When an application is presented with a domain name, it cannot know
whether it maps to IPv6 or IPv4 address. Thus the resolver library
needs to make a query for both A and AAAA records. (Right?)

Just writing a resolver based on reading the RFC-1035, the first idea
was: hey! you can put both queries into same message, just have the
QDCOUNT=2...

... but, we quickly found that apparently nobody supports such thing.

Anyone care to comment the background of this: why the multiple query
feature of RFC-1035 is not implemented?

The KAME resolver appears to first send an AAAA query, and if that
results an error, it then sends A query.

Another idea is to send both AAAA and A in parallel and then use the
first good answer, if any arrives. And, when A6 is added, we have 3
queries to send?

-- 
Markku Savela ([email-masked]), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 26 May 2000 09:58:50 -0500

> feature of RFC-1035 is not implemented?

I thought it was lazy implementors of BIND when I first noticed that
lack of support.  But they instantly convinced me that the problem is
in the spec: what's the right RCODE when you can answer one query but
not the other?  What do you do if you have the answer to one in the
cache?  And so on.

draft-ietf-dnsind-edns1-NN.txt addresses this.

> first good answer, if any arrives. And, when A6 is added, we have 3

Other suggested reading:

RFC 1933
draft-ietf-ipngwg-dns-lookups-08.txt (recently passed by IESG):

    On the client side, when looking up and IPv6 address, the order of
    A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA;
    AAAA, then A6; A6 only; or both in parallel.  The default order (or
    only order, if not configurable) MUST be to try A6 first, then AAAA.
    If and when the AAAA becomes deprecated a new document will change
    the default.

    The guidelines and options for precedence between IPv4 and IPv6
    addresses are specified in [TRANS].  All mentions of AAAA records in
    that document are henceforth to be interpreted as meaning A6 and/or
    AAAA records in the order specified in the previous paragraph.

Where [TRANS] = 1933.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 26 May 2000 11:36:43 -0400

>needs to make a query for both A and AAAA records. (Right?)

Correct

>feature of RFC-1035 is not implemented?

There is no specification on the relationship of the queries is it
first match, match all that apply, or some other one. 

Then there is the issue of error reporting, if there is a query for 
first A6 and secondly A, and A6 does not exist is but A does is this
an error or not ? 

>first good answer, if any arrives. And, when A6 is added, we have 3

There has been a suggestion to use a META query for IPv6 address records
but that was shot down as AAAA records are supposed to die soon. 
If your host does not care if the connection is IPv4 or IPv6 then 
doing the queries in parallel does not seem such a bad idea. 
But us DNS people are going to scream as it doubles the 
number of queries. If your host has preference query for that type first.
If I recall correctly you support A6 you MUST try that first before 
issuing AAAA queries. Thus there will never be more than two queries
in parallel. 

It is not likely that multiple queries will be standardized in the near
term. 

	Olafur

---

From: Markku Savela <[email-masked]>
Date: Mon, 29 May 2000 14:22:04 +0300 (EET DST)

> first A6 and secondly A, and A6 does not exist is but A does is this

If there are no deployed software that implements the multiple query
feature, would there be a window for actually specifying some working
semantics for it now? The goals being

 - detection the old servers that don't support multiple query
   ("format error" seems to be a tell tale from some?)

 - minimise the transactions for AAAA,A,A6 (it would be such a neat
   package, with one hostname appearing only once using the DNS
   compression...)

 - define rules how to reply in case not all queries succeed (the
   particular goal being the needs of IPv4/IPv6 transition). Can think
   few starters

     - if all are in cache, return all
     - if some are in cache, return them separately, but
       proceed with query
     - if some name results error, and some not, perhaps return a
       separate error reply for them?
   
 - wouldn't multiple queries be more clean for some other purposes
   too? Query A or MX? (instead of messy "addional section..." :-)

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 30 May 2000 18:36:22 -0400

At 07:22 AM 5/29/00 , Markku Savela wrote:
>semantics for it now? 

Yes and NO. 

DNS implementations are just starting to catch up with the
many new features that have been added in the last few years, Dynamic 
Update, Incremental Zone transfer, IPv6 support (AAAA, A6, DNAME  and 
bit string labels) and DNSSec. There is going to be a lag in deployment 
any new features. 

>......The goals being

There is discussion going on how to find out in general what features a
particular server supports. 

>   too? Query A or MX? (instead of messy "addional section..." :-)

Multiple queries have certain attractiveness to them but once you think the
issue through, things get quite complicated.

If your client does not care what version of IP is used, then ask in parallel,
if it has preference express it in query ordering. 

Saving bits on the wire with compression in query is not a factor, getting 
back a truncated answer in response to a multiple question request 
is a bigger issue.

	Olafur