Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

David Conrad <drc@virtualized.org> Fri, 07 April 2017 01:25 UTC

Return-Path: <drc@virtualized.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32778129551 for <dnsop@ietfa.amsl.com>; Thu, 6 Apr 2017 18:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3IA_N87DYb9 for <dnsop@ietfa.amsl.com>; Thu, 6 Apr 2017 18:25:00 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 23B031293DF for <dnsop@ietf.org>; Thu, 6 Apr 2017 18:25:00 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id g2so50266011pge.3 for <dnsop@ietf.org>; Thu, 06 Apr 2017 18:25:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=57xpah1MphYSetvt47cPhUU6Uf9bZ4rXcMgA94WqDt0=; b=MWGZDwcwWGZzWxwJJC38pJbeYU1bcEsDC6Ji83mg2FLa/NKQGUgDCAbjfXUf0LyE/k DQVXbdZruetEIObYn/2RjAmsxWViWc6r0dF59RGoLa19MMeJTAR4fCWzj9ocNDfhdB5m bObpQoeCIGG/riWICbusfGWEUPPlPbIA8rDKQAbtk8woI6qYiIUozXzRemNFsxQ75BPH tbZo/1tbGA5+si+h3Wbsc9KqqhIpwvSblf2H+xqnnRDUA4aqANkDtU9HQ+NgDqmfxNa7 /gDqmieJiF/GmFmjtLLO+EW0UiauExOs6PEt2olH6kNF6lxX4Jkxdqn+zLWMspN2RjTr FC4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=57xpah1MphYSetvt47cPhUU6Uf9bZ4rXcMgA94WqDt0=; b=lkRBzkHnckwt+MGUtwybS5NOLjSfaDxBKIr6ZA0vGg6/8urmGo3swR3ckGAwHFDFKq H3tvX11Nkm3kxHN3U5D1CJvOogWBHrlNgVmrYuacPUHqba9M4NqPz5/iicL/8mR2qAXG PamrTPjLI2qiW/7XH11Yt/pLo6g6+kVO3N0KyqM+Qj5ynfECGQ4Kh6WarSmfIv10wH45 NWnKyTlpDlonQSpi0e0oCdUd5mqLGN/Aieyow4ZAhYAwGWAL1ohBN84MvFc+57egQNly +r8ZsRfryKm6gS0qpSi9lShEBbUEkiTmcFDKRzcAwsoRBnaLqh3W30Z/NUUBQDLzsvHp UF+w==
X-Gm-Message-State: AFeK/H2/AAog9Z8rYAAY3lqAelTwZKHNObi2uJMAZCFLduEk2XJ6k+K9YN9xhZVLRIvZhw==
X-Received: by 10.98.218.73 with SMTP id w9mr38900786pfl.100.1491528299677; Thu, 06 Apr 2017 18:24:59 -0700 (PDT)
Received: from [172.10.3.106] ([202.65.34.7]) by smtp.gmail.com with ESMTPSA id m20sm5829111pgd.32.2017.04.06.18.24.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 18:24:59 -0700 (PDT)
Date: Thu, 06 Apr 2017 14:51:40 -1000
From: David Conrad <drc@virtualized.org>
To: dnsop@ietf.org, Paul Vixie <paul@redbarn.org>
Message-ID: <f321b974-2149-478d-9b63-a19d10ed013e@Spark>
In-Reply-To: <2448193.4rPzoQ60ob@linux-hs2j>
References: <87inmhrjpx.fsf@miraculix.mork.no> <58E63559.1030608@redbarn.org> <6ac82154-9990-4f20-9d38-090df7a3e098@Spark> <2448193.4rPzoQ60ob@linux-hs2j>
X-Readdle-Message-ID: f321b974-2149-478d-9b63-a19d10ed013e@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58e6ea67_66334873_12065"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zEI_06n_qSAR2-u85dB1gj10ZIE>
Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706
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, 07 Apr 2017 01:25:02 -0000

Paul,

On Apr 6, 2017, 2:24 PM -1000, Paul Vixie <paul@redbarn.org>, wrote:
> the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or non-experienced or non-protocol-geeks;

7706 doesn't recommend editing someone else's zone file, re-signing it, and figuring out how to replicate the hints and trust anchor to _all_ relying devices (and restoring the real hints/trust anchor when you're done). This strikes me as a bit more complicated than 7706. YMMV.

> and both approaches are appropriate only for closed internal networks where the configuration is controlled by a single administration.

If I set up an open resolver using 7706, what negative repercussions do you see?

> the misstatement is, dnssec's purpose is not defeated, because iana's signatures are checked before the zone is accepted, and new signatures are added using local keys before publication.

Meaningless given you are explicitly editing the zone as published from and signed by the authority. You claim you aren't modifying the namespace content (well, except for the root NSes), but the point of DNSSEC and the rather Byzantine structures we've built around establishing trust is that we don't have to believe you: you can see _everything_ having to do with creating the trust anchor and everything down to the leaf.

The only advantage(?) I see in your approach is that is allows (forces) you to play around with the namespace and re-sign. Might be useful for neo maxi zoom DNSSEC nerd experimentation, however as mentioned previously, that doesn't strike me as something one might recommend lightheartedly.

> for my many-vm's laptop environment, running on a loopback isn't a solution.

I strongly suspect you could come up with a solution that didn't use loopback but which also didn't require modifying the root zone, resigning it, and getting all relying devices to use both your NS hints and trust anchor. Like, perhaps running on a non-loopback address within your flock of laptop VMs?

> http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/

Saw that a year ago and still think it post-hoc rationalization and specious, but I'm sure that's just me.

Regards,
-drc