Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

From: Tim Wicinski <[email-masked]>
Date: Wed, 24 Oct 2018 08:41:38 +0200

Hi

We've been talking with the authors of Extended Error and now that
they've gotten around to updating the document, and the chairs
feel it is ready for Working Group Last Call.

We're going to kick this WGLC off this week and run it through IETF103.
This will give folks time during the meeting to bring up any issues
they may have there.

This starts a Working Group Last Call for draft-ietf-dnsop-extended-error

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

The Current Intended Status of this document is: Standards Track

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication,
please speak out with your reasons.

This starts a two+ week Working Group Last Call process,
and ends on at the end of IETF 103: 9 November 2018

thanks
tim

---

From: George Michaelson <[email-masked]>
Date: Thu, 25 Oct 2018 08:30:20 +1000

How can it go WGLC with section 6 an open question?

in every other respect I like the document. Bad Hair and all.

I would like to understand if we could work out a way to do traceroute
in the codes, with some defined code to ask the DNS resolver to
perform a TTL drop on a counter and mark itself into the chain, which
would help uncover resolver chains.

With IANA registry requests, I may be wrong here, but I thought we had
some (boilerplate?) language about how IANA is asked to operate the
registry: what criteria judge acceptance. Is it like the OID and
basically open (hair oil) slather, or is it only at WG RFC documented
request?

-G

On Wed, Oct 24, 2018 at 4:42 PM Tim Wicinski <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Shane Kerr <[email-masked]>
Date: Thu, 25 Oct 2018 22:11:02 +0200

Dear DNS colleagues,

I definitely agree with George that last call seems a bit premature. As 
he points out, section 6 is a large open question. We need to either 
change EDNS behavior to allow an unsolicited EDNS option in a response 
or change this draft to include an appropriate EDNS option when it 
queries. Personally I think the draft should specify that the query 
should include an empty version of this EDNS option to indicate support 
(this is actually helpful, as it doesn't make too much sense sending 
back extra information that clients will ignore, decades of BIND adding 
useless ADDITIONAL section data notwithstanding).

Plus there's also this odd bit of stray text laying around:

    Here is a reference to an "external" (non-RFC / draft) thing:
    ([IANA.AS_Numbers]).  And this is a link to an
    ID:[I-D.ietf-sidr-iana-objects].

Also is this correct:

    o  OPTION-LENGTH, 2 octets ((defined in [RFC6891]) contains the
       length of the payload (everything after OPTION-LENGTH) in octets
       and should be 4.

If I am correct there are at least 6 octets after the OPTION-LENGTH and 
possibly more if EXTRA-TEXT is present.

Also, this text seems a bit unclear:

    R - Retry  The R (or Retry) flag provides a hint to the receiver that
       it should retry the query, probably by querying another server.
       If the R bit is set (1), the sender believes that retrying the
       query may provide a successful answer next time; if the R bit is
       clear (0), the sender believes that it should not ask another
       server.

The "probably by querying another server" is odd. In my mind it should 
explicitly apply to querying another server ONLY.

The draft refers to EXTRA-TEXT twice, and EXTRA-INFO once which is 
presumably meant to be the same thing. In any case, I think the encoding 
of this field should be specified as either ASCII or UTF-8. I prefer 
UTF-8, because otherwise I won't be able to send back 🤯 emoji in error 
messages (and the authors won't be able to use the 🍄 emoji that they 
clearly want).

I am not sure I agree with these recommendations:

4.1.5.  Extended DNS Error Code 5 - Unsupported DNSKEY Algorithm

    The resolver attempted to perform DNSSEC validation, but a DNSKEY
    RRSET contained only unknown algorithms.  The R flag should not be
    set.

4.1.6.  Extended DNS Error Code 6 - Unsupported DS Algorithm

    The resolver attempted to perform DNSSEC validation, but a DS RRSET
    contained only unknown algorithms.  The R flag should not be set.

This seems like a case where a stub resolver may want to try another 
full-service resolver that may support more algorithms, so perhaps the 
text "The R flag should not be set" should be removed.

While the draft suggests that it is possible to add multiple EDE to a 
message:

    o  RESPONSE-CODE, 2 octets: this SHOULD be a copy of the RCODE from
       the primary DNS packet.  When including multiple extended error
       EDNS0 records in a response in order to provide additional error
       information, the RESPONSE-CODE MAY be a different RCODE.

It is not explicit about how this is done. If the intention is for a 
resolver to forward this back to a stub resolver, then it needs to be 
mentioned, probably in section 3, something like this. However, then we 
also need some text describing how a client behaves when presented with 
multiple EDE.

Finally, do we have any implementations of this draft? It seems pretty 
straightforward, but I don't actually think that it's possible to 
develop interoperable code with the draft as it stands today. I vaguely 
recall that we wanted running code going forward to try to starve the 
DNS camel...

Cheers,

--
Shane

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 30 Oct 2018 09:57:02 -0700

> How can it go WGLC with section 6 an open question?

Well, the plan is to not allow it per the original EDNS0 spec.  We
should have said that in the section and said "going once...." or
something.  IE, the plan is to disallow sending it back unless the
source indicates support.

[In theory, it should be possible to always include it because of the
"ignore additional you don't understand" rule]

> would help uncover resolver chains.

That's an interesting idea!  (not for this draft though right?  Seems
overreaching for this one)

