Subject: Re: QType: ADDR

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 08 Aug 2002 10:40:32 -0500

on 8/7/2002 7:52 PM [email-masked] wrote:
>>> On the other hand, my bet is that more applications are likely to
>>> START doing it once we have IPv6 applications that query for
>>> qtype=any instead of doing AAAA before A.
>
> "any" query does not return all available data.  it is allowed for a
> recursize resolver (named) to return data on the cache already, and not
> with other records actually available.  therefore, stub resolvers (libc
> resolver) that makes "any" query will not work.

You are of course correct. But that didn't stop sendmail from doing it,
and it isn't likely to stop v6 apps from doing it. The canonical issue
here is that there will (hopefully) be millions of applications which are
now faced with having to find two different RRs, whereas this problem has
historically been limited to a few hundred MTAs in the past. If we know
that a certain percentage of MTAs have done it (for whatever reasons they
considered to be valid), then we can also assume that there will be a
similar percentage of v6 apps that also do it (using similar reasoning).

Secondarily, being able to provide a single query should result in lower
overall utilization.

The real question at this point is whether or not implementors would care
to do it, given the necessary requirement for ensuring synchronization
between the cache and the server (this also includes local caches, btw).

I'll write this up and submit an I-D and see where it goes.

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

--
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: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2002 11:35:43 -0500

> and it isn't likely to stop v6 apps from doing it.

This sounds like a good reason to strategically place some very large 
RRsets in the DNS at places where these stupid applications will trip over 
them, not a good reason not to add a useful feature to the protocol.

It is not the IETF's business (I hope!) to make life easy for application 
developers who don't know what they're doing, and can't be bothered to 
study.

---

From: Rob Austein <[email-masked]>
Date: Thu, 08 Aug 2002 14:30:44 -0400

> similar percentage of v6 apps that also do it (using similar reasoning).

Sounds like a case for a (long overdue) document:
"Non-debugging Use of DNS `*' Query Type Considered Harmful".

> Secondarily, being able to provide a single query should result in lower

It's not that much of a saving, since whatever iterative resolver is
doing the work for you should already have the delegation chain cached
when (and if) you issue subsequent queries.

"Make it right before you make it faster.
 Keep it right when you make it faster."
 -- Kernighan & Plauger, "The Elements of Programming Style", 1974.

---

From: Robert Elz <[email-masked]>
Date: Sun, 11 Aug 2002 21:57:43 +0700

Date:        Thu, 08 Aug 2002 14:30:44 -0400
    From:        Rob Austein <[email-masked]>
    Message-ID:  <[email-masked]>

  | Sounds like a case for a (long overdue) document:
  | "Non-debugging Use of DNS `*' Query Type Considered Harmful".

This is a good idea, but it should be extended to meta queries in general,
so we don't keep seeing suggestions like the ADDR meta query, which apart
from the size issue, is no different in the problems it causes than ANY.

  | It's not that much of a saving, since whatever iterative resolver is
  | doing the work for you should already have the delegation chain cached
  | when (and if) you issue subsequent queries.

Yes.   Also the idea of adding A's as additional info on an AAAA query
is attractive.   The RRset rules mean that if you have any A's, you are
able to assume you have the full set.   So, adding those A's will get
them to the client's local back end resolver cache, meaning just one
local very cheap query when the client decides it wants the A's.

