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

Brian Dickson <> Tue, 14 February 2017 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EA3A129460 for <>; Mon, 13 Feb 2017 16:06:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 ldWUlcmcuq9x for <>; Mon, 13 Feb 2017 16:06:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B358129436 for <>; Mon, 13 Feb 2017 16:06:55 -0800 (PST)
Received: by with SMTP id c7so10063187itd.1 for <>; Mon, 13 Feb 2017 16:06:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=odcAPsGKytvCxYSCUz50al+QY5Xu5fEqJOu1NHG0Rrc=; b=OiIghF9T1Y2t4j6hdGnh50uH0lGOg4P0fLBsicvwUXycHqwdGSy/G34r+4oOWG/sMI xtyZ1fTAk2U/syOSHuC8zj5KMoW6ILm2Kryliu0wduczHas/0t2ix2d+wVjXLah7/OMH AYcRwNGA+F0XAYQdiXOuSlW3n5SKc0Lf/IgK9yp+Cvob7qBZAkVa3BJL2edKDXogK2vX hvM6eJOZrrYWiaqqGnBVQtvd2Jarp+D/wlTiVwYnsDHOir7cFIt6ABkgVarhpwV35GLJ cWBSu4Zs2n01Ws7NIDeXO185y0HbW4IIdMi+NIOEdWe6fcE9dZzowp8czqvzkIghSXh2 ZYwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=odcAPsGKytvCxYSCUz50al+QY5Xu5fEqJOu1NHG0Rrc=; b=Hsgs57TRrmhAZ/Nz3+toDqg7mcNia1R42R1wbwkhjAuV6XwVh+lLdrofOs7SLuSTDH JcyjyKkiqKSz2WTOZapT4gv04/cZcdFoUx+wcJ0wVPjxi5EhqG3RPr4ApMRKO22ft8A6 sXPDYKOCItIiS+wvul+hQ2iGykNxceqioOtvZC3pBy1coZGRL6iY4N1AXGGbfDZQS9f2 jHXSVDrGQWz77Ihp8rE4FPxDlvZZq8yy+2m2gCLD7FJaw959E2jZIEcd4wK9TWjPiJIw yCotHlREo8/4LI+L/Iw6uuUJFGH+BtRpQdIK6Uyl9RCjiSwAT2idu20WO35b1EHNg3va 7weQ==
X-Gm-Message-State: AMke39lHJlip/rtPbcMi+0hj1CfpSGT5BgjmZfwQDQWcf1/UgbA4tusHuEusvbsM9O0BGflRhxHWh9gYtoHVbg==
X-Received: by with SMTP id x18mr23305260iod.167.1487030814204; Mon, 13 Feb 2017 16:06:54 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Feb 2017 16:06:53 -0800 (PST)
From: Brian Dickson <>
Date: Mon, 13 Feb 2017 16:06:53 -0800
Message-ID: <>
To: " WG" <>
Content-Type: multipart/alternative; boundary="001a1140fee4737a690548725706"
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: Tue, 14 Feb 2017 00:06:56 -0000

> Richard Gibson <rgibson at> wrote:
> > Because without such a signal, humans using ANY for legitimate diagnostic
> > purposes have no means of differentiating section 4.1/4.3 "subset"
> > responses from conventional responses where there just happen to be only
> a
> > small number of RRSets at the queried name, encouraging (or at least
> doing
> > nothing to dissuade) a conclusion that the response is in fact
> conventional
> > and complete.
> There are several ways to avoid this pitfall:
> Use TCP
> Look for an NSEC(3) record
> Query for the specific types you want to know about
> Tony.

I hope it's not too late to discuss additions to the I-D. Sorry for not
contributing sooner.

So, I have a question about EDNS and DNSSEC (and maybe when DO=1):

Suppose a zone is NOT signed, but the requestor uses EDNS (and maybe DO=1).

What would resolvers do if they received, in addition to normal RRs, one or
more NSEC or NSEC3 records, and no RRSIGs?

That would be one way to provide information about RRtypes at the owner
name, even if the zone was unsigned.

Would it be feasible to limit the behavior of "refuse-any" returning
"partial" UDP responses, to situations where EDNS with DO=1 is used? Older
resolvers would need to have some method of getting answers, so maybe for
those, use the TC=1 method?

 When a QTYPE=ANY is received, respond with some "arbitrary" choice of
RRTYPE, and add an unsigned NSEC or NSEC3 record to list RRTYPEs present.

In the case of SIGNED zone, returning a random RRtype and including the
NSEC/NSEC3 would be ideal for both signaling that "ANY" is not supported,
as well as what else to query for.

I think NSEC or NSEC3 could be used in an unsigned zone, and generated "on
the fly" with trival or empty values for "next owner", with the caveat that
it MUST NOT be used for generating negative or empty responses. But that is
a stretch, and probably not worth pursuing without some further
investigation into resolvers' handling of such unsigned responses inside
unsigned zones.

(This on-the-fly suggestion is a compromise to avoid the need for
NSEC/NSEC3 over unsigned zones, or forcing everything to be signed, which
is clearly not yet a reasonable suggestion.)