Subject: !! DANGER -- POTENTIAL FUD -- DANGER !!

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 18:35:04 -0500

on 8/7/2002 6:03 PM Eric A. Hall 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.

It occurs to me that an easy prevention against this potential problem
(OKAY ITS FUD, SHEESH) would be define a new query-type for addresses,
similar to the old MAILA and MAILB qtypes. Rather than issue two queries
for AAAA plus A, and rather than issue a qytpe=ALL, v6-aware applications
could issue the qtype=ADDR (or whatever). More efficient.

-- 
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: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 19:41:01 -0400

> could issue the qtype=ADDR (or whatever). More efficient.

Why is this FUD?  This is an interesting proposal..  I'm not sure if
it is reasonably implementable, but it's still interesting.  In
particular, I don't know what kind of failure characteristics this
would have.  Is there a preference of AAAA over A?  Would it imply
that if no AAAA exists you would have to provide the NXT to prove
it?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 07 Aug 2002 19:19:58 -0500

on 8/7/2002 6:41 PM Derek Atkins wrote:

> what kind of failure characteristics this would have.  Is there a
> preference of AAAA over A?

I would think that the application would determine its own preference for
the returned data.

The big concern is with caches. They would have to be limited somewhat.
For example, they couldn't answer the query with cached data unless they
had positively absolutely passed another qtype=addr or distinct qtype=A
and qtype=AAAA queries. Otherwise, they could return any A RRs which had
been cached but not AAAA RRs (or vice versa), resulting in an incomplete
and erroneous view of the complete answer, thereby causing the client to
make the wrong decision.

> Would it imply that if no AAAA exists you
> would have to provide the NXT to prove it?

I disclaim any expertise on DNSSEC.

---

From: Derek Atkins <[email-masked]>
Date: 07 Aug 2002 20:28:16 -0400

> I would think that the application would determine its own preference for

So the qtype=addr would have you return _ALL_ data, both AAAA and A?
Couldn't that be a rather large response?  If not, then how does the
_server_ know which type to prefer in the response?

> and erroneous view of the complete answer, thereby causing the client to

Caches are already going to have to do this for proper NXT processing.

> I disclaim any expertise on DNSSEC.

Well, you (in general, not Eric Hall specifically) need to think
about how it would interact with DNSSEC.

-derek

---

From: [email-masked]
Date: Thu, 08 Aug 2002 09:52:28 +0900

>> doing it once we have IPv6 applications that query for qtype=any instead

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

tojun

---

From: Rob Austein <[email-masked]>
Date: Wed, 07 Aug 2002 23:24:39 -0400

> that if no AAAA exists you would have to provide the NXT to prove

It's not FUD, but I don't think it works: if there's more than one
distinct RRset that can satisfy a particular query, you can't predict
which RRset(s) you're going to get back in the response unless you're
talking to the authoritative server.  Additional section processing
doesn't count, since in all but a few (reasonably well-understood)
cases the additional section is just an efficiency hack and one can
just query explictly for whatever one might have wished to find there.

This is basicly the same problem as we have with QTYPE=*, hence the
occasional reference you might see in old namedroppers archives to
MAILA and MAILB as "semi-wildcards".

---

From: Markku Savela <[email-masked]>
Date: Thu, 8 Aug 2002 09:01:20 +0300

> From: Derek Atkins <[email-masked]>

> _server_ know which type to prefer in the response?

Just a thought occurs...

Instead of having a new query type 'addr', could we just define that
AAAA query returns both IPv4 and IPv6 addresses? (And if you want
uniform format in reply, put IPv4 addresses into IPv4 mapped format)

Unfortunately, due to already existing implementations of AAAA in
servers, resolvers would always have to do the A query too (if AAAA
doesn't have any IPv4 addresses), but if it did, then it could
consider it a "new AAAA" reply and skip A.

---

From: "Kandra Nygards" <[email-masked]>
Date: Thu, 8 Aug 2002 10:25:17 +0200 (CEST)

> uniform format in reply, put IPv4 addresses into IPv4 mapped format)

If I ask for MX, I want MX as the response. If I ask for AAAA, I want AAAA
in the answer. An option could be to respond to AAAA-queries with A in the
additional section, but that might also not be desirable, depending on
your milage.

Best regards,
Kandra Nygards

---

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.

---

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: [email-masked]
Date: Fri, 09 Aug 2002 01:42:03 +0900

>developers who don't know what they're doing, and can't be bothered to 

	for this reason we have RFC2553.

itojun

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 08 Aug 2002 11:50:27 -0500

on 8/8/2002 11:35 AM Ted Lemon wrote:
> 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.

That might solve one problem, but not the one I'm worried about.

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

