Subject: Re: Issue: Add a new QTYPE

From: Robert Elz <[email-masked]>
Date: Thu, 20 Nov 2003 01:31:57 +0700

Date:        Wed, 19 Nov 2003 17:18:14 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

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

That is it would work now, as in practice, just about everything has an
A record, so you'd either expect to get one, or assume the server is old
and do a second query.

But if/when we reach the state where many names have only AAAA, then
not getting the A just means there isn't one - unless of course, it is
an old server for which we need an extra A query.   The effect of this
is that as the number of A records decreases, the number of A queries
increases.   That's not a good property.

Doing it just this way (and not also saying "add AAAA as additional in
any A query") is also assuming that AAAA is a 2nd class type of address,
and that everyone is really going to need the A that goes along with it.
That's not the message to send either.

So, I wouldn't support this (I actually don't really believe that simply
doing both an A and an AAAA query is all that bad - hosts can prefer one,
and only do the other if the preferred one is NODATA - or they can simply
send 2 queries in parallel, and get back both answers).

Briefly in reply to a couple of other messages ...

Eric - as I recall the ADDR query wasn't quite a subset of ANY, but
to get that more or less abandoned reasonable caching - which is the
real problem with all meta queries, they simply don't play well with
caches, and caches are more important.   In any case, those discussions
are in the archives too...   The point of my original reply was that
the suggested idea is not new, and has never gotten anywhere before.

Bill - I can't even begin to imagine what discover has to do with any
of this.

kre

--
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: Peter Koch <[email-masked]>
Date: Wed, 19 Nov 2003 20:12:42 +0100

> send 2 queries in parallel, and get back both answers).

what one can see at an "edge nameserver" is an amount of queries for AAAA and
A6 which each is around 50% of the number of A queries. That's far higher than
justified by the currently deployed IPv6 base. One "culprit" is a popular
nameserver implementation. Another share is due to the usually lower TTLs
for negative answers. So A stays in the cache, the NODATA for AAAA doesn't.
While I think the multiple-queries-approach deserves some further investigation
I'm not too sure it would help in significantly reducing the number of queries
and thus RTT. There's simply no way to influence the lifetime of a
particular negative response and there's no other way to say "I have no
AAAA for foo.example.com and won't for the next day".

Paul's suggestion to piggy-back the A RRs onto the AAAA responses won't really
help unless the queries are sent non-recursively (to the local resolver/cache).

-Peter

---

From: Rob Austein <[email-masked]>
Date: Wed, 19 Nov 2003 15:13:28 -0500

> for negative answers. So A stays in the cache, the NODATA for AAAA doesn't.

Another known culprit is a certain (otherwise rather nice) open source
web browser, which apparently includes its own resolver implementation
and which issues not just AAAA but also A6 queries for every new name
it sees in a URL.  (One finds the oddest things running dnstop....)

Point here is not to slam the browser authors, it's to underscore that
even with negative caching there's a limit how much we can hold down
the traffic generated by a busy little dual-stack application.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 19 Nov 2003 14:10:21 -0600

> the suggested idea is not new, and has never gotten anywhere before.

It's true that all of the proposals have gone nowhere, but that's because
they all share the same problem, which is that empty RRsets of alternate
addresses can't be represented in the answer -- you can't give AAAA RRs
and an NXDATA for (non-existent) A RRs in the same answer, so resolvers
are forced to assume that any incomplete answer is truly incomplete,
essentially requiring multiple queries to find out for sure. This problem
exists for qtype=ADDR and just-include alike. If it is explicitly
addressed in either proposal (such as including some kind of flag, or
including an SOA, or whatever), it can also be addressed in the other.

We need to figure out the preferred mechanism for representing incomplete
answers in the zone versus incomplete answers in the cache, and then we
can back-design whatever mechanism we want to use for the query part.

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

---

From: [email-masked]
Date: Thu, 20 Nov 2003 07:29:17 +1100

One way around this is to publish the IPv4 address as mapped
	addresses in the AAAA records and only look for A records
	if there are no mapped records.  For this to work in the
	long term a cut off date for looking for A records when
	there are no mapped IPv4 addresses in the answer would
	have to be set.

	A zone verifier would check for inconsistancies between the
	A / AAAA records and correct / report them.  Correcting
	could be one of "mapped from A" or "A from mapped" or "add
	missing".

	An UPDATE to a A/AAAA record would perform the corresponding
	change on the other RRset. Delete all A records would delete
	all mapped AAAA records.

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

---

From: Rob Austein <[email-masked]>
Date: Wed, 19 Nov 2003 15:30:33 -0500

> can back-design whatever mechanism we want to use for the query part.

Is it just me, or have others started to wonder whether this thread
feeds back into DNSSECbis Q-21?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Nov 2003 16:12:09 -0500

-----BEGIN PGP SIGNED MESSAGE-----

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.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [