Subject: Re: qtype addr scorecard

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Aug 2002 19:23:50 +0000

> ..., don't you have to upgrade every name server in the resolution
> chain at least to EDNS0 before you can stop worrying about getting
> back RCODE=1 ("Format Error")?

yes.  however, since we expect this to last more than our lifetimes,
it is reasonable to design for (eventual) success.  it's a near thing,
since by the time EDNS1 would fully penetrate the installed base, A RR
queries could be expected to reduce in number since there would be few
non-V6 endstations and the majority of transactions will be satisfied
by a AAAA result.  the thing that tips the balance is the ability to
ask for MX and A and AAAA all together, or some day, A and AAAA and
AAAAAAAA all together.

> So we immediately run up against the question of whether the problem
> we'd be solving is important enough to be worth this kind of upgrade
> effort.

something called EDNS1 is inevitable, from a social perspective.  the
question is: have we found something that makes another crank-turn worth
the effort, or should we wait for more things or bigger things to come
along before turning this crank?  here again it's a near thing, since
something called EDNS2 is also inevitable, from a social perspective,
and EDNS2 will be inclusive of EDNS(n<2).  we could turn the crank every
year and never really miss an opportunity to get more out of the protocol.

> Backing up a bit to a more abstract level in an attempt to start down
> the path towards a crisp problem statement: I think that, broadly
> speaking, we have two choices when talking about the general issue of
> applications that expect to need multiple RRsets with the same owner
> name in quick succession:
> 
> 1) We can take the approach that the application just asks for
>    whatever specific RRset it needs, one RRset at a time, and assume
>    that the DNS caching mechanism will do whatever it does but that
>    optimization of the query process is not the client's problem; or

based on what we see at the root name servers, caching (statistically
speaking) just doesn't happen.  that ought to get fixed.  but i'm betting
that it's more wide spread -- that every authoritative zone, and not just
".", is getting pounded by repeated queries for both existing and non-
existing names.  if we take approach (1) then let's also embark on an
internet-wide crusade to improve dns caching.

> Last, a nit in the current EDNS1 draft: the EDNS1 draft refers to the
> LM flag, which is defined in the EDNS2 draft.  Based on what I think I
> remember of Paul's theory about how the general EDNS framework should
> evolve, I'd guess that this is just an editing oversight rather than a
> deliberate cross dependency, but it would be good to confirm that.

it was an oversight, and was corrected in this morning's published diffs,
which evidently crossed your letter in the post.

--
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: "Eric A. Hall" <[email-masked]>
Date: Wed, 21 Aug 2002 15:43:34 -0500

on 8/21/2002 2:23 PM Paul Vixie wrote:
> yes.

You can avoid this if the cache forms answers by assembling discrete
components. That's how qtype ADDR avoids it. If q1 is cached but q2 is
missing, only fetch q2. With that in place, apps/users only need to
support the query at the local cache. Every other server on the Internet
can refuse to support the query and it won't matter.

There is a hole here that has to be avoided in terms of short TTLs on the
discrete answer sets. If q1 has a ttl of 3 seconds but it takes 4 seconds
to fetch q2, oops got to get q1 now, dang where did q2 go, etc.

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 22 Aug 2002 19:26:47 +0700

Date:        Wed, 21 Aug 2002 15:43:34 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | You can avoid this if the cache forms answers by assembling discrete
  | components. That's how qtype ADDR avoids it.

As I said in a private reply to a private message, but repeat here for
the list - this is optimising the wrong thing.

What happens between client & cache is, in the grand scheme of things,
irrelevant.

None of these schemes are useful unless they work across the net, to the
auth servers.   That's where optimisation is useful (less traffic to the
auth servers, less traffic on the congested wires).

If there's a problem with a local cache, there's an easy answer - just
install another one, we don't need protocol mods to improve that part of
the universe.

kre

---

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

> What happens between client & cache is, in the grand scheme of things,

Which cache? For a query against munnari.OZ.AU, my resolver asks (1) my
local forwarding cache, who asks (2) my resolving cache, who asks (3) the
root, (4) the AU servers, (5) oz.au, and then (6) munnari.oz.au.

