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

Loganaden Velvindron <> Wed, 11 September 2019 06:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2003112080A for <>; Tue, 10 Sep 2019 23:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z1LxNBI9yzEw for <>; Tue, 10 Sep 2019 23:09:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52324120073 for <>; Tue, 10 Sep 2019 23:09:09 -0700 (PDT)
Received: by with SMTP id d25so43211638iob.6 for <>; Tue, 10 Sep 2019 23:09:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OLbe7wnpRbucejHKut5xANMRhBLyIs47eOx/0HiWB7Y=; b=uVKx2IXXzcuQ8hFEONhJmSGjEnEzZqur7qX0M0I3hnf1BjEYOQUpdI1Lui1idOeLJ5 m785AFfXBAFNNjYAWOqTPd0n5a4S9bQknE3uSX9NOQ5/aOTP6aEsTWB8DwQXbqkhkij2 tx6Cwn7n0gDfBPe45e1UWJBY4hhDxbeaiyWuvBAWKpOZXHHRa3++KMCzA3WaoapdmZka rpg2Tuw/zIPzxv7VCI0QXk09SimfZb/RgbaGaQOfu79pr2lgP5cytNJI3Az8FTCBsz6A JG5ogZpU6RTO8yOok7X2jwGmzEjdTz0jx5z2s7/0W+3GtxCZ9JQm4CMY+Sad/LdXZRbJ wPbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OLbe7wnpRbucejHKut5xANMRhBLyIs47eOx/0HiWB7Y=; b=RxhGENUi3tA5aaqD6p1YSOmgTV4c/lhlZ0l3NLU0rCcl8paQivkwXgIXO5chNVNQB2 dqw34qr8sfOx64tvn/c/p2x1WKytndC0Ppp90RVqIWcsvN8WVgANLS0/jdVIOAEjEzwy IvENQy8RYdBVzUYpkAd3WCMVVXou2KBAP33WzYnvU6E+ozQ+i6VjkIbC3gF8Mbr1DBMO YmDuLqvHxa40VuRVtWYP+YiV31TL+znSWhuDeXXuw+cxiS3Jjmgl5cDEOCU0xN7w3ndk lq/UdIe96GYG0fp0NVI7sHodUeO7TdlEauxxx/2jCUVdl/8Ny9uDo0SOSEbgVBeC98dD ES6A==
X-Gm-Message-State: APjAAAXm+h3VnUg4k8iiaaOfvbaMM7FgpyXl7N6zt/RU7086w1zYTMI1 SlQg2uJfU68j9VWnpzo/py1j87C7/zZOxKa3/K0=
X-Google-Smtp-Source: APXvYqzziD2yk1Ym+QtMZ7fx87HEh+JrZxhnC56PtPKXW1N2VzgNiXhzYsG0GMF3QSMsmKx4ZPh2g5TD1A61HEHK/h0=
X-Received: by 2002:a6b:c810:: with SMTP id y16mr40827215iof.75.1568182148492; Tue, 10 Sep 2019 23:09:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Loganaden Velvindron <>
Date: Wed, 11 Sep 2019 10:08:56 +0400
Message-ID: <>
To: Wes Hardaker <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-07.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Sep 2019 06:09:12 -0000

On Wed, Sep 11, 2019 at 7:42 AM Wes Hardaker <> wrote:
> Loganaden Velvindron <> writes:
> Hi Loganaden,
> Thanks for the comments about the EDE draft.  I've marked up your
> comments with responses and actions below.  Let us know if you have any
> questions.
Hi Wes,

One small note: This reply was from John Todd from Quad9. I asked him to review
the draft, and he sent me his comments which I then forwarded to the
dnsop wg mailing list.

