Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt

From: Erik Nordmark <[email-masked]>
Date: Mon, 4 Oct 1999 12:46:55 -0700 (PDT)

> On Jun 29th Paul A Vixie wrote:
> if we want to specify a metaquery that can be satisfied by either AAAA
> or A6 records (or A records for that matter) then by all means let's make
> one.  MAILA and MAILB are metaqueries.  they have no corresponding RRTYPES;
> they are examples of QTYPE being a subtype of RRTYPE in the DNS specs.

Do we want to define a meta-query for AAAA and A6?
What are the issues in doing so?

(Trying to get the discussion restarted so we can get closure.)
   Erik

--------------------------------------------------------------------
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: Mon, 04 Oct 1999 15:35:06 -0500

> (Trying to get the discussion restarted so we can get closure.)

IANA has already given me a type code and in my copious free time a
new draft will be created, containing words like the following ...

  .IP o
  A new DNS query type "ADDRS" which requests A6, AAAA and A records.
  [...]
  .SC 1
  IANA Considerations

  The A6 resource record has been assigned a Type value of 38 and the ADDRS
  query has been assigned a Qtype value of 248.

And something in between to define it.  My thinking right now is that
QTYPE=ADDRS should get back A, AAAA and A6.  Any differing opinions?

				Matt

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 04 Oct 1999 16:49:16 -0400

> QTYPE=ADDRS should get back A, AAAA and A6.  Any differing opinions?

What are the caching semantics for intermediate caching resolvers,
where some hosts are doing ADDRS queries and others are just doing A
queries?  i.e., if an A is cached but A6 isn't, is an intermediate
resolver required to do a new ADDRS query to retrieve the other data?

What order are the records retrieved in?  (in case there isn't room in
the reply packet..)

(I hope the answer is "yes").

					- Bill

---

From: Bob Halley <[email-masked]>
Date: 04 Oct 1999 17:37:52 -0700

> What are the issues in doing so?

There are some issues with metaqueries.

Many sites are slow to deploy new versions of nameserver software, so
we have to expect that servers that do not understand an address
metaquery will be around for years to come.

How do you tell if the server does not understand the metaquery, or
does understand but is saying there are no matching records?
E.g. here's the result of a "dig" for type 248 sent to a server:

; <<>> DiG 8.2 <<>>
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;      vix.com, type = 248, class = IN

;; AUTHORITY SECTION:
vix.com.                1H IN SOA       ns-ext.vix.com. hostmaster.vix.com. (
                                        1999082900      ; serial
                                        1H              ; refresh
                                        30M             ; retry
                                        1W              ; expiry
                                        1H )            ; minimum

Is this server telling me that there are no A, AAAA, or A6 records at
this node, or that there are no records of type 248?  (The latter happens
to be true, but how can you tell?)  Also, does the address meta query
apply only to A, AAAA, and A6, or does it apply to any present or future
"address" type?

Making an address metaquery part of some EDNS version would solve the
meta/non-meta ambiguity.

Caching, especially negative caching, also raises issues.

RFC 1035 section 3.6 says

	The difficulty is that the presence of one RR type in a cache
	doesn't convey any information about the other because the
	query which acquired the cached information might have used a
	QTYPE of MF, MD, or MAILA (which matched both).

Similar problems would apply with A, AAAA, A6, and ADDRS if ADDRS
does not cause recursion.

If doing an ADDRS meta query does cause recursion, do you recurse for
the types you do not know about individually, or do you issue an ADDRS
query?  You must always be prepared to do individual queries, since
the remote nameserver might not implement ADDRS.  If you do the ADDRS
query, do you cache it as a block (i.e. as if there were an ADDRS
rrset), or do you cache the types individually?  If you do cache as a
block and someone issues a query for A6, do you realize you have an
ADDRS block and extract what you need, or do you just issue the A6
query?