The benefit isn't limited to the first-hop pair, but can kick in anywhere
that one of those 6 caches doesn't support the query. The minimum
requirement is for my local forwarding cache to perform this conversion
(it MUST be able to handle the query, or the query won't get used
anywhere). In the best case, all of the boxes can handle it.

In the normal case for the next 10 years, conversion will happen somewhere
in the middle. If the root servers can't handle EDNS1 messages, then it
would happen whenever any resolving cache asked the root servers. If the
root and OZ.AU servers can handle EDNS1 messages, then it would happen
whenever any resolving cach asked munnari.oz.au for info.

> auth servers.

Which this does.

---

From: Rob Austein <[email-masked]>
Date: Thu, 22 Aug 2002 15:09:49 -0400

At Thu, 22 Aug 2002 10:08:49 -0500, Eric A. Hall wrote:
> that one of those 6 caches doesn't support the query.

Your message seems fairly confused about which functions those six
entities support.  I can't tell whether I'm just misreading what you
wrote or you really don't understand this.  If I'm just confused,
please forgive the following.

Let's try using the terminology that's defined in the RFCs to identify
the functions that each entity in this scenario performs.

(1) is the combination of a caching recursive-mode resolver and a
    name server.

(2) is the combination of a caching iterative-mode resolver and a name
    server.

(3), (4), and (5) are just name servers as far as this query is
   concerned, not resolvers at all, and thus have no caches at all.
   I'm quite certain that (3) does not support recursion, I'd be
   surprised if (4) or (5) do, and certainly none of them should.

(6) is either in the same catagory as (3), (4), and (5), or is not
    involved at all, depending on what you mean by "a query against".

So the only caches that should be relevant to this are in the resolver
portions of entities (1) and (2), and at least one of us is seriously
confused about the benefit you think you're seeing.

Last, with all due respect, this QTYPE=ADDR thing just does not work,
because it's a single QTYPE that can match more than one RRset, thus
whenever the name server answering it has an associated caching
resolver, the results you get back will depend on the previous query
history of that resolver.  This is ok for debugging, but not for
operational use.  Thus, while you're certainly entitled to say your
piece, this approach demonstrably will not work, so I don't understand
why you keep bringing it up.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 22 Aug 2002 16:07:31 -0500

>    surprised if (4) or (5) do, and certainly none of them should.

Let me answer this with the qualification that it is not relevant to the
discussion at hand. Depending on the question, one of those servers may
respond. Whether they are supposed to respond or not is a function of the
data they have, their configuration, or their bugs. (3) will indeed return
NS and A RRsets in the answer if this data is available through delegation
knowledge or glue, even though it shouldn't. (4) or (5) might if they were
also configured as secondaries or had similar bugs. I'll demonstrate this
if you want, although I'll do this off-list since it's not relevant.

The discussion is about where in the query chain fallback processing can
happen and the cost of that processing. My point is simply that QDCOUNT>1
can be converted into atomic lookups anywhere in the path, and it can
survive from resolver all the way to an authoritative server without any
conversion being required, but that at a minimum the first-hop cache has
to support it. Actually, upon further though, this latter point is in
error, since the resolver can perform the conversion on its own (see the
last message for details).

> history of that resolver.

Two things. First is that I'm not flogging qtype ADDR other than to use it
as an example of one method for caches to process multiple questions.
Secondarily, your interpretation of its model is erroneous. I'll gladly
clarify this off-list as well, if you wish.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 22 Aug 2002 19:25:38 -0400

Rob Austein wrote:

> operational use.