> 11 Loganaden Velvindron
> ==================================================
> 11.1 NOCHANGE pass-through
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
>   1) I see at least one more model that needs to be supported, which is
>   how to handle edns extended codes that are generated by a remote
>   server, i.e. passthrough. Layering multiple forwarding resolvers
>   behind each other is common, and some way to notify the end user that
>   the originating message was not generated by the first resolver would
>   be important.  I don't know if there needs to be some way to indicate
>   how "deep" the error was away from the end user; it seems just two
>   levels (locally generated or non-locally generated) would be
>   sufficient with only minor thought on it.
>   Re: 1) This is a good point, but implementation will likely run afoul
>   of existing standards or else require duplicative response codes or
>   use of an additional flag in the INFO-CODES section.  Perhaps a new
>   flag type, similar to AA, which can be used to say that this recursor
>   will return this result reliably/deterministically.  Attempting to
>   provide depth is perhaps unlikely, but flags for
>   stub/forwarder/recursive/intermediate recursive or a subset of those
>   might make sense.  Perhaps a non-descript flag such as 'DR' for
>   Deterministic Response.  Obviously INFO-CODES can support many
>   different flags, of which IR (Intermediate Resolver) or such could be
>   included at the point of response generation, with the last server
>   providing actual data in the chain being the one to authoritatively
>   set the flag, which then must not be modified by further downstream
>   resolvers in the process of returning the response.
>   + Response: this has been discussed a few times, and the current view
>     (that at least I hold, and likely others based on past discussions)
>     is that it would be best to get this out as is, without a
>     pass-through model while we deploy it and get operational experience
>     with its use.  Pass-through is complex for a bunch of reasons (NAT
>     alone, eg), and it's unclear we can come up with a solution for all
>     the likely corner cases to appear.
>     TL;DR: we should definitely work on it, but in the future.
> 11.2 DONE network error code needed beyond timeout
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   1) SERVFAIL needs another error code to indicate the difference
>   between a network error (unexpected network response like ICMP, or TCP
>   error such as connection refused) versus timeout of the remote auth
>   server, as that is often a confusing issue.
>   + Response: looks like a reasonable idea, so it has been added to the
>     latest draft.  thank you!
>   Re: 2) Specifics as an item in the below list.
> ~~~~~~~~~~~~~~
>   1) Really, I'd like to see a definition of some of the EXTRA TEXT
>   strings here, since that will be almost immediately an issue that
>   would need to be sorted out before this could be useful. There have
>   been some discussions (sorry, don't know if it's a draft or just
>   talking) about browsers consuming "extra" data in DNS responses that
>   can do a number of things.  As an example that is important to Quad9
>   (or any blocking-based DNS service) it might be the case that upon
>   receiving a request for a "blocked" qname/qtype, we would hand back a
>   forged answer that leads to a splash page as the default result.
>   However, if the request was made from a resolver stack that had the
>   EDNS extensions, we might include the "real" result in the EXTRA TEXT
>   field, as well as a URL that points the user to an explanation of why
>   that particular qname/qtype was blocked.  Or we might add a risk
>   factor, or type of risk ("risk=100, risktype=phishing") or the like.
>   This allows a single query to be digestable by "dumb" stacks that we
>   want to have do the most safe thing, but also allow "smart" resolver
>   stacks to present a set of options to the end user.
>   + Again, I suspect that the complexity associated with standardizing
>     on exactly a structure (including internationalization) of
>     extra-information in a machine understandable and parsable mechanism
>     is fraught with a very long discussion period.  It might be worthy
>     of future work, and I certainly think it would be valuable, but
>     (IMHO) it would be better to get this out and work on that as a
>     follow-on project *if* we could achieve consensus on it (which, I'll
>     be honesty, will be either difficult or take a long time or both).
>   Re: 3) Seems reasonable.
> 11.4 NOCHANGE blacked/censored/retry
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   1) I'm confused as to why a "blocked" or "censored" result would have
>   a retry as mandatory.  The resolver gave a canonical answer from the
>   point of policy.
>   + the retry flag is now gone.
>   Re: 4) See below notes.
>   Potential inclusions/Adjustments:
> 11.5 NOCHANGE More retry case thoughts
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> A use case exists where a stale answer should attempt a
>   retry. A declarative setting for the Retry bit should not be specified
>   here, but instead guidance on whether or not the R bit should be set
>   should be included. For example, when using a front-end load balancer,
>   if the recursive backends are temporarily inaccessible but are
>   expected to recover in time to handle a subsequent query, it would be
>   prudent to include the R bit. No additional load would be generated
>   towards the Authoritatives in this case, and the Intermediate Recursor
>   may choose to set the R bit or not based on whether the failure mode
>   appears to be temporary.
>   4.1.5: Another area where guidance should be provided. Some recursive
>   resolvers process requests out of order, asynchronously, or will retry
>   alternative authoritatives post-processing as part of infrastructure
>   table management and thus may response to a subsequent query, where
>   the initial will fail, likely due to timeouts. In our specific case,
>   due to our use of multiple recursive backend technologies, a
>   subsequent query failing DNSSEC validation has a significant chance of
>   being answered by an alternative recursor. See also 4.2.1.
>   4.2.11: SERVFAIL - Network: The SERVFAIL response is being generated
>   due to what is clearly identifiable to the answering server as a
>   network issue. R bit should be set.
>   4.4.3: Abusive: The answering system considers the query in question
>   to be abusive for reasons other than load, indicating that the
>   specific requests are undesired. This could provide hints to Network
>   Operators or simply poorly configured client implementations that the
>   specific queries may be part of an amplification or other attack and
>   should be inspected.
>   4.4.4: Excessive: The answering system considers the query volume of
>   the client to be excessive, indicating that it is the volume and not
>   the content of the queries being refused and that it may be willing to
>   answer if volume is reduced. This could provide hints to Network
>   Operators or poorly configured client systems that they need to add
>   additional endpoints or reduce their request volume to restore
>   service.
>   4.4.5: Go Away: The answering system considers further queries from
>   the client/network to have to exceeded thresholds by large margins or
>   excessive durations, and further queries are likely to be dropped.
>   This message is an attempt to limit the continued use of resources
>   terminating queries which will not be answered. This may simply be a
>   sub-case of Abusive/Excessive, but also is not intended to be sent for
>   each query, but instead only intermittently, and to bypass the need
>   for lengthy troubleshooting efforts when drop rules cause a recursor
>   to seem to have vanished.
>   4.5.1: The R flag being set here implies that there are potentially
>   multiple policies in use and that a retry might receive an answer -
>   which should not be the case with a single intermediate recursive
>   service. A client, knowing that it has multiple recursive services
>   with differring policies might retry against a different recursive
>   service (ex: instead of, but this effectively defeats
>   the policies of the initial recursor, rendering it ineffective. The
>   use of a specific server as a delineation is also confusing - it
>   should instead specify that the answering entity - be it a single
>   server or larger entity, has blocked this response. Also, blocked
>   should be further defined to avoid collision with the definition of
>   the Censored response code. Blocked in this case would be used as a
>   catch-all for anything not otherwise categorized.
>   4.5.2: See 4.5.1. Censoring is inherently a governmental action and
>   this should be reserved for that due to the severity and legal
>   repercussions of attempts to bypass. R bits should not be set.
>   Censored should be defined in the document to avoid confusion.
>   4.5.3: Filtered: Differentiated from Blocked/Censored in that this
>   content has been specifically redacted at the perceived behest of the
>   client - may include ad-blockers, dnsbl, or other specific cases -
>   intended to be used by those systems. Would potentially include
>   corporate IT policies.
>   4.5.4: Malicious: Differentiated from Blocked and Filtered in that the
>   answering server believes the response to be actively malicious and
>   harmful to the requesting systems or applications, and not merely
>   undesired or offensive. R bits should not be set.
>   4.5.5: Malicious Upstream - The upstream entity is considered
>   malicious by the answering server and thus a refusal to respond has
>   been returned. Details should be included within the INFO-CODE and
>   potentially EXTRA-TEXT. This is differentiated from Malicious in that
>   in this case, it is the actual upstream server that is having all
>   responses blocked, not the content itself - for instance a revoked or
>   unexpected certificate (such as due to a CAA record) - from which no
>   responses will be accepted. The R bit being set here depends on
>   whether the server believes that the specific path is compromised - if
>   all authoritatives are failed, then a retry will not help. If only one
>   is, then it will help to get to the non-compromised server. In the
>   absence of data, the R bit should be set.
>   It may make sense to create an extension of the R bit, via additional
>   flag or other field which adds additional context to the retry
>   declaration, such as that the request should retry the same recursor,
>   or should instead immediately move to and try the next available.
> 11.6 TODO synthesized == forged
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   4.1.6: Synthesized Answer: This response could be considered a
>   sub-case of forged. An example of this would be the id.server or
>   version.bind queries, they cannot be considered forged, but also no
>   authority truly holds them.
>   + Response: I think this is worthy of further thought and I'd love to
>     hear opinions from others.  IMHO, I'm not sure we should get into
>     micro-error coding.  I would say forged, in your examples, still
>     fits.  But there are other cases where I think synthesized may make
>     sense.  Anyone else have thoughts?
> 11.7 NOCHANGE finish categorizing
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   Other Notes: INFO-CODE: It would seem that would be best to include a
>   basic recommendation for a standard DNS-specific RWhois/CRL-like
>   endpoint which could provide local (non-IANA) information about
>   returned codes, potentially at a well-known URI, or even within the
>   DNS itself via TXT records or even within the EXTRA-TEXT field itself.
>   + Response: per discussions with others too, which you've hopefully
>     read, there is a lot of desire for ways to potentially standardize
>     supplemental information within the EXTRA-TEXT field.  However, for
>     the time being the goal is to get this out and get experience with
>     how it is used and potentially standardize on the addition of
>     machine readable supplemental information (URLs being the other
>     common suggestion).  Publishing this first (as is) doesn't get in
>     the way of a future RFCs extending this specification.
> --
> Wes Hardaker