Subject: app-layer acks in DNS

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 04 Apr 2002 20:12:57 -0600

As we all know, DNS doesn't provide any kind of application-layer
flow-control or acknwoledgements. Queries either succeed or they fail, and
the outcome is only reported when processing either succeeds or fails.
However, there will often be multiple intermediate events between the
final success or failure.

Q: Would notifications about these transitional events be a bad thing?

More specifically, consider the following example. A stub resolver issues
a query to its local caching server, and as far as the stub is concerned,
the query has gone into a black-hole. Meanwhile, the cache is generating
bunches of queries, following referrals, chasing down CNAMEs, and so on.
While all of this is happening, the stub is twiddling its thumbs,
completely oblivious to everything. Given enough time, the stub will just
assume failure and then go ask another server, and that server has to go
beat up the network all over again.

Clearly there would be some benefit to having the cache tell the stub "got
some of your data, I'm on the case, hold for N seconds". The question is
whether or not the amount of extra processing and messaging load would be
a bad thing.

Thoughts?

-- 
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: Allan Liska <[email-masked]>
Date: Thu, 4 Apr 2002 22:40:05 -0500

Hello Eric,

Thursday, April 04, 2002, 9:12:57 PM, you wrote:

EAH> Clearly there would be some benefit to having the cache tell the stub "got
EAH> some of your data, I'm on the case, hold for N seconds". The question is
EAH> whether or not the amount of extra processing and messaging load would be
EAH> a bad thing.

EAH> Thoughts?

Without some sort of session tagging, how would the stub know which
record the cache is talking about?

I also wonder how often this is a problem?  I don't see too many DNS
queries that take more than 30 seconds.  If this is a problem, I think
it would make more sense for the cache to just give the stub the
information as soon as it is found during the recursive query, and
then continue with the rest of the query.

allan
btw: I think Internet Core Protocols is a great book.
-- 
allan
[email-masked]
http://www.allan.org

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 04 Apr 2002 22:19:07 -0600

> record the cache is talking about?

Well, I was thinking that the cache would return the Question section, the
flags, and an RCODE for "chasing" or whatever.

> I also wonder how often this is a problem?

I don't think it's much of a problem now, but I am wondering about future
issues. In particular, if a cache gets in the habit of validating DNSSEC
signatures on all referrals and answers then the overall latency will go
up. Also, if a cache has to do multiple conversions between label formats
(eg, between UTF-8 and ACE encodings) then latency will go up. If both of
those happen plus a remote CNAME plus umpteen levels deep, well, you get
the idea. Sooner or later all of this latency is likely to mean that
clients will be timing out more often.

I also think it is a good design point, although I'm not sure to what
degree the cost would be worth the benefit. Clearly returning an update
message for every referral would be too much noise.

> I don't see too many DNS queries that take more than 30 seconds.

RFC 1035 specifies a default timeout of 5 seconds. MS clients use a
default timeout of 1 second.

Five seconds is too high IMO. If a simple query is going to fail it will
fail within a couple of seconds. On the other hand, the 1 second failure
threshold is way too low. I think that the timeouts could be made less
painful if there was a way to improve feedback.

But the real concern I have is with tripping timeouts period.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 5 Apr 2002 09:37:32 -0500

Personally, I think this is off-topic for this mailing list.  I don't mean
that as a "squelch this discussion" comment, but rather that this subject
is a huge paradigm shift away from DNS as we know it.

It makes me even think back to X.500 and ldap - a division of labor in the
name space service.  This also makes me think over the middlebox comment
made by Rob a few weeks ago when we were talking about how involved a name
server should get when "editing" a zone (e.g. dropping expired signatures).

I would hold the thoughts about app-layer acks for a time when we seriously
think about a new name service.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 05 Apr 2002 09:55:06 -0600

Edward Lewis wrote:

> I would hold the thoughts about app-layer acks for a time when we
> seriously think about a new name service.

Couple of things. First is that the UTF-8/ACE conversions only work when
one of the query formats fail, so they use 2 round-trips to succeed. This
is the latency equivalent of an extra delegation, so its not an infinite
amount of time, but given multiple conversions, it can easily trigger a
timeout on the client. From that perspective, some sort of "chasing" RCODE
is going to be necessary sooner rather than later. Second is that we can
define these RCODEs as EDNS values, which for all practical purposes makes
them "new name service" messages as far as legacy systems are concerned.

I suppose that I'm really just wondering if these messages should become
mainstreamed for other uses.