Negative caching adds more fun, since you cannot necessarily construct
a coherent negative cache response from negative cache entries created
at different times.  Assume that I've got a negative cache entry for
www.example, type A, in my cache.  The negative cache data includes
the SOA that was in the negative response; say it was serial number
100.  Assume I also have a negative cache entry for www.example, type
A6, with SOA serial 101.  If I get an ADDRS metaquery, I have to
discard the cache data (at least the data with SOA serial 100) since
the serial numbers are not the same -- maybe there are A RRs in
version 101 of the zone.  If I get negative replies with NXT records,
I can infer more.

Does an ADDRS response mix answers with negative caching?  If www.example.
has A and A6, but not AAAA, do I get an answer like the following?

; <<>> DiG 8.2 <<>>
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;      www.example, type = 248, class = IN

;; ANSWER SECTION:
www.example.		1H IN A		10.0.0.1
www.example.		1H IN A6	64 ::1:2:3:4 ip6.example.

;; AUTHORITY SECTION:
example.                1H IN SOA       ns.example. hostmaster.example. (
                                        1999082900      ; serial
                                        1H              ; refresh
                                        30M             ; retry
                                        1W              ; expiry
                                        1H )            ; minimum

EDNS1-style multiple question queries have similar problems.

I think things would be a lot simpler if we just did individual queries.

/Bob

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 4 Oct 1999 18:31:16 -0700 (PDT)

> E.g. here's the result of a "dig" for type 248 sent to a server:

Yes, the resolver would clearly need a fallback.
I'm assuming we time things so that everything that supports A6 will
support the meta-query, which makes the fallback simpler.
	Try meta-query
	If NOERROR && ANSWER == 0
		try AAAA

This is never any worse then
	Try A6; fallback to AAAA (which is one of the current proposals
	in the draft)

I don't think there has (yet) been a discussion to include A records in the 
meta-query; it would make the fallback more complex. 
But once the servers understand the A6 and meta-query a single
query would suffice, except when there are no A* records for the name.

> I think things would be a lot simpler if we just did individual queries.

Sounds like it.
But that means we need to figure out what the correct order/choice
is between A6 and AAAA in the resolver, and decide to what extent we need a
knob to adjust that order/choice over time.

   Erik

---

From: Jim Bound <[email-masked]>
Date: Mon, 04 Oct 1999 23:40:04 -0400

I don't think we should mix A records in the query.  Just AAAA or A6.

/jim

---

From: Bill Manning <[email-masked]>
Date: Thu, 7 Oct 1999 12:13:52 -0700 (PDT)

> QTYPE=ADDRS should get back A, AAAA and A6.  Any differing opinions?

Well, thats a nice subset.  Why not get back all ADDR types?

-- 
--bill

---

From: Bob Halley <[email-masked]>
Date: 11 Oct 1999 12:02:42 -0700

> I don't think we should mix A records in the query.  Just AAAA or A6.

It doesn't make sense to me to worry about saving roundtrips in the
AAAA to A6 transition and not worry about roundtrips spent co-existing
with the IPv4 Internet.

Nevertheless, I remain opposed to a meta query at this time because of
the problems interoperating with existing implementations and with
negative caching which I described in my previous message.  I'm not
saying these problems can't be resolved with further changes to the
DNS standards, but I don't think now is the time to do it.  I think
we're better off getting DNS lookups out of draft state ASAP.

I propose the following changes to draft-ietf-ipngwg-dns-lookups-04:

	Eliminate type A and AAAA additional section processing for A6
	records.  This additional section processing doesn't save any
	effort unless you query for type A6 first, and the A/AAAA
	records are present.  Because this is additional data, you
	can't assume that the absence of A or AAAA in a reply implies
	their nonexistence, so you have to query for them if they're
	not in the reply.  Also, I think many resolvers would want to
	query for type A first, since I expect the majority of hosts
	will be IPv4-only for some time.

	Add guidance that resolver and nameserver implementations SHOULD
	allow the types, and order, of address queries to be specified.
	E.g. query for A, A6, and then AAAA.  A resolver could choose to
	send the queries in parallel or in series as it saw fit.  E.g.
	Send out A and A6 in parallel, and if there are no A6 records,
	send out an AAAA query.

