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
On 25/10/2018 00.30, George Michaelson wrote:
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 <tjw.i...@gmail.com> wrote:
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
