Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

Richard Gibson <> Fri, 10 February 2017 04:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1574129FA5 for <>; Thu, 9 Feb 2017 20:48:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.74
X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bL1YA_iSoDgK for <>; Thu, 9 Feb 2017 20:47:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c08::248]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B1D1129FA9 for <>; Thu, 9 Feb 2017 20:47:57 -0800 (PST)
Received: by with SMTP id f2so14918681uaf.2 for <>; Thu, 09 Feb 2017 20:47:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FMECZJt7dGrkDmbkM/3mQ+Ydy9LHBKUJYFXJEohH3WY=; b=EK4+zRApS2aEcXZTNN3e0vkZhhEukKqfMD3wsbJX+PC/IIJKe/C/bXJ0r7IHbdNgh+ KY9KMDt62/c4c10FXHkc98STruKwGAaIJmiyhW6gubPvxht5Cc+n2iZFT1KV4FA7njHi /Q9KmmY0TCe1d4Jn386IOzeHOrr8sBC12oqGk=
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=FMECZJt7dGrkDmbkM/3mQ+Ydy9LHBKUJYFXJEohH3WY=; b=K90k3dsBnARXACBCD1mYvNWXJ3QG52WEKPpdcm0k2Ltee/ZH7EfSuoxoxpVlEyPcnD Ch0C9fTsOaWX/zZo3u4I0tNoWjEiZql0Ns8I147vdu7wudSt+Tp8+gGKY7zwT3e0q21n lwz4ilrFPS3QouOsrH8cKJEyULMcFXeDyI6VaSk/JjJmQQMiNP3EKdaxO435Xjho49gA dvQcg/oFR3t5IvMmllAMkxcep8pQS2kzWVVGHsQseOWINM1MZATwiiVt82ItOybATvOE iBkkTfidLrmH+H1XTQGt54/yLK+hBCaXiIODeBXrkkASmqMeGKEp/NNoqBIVImOLrjsJ APOQ==
X-Gm-Message-State: AMke39nt2wsr2qYaeHRkVUQkWX3LJMD/IUlAljb5MVYoYcU58C35eJOC94P8D75k5hmyt2U648Cs7LwXBW4/0XGH
X-Received: by with SMTP id k17mr3625944uaf.99.1486702076200; Thu, 09 Feb 2017 20:47:56 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Feb 2017 20:47:35 -0800 (PST)
In-Reply-To: <>
References: <>
From: Richard Gibson <>
Date: Thu, 09 Feb 2017 23:47:35 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="f40304361f32239ace054825cd3d"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Feb 2017 04:48:01 -0000

With full realization that this is coming very late in the game, we had a
great deal of internal conversation within Dyn about implementing
refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
approaches—the latter because of reasons that have already been covered,
and the former for lacking in-band signaling of non-"conventional"
incompleteness to aid legitimate use.

I believe there is sufficient cause to reserve a new OPT record EDNS header
flag bit
for indicating "partial response" (as distinct from "truncation"). It will
be safely ignored by current clients, but convey the desired information to
those in the know.

P.S. Our discussion also raised some more minor points:

   - Insisting that the HINFO OS field SHOULD be empty ("set to the null
   string") seems a little too strong; there's room in it for (and value
   from) a short explanation (e.g., 3789 IN HINFO "Please
   stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer text
   like "The OS field of the HINFO RDATA SHOULD be short to minimize the size
   of the response, and MAY be empty or MAY include a summarized
   description of local policy."
   - "Conventional [ANY] response" is used but not defined.
   - "ANY does not mean ALL" is misleading—RFC 1035
   <> is clear about
   QTYPE=255 being "a request for *all* records" (emphasis mine). That
   said, the proposed *response* behavior is consistent with that RFC.

On Thu, Feb 9, 2017 at 12:56 AM, <> wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>         Title           : Providing Minimal-Sized Responses to DNS Queries
> that have QTYPE=ANY
>         Authors         : Joe Abley
>                           Olafur Gudmundsson
>                           Marek Majkowski
>         Filename        : draft-ietf-dnsop-refuse-any-04.txt
>         Pages           : 10
>         Date            : 2017-02-08
> 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.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> DNSOP mailing list