Subject: Re: [DNSOP] draft-ietf-dnsop-extended-error code options

From: tjw ietf <[email-masked]>
Date: Mon, 13 Nov 2017 18:43:34 +0800

To follow up from the meeting this morning,  it sounded from the room that
in the case of these
four options, #4 was the one which makes the most sense.

tim

On Tue, Oct 17, 2017 at 6:39 AM, Wes Hardaker <[email-masked]> wrote:

>
> Folks,
>
> We were given feedback during the call for adoption to "use numeric
> range codes like those in HTTP".  Following that, Warren and I sat down
> and came up with some possibilities and would like your feedback about
> which of these options you would prefer:
>
>   1. Individual codes assigned one at a time, per the existing doc
>
>   2. HTTP like: integer ranges where NNYY indicates the NN integer rcode
>      and YY indicates the sub-code.  Note that this needs a 32 bit error
>      code field.
>
>   3. Use a 16 bit error code field, with the 16 bits differ per rcode.
>      Thus, clients would need to use the combination of rcode and error
>      code to determine the error.
>
>   4. 32 bit code field, repeating rcode from elsewhere in the packet
>      Like #2, but copies the rcode directly into the error code header
>      within the extended-error component of the packet.  Redundant but
>      clear that the entire 32 bits are needed.
>
> Thoughts?
>
> --
> Wes Hardaker
> USC/ISI
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Geoff Huston <[email-masked]>
Date: Mon, 13 Nov 2017 22:01:30 +1100

> On 13 Nov 2017, at 9:43 pm, tjw ietf <[email-masked]> wrote:
> 
> To follow up from the meeting this morning,  it sounded from the room that in the case of these 
…..

>      clear that the entire 32 bits are needed.

errr - what would it mean if the rcode in the error code header differed
from the rcode value in the extended-error component?

The issue with duplicated information in a packet is that you then have
add even further consideration to cope with the cases where the expected
thing did not happen.

Not exactly blown away by #4 myself.

Geoff

---

From: Ray Bellis <[email-masked]>
Date: Mon, 13 Nov 2017 20:54:16 +0800

> Not exactly blown away by #4 myself.

Would it be feasible to reserve a standard RCODE value in the header
that just means "see extended error"?

It has always kinda surprised me that the EDNS RCODE didn't work that
way, instead of the current situation where if you only read the bottom
4 bits of the extended 12-bit code you could completely misinterpret the
status (e.g. treat BADVER[16] as NOERROR[0], since the bottom four bits
are all zeros for both).

Ray

---

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

> that just means "see extended error"?

That would require client-to-server signalling, and the server would be
unable to simply unconditionally include the extended error in the OPT
record.