With all due respect to _you_, Rob, read the draft. Sure, "the results you get
back will depend on the previous history of that resolver", but that's true
for *any* query to a caching resolver (maybe it has a cached answer, maybe it
doesn't; maybe it has a negative cache entry, maybe it doesn't; maybe it has
cached referral information, maybe it doesn't). The plain fact that caches
have "histories" doesn't render the qtype unusable. As the draft specifies,
the caching resolver will, if configured to recurse for the query, fetch
whatever RRset it happens to be missing (A or AAAA), in order to answer the
QTYPE=ADDR question. You seem to be assuming that QTYPE=ADDR will function
identically to QTYPE=* inasmuch as it will automatically be denied recursion
(who decided that QTYPE=* should automatically be denied recursion, by the
way? AFAICT, nothing in the standards -- including the ambiguous
query/response examples in RFC 1034 -- mandates this behavior).
QTYPE=ADDR behaves differently; it's more diligent about fetching missing data
than the current implementations of QTYPE=* resolution algorithms.

Note to Eric: please use the "RRset" terminology in the document, and use it
consistently. I found the "as an individual group" and "cumulative set of
resource records" terms in the the TTL section, for instance, very confusing
until I realized you were talking about separate RRsets and combined RRsets,
respectively. Since you're basically echoing RFC 2181 in that section, it
makes sense to adopt the same terminology used in that document.

- Kevin

---

From: Rob Austein <[email-masked]>
Date: Thu, 22 Aug 2002 23:18:26 -0400

At Thu, 22 Aug 2002 19:25:38 -0400, Kevin Darcy wrote:
> 
> With all due respect to _you_, Rob, read the draft....As the draft specifies,

Oh.  You're right, I assumed that its behavior was similar to *,
MAILA, and MAILB, because that's what I thought Eric had said on the
list.  My oops.

> query/response examples in RFC 1034 -- mandates this behavior).

QTYPE=* doesn't disable recursion, it just stops as soon as it finds
anything that matches, which is not quite the same thing.

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Aug 2002 03:11:25 -0400

> internet-wide crusade to improve dns caching.

I know that:

- we have hard data on the unbelievable amount of garbage that hits
  the root name servers;

- we have theoretical work attempting to demonstrate that caching of
  leaf data (not delegations) is most useful (for web browsers) in
  the first ten or twenty minutes after being cached; and

- we're pretty sure that negative caching is under-utilized;

but do we really have data to suggest that caching isn't happening at
all on any significant scale?  If so, it's news to me, please share. :)

The thing about the above breakdown is that most of the traffic either
comes from bad practice (whether coding or operational) or from
traffic patterns that don't cache well, so it's not clear that an
optimization to the query process is going to help that much.

Improving DNS caching Internet-wide sounds like a worthy goal in any
case.

---

From: Robert Elz <[email-masked]>
Date: Fri, 23 Aug 2002 14:31:38 +0700

Date:        Thu, 22 Aug 2002 16:07:31 -0500
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The discussion is about where in the query chain fallback processing can
  | happen and the cost of that processing. My point is simply that QDCOUNT>1
  | can be converted into atomic lookups anywhere in the path, and it can
  | survive from resolver all the way to an authoritative server without any
  | conversion being required, but that at a minimum the first-hop cache has
  | to support it.

yes, but you keep missing the point.   All of this is possible, what matters
is the cost, and whether it is likely to be a benefit or not over the
life of the proposal.

The analysis of this is completely different for ADDR and for EDNS1.
ADDR is useful only while A records remain alive.   That is, the net
benefit from using it must outweigh the deployment costs.

As I showed in another message (which may have been off list, so readers
other than Eric,  & maybe Greg, might not have seen it), early in its
deployment, ADDR costs more than doing nothing.   It can double the delay
and add 50% to packet counts.   If we reach a stage where most of the net
supports ADDR, then it can save 50% of the packet costs (no delay savings
of note).

Once A vanishes, ADDR starts costing more than not having it again, though
at a smaller rate that is harder to calculate (it's because negative caches
time out faster than positive ones).   If there was no ADDR, clients by
then would be just doing AAAA as in general, all they care about is an address,
very few actually want both - the dual query is a transition mechanism to
find AAAA when it exists, but fall back to A when it doesn't.   When A is
vanishing, one presumes just about everyone will have AAAA, so the AAAA
query would return an address, and no A query would be wanted.   But if
ADDR is being used, no-one can assume that, the cache still has to go hunting
for the non-existing A records.

So, we have a period of increased costs, a period of benefit, and then
forever after, increased costs.   The period of benefit would have to be
a HUGE benefit to make this a worthwhile - and it isn't.

So, can we just forget ADDR, forever, please?

  | First is that I'm not flogging qtype ADDR other than to use it
  | as an example of one method for caches to process multiple questions.

A job which its special nature makes it particularly bad at.

