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

Petr Špaček <petr.spacek@nic.cz> Thu, 07 February 2019 15:46 UTC

Return-Path: <petr.spacek@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4B21293B1 for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 07:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.994
X-Spam-Level:
X-Spam-Status: No, score=-4.994 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.105, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU5ue0WysllU for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 07:46:53 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABF9126D00 for <dnsop@ietf.org>; Thu, 7 Feb 2019 07:46:52 -0800 (PST)
Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:67c:1220:80c:2198:e685:86e1:b423]) by mail.nic.cz (Postfix) with ESMTPSA id 0C19662FB2 for <dnsop@ietf.org>; Thu, 7 Feb 2019 16:46:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1549554411; bh=5XA99b08HXlO1K4X81+vJhLiihZx+Lt99I/Hgew75MU=; h=To:From:Date; b=DW3n4GXl/ecF+pKt3ZeqT5kqE2fp49J8VCc4Uxe7pHJ8QaPjY7Y/A3aPZniFfwWu3 V4xNzrzJILLIXhKerDsfVEvGo0ZvuiqNDEEaUxvwC3TZnWXlgHGe2cfPkpW6p7vc3d Tfi2zBSfc0ALvrpklojxaS80ctJ2KcUQq+6hFDcM=
To: dnsop@ietf.org
References: <154689301066.32204.17312124670782800354@ietfa.amsl.com> <ybl1s5nxgau.fsf@w7.hardakers.net>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Openpgp: preference=signencrypt
Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCBQZXRyIFNwYWNl ayA8cGV0ci5zcGFjZWtAbmljLmN6PokCVAQTAQgAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIe AQIXgBYhBL4m67nL4FmzkQyjW86N1qGlCiHkBQJcEOXhBQkFp4LgAAoJEM6N1qGlCiHkxNwQ ALFyQ7Rrghf0rM9GN2+kgP92Qvot21h8/Je3bRTvoLyhYUXcAMRmODZQ/0EsjExFc+pRwn+E 0GD2TpiorDnRMpJYEmHqenYGIrZ5TE0lHwwu0fi/X3evDY4j68OFlim5Q6+7pHOlZWaRsSm5 T6blSwIaNDFYtBhI0X1ZXTGqbXIUBFuGxolo/xEgUkeDy+6D4R8yT17CTHkuGYYrfUYnoBTr j3xMVil/lNMievaklAL8kRNVl0It4M8VzHTyEdMq7pG0CJ0CfU8COizCsu4+zy8dsxMVE0Su hju05LSsClZ9X1csxSK9HjKq+TG1Hx2qciFHRB1qC2mNIvWTm10Gkj4tLTWcJp3k2Wyv+1K2 sLFxreGOwbx0uR7XtIIBTiiZAiVsjBH0D39qG2ZLz+bJkQvlTDZQuXzsMS51wROvTVxPYcXX p069hON2+/QqJasmpOHhOydGkB3uokA0crqvMOnK+EcueKQQspvdLGiFLefJPuM8VVyR9fFZ YjnX2vfGZbE+MxY8wG4mDbhgxsUORAEtNUH/G0dvTv66fzKpl5q9GIZs7el+1IU31w7KivgS 7fsWcOsdzq4KzZzNBRJtEDoxX4b9lQ8P6ttMlPi7PnQ+iN0OUxKSnAnKQiqKMFRO1zH22vn7 iiF4JMO32//0HcpsyV8oEdjDkSJsFRnDfLW2uQINBFhri/0BEADFp4ZfxSoKTAad0IkFK9CV oZ6XKywYLFNPPhzw++gbvHL2EX7QqhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQo u0FeSNnzRGb607U8OFOPQ+ei92Mm1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkh wtWU/6yo+RZs7cFRuihuLl8FuoP0A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAw GDtjWkBVawpoHWwq58OQSx5piwyOCnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdW Jw5OV9BoA7UTHG95xVHV5QiEm6q6igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8 mmKyS8E+mSh3djmqdJNHF1pJqKxAxPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03d uzocyU95DfP/lwNJr5SH918Vf1t7WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkS eXNoMlHJOIqbqm7N414I0HytbENf7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw 3f3Gn3+PDzGEHI9sfQv/mYvO77oRSGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6If ZZ0OIWKLSRa/DQARAQABiQI8BBgBCAAmAhsMFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ 5fcFCQWngvoACgkQzo3WoaUKIeTg+w/9Gyp5EcB4AoR3vKVxP0SAh1zBher3bh9uGaKTAWt0 +0v8fyZYGEPqZr//9rkodPnXbQnr9ogzjJmZpsPvGPyRZikWjYIwkfM2Vb4BCyr5wQ9++9KB kob5zCQmUw2o7s/gISpFsCC5B0eYusArVDnrCyrroyaxbN6MpUb5lzVMEOCzYljtdrPRAXPL FKRm3ijLV0RcYPzJJVOPV5EzUfCtGsGTXXRI9Y9O/7lFaJ+iWnwygo/Xoi0IgBHvOAj9Gp3Q 0BY+sI6Rgzm9dbddm8gYJ4+FjfZivI7fbdfSubTWvrtFmFdHovIPJYLvXK7hUG22ww4CneIF D4oZSVy9xUoqJf0qQNruzEqTr7y7lbZIzxgPCSVmH0jpgJ1po6RLaJllNA+ZklOQ76fCMiaD 5yQuJluwD5w+acPWTbmZX6DijGHPZSjzeUkiMKctYSRqVUo6JmK0dgwwm3l1/Orb4D3YsLVP QDa4ZrCfSldrGC3zkEJ8iCVSYQwlc0JfIxyn8C3LLxToPYeFv/bQTeDYBjaV7a0SQ/xKUdpg RFzrGrxj7CM2WHcpxCLVK0agobuUO7YXoufHRM6y0rfMwT10baDjh+hLKMshxTqsP55lWvtM SleSGjheVTiZChb3jK0rUPCC4Rg3gDTEQsptC3TgN48PtLpmhsNc4JPm64zlrreInZQ=
Organization: CZ.NIC
Message-ID: <3c2ef704-148f-ed03-26a9-8ea29256acc2@nic.cz>
Date: Thu, 7 Feb 2019 16:47:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <ybl1s5nxgau.fsf@w7.hardakers.net>
Content-Type: text/plain; charset=utf-8
Content-Language: cs
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JHYQunp0L7C_vUcBb9fOi22QfpI>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 15:46:56 -0000

On 08. 01. 19 17:30, Wes Hardaker wrote:
> internet-drafts@ietf.org 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