> basically open (hair oil) slather, or is it only at WG RFC documented

If there is a better template, we'd certainly like to hear it.
-- 
Wes Hardaker
USC/ISI

---

From: Joe Abley <[email-masked]>
Date: Tue, 30 Oct 2018 13:03:47 -0400

> If there is a better template, we'd certainly like to hear it.

RFC 8126 contains exactly the guidance you're looking for. When creating a new registry you not only need to specify the schema and the initial rows to populate the new table with (as you started in section 5.2, although the formatting of the table is a bit horrifying); you also need to specify the name of the registry, required information for future additions and the registration policy.

Happy to contribute some text if that seems useful.

Joe

---

From: Ray Bellis <[email-masked]>
Date: Tue, 30 Oct 2018 17:21:53 +0000

> "ignore additional you don't understand" rule]

Except that RFC 6891 expressly prohibits that (§7):

   Lack of presence of an OPT record in a request MUST be taken as an
   indication that the requestor does not implement any part of this
   specification and that the responder MUST NOT include an OPT record
   in its response.

FWIW, I really wish in retrospect that EDNS(0) had defined the extra
rcode bits as being for a _sub-type_ of the primary RCODE, i.e. SERVFAIL
is always "2" in those four bits in the main header, with the extended
field in the EDNS response allowing for more detail (c.f. this draft).

Unfortunately with the newer RCODEs just being assigned contigiously
from 16 onwards that's no longer possible :(

As it is, if you send extended RCODE 18 (BADTIME) in a packet a non
EDNS-aware client will only see RCODE 2, which is probably in large part
why we have the very stricture quoted above.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Tue, 30 Oct 2018 10:42:21 -0700

Ray Bellis wrote:
...
> from 16 onwards that's no longer possible :(

it was never possible -- we needed more rcodes, even though we now know 
we also need more detail on existing rcodes.

-- 
P Vixie

---

From: Petr Špaček <[email-masked]>
Date: Tue, 30 Oct 2018 18:44:35 +0100

> and ends on at the end of IETF 103: 9 November 2018

I believe the document is not ready for multiple reasons:
- EDNS handling as mentioned elsewhere in this thread
- lack of implementation reports

With my implementer hat on, this might not be as easy to implement as we
would like. An actual implementation might uncover various weird corner
cases so I'm against advacing this document before there are
implementations for *real* resolvers/DNSSEC validators.

-- 
Petr Špaček  @  CZ.NIC