EDNS1 on the other hand doesn't have these problems - the client gets to
specify the actual data wanted, and the FM flag means that the (very common)
"I only need this other record if the first one doesn't exist" semantic
can be processed (for the AAAA & A case, the cache only needs the AAAA
records, if they exist, it never needs to bother with A records, in the
common client query of "Give me AAAA if they exist, otherwise A".)

We still need to evaluate the costs of EDNS1 vs its benefits.   Just as
ADDR, it increases delay & packets while it is being deployed.   And then
it can descrease packets while it is in use.   But it has no end point,
there's no point after which it starts costing more again.   And it has
more general applicability, so this one isn't as easy to just write off
as useless.

I appreciate Rob Austein's point - just let the cache's do the work, and
if the multiple queries in EDNS1 didn't have the FM capability, but always
requested all the answers, I think that would sway me.

But it is real hard to do a "a or b or c" (as in MX, or AAAA, or A)
query using the DNS without excessive delay, or excessive waste (the
queries are either serialised, in which case you have 3 RTTs to get a
useful answer, or sent in parallel, in which case you get all three answers,
and in many cases, discard 2 of  them - wasted work for the server, and
for the network).

On balance, I think EDNS1 is worth the deployment pain, and increased
usage costs while that is happening.

kre

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Aug 2002 08:02:53 +0000

> all on any significant scale?  If so, it's news to me, please share. :)

the data at hand indicates that a great number of people do not cache
referrals, either positively or negatively.  i've provided several
(anonymized) tcpdumps to caida over the years, so let's ask them to
comment.

> optimization to the query process is going to help that much.

i completely agree.

> Improving DNS caching Internet-wide sounds like a worthy goal in any case.

yes indeed.  but it'll receive no real attention unless one of two
things happens.  (1) one more person comes forward with a design proposal
of the form "we don't need to do that because caching will take care of it"
or (2) the amount of rejected repeated useless query traffic at some root
server exceeds 1 gigabit per second.  (both of those things will happen
within my lifetime, unless i miss my guess.)

---

From: Randy Bush <[email-masked]>
Date: Fri, 23 Aug 2002 08:08:04 -0700

> all on any significant scale?  If so, it's news to me, please share. :)

hari's work at mit said the opposite, yes?  sorry, their server
is rejecting me this morning, so no url.  but there was even a
presentation at dnsops a bit ago.

randy

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 23 Aug 2002 14:21:48 -0400

> anything that matches, which is not quite the same thing.

A minor semantic distinction. It *could* recurse the QTYPE=* query if it wanted
to. It chooses not to. In this context, has it "disabled recursion" (perhaps
"declined" would have been a better word choice) or is recursion unnecessary? It
can be viewed either way.

(Obviously, it would behoove any implementation that would actually consider
recursing a QTYPE=* query to keep track of whether it already has an intact,
no-RRsets-expired answer to a previous QTYPE=* query for the same name, since in
that case it can answer from the cache just like it would for a normal QTYPE).

- Kevin

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Aug 2002 14:26:36 -0400

> presentation at dnsops a bit ago.

Jaeyeon Jung's slides from the DNSMEAS BOF in the proceedings from the
Salt Lake IETF suggest a DNS cache hit rate of 80%-86% at MIT.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 23 Aug 2002 19:02:40 +0000

> Salt Lake IETF suggest a DNS cache hit rate of 80%-86% at MIT.

that's great but we need to know the impact on authority servers
not just the hit ratio of caching recursive forwarders.

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Aug 2002 17:37:00 -0400

> not just the hit ratio of caching recursive forwarders.

That is indeed a different study, and as far as I know it isn't one
that anybody has performed.  Work to date has concentrated on the view
from the client, the view from the root, and performance.

If somebody with a seriously-high-traffic name server two or more
levels down the tree wanted to work with some researcher who had time
and funding to look into this, it might be a good thing.

TLD data would also be interesting, but weirdness factors at TLD name
servers, while not as high as at root name servers, might still be
high enough to complicate interpretation of the data.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 28 Aug 2002 13:12:56 -0400

At 04:02 AM 8/23/02, Paul Vixie wrote:
>  (2) the amount of rejected repeated useless query traffic at some root

Out of curiosity, what is the current amount of query traffic on F? And
what is the percentage of useless query traffic out of the total traffic?

Danny