Re: [DNSOP] Last Call: <draft-ietf-dnsop-refuse-any-07.txt> (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard

Ted Hardie <> Tue, 21 August 2018 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92962130DC3; Tue, 21 Aug 2018 09:48:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0GTbMqBgP_r5; Tue, 21 Aug 2018 09:48:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0E3A130E4B; Tue, 21 Aug 2018 09:48:52 -0700 (PDT)
Received: by with SMTP id v8-v6so33200293oie.5; Tue, 21 Aug 2018 09:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=abGt73glpKznC/bjZvqtNz/BINGfUPAn9us4AxP3Jew=; b=pOjRmvZRripGs/jaZxSIU4ifTRmj6xotx7MRQ66ZG70xymjXZeuD2g/vby96gAwCYo TAkZDotYPblZHUa7dvZzzb284LFdjcM5JGR1eBNVnHCN18ofP5p5BdRxKzYQKTPa2O/k 184dahLolgDdPt1qqy1ZkazYTp4H3ETqgs7FlwPuoC8rMlmBaQwVysxjQi5KlF5Ux5Je kNJe33xw7FfeZPHBBmSUm1qBfoAJ4cQfbcsumpcazTkjJl515FJ5rkXxAkEti/i5e3zl x8LYSq/r18DBlIIBaKROxoMpHqia8vVg85W21rCGoKm/5PIm6ACA/1CykZtYn0GwglJk 3K9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=abGt73glpKznC/bjZvqtNz/BINGfUPAn9us4AxP3Jew=; b=AbRjKbbmxE53EGVbHs2k/zl1vrAhSOS9qxOwrkF5cwyKIJ7H5FmvEn+fcGML/WPssg ++MITkrsLYfamqM3egQasNLqhsFgdlqvR9T2ZXmLTVCsI8Kc/w4H3fRHmn2pknLoArOG RdosYgtxLiOOVapEpkAKMUf/MS4DAlnLAYeIOyLDYYUK3xZquxx0Wj98xGMHGzXPnTlP ZXS9uAYmGm8/DJndrtm/xqTwa1Am28N3U/o/uYAWPDSi/wKAckQSCTt8pQ8DBJ9adWGJ +ppR0isnAt7YWJmyDR6ybJpxKjoPCrxXJ0L3wLBJETVZ2pNvwGeg5thhG442FdUV0Xrv jqbg==
X-Gm-Message-State: APzg51Bthj3495I4I1RuAG0Ql1hAtpoUNwY5y8RzfYuJCpss9eewkEtp OqKO7Y0P+63hbGUc6pZzqBjcolijmG2o/RAAY49KPmii
X-Google-Smtp-Source: ANB0VdajFDmEf5+6L9ZCwCkFPmUAH3lrYeHGDffAAHyK6i9/nBk17/BuLbA3Yp2Ffa19Dj51EMUyzXdwLfv9n1Bx7mQ=
X-Received: by 2002:aca:4994:: with SMTP id w142-v6mr146905oia.114.1534870131052; Tue, 21 Aug 2018 09:48:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:66ca:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 09:48:20 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Hardie <>
Date: Tue, 21 Aug 2018 09:48:20 -0700
Message-ID: <>
To: IETF <>
Cc:,, dnsop-chairs <>
Content-Type: multipart/alternative; boundary="000000000000f0149c0573f4ccb0"
Archived-At: <>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-refuse-any-07.txt> (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Aug 2018 16:48:57 -0000


I note that section 4.4 calls out TCP transport and says this:

4.4.  Behaviour with TCP Transport

   A DNS responder MAY behave differently when processing ANY queries
   received over different transport, e.g. by providing a conventional
   ANY response over TCP whilst using one of the other mechanisms
   specified in this document in the case where a query was received
   using UDP.

   Implementers SHOULD provide configuration options to allow operators
   to specify different behaviour over UDP and TCP.

Given that we now have multiple available transports for the DNS (TLS,
DTLS, HTTPS), it may be worth generalizing the heading and updating the
text to handle those cases.  I suspect that involves a bit more work than
just adding the transport names to the paragraph, unfortunately.  All of
the newer transports provide return routability, which means, as for TCP,
that ANY doesn't create DNS amplification for them.  But they also have
other characteristics (e.g. channel confidentiality and/or additional
caching layers) that may make for other decision points.  Some text on that
would be useful, at least in my opinion.


Ted Hardie

On Tue, Aug 21, 2018 at 8:59 AM, The IESG <> wrote:

> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document: - 'Providing Minimal-Sized
> Responses to DNS Queries that have QTYPE=ANY'
>   <draft-ietf-dnsop-refuse-any-07.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> mailing lists by 2018-09-04. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
> Abstract
>    The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>    The operator of an authoritative DNS server might choose not to
>    respond to such queries for reasons of local policy, motivated by
>    security, performance or other reasons.
>    The DNS specification does not include specific guidance for the
>    behaviour of DNS servers or clients in this situation.  This document
>    aims to provide such guidance.
>    This document updates RFC 1034 and RFC 1035.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.