[DNSOP] DNSSEC corner case -- (surfaced by homenet vs stub validators)

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 31 March 2017 00:23 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1B739127B73 for <dnsop@ietfa.amsl.com>; Thu, 30 Mar 2017 17:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Blxi3jNVJ5pu for <dnsop@ietfa.amsl.com>; Thu, 30 Mar 2017 17:23:47 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C98D127A91 for <dnsop@ietf.org>; Thu, 30 Mar 2017 17:23:47 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id l7so30351264ioe.3 for <dnsop@ietf.org>; Thu, 30 Mar 2017 17:23:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BZrSuk/OrNi71lugBBbQ5rbQ0Puox5uUQTymf2EBroI=; b=RPRfu1Og96STF9A8kJ6u11e3Ig++P6Zti7DZnEwko2m56tgjWUZlqRAuaMVuGEzvMs X+eNnsnx/xXqHHL3z481ZAMHew00tFUV0YLzb2nCbRybHeo144D8SjO5+2B/EbQ2VZsg s5FLJzNE11/KOx9hmBseMJNVZgeKLU70JI2/UMzYldouQnbjy9RhTNFD0/B4rDzZ7O4o UTpJ+Qh7qDE4Laotun7RRq0a1TrrVIzBgVDW9NwS+fV64BoICpQ8bnw6iAjkPupnMcA6 uwFBavmjzzjh3lBV6nMNRXikQMTMHAtuYQtSH2PHA7BiRO+2DrEOz6/jiVN/4wNyhLWx ldSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BZrSuk/OrNi71lugBBbQ5rbQ0Puox5uUQTymf2EBroI=; b=NBHfxOWJyKUdFqSesZpkBzFfpueaZPoTcQCd7nuBCjjrki1Js/jDJVROa/5WAxbhjM XYtAQpHLux6Akcneruz32nWgoT5cHq2vzpk2QsKYJJbUjsO9YetJ/DFqXdCIxBVe33gk vL2GaOkyLMd6FJ8WOvjdiQLSYySNrZ45Q5T3PVYjcZP+f087VEgk2GSFwEuo4HEDsIP9 ofUp/7SO21lPQMZNwGMbhk0ZGyjZMH9lNxEcMm0/GhLTLvegFmnhd0w6xlRzrnWd1I07 +wm/NinEXf7/Jput6gBQiVIBXbWkp3jnw+R1hDWHvkQzR+JiDRF9Rr5cjUa4u8T7ZUkC ZOuw==
X-Gm-Message-State: AFeK/H1fJQ2fZNd8gDloBxenL4K7ckJL7KGIkoASNEpwXt8VwpJfLI46QUdoxmIa9klEK85JfF/g73KlNHLGRg==
X-Received: by with SMTP id d191mr328581iof.42.1490919826393; Thu, 30 Mar 2017 17:23:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 30 Mar 2017 17:23:46 -0700 (PDT)
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 30 Mar 2017 19:23:46 -0500
Message-ID: <CAH1iCirtMRLM8Lutmb+nPMmcN1qpOqKZSHOZP=in9AwynCBN7w@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0685cea411c6054bfbd2a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/My5Qf9LZAtfzxsLkDmfFxH7WDFM>
Subject: [DNSOP] DNSSEC corner case -- (surfaced by homenet vs stub validators)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 31 Mar 2017 00:23:49 -0000

I have looked at the need for unsigned delegations required to satisfy stub
validators, and am interested in feedback to an idea I have: signal to the
stub, deliberate non-use of DNSSEC.

The presumption is that a stub's use of a recursive resolver involves some
degree of "trust", at least if it uses the resolver by choice, and does not
set the CD bit.

What seems to be "missing" (as in, maybe it is a corner case that wasn't
noticed before), is the ability for a security-aware resolver to "signal"
to a stub, that it is deliberately not returning DNSSEC records, even
though the stub set the DO bit (DO=1).

The obvious signaling mechanism, at least to me, would be setting DO=0 in
the response.

The particular circumstances under which a resolver might do so, are
probably irrelevant (call it "local policy"), but one example in particular
would be homenet.

If a query for <something>.<homenet-domain> from a validating stub were
received, and local policy was "no DNSSEC for you" if the query is at or
below <homenet-domain>, this signaling would help the stub realize that the
situation for that resolver is, "I'm not deaf, I'm ignoring you". Set DO=0
and return unsigned answers.

Or is it far too late to be suggesting changes for sub-resolver DNSSEC