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

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 12 Nov 2017 09:28:35 +0800

[About -00]

Excellent idea, I strongly support the project.

I intend to use it to register 451 for DNS censorship
<https://labs.ripe.net/Members/stephane_bortzmeyer/dns-censorship-dns-lies-seen-by-atlas-probes>,
following RFC 7725. (I'm serious.)

> This document discusses extended *errors*, but it has been suggested
> that this could be used to also annotate *non- error* messages.  The
> authors do not think that this is a good idea, but could be
> persuaded otherwise.

Why is it a bad idea? I would appreciate some elaboration.

> It can be included in any error response (SERVFAIL, NXDOMAIN,
> REFUSED, etc)

It can be argued that NODATA (pseudo rcode, I know) is an "error" as
well as NXDOMAIN...

> Usually attached to SERVFAIL messages.

This raises an interesting point. Should extended error codes be
limited to a specific rcode? For instance "Extended error code 100
MUST be used only with SERVFAIL"?

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Nov 2017 12:36:57 +0000

> It can be argued that NODATA (pseudo rcode, I know) is an "error" as

Or, neither of them are errors :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Biscay: North 4 or 5 becoming variable 3 or 4. Moderate, occasionally rough at
first in south. Fair. Good.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 13 Nov 2017 18:02:11 -0800

> Or, neither of them are errors :-)

We'll remove the restriction in any wording that says it can only be for
errors.  I think there is clear consensus to do so.
-- 
Wes Hardaker
USC/ISI

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Nov 2017 07:32:27 +0000

> errors.  I think there is clear consensus to do so.

For the record, I'm with Tony, neither NODATA nor NXDomain are DNS
lookup errors.  Lack of answers may (or may not) lead to
application-level errors depending on whether the data sought was
functionally essential, but either way the DNS lookup was successful,
and returned the status of the requested RRset.

This is, for example, important with opportunistic DANE TLS, where
actual lookup errors are potential downgrade attacks, but NODATA
and NXDomain are not lookup errors.

And indeed unlike actual errors, there is nothing one could possibly
add in the form extended "error" diagnostics when returning a NODATA
or NXDomain response, these non-error conditions don't require any
additional context to aid problem resolution.

-- 
	Viktor.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 14 Nov 2017 07:56:00 +0000

Viktor,

> additional context to aid problem resolution.

Be careful when you say "nothing ... possibly". ;)

For example, you could have something like:

RCODE: SUCCESS (NODATA)
Extended code: ERRBLACKLIST
Explanation: "Client blacklisted for IPv6 queries"

This could be helpful for a user or operator. (Of course, it also hints
that being able to add arbitrary text to an error may be useful, as
including a URL with more information in the response might provide
further insight. But perhaps having Google is enough that this is not
necessary?)

Cheers,

--
Shane

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Nov 2017 08:47:25 +0000

> Explanation: "Client blacklisted for IPv6 queries"

Well, once we're in the "lying with DNS" business, we hardly need
to restrict extended diagnostics to errors, we can equally contemplate
them for policy-based answers that don't reflect the authoritative
zone content... :-8

-- 
	Viktor.

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Nov 2017 16:54:15 +0800

On Nov 14, 2017, at 16:47, Viktor Dukhovni <[email-masked]> wrote:

You make it sound like "lying with DNS" is some future thing and not
something that happens right now, 500,000 times per second!

I think it's fair to clarify that we're not talking about extended errors
any more but rather extended RCODEs or something, if that's what we are
doing.

I don't think it's sensible to say absolutely that there will never be a
need to disambiguate NXDOMAIN or NOERROR since never is an awfully long
time, and who knows or dares to dream?

Joe

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Nov 2017 01:06:46 -0800

Joe Abley wrote:
> ...

that outcome depends on scope. if you imagine a protocol speaker 
behaving differently based on fine-grained differences in cause that 
relate in small ways to the larger NXDOMAIN/NOERROR status code, then i 
think we should not allow for that -- it would be madness, even compared 
to the present day.

if you believe that it will appear in "dig" output and syslogs and 
dnstap traces, so as to help diagnosticians and academicians decide the 
whichness of what, after the fact, then i agree, we should not prohibit 
the fine detail just because we think the gross details are obvious.

-- 
P Vixie

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Nov 2017 17:32:13 +0100

On Tue, Nov 14, 2017 at 08:47:25AM +0000,
 Viktor Dukhovni <[email-masked]> wrote 

> them for policy-based answers that don't reflect the authoritative

May be you were joking but I'm serious and I think it would be a good
idea. For instance, extended "error" codes for "This is not the real
IP address, I lied to protect you from malware/pedoporn/terrorism"
would be very useful (see RFC 7725).