Requiring applications to issue 2x the queries (until the majority of
nodes have AAAA RRs) doesn't help anybody. Consider also that negative
caching has different ramifications (typically shorter TTLs) which mean
that the first query (failure) will get passed along more often. An ADDR
qtype can help against these potential problems somewhat.

So even if everybody learned the lesson (yeah right), there are other good
reasons to do it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2002 12:45:56 -0500

> qtype can help against these potential problems somewhat.

Nobody, so far, has agreed with you that ANY is a good thing for 
applications to use.   Several people who I think know what they are 
talking about have said that it is not.   Applications that used to use it 
no longer do.   So if your goal is to convince us of anything, you can't 
use the idea that applications need ANYas a basis for your arguments.

Honestly, I think you are getting into optimization mentality here - you 
see a way to do things "more efficiently", and you want to use it, even 
though you don't have any practical experience that says that your 
optimization is actually a win.   I do this all the time.   It makes for 
complicated and unreliable code.   The best way to do start is to implement 
things the "stupid" way, and optimize if you see that there's a problem.   
The evidence suggests that there's no problem here.

---

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

on 8/8/2002 12:45 PM Ted Lemon wrote:
>>  nodes have AAAA RRs) doesn't help anybody. Consider also that
>> negative caching has different ramifications (typically shorter TTLs)
>> which mean that the first query (failure) will get passed along more
>> often. An ADDR qtype can help against these potential problems
>> somewhat.
>
> applications to use.

I haven't said so myself.

This doesn't mean I don't think people won't do it. History clearly shows
otherwise.

> Honestly, I think you are getting into optimization mentality here -
> you see a way to do things "more efficiently", and you want to use it,
> even though you don't have any practical experience that says that your
>  optimization is actually a win.

Are you saying that there is no experience indicating that fewer queries
are better?

---

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: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2002 13:38:18 -0500

> Are you saying that there is no experience indicating that fewer queries

No, I'm saying that there is no experience that suggests that using ANY to 
reduce the number of queries is better.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 08 Aug 2002 13:45:44 -0500

on 8/8/2002 1:38 PM Ted Lemon wrote:
>> Are you saying that there is no experience indicating that fewer
>> queries are better?
>
> No, I'm saying that there is no experience that suggests that using ANY
> to reduce the number of queries is better.

Do you think I'm advocating such?

[hint: the subject is "qtype: addr" not "qtype: any"]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2002 14:07:44 -0500

> [hint: the subject is "qtype: addr" not "qtype: any"]

Unless I've just been off in space-cadet land, you've been saying that 
storing application keys in the DNS is wrong, because it means that a query 
of type ANY will no longer be possible for names with lots of keys.   I 
think that the ADDR query type is a bandaid, not a solution, but that's 
another debate.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 08 Aug 2002 14:35:03 -0500

on 8/8/2002 2:07 PM Ted Lemon wrote:

> storing application keys in the DNS is wrong, because it means that a
> query of type ANY will no longer be possible for names with lots of
> keys.

That was one reason cited against willy-nilly RRs (specifically in
response to "other protocol data" and not to keys, but I didn't make that
clear, so fair play). Lots of RRs force retries for applications that do
qtype=any, there are plenty of deployed apps that do qtype=any (popular
apps anyway), and there will probably be a lot more of them. I'm not
advocating these apps, I'm using them as an example of harm caused from
excessive RRs.

FWIW, hotmail.com overflows even if you only ask for MX and get a full
answer (including all NS and glue). Mark mentioned excess PTRs as a source
of TCP overflow problems. So too many of one RR causes problems even for
applications that do the "right" thing. [Lord, please don't let this turn
into another strawman of me being against MX!]

There are other reasons, already mentioned. My opinion should be obvious,
that we need to be really conservative with this stuff. Even my dual-mode
i18n DNS work focuses on collapsing names into a canonical form for
storage, and avoids 2x storage and queries wherever possible.

Frankly, I am more concerned with large uses. A billion phones looking for
a billion phone numbers in the DNS is not going to be healthy. People talk
about storing user data in the DNS from time to time, as if defining and
replicating user-specific ACLs for RRs is no big deal. People talk about
having DNS be a PKI, with all that it implies.

The small stuff adds up too, you know.

---

From: Markku Savela <[email-masked]>
Date: Thu, 8 Aug 2002 23:05:10 +0300

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

> a billion phone numbers in the DNS is not going to be healthy.

Yes, phones will ask AAAA and/or A.

Please, raise hand if *anyone* knows dual IPv4+IPv6 implementation
which actually chose to do qtype=ANY instead of specific A and AAAA?

I'm surprised (horrified) if I see any hands! :-)

---

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

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