[email protected] writes:
> Title : Extended DNS Errors
> Authors : Warren Kumari
> Evan Hunt
> Roy Arends
> Wes Hardaker
> David C Lawrence
> Filename : draft-ietf-dnsop-extended-error-03.txt
> Pages : 12
> Date : 2018-12-20
Folks,
With a LOT of embarrassment, I did a lot of editing and discussing to
bring the draft into much better shape. We had a LC issued while
discussing the draft with the chair only to find out that our memory of
its state was far worse than reality. Though it wasn't the worst thing
in the world, it needed a fair amount of improvement. That being said,
thank you to everyone that submitted comments about it and all of those
issues have been addressed (details below).
In the mean time, the new draft is much stronger. One of the comments
about the draft previously was "are their implementations?", as that
became a sort of pseudo-requirement since the original start of the
work. So with that, we're very curious:
QUESTION: Is anyone planning on implementation this draft?
Otherwise, here's the results of the rest of the comments and concerns
that came about in the Last Call:
1 Shane Kerr's review
.. 1.1 DONE Plus there's also this odd bit of stray text laying around:
.. 1.2 DONE Also is this correct:
.. 1.3 DONE Also, this text seems a bit unclear:
.. 1.4 DONE EXTRA-TEXT and EXTRA-INFO duplication
.. 1.5 DONE encoding of the EXTRA-TEXT field
.. 1.6 DONE I am not sure I agree with these recommendations:
.. 1.7 DONE How to add multiple EDE
.. 1.8 CANCELED Implementation required
2 Peter Spacek
.. 2.1 DONE EDNS handling as mentioned elsewhere in this thread
.. 2.2 CANCELED lack of implementation reports
3 Joe Abley
.. 3.1 DONE Fix IANA registry template
4 Donald Eastlake
.. 4.1 DONE two dimensional table is unneeded
.. 4.2 DONE rcodes are only 4 bits
1 Shane Kerr's review
=====================
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).
1.1 DONE 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]].
+ Result: removed
1.2 DONE 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.
+ Result: fixed text to say "OPTION-LENGTH, 2 octets ((defined in
[RFC6891]) contains the length of the payload (everything after
OPTION-LENGTH) in octets and should be 6 plus the length of the
EXTRA-TEXT section (which may be a zero-length string)."
1.3 DONE 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.
+ Result: that's fair. Changed it to " it should retry the query to
another server."
1.4 DONE EXTRA-TEXT and EXTRA-INFO duplication
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The draft refers to EXTRA-TEXT twice, and EXTRA-INFO once which is
presumably meant to be the same thing.
+ Result: switched to all EXTRA-TEXT
1.5 DONE encoding of the EXTRA-TEXT field
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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).
+ Resolution: we're proposing ASCII to keep the protocol simple and to
match TXT records. These are not intended to be end user messages
but rather administrative hints for operators.
+ resulting text:
A variable length, ASCII encoded, EXTRA-TEXT field holding
additional textual information. It may be zero length when no
additional textual information is included.
1.6 DONE 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.
+ Resolution: we agree; text changed
1.7 DONE How to add multiple EDE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
+ Tried to clean this up with new text about multiple inserts. Please
see what you think!
1.8 CANCELED Implementation required
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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...
+ issue response moved to a generic multiple-people issue
2 Peter Spacek
==============
I believe the document is not ready for multiple reasons:
2.1 DONE EDNS handling as mentioned elsewhere in this thread
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ Response: we believe we have handled all other issues; please let us
know if you disagree.
2.2 CANCELED 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.
+ issue response moved to a generic multiple-people issue
3 Joe Abley
===========
3.1 DONE Fix IANA registry template
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 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? > > 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.
+ Response: cleaned up and tried to make it pretty
4 Donald Eastlake
=================
I like the Extended Error Code using EDNS idea. This was effectively
what was done with TSIG and TKEY that have an expanded Error field
inside the RR. However:
4.1 DONE two dimensional table is unneeded
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> I don't see any reason for the complex two-dimensional table to
new error codes. Given that 16 bits is available for "INFO-CODE"
(which I think, to follow the DNS nomenclature used in TSIG and TKEY,
should just be called "Error"), I don't see why these extended error
codes, which provide more detail beyond the top level Error code
value, can't be from the single unified DNS error code table. That
way, wherever you get a DNS Error code (from RCODE or the EDNS
extended error field or the TSIG or TKEY error fields or wherever,
there is just one table to look it up in. For example, you could
Reserve 4096 through 8191 for this purpose, which is probably enough
values :-)
+ response: this was discussed multiple times in previous working
group meetings and on the mailing list, and the general consensus
was to use a multiple-lookup table. Continue reading into the next
issue for further information on a decent compromise:
4.2 DONE rcodes are only 4 bits
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Since RCODEs are 4 bits, I don't see why a 16-bit RESPONSE-CODE
field is required. Even if you want to be able to provide additional
information for the 12-bit error codes of RCODE as extended by base
EDNS, there is still enough room in the previous 16-bit word which has
15 unused bits in it. Just move the RESPONSE-CODE up into the previous
word
+ Response: you're right about the 4 bits of course. Somehow our
initial remembrance of this got lost in the double table issue. So
to simplify both this issue, and the previous, we've decided to
merge the two codes into a 4-bit RCODE value and a 12-bit INFO-CODE
value. This actually allows implementers to treat it easily as two
codes, if they'd prefer, or a single 16b-bit code if they'd rather
handle it that way while preserving interoperability between
everything.
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
