Subject: [DNSOP] draft-ietf-dnsop-extended-error status

From: Wes Hardaker <[email-masked]>
Date: Fri, 27 Sep 2019 16:39:11 -0700

I've gone through everyone's (wonderful) comments and have addressed
almost all of them, and published a -10.  Please let me know if you
think I missed anything.  Responses to the comments will be sent out
shortly.

(and sorry for the delay on this ; day-job hit me over the head hard in
the last three weeks )

Two outstanding topics:

1) A number of people have suggested adding references to other
RFCs/documents to many of the error codes.  This is probably a good
idea.  A beer or other drink in Singapore to anyone willing to do the
work to give me a list of references to add for each code.

2) One outstanding topic of discussion that I think we need to decide to
handle or table till a future document: how do we handle forwarding,
chained resolvers, and caching.  Puneed brought this up most recently in
his comments.  In the past we've pseudo-agreed that it will be rather
complex to document how to handle forwarding, etc, when some of the
error context will change upon a forward, for example.  IE,
forwarding/caching/whatever rules may end up being code specific and may
require a *lot* more thought.  So, IMHO, we have choices:

A) Label these situations as "undefined behavior" and define it in a
future document after we get more experience with deployment.  This is
typically where I've landed opinion-wise in the past, and still do
mostly now.

B) Document globally how to handle various cases (and we'll need to
enumerate them)

C) Document how to handle each one independently (or as an override if
needed to a global policy)

D) Your option here

So really, this first comes down to how important is it we handle this
case set before it goes out the door?

-- 
Wes Hardaker
USC/ISI

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Sep 2019 12:54:08 +0100

Wes Hardaker <[email-masked]> wrote:
> chained resolvers, and caching.

Difficult. In general there will be multiple upstream servers, even in
the simplest case of a stub talking to a recursive server talking directly
to authoritative servers. So there can be an arbitrary combination of
upstream errors, and they might not relate directly to the QNAME, (e.g.
problems with a parent zone, problems chasing down nameserver addresses).

Perhaps if the upstream problems are consistent with each other, the
resolver can return a single extended error code to its client; otherwise
fall back to a "multiple errors" catch-all?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin: East backing northeast 5 to 7. Moderate or rough. Showers. Good.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Sep 2019 17:47:33 -0400

> problems with a parent zone, problems chasing down nameserver addresses).

RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) speaketh thusly:

"EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is
negotiated between each pair of hosts in a DNS resolution process,
for instance, the stub resolver communicating with the recursive
resolver or the recursive resolver communicating with an
authoritative server."

and also sayeth:
"OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from
master files."

I *think* that this covers the issue for many cases; EDE is not
intended to be a silver bullet, more something which provides useful
information for troubleshooting / debugging.
We would not (and cannot :-)) preclude other work from further
defining this, but I think that it's beyond the scope of this document
/ we will better be able to understand things once we've had some
deployment experience.

Thank you,
W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf