Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

Paul Vixie <paul@redbarn.org> Wed, 16 August 2017 20:13 UTC

Return-Path: <paul@redbarn.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 3072C1326DB for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 13:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 byBspUgkbI9v for <dnsop@ietfa.amsl.com>; Wed, 16 Aug 2017 13:13:24 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC761326E1 for <dnsop@ietf.org>; Wed, 16 Aug 2017 13:13:24 -0700 (PDT)
Received: from [IPv6:2602:306:8074:1ac0:8c44:219f:380c:bf7c] (unknown [IPv6:2602:306:8074:1ac0:8c44:219f:380c:bf7c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4F4C561FF3; Wed, 16 Aug 2017 20:13:23 +0000 (UTC)
Message-ID: <5994A761.8080009@redbarn.org>
Date: Wed, 16 Aug 2017 13:13:21 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.16 (Windows/20170718)
MIME-Version: 1.0
To: Vernon Schryver <vjs@rhyolite.com>
CC: dnsop@ietf.org
References: <201708161733.v7GHXWwr028294@calcite.rhyolite.com>
In-Reply-To: <201708161733.v7GHXWwr028294@calcite.rhyolite.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CJB4Eu52GM-jP9XSr9defXrYDss>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt
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: Wed, 16 Aug 2017 20:13:26 -0000


Vernon Schryver wrote:
>> From: Paul Vixie<paul@redbarn.org>
>
>> some time before bad people get around to using dnssec to bypass rpz,
>> the spec will have to evolve to allow new signalling ("i want to hear
>> both the truth and the lie, and please sign the lie with our shared key
>> so i'll know it's from you").
>
> I disagree.  The last year has shown there there is limited appetite
> in the IETF for RPZ work

i think we have to keep trying until and unless the co-chair say to stop.

> A second issue concerns the use and purpose of the DNS.  No applications
> that are not DNS debugging or forensic tools want both DNS truth and
> lies.  All ordinary applications want an IP address and sometimes
> application protocol data such as in SRV, MX, TLSA, and TXT.  ...

well, yes, but a directive in /etc/resolv.conf saying what lies to 
trust, or whether to trust all of them, or whether to trust none of 
them, would be a way for a system operator or owner to set response 
policy for all applications. the resolver is a dns-aware application.

> Users of applications might want either truth or RPZ lies, but not both
> except for debugging and forensics.  Those user preferences can vary
> depending on the application.

if an application wants a different kind of lies than is the default in 
/etc/resolv.conf, it will need API hooks to say so. i predict that the 
getdnsapi team would offer such hooks if there were an underlying 
protocol with knobs like that. obviously "dig" will always just print 
both the truth and the lies, and let /dev/stdout sort out the meaning.

> On the other hand, there is already signaling that provides both DNS
> truth and lies.  A UNIX shell command like `alias honest "dig @8.8.8.8"`
> implements kludge "signaling" to get the DNS truth, while straight
> `dig` gets the possible lie.

alas, this is unreliable. i've been hooked up to networks with policy at 
the IP layer causing 8.8.8.8 requests to be rerouted to a local DNS 
server with advertising (NXDOMAIN substitution) support. considering 
that google's original motive for creating the 8.8.8.8 service in the 
first place was that various rDNS services were giving locally-faked 
responses to "www.google.com/A", i think this shows the slipperiness of 
the slope, in neon glowing detail.

> The SOA added by RPZ to the additional section is perfectly sufficient
> to signal the honest presence of an RPZ lie.

well, yes. but it may be the law of the land in some countries that 
citizens accept DNS lies, whereas foreign visitors can accept DNS truth. 
so i'd like the protocol to carry both (lies and truth), with 
policy-level digital signatures on the lies, to be sure they are coming 
from the place we're expecting our lies to come from.

-- 
P Vixie