I propose that support for an address metaquery / multiple questions,
and the negative caching changes that go along with it, be addressed
in a separate future draft.  I think any such support will have to be
done as an EDNS version.

/Bob

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 11 Oct 1999 15:38:41 -0500

Jim, Bob, Erik, and all other interested parties,

  I hope to distill the differing viewpoints into consensus soon, if
possible.  I think we may fairly say that every preference put forth
so far entails some cost; there's always a trade-off to be made.

  I propose that we deliberately sacrifice efficiency (in the form of
possible extra DNS round-trips) for correctness (in the form of
relying on long-tested semantics for all operations).  Leave
efficiency improvements for another, more general mechanism.

My perception of a spec. derived from this position is:

 No new Qtype.  No type A or AAAA additional processing for A6
 queries.  (RFC 1886 is already implemented and does not specify
 additional "A" data for AAAA queries.)  "Recursive" additional
 processing for the DNS name (if any) found in the RDATA of the A6
 records in the answer.  All old query types that now do type A
 additional processing redefined to do A, A6, AAAA, in that order.

				Matt

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Oct 1999 16:41:28 -0700 (PDT)

>  additional processing redefined to do A, A6, AAAA, in that order.

I think it would also be useful to try to nail down a default order
that the resolver will ask for IPv6 address records and whether or
not implementaions should have knobs to adjust that order.
(The issue of ordering between A and AAAA/A6 records is already
discussed in RFC 1933 if I'm not mistaken.)

   Erik

---

From: Bob Halley <[email-masked]>
Date: 11 Oct 1999 16:41:31 -0700

>  additional processing redefined to do A, A6, AAAA, in that order.

Sounds good to me.  BIND 9 does additional data section processing in
the order you specified, but I don't think that the order really
matters and would be inclined not to specify it in the RFC.

/Bob

---

From: Jim Bound <[email-masked]>
Date: Mon, 11 Oct 1999 22:53:07 -0400

Hi Matt,

I agree with your logic and as Bob stated leave the nextgen solution to EDNS
as it evolves.

This sounds doable and will work and we can ship it moderately quick
(like that eh!).  Would be good to provide some order to which types are
searched for given first type requested (as the API defines the type
initially and almost absolutely with the new flags param in
getipnodebyname).  

thanks
/jim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Oct 1999 09:19:38 +0200

In your previous mail you wrote:

=> about ordering, something is not specified: when an address is
searched for a not fully qualified domain name then there is a search
for IPv4/A and IPv6/AAAA/A6 and in the search list (the list of domains,
usually initialised with the local domain name).
Should we do IP version or domain first? I believe many implementations
do domain first, ie. for instance look for an AAAA RR for the name
completed with search list elements then if nothing is found try
the same thing for an A RR.

[email-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 14 Oct 1999 08:52:01 -0500

Francis dit:
> Should we do IP version or domain first?

Let me restate the situation.  The user refers to short-form name H,
and the resolver is configured to search domains D1, ..., Dn.

As I see it, the FQDN the user is implicitly naming is the first one
which *exists* from the sequence H.D1, ..., H.Dn.  Then the resolver
gives back whatever suitable records are listed for that FQDN, or
some sort of error if there are none.

> I believe many implementations do domain first, ie. for instance
> look for an AAAA RR for the name completed with search list
> elements then if nothing is found try the same thing for an A RR.

This isn't the same as what I presumed above.  Which more closely
matches the behavior of existing implementations?  If in a v4-only
world I type "telnet H" and H.D1 exists but has no A record, but H.D2
has an A record, what happens?

				Matt

---

From: Robert Elz <[email-masked]>
Date: Fri, 15 Oct 1999 00:29:16 +1000

Date:        Thu, 14 Oct 1999 08:52:01 -0500
    From:        "Matt Crawford" <[email-masked]>
    Message-ID:  <[email-masked]>

  | This isn't the same as what I presumed above.  Which more closely
  | matches the behavior of existing implementations?  If in a v4-only
  | world I type "telnet H" and H.D1 exists but has no A record, but H.D2
  | has an A record, what happens?

Assuming that H.D1 also does not have a CNAME which then gets to an
A record, H.D2 is found.

That's needed, or
	*.D1 MX whatever
would cause "telnet H" to always attempt H.D1, regardless of there
being nothing really called H in D1 at all.

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 14 Oct 1999 11:32:57 -0500

(Wow, the time zones invloved in this discussion!)

Matt:
>   | Which more closely matches the behavior of existing implementations?
>   | If in a v4-only world I type "telnet H" and H.D1 exists but has
>   | no A record, but H.D2 has an A record, what happens?

Francis:
> => I think the first choice is used by most of them, try first IPv6,
> if there is no result and no fatal error then fall back to IPv4.
> (ie. it is convenient to use the res_search() function)

Sure enough.  I dug through the most common genus of nameserver and
resolver for which I have source code and this is what will happen.
In capsule form, if an application prefers addresses coming from RR
type T1 over those coming from RR type T2, and T2 over T3, and if the
resolver has a domain search list D1, ..., Dn, then the conceptual
operation "get me a connection to H" will choose an H.Dx with the
most-preferred address type rather than the one with most-preferred
domain.

If a resolver's search list includes domains which have little or no
administrative relation to one another, then this could cause
surprises.  If, for example, one had been accustomed to reaching H.D1
with the less-preferred address type one might suddenly reach H.Dn
instead because it has added a more-preferred address type.

Pretty much the same thing can happen in a pure-IPv4 setting if one
is in the habit of specifying "H" to reach "H.D2" and then domain D1
adds a host "H".  Therefore, proposed that we not concern ourselves
about this except perhaps to mention it.  When and if multi-question
queries become available, other approaches will become possible.

				Matt

---

From: Francis Dupont <[email-masked]>
Date: Thu, 14 Oct 1999 17:06:23 +0200

=> with this notation the two choices are :
 - AAAA for H.D1, ..., H.Dn then A for H.D1, ..., H.Dn, or
 - AAAA then A for H.D1, ..., AAAA then A for H.Dn.

   As I see it, the FQDN the user is implicitly naming is the first one
   which *exists* from the sequence H.D1, ..., H.Dn.

=> this is the second choice, with the first one if H.Dx exists but
has no AAAA RR and H.Dy exists and has an A RR with x < y then the
returned FQDN will be H.Dy. Unfortunately this is not a theorical
case because for instance my current search list is
"inria.fr ipv6.inria.fr"!

   Then the resolver gives back whatever suitable records are listed
   for that FQDN, or some sort of error if there are none.

=> yes, a correct resolver should understand CNAME RRs and the
difference between "no such domain" and "no address" (ie. name
exists but has no such RR).
   
   > elements then if nothing is found try the same thing for an A RR.
   
   This isn't the same as what I presumed above.

=> of course a query "address" type, even managed internally by the
resolver (the T_ADDR hack), will give the second choice!	

   Which more closely matches the behavior of existing implementations?

   If in a v4-only world I type "telnet H" and H.D1 exists but has
   no A record, but H.D2 has an A record, what happens?

=> H.D2 (and its address) is returned. All the standard applications
use gethostbtname() function or a clone, only sendmail is smarter
and uses directly the resolver library (with "mx" and "any" queries,
avoiding to be fooled by wildcards, ...).

Thanks

[email-masked]

PS: the code for AAAA and A RRs should be the same but some bogus
name-servers don't deal correctly with queries for an AAAA RR for
a name with (only) a CNAME RR then the choice between the two orders
has some impacts on the answer decoding function in the resolver.
PPS: the choice has a big impact in the speed and the number of
queries in the current Internet where AAAA (and soon A6) RRs are
*sparse*: this is not only an implementation issue!
--------------------------------------------------------------------
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: Paul A Vixie <[email-masked]>
Date: Thu, 14 Oct 1999 11:12:10 -0700

> some sort of error if there are none.

we went through this in pure IPv4, too, due to early API ambiguity
between "name doesn't exist at all" and "name exists, but there are
no address records."  in fact it was KRE who complained about it then,
as now.  so assuming

	H.D1	IN MX	10 foo
and
	H.D2	IN A	10.0.0.53

and a domain search list of D1,D2, it used to be that "ping h" would
return "no such host".  now it pings 10.0.0.53.  to me, this is the
same issue except that we're fine-pointing on the meaning of the
question "are there address records at this node?"

---

From: [email-masked]
Date: Fri, 15 Oct 1999 15:04:19 +1000

> question "are there address records at this node?"

 Paul has heard my views on the behaviour in the past. i.e. I think
 that it is broken in the same way that RFC1535 show the old search
 list behaviour to be broken.

 I understand why the current behaviour is there, to cope with
 wildcard records with the old search list behaviour.

 To my view this is as dangerous as having the old search list
 behaviour.

 The current behaviour has it such that you can telnet to a box
 and then attempt to send mail to the same box and get two different
 fully qualified named.

 I for would be happy to see this behaviour change even though it
 may break some existing systems that are depending upon it.  It is
 counter intuitive.  It should even be possible to have to new lookup
 mechanisms get the new behaviour getipnodebyname() and the old 
 gethostbyname() implement different search strategies.

 Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jeff Williams <[email-masked]>
Date: Fri, 15 Oct 1999 13:45:02 +0100

mark and all,

  Good points here mark, and I agree essentially with you contention.
But why not provide for this as an option so that a transition can be
made?  Follow me?  >;)  We did this in our "Interface Facility".
Thought it did required for us to make some changes to our
"BindPlus", but they were minor.

>  gethostbyname() implement different search strategies.

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: Robert Elz <[email-masked]>
Date: Sat, 16 Oct 1999 20:34:01 +1000

Date:        Fri, 15 Oct 1999 15:04:19 +1000
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  |  I understand why the current behaviour is there, to cope with
  |  wildcard records with the old search list behaviour.

While the old search list behaviour probably made it more necessary,
the two aren't really directly related.   In fact, as personal domains
become more prevalent, where users want mail to [email-masked]
delivered to them, and hence wildcard MX's perhaps become prevalent
again - and also want their search list to start with my.domain (because
it is their local domain) but to probably also include their ISP's domain
(so they can easily refer to pop servers, news servers, http caches, etc)
they aren't really going to want the wildcard MX to completely defeat their
search list.    Wildcards are useful - they're also a pain sometimes (or
perhaps frequently).

  |  The current behaviour has it such that you can telnet to a box
  |  and then attempt to send mail to the same box and get two different
  |  fully qualified named.

Yes.  Good.   A per protocol search list would suit me just fine
(even better than just per type).   The set of hosts that I want
to telnet to are typically a completely disjoint set from the ones
that I want to send e-mail to, which are again disjoint from the
ones I want to http or ftp to, and those aren't the same as the set
I want to send rwhois or DNS or TFTP packets at.

For mail, I actually don't like the search list at all, and certainly
not when it is implemented in the MTA (as distinct from the user agent).
MTA's have no good way to get the user's desired search list (the
mail may have been relayed several times already - by mailers which
aren't completing the domain name, even though they should) - I disable
all implicit domain searching in my sendmail.   So whatever rules
the resolver applies to other lookups, mail (sendmail anyway) is
never going to be the same.    Most UA's I have seen just do the
same gethostbyname() as everyone else does.

On the other hand, the "desire" as Matt first stated it, as it applies
to "address" type records seems fairly reasonable to me, I doubt it
would be terribly useful to have "any IPv4 host on the search path
is found ahead of any IPv6 host" (or vice versa) as the mechanism,
if some rational and implementable way to avoid that can be found.

kre