This doesn't have the negative effects of meta queries, because the
answer is only expected to contain the AAAA records (just as including
A's with MX queries).   If the A's didn't get returned, the later query
the client does (we don't need to assume that the stub resolver will be
smart enough to cache the A's that appeared in the AAAA query) will fetch
them the hard(er) way.  If they do, the local cache has them.

The best two things about this are that there is no need for any IETF work
to make it happen - just a request to the DNS server implementors to do
the right thing, and a suggestion to DNS cache implementors (to the extent
they're not the same people) that receiving A's in the additional info
section of a reply containing AAAA's in the answer section is normal, and
not some kind of attack to guard against.

And second, it dies naturally, with no effort, when it is no longer useful.
That is, when there are no more A's in use any more, there will be none to
include, and the whole thing will just stop - domain by domain, as the
transition eventually happens (sometime in the far future).   As soon as
the DNS server implementors decide that there aren't enough A users left
to bother supporting, they can rip this code out of their servers.  The
only effect of that will be that the (very few remaining) queries that still
do need A records will result in the extra query going further, but the
assumption is that there will be so few of them by then that no-one will 
notice.

So, server/cache people - go try it...  I think this is easy (as code to
add A's ad additional info is already there, just needs to be enabled for
AAAA as it is for MX, NS, and others).

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 12 Aug 2002 08:38:04 -0500

on 8/11/2002 9:57 AM Robert Elz wrote:

> suggestions like the ADDR meta query, which apart from the size issue,
> is no different in the problems it causes than ANY.

That's a hollow argument, since "the size issue" is exactly what's trying
to be avoided.

There's no doubt that these kind of meta-queries have issues. In
particular, an ADDR qtype relocates fall-back complexity from the API side
of the resolver to the protocol side. It isn't "free", and from an
holistic perspective, it's probably a wash. There is also a new cost in
terms of fallback failure which comes from having to deal with NOTIMPL
responses in downstream agents. OTOH, the prima benefit is still there,
which is that it provides application developers an efficient alternative
(from their PoV) to qtype=any.

> able to assume you have the full set.

True for resolvers/servers compliant with 2181, but not earlier.

Also, this method relocates complexity to the servers, while *also*
preserving it on the API side of the resolver. This approach has many of
the complexities of qtype=ADDR (potential overload, DNSSEC, and so forth),
and we *still* have to worry about developers issuing queries for
qtype=all. Holistically, things become more complex, not less. On the
other hand, this is also true for qtype=ADDR (at least in the short term),
since applications won't be able to assume that it will work, either.

One more comment for the record, I'm not convinced that qtype=addr is
worth the pain, but I know that qtype=any is worth being avoided. An
initial draft has been submitted and should be coming through the pipeline
in a day or two, but somebody else will have to do something with it. I'm
not going to advocate it. It seems to be a wash.

---

From: Kandra Nygårds <[email-masked]>
Date: Mon, 12 Aug 2002 17:46:32 +0200

From: "Eric A. Hall" <[email-masked]>

> True for resolvers/servers compliant with 2181, but not earlier.

Are there any implementations out there that send incomplete RRsets to any
query?

> the complexities of qtype=ADDR (potential overload, DNSSEC, and so forth),

Potential overload is an even bigger problem on queries such ax MX (assuming
we're talking about the same thing). As for DNSSEC, I haven't had the time
to get much deeper into it, so I'd welcome any input on potential issues
from someone who knows a bit more than me. I still believe that my idea has
certain advantages though, most notably the fact that there's no need for
any protocol changes.

Best regards
Kandra Nygards

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 18:48:51 +0700

Date:        Mon, 12 Aug 2002 17:46:32 +0200
    From:        =?iso-8859-1?Q?Kandra_Nyg=E5rds?= <[email-masked]>
    Message-ID:  <006e01c24217$6ee92790$0ef2a8c0@amalthea>

  | Are there any implementations out there that send incomplete RRsets to any
  | query?

I have seen incomplete RRsets in the additional info back in the
distant past.  (That is, fill in RRs until the packet is full, and stop).

One hopes that there aren't too many of those around any more.

And if you do a query for A records of munnari.oz.au to a root
nameserver, you'll get an incomplete RRset back - but that one is
caused by a different kind of brain damage.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 18:46:39 +0700

Date:        Mon, 12 Aug 2002 08:38:04 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | > suggestions like the ADDR meta query, which apart from the size issue,
  | > is no different in the problems it causes than ANY.
  | 
  | That's a hollow argument, since "the size issue" is exactly what's trying
  | to be avoided.

You're missing the point.   I know that ADDR is attempting to avoid
the size problems with ANY.   If that was all that mattered, then
(apart from how to actually get it deployed) it would be fine.

The issue is that meta queries have other problems (the ones Rob Austein
pointed out) - there is simply no way to make them work properly (assuming
that caches still exist - no difficulty if we were to do away with cahcing).

  | There's no doubt that these kind of meta-queries have issues.

Yes.  They simply don't work reliably.

  | In
  | particular, an ADDR qtype relocates fall-back complexity from the API side
  | of the resolver to the protocol side. It isn't "free", and from an
  | holistic perspective, it's probably a wash. There is also a new cost in
  | terms of fallback failure which comes from having to deal with NOTIMPL
  | responses in downstream agents.

All this would be important, but is irrelevant, because of the more
serious problem, that it simply doesn't work.   (If you were to redefine
it to be "any of A or AAAA" instead of "both of A and AAAA" then it would
work, but wouldn't be very useful).

  | OTOH, the prima benefit is still there,
  | which is that it provides application developers an efficient alternative
  | (from their PoV) to qtype=any.

If it did this, then yes, that would be good.   But I don't think it can,
as there aren't any of those application developers to provide an
alternative to.   Certainly qtype=addr would work as well as qtype=any
(better because of the usually smaller response), but all that says is
that it works as well as something which doesn't work at all.

All the evidence is that use of ANY queries (other than for debugging,
to answer the question, "just what data is in that cache") is falling
from what small favour it had, as people are realising that it doesn't
work.

  | > Yes.   Also the idea of adding A's as additional info on an AAAA query
  | > is attractive.   The RRset rules mean that if you have any A's, you are
  | > able to assume you have the full set.
  | 
  | True for resolvers/servers compliant with 2181, but not earlier.

No.   2181 says it can be assumed.   It might be wrong, but you're
allowed to assume it anyway.   And it is what everyone always did.
That is, ask any cache for the A records for foo.example.com, and if
it has any (complete, incomplete, or super-complete) it will send you
those A records.   It won't go looking to see if there are more.  That
is, it assumes that what it has is the complete set.

It was because of that (and because nothing else is reasonable anyway) that
2181 requires that only complete RRSets be included in responses (and that
responses not be merged).

  | Also, this method relocates complexity to the servers, while *also*
  | preserving it on the API side of the resolver.

True.   It saves some traffic & delays by making the code more complex.
That's not an unusual trade off.

  | This approach has many of
  | the complexities of qtype=ADDR (potential overload, DNSSEC, and so forth),

No, it doesn't.   Additional info has been part of the DNS from the
beginning.   DNSSEC copes (if necessary, by ignoring it and querying
again).

  | and we *still* have to worry about developers issuing queries for
  | qtype=all.

No, we don't have to worry about that, even if we do nothing.  It isn't
happening, and there's no sign of it suddenly starting to happen.   If
the doc that Rob proposed, to explain just why it doesn't work every gets
written, then only someone truly ignorant would try it - their stuff ends
up failing in all kinds of ways, but who cares, we cannot force anyone
(market pressures excepted) from doing anything they like.

  | One more comment for the record, I'm not convinced that qtype=addr is
  | worth the pain, but I know that qtype=any is worth being avoided.

Agree.  And qtype=addr would be worth avoiding too, if it existed.

  | An
  | initial draft has been submitted and should be coming through the pipeline
  | in a day or two, but somebody else will have to do something with it. I'm
  | not going to advocate it. It seems to be a wash.

OK, but I think we can already discard it, don't you?

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 13 Aug 2002 11:34:28 -0500

on 8/13/2002 6:46 AM Robert Elz wrote:

> The issue is that meta queries have other problems (the ones Rob
> Austein pointed out) - there is simply no way to make them work
> properly (assuming that caches still exist - no difficulty if we were
> to do away with cahcing).

See the I-D for the mechanisms used to make it work.

> from what small favour it had, as people are realising that it doesn't

A BCP to this effect would probably be a good idea, then.

A BCP telling people to read BCPs would also be a good idea. :)

> happening, and there's no sign of it suddenly starting to happen.

As any designer of an idiot-proof system can tell you, God can always make
a better idiot.

> OK, but I think we can already discard it, don't you?

I think it bears some exploration. If it proves to be useless and more
trouble than it's worth, it will kill itself.

Let's discuss the I-D and whether or not it will work.