Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

[Petr Špaček <[e-mail]>]

On 08. 01. 19 17:30, Wes Hardaker wrote:
> [e-mail] writes:
> 
>>         Title           : Extended DNS Errors
>> 	Filename        : draft-ietf-dnsop-extended-error-04.txt
> 
> FYI, updates from 03 to 04 include:
> 
> 1. moving the unsupported algorithm codes to "NOERROR"
> 2. changing the text encoding to UTF-8 (was ASCII)
> 
> The authors know of no more outstanding issues.  Time for LCv2?

Hello and sorry for being late,

first of all I believe this is useful and suppor the work, but still
needs more work *and implementation experience* before going to LC.

Here is couple specific changes to version 04.

--- Minor changes/clarifications ---

> 2.  Extended Error EDNS0 option format
>    o  The RESERVED bits, 15 bits: these bits are reserved for future
>       use, potentially as additional flags.  The RESERVED bits MUST be
>       set to 0 by the sender and SHOULD be ignored by the receiver.
IMHO "SHOULD be ignored" is asking for trouble. We just went through DNS
flag day to clean up implementations which insisted on some fields being
zero. Can we please use this instead?
      set to 0 by the sender and MUST be ignored by the receiver.


> 3.  Use of the Extended DNS Error option
>    The Extended DNS Error (EDE) is an EDNS option.  It can be included
>    in any response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query that
>    includes an EDNS option.
Why "EDNS option" (at very end of the sentence) and not "OPT Pseudo-RR"?
AFAIK it is perfectly fine to send EDNS0 OPT without any options inside.
Proposed text (only the last line was changed):
   The Extended DNS Error (EDE) is an EDNS option.  It can be included
   in any response (SERVFAIL, NXDOMAIN, REFUSED, etc) to a query that
   includes OPT Pseudo-RR [RFC 6891].


> 3.2.  The RESPONSE-CODE field
>    This 4-bit value SHOULD be a copy of the RCODE from the primary DNS
>    packet.  Multiple EDNS0/EDE records may be included in the response.
>    When including multiple EDNS0/EDE records in a response in order to
>    provide additional error information, other RESPONSE-CODEs MAY use a
>    different RCODE.
This paragraph worries me for multiple reasons:
0) Terminology: EDE is an EDNS option, not record!
a) If I am an implementer, in what cases I might want to go against
"4-bit value SHOULD be a copy of the RCODE"?
b) Terminology: Where is a definition of "primary DNS packet"?
c) When I read this now, many months after the initial draft, I have
trouble understanding logic why we are duplicating RCODE here. There
might be a good reasons but we need to state them explicitly otherwise
it will get ignored (or misunderstood).

Unfortunatelly I have trouble understanding intent behind this
description so I'm not able to draft a better text.


> 4.1.1.  NOERROR Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm
> 
>    The resolver attempted to perform DNSSEC validation, but a DNSKEY
>    RRSET contained only unknown algorithms.  The R flag should be set.
> 
> 4.1.2.  NOERROR Extended DNS Error Code 2 - Unsupported DS Algorithm
> 
>    The resolver attempted to perform DNSSEC validation, but a DS RRSET
>    contained only unknown algorithms.  The R flag should be set.

Why R flag? This is not an error, resolution suceeded, and there is
nothing to retry. I propose change both cases to
"The R flag should not be set."

> 4.2.2.  SERVFAIL Extended DNS Error Code 2 - DNSSEC Indeterminate
> 
>    The resolver attempted to perform DNSSEC validation, but validation
>    ended in the Indeterminate state.  The R flag should not be set.

This should be in NOERROR category.

AFAIK Indeterminate state is not an error, it is most likely a
configuration choice on the resolver. E.g. DNSSEC-validating resolver
running without any trust anchor is in Indeterminate state.



--- New code points ---

I propose to add couple more codes:

+ SERVFAIL Extended DNS Error Code 8 - NSEC Missing
   The resolver attempted to perform DNSSEC validation, but the
   requested data were missing and covering NSEC was not provided.
   RETRY=0

+ SERVFAIL Extended DNS Error Code 9 - Cached Error
   The resolver has cached SERVFAIL for this query.
   RETRY=1
Often the SERVFAIL comes from cache which is unlikely to contain
specific error details, but it is still useful to distinguish "proper"
cached SERVFAIL from other weird errors like running out of file
descriptors etc. Info text could contain remaining TTL ...

+ SERVFAIL Extended DNS Error Code 10 - Server Not Ready
    Server is not up and running (yet). RETRY=1

+ NOTIMP Extended DNS Error Code 1 - Deprecated
Requested operation or query is not supported because it was deprecated.
Retrying request elsewhere is unlikely to yield any other results.
RETRY=0
Intended use:
- OPCODE=IQUERY
- OPCODE=QUERY QTYPE={ANY, RRSIG, MAILA, MAILB} etc.



--- More adventurous proposals ---
a) Two more bits to implement "advice for user" (longer explanation can
be found in archives
https://mailarchive.ietf.org/arch/msg/dnsop/b3wtVj_aWm24PXyHr1M9NMj3LJ0)

I believe this will make the draft way more useful for everyone and not
just geeks.

Proposed addition to text:

> 2.  Extended Error EDNS0 option format
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   4: | R | N | F |                  RESERVED                         |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   o  The NEAR flag, 1 bit; the NEAR bit (N) indicates a flag defined
      for use in this specification.
   o  The FAR flag, 1 bit; the FAR bit (F) indicates a flag defined
      for use in this specification.

> 3.  Use of the Extended DNS Error option

3.2.  The N (Near) flag   The N (Near) flag indicates that the error
reported is likely caused
   by conditions "near" the sender. Value 1 is a hint for user interface
   that user should contact administrator responsible for local DNS.

   For example, an DNS resolver running on CPE will set N=1 in its
   error responses if it detects that all queries to upstream DNS
   resolver timed out. This likely indicates a link problem and must be
   fixed locally.

   Another example is an DNSSEC-validator which detects that query
   ". IN NS" fails DNSSEC validation because signature is expired
   or not yet valid. This most likely indicates misconfigured system
   time and needs to investigated and fixed locally.


3.3. The F (Far) flag
   The F (Far) flag indicates that the error reported is likely caused
   by conditions on the "far" end, i.e. typically authoritative side or
   upstream forwarder. Value 1 is a hint for user interface to display
   message suggesting user to contact operator of the "far end" because
   it is unlikely that local operator can fix the problem.

   For example, an DNS resolver might set F=1 if all authoritative
   servers for a given domain are lame.



b) Another thing to consider is adding optional TTL value to EDE option.
E.g. there is no point in retrying the query again and again until bogus
response is cached. It is much better to display error message "try
again in 10 seconds, if the problem persists call X" than just "try again".


What do you think?

-- 
Petr Špaček  @  CZ.NIC