> status (e.g. treat BADVER[16] as NOERROR[0], since the bottom four bits

There can only be an EDNS RCODE if the client sent an EDNS OPT; if the
client forgot it sent the OPT then it's too broken to worry about.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire: Northwesterly, backing southerly for a time, 5 to 7, decreasing
4 for a time. Moderate or rough. Rain for a time. Good, occasionally poor.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 13 Nov 2017 21:16:57 +0800

On 13/11/2017 21:13, Tony Finch wrote:
>> Would it be feasible to reserve a standard RCODE value in the
>> header that just means "see extended error"?
> 
> That would require client-to-server signalling,

It would.  Perhaps the *request* RCODE could contain the same value to
signal acceptance of the extended version in the response ?

> and the server would be unable to simply unconditionally include the
> extended error in the OPT record.
> 
> There can only be an EDNS RCODE if the client sent an EDNS OPT; if
> the client forgot it sent the OPT then it's too broken to worry
> about.

Indeed - unsolicited EDNS OPT RRs aren't legal in responses.

Ray

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Nov 2017 05:19:30 +0800

Hi Geoff,

I think the number 4 on the slide was different from the one in the mail.

The option on the slide that I mentioned I liked the most was the one that didn't copy the RCODE value from the header, but in effect provided a 16/32/whatever-bit sub-code for whatever the RCODE happened to be.

So, for each permissible value of the RCODE field, this new field would provide additional information that was relevant to that value.

Compared to the other options presented, this avoids having to specify behaviour for all the unhelpful corner cases of RCODE in message header doesn't match the copy in the new field, new field value (e.g. "validation failed" or something) doesn't make sense for this particular RCODE (e.g. "NOERROR"), etc.

Joe

> On Nov 13, 2017, at 19:01, Geoff Huston <[email-masked]> wrote:
> 
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 14 Nov 2017 08:37:55 +1100

> On 14 Nov 2017, at 8:19 am, Joe Abley <[email-masked]> wrote:
> 
> Hi Geoff,
> 

I thought so too, but I wasn’t sure if it was me not paying attention in the WG meeting or not!

> The option on the slide that I mentioned I liked the most was the one that didn't copy the RCODE value from the header, but in effect provided a 16/32/whatever-bit sub-code for whatever the RCODE h…

and that makes sense to me, considering my perspective of the risk associated with duplication of protocol field values

> Compared to the other options presented, this avoids having to specify behaviour for all the unhelpful corner cases of RCODE in message header doesn't match the copy in the new field, new field val…

thanks Joe,

   Geoff

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Nov 2017 09:30:49 +0800

On Mon, Nov 13, 2017 at 08:54:16PM +0800,
 Ray Bellis <[email-masked]> wrote 

> that just means "see extended error"?

First reaction: no. Middleboxes would block these responses, or old
clients would not know what to do with it.

---

From: George Michaelson <[email-masked]>
Date: Tue, 14 Nov 2017 09:37:48 +0800

Stephane, I don't entirely understand your response. old systems can
never understand new code point assignments, or know what to do with
it, no proposed change can alter this. Middleboxes dropping unexpected
things will hit almost any proposed modification of packets in flight.

Basically, I don't think any proposed modification of DNS in this
space can be done, which doesn't face this risk: therefore, I don't
see it having directing force.

If there is some trick to doing something which doesn't expose the
risk, What is it?

cheers

-George

---

From: Joe Abley <[email-masked]>
Date: Tue, 14 Nov 2017 09:48:28 +0800

> things will hit almost any proposed modification of packets in flight.

The implication is, I think, that some new code points are more likely to survive the attention of Sauron's Middleware than others.

We have seen claims in the past that new RRTYPEs, new EDNS(0) options, new EDNS(i) with i > 0, new records in ADDITIONAL sections, etc that will all fall fail of middleware or other dependent systems. What's not clear is the relative impact of each, but it seems intuitively true that the impact of each is probably not the same.

For example, I bet it's more practical to implement a new EDNS(0) option than it is to deploy EDNS(1), but I have no science to back up that intuition.

If only there was some kind of research group adept at wide-scale measurement from the end-user perspective that could shed some light on this!

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Nov 2017 09:56:31 +0800

On Tue, Nov 14, 2017 at 09:48:28AM +0800,
 Joe Abley <[email-masked]> wrote 
 a message of 24 lines which said:

> The implication is, I think, that some new code points are more
> likely to survive the attention of Sauron's Middleware than others.
...
> it seems intuitively true that the impact of each is probably not
> the same.

Exactly. Thanks for a better wording of my concern.

> If only there was some kind of research group adept at wide-scale
> measurement from the end-user perspective that could shed some light
> on this!

There is such a research group, it's called Geoff Huston.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Nov 2017 14:05:52 +1100

> On 14 Nov 2017, at 12:48 pm, Joe Abley <[email-masked]> wrote:
> 

Only marginally.  Both are deployable between recursive server and authoritative.
It’s easy enough to detect mis-implementations and fallback though one shouldn’t
have to do that.

If Amazon (bad EDNS version negotiation), GoDaddy (bad EDNS flags handling)
and Microsoft (bad EDNS version negotiation, bad EDNS options) would fix their respective
DNS server farms we would have much improved error rates.  Amazon, GoDaddy have
removed the firewall entries that were dropping the test queries since testing started.
I can’t remember if Microsoft was blocking queries.

Amazon’s mis-implementation needs to be fixed before they start serving any signed
zones as the answers to EDNS(1) queries appear as if they come from a server that
doesn’t support EDNS at all (no opt record returned).

18f.gov. @205.251.192.110 (ns-110.awsdns-13.com.): dns=ok edns=ok edns1=noerror,noopt,soa edns@512=ok ednsopt=ok edns1opt=noerror,noopt,soa do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok
29palmsbomi-nsn.gov. @208.109.255.45 (ns70.domaincontrol.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=mbz optlist=ok,nsid signed=ok ednstcp=ok
boimi.gov. @64.4.48.6 (ns2-06.azure-dns.net.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok

http://ednscomp.isc.org/compliance/summary.html

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Nov 2017 16:40:09 -0800

> in the WG meeting or not!

Yes, you're both right.  And absolutely my bad for writing the
presentation without looking at the mail I sent and synchronizing the
numbering.

The preferred option in the room was the 16-bit value that would be used
in combination with the rcode to indicate the full meaning of the
extension value.
-- 
Wes Hardaker
USC/ISI

---

From: tjw ietf <[email-masked]>
Date: Wed, 15 Nov 2017 08:58:30 +0800

Actually Wes, it was absolutely bad for me making the poor assumption on
the choices aligned between the email and the slide.

You are correct the preferred option we hear as the 16 bit value.