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

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

> 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?

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: 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

---

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.

				Matt

---

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

> 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:

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: 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.

; <<>> 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.

/Bob

---

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: Kevin Oberman <[email-masked]>
Date: 07 Oct 1999 14:27:40 -0700

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

I disagree. The formats of the replies will be distinct, so that there
can be no confusion and, for quite a while, most connections from
systems running IPv6 will be to IPv4 systems.

The inclusion of A into the meta-type will remove the need for a
second query should the connection be a v4 only system. It may
eliminate a call the gethostbyname and, even if the client makes a
second call for an A record, will allow a single DNS query by the
server to load both IPv6 and IPv4 addresses into cache so that a
subsequent query for an A record will be locally resolved.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest Orlando Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [email-masked]				Phone: +1 510 486-8634

---

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: Terry Lambert <[email-masked]>
Date: Fri, 08 Oct 1999 10:07:52 -0700

Kevin Oberman wrote:
> I disagree. The formats of the replies will be distinct,
> so that there can be no confusion and, for quite a while,
> most connections from systems running IPv6 will be to
> IPv4 systems.

I think that the rationale behind the thought is probably
that the 6-bone is not widely deployed, and when DNS is
deployed for it, it would be nice to have a request that
would result in 6-bone records _only_, and that the A
records and so on for IPv4 can be handled seperately, as
a legacy support issue (for which additional overhead on
gateways is an acceptable penalty for not upgrading).

> subsequent query for an A record will be locally resolved.

I view that support of IPv4 in the face of wide IPv6
deployment as a method of legacy system support.  I
think that going forward, DNS should shed the legacy
support for IPv4.  The alternative is heavy, barnacle
encrusted implementations that never get smaller, e.g.
the Novell huge-number-of-NCPs legacy that has so bloated
NetWare.

Other protocols are specifically versioned (LDAPv3, NFSv3,
etc.) such that support for legacy systems is optional,
rather than mandatory.  A requirement for inclusion of A
records seems to me to be a requirement for bringing the
IPv4 legacy with us into a future where it will have all
but disappeared.

Of course, this objection could be met by a stated intent
to version the protocol at some point in the future, but
I think that that would be inadequate; on the cusp of
wide deployment of IPv6, there exists an opportunity to
break with the past, and this opportunity should be siezed,
where appropriate.

Carpe Diem.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: "M. T. Hollinger" <[email-masked]>
Date: Fri, 8 Oct 1999 15:38:44 -0400

> A requirement for inclusion of A records seems to me to be a requirement
> for bringing the IPv4 legacy with us into a future where it will have all
> but disappeared.

Yes, but I would expect AAAA records to disappear long before the bulk of
the IPv4 Internet does.  Bear in mind that this query type is, itself,
proposed as a transition tool.  That is, it reduces the number of queries
needed to find both AAAA and A6 records corresponding to a particular domain
name.  In the future you envision, by the time only IPv6 is of interest,
AAAA records will no longer be of interest.

I therefore support inclusion of A records in this meta-type.  If we're
going to specify a transition tool that's useful for about the next 3 to 5
years, let's make it *really* useful.  One query should return all available
RR's (A, AAAA, and A6).  Why stop at halfway?

In order to make this useful, there must be a provision for the response to
return negative caching information: the fact that certain record types do
not exist.  For example, if your nameserver knows that no A or A6 records
exist for a given name, I wish your server could send me just one response
indicating both the list of AAAA records and the fact that there are no A or
A6 records.  If you just return the AAAA records when I send my first
meta-type query, then I have to turn around and send a second query for A
and a third for A6 in order to be sure I have a complete list of addresses
for the target hostname.  That would negate the value of the meta-type,
since I'd still have to send 3 queries and parse 3 responses.

             - Mark

---

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: Bob Halley <[email-masked]>
Date: 11 Oct 1999 16:41:31 -0700

"Matt Crawford" <[email-masked]> writes:
>  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.

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: 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: 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.

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

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: "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.

				Matt

---

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]