Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Matthew Pounsett <matt@conundrum.com> Wed, 21 December 2016 17:14 UTC

Return-Path: <matt@conundrum.com>
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 3E564129670 for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 09:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.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 SnoHehawjQBf for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 09:14:26 -0800 (PST)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 B2DD1129438 for <dnsop@ietf.org>; Wed, 21 Dec 2016 09:14:26 -0800 (PST)
Received: by mail-vk0-x232.google.com with SMTP id y197so4355694vky.2 for <dnsop@ietf.org>; Wed, 21 Dec 2016 09:14:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SW/h+36xhiUhfB90vH0cZ3pbTJebqjbxRh8y+AAAeQE=; b=1bRg3dulv+sBXSAaUHyNzD0wXJsqUvykJD83eHbe3SP6jwvlmZb1fGnOuFWW2eMfRM V/wr2ATz1IIcAY8Fa5vX7GuriwTb5fiq12wOygY5eWvrtRcSvPqgIjxw4ZcozwsUWdav CrC7RidU4xhrddDFknT/o31oMsbgP5aBcGLu1Wd0qJhC2SlU3J90Qm/pgc3apENJtEud PdGSE9ERVQLwA2cE3p8t53lKJOvoTwFfqqP9TMmswqNbl4Hb6pr+RtvM8pRdZaUpse6u s4OTMNPOBgUFgM9qHSAtPOWHKoNey9BttbSmhS/zldumvRyvzpIfdU9y63+g0/mUXcZo 5FUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SW/h+36xhiUhfB90vH0cZ3pbTJebqjbxRh8y+AAAeQE=; b=KftlMKgkdwQ3F6cj6IolADeb3DEmCtpAlHjU5n4PWOg8aWdkv2g7KUr0djbd59Cgyl wFb4hlb5gjvBdehTaggfExja2Y96EGpMqwmUKrupG+ivxAtGURLd5OWTtimWNlb/kZ8Y 6i2qGAsyoQY2nwiOny7MLIaW6hKAp2hy+7cuFlEd9Geew+HXlkXizA9lplYLiZHib08v 9qqtJmOXImsUi/WxOuBOtlO91g/TNWs4kza1zA8j5Lz0SoIlP0g45yup/6ZaVLAIjukZ SFihPkPAEcWseUNYo3mWvcAbn4OY15OfFshObPYyloRg9WmwjxKWTNPionpIa5CbmGQv ZhVg==
X-Gm-Message-State: AIkVDXKgWuLpXo7x9PLyNhm5Klle0zt25nAtHjIH6A/MbXSx40Cgwqbg6se6jkjoMSEpNyK4LDju5kp1dNhmkg==
X-Received: by 10.31.80.197 with SMTP id e188mr2334224vkb.109.1482340465770; Wed, 21 Dec 2016 09:14:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.133.135 with HTTP; Wed, 21 Dec 2016 09:14:24 -0800 (PST)
In-Reply-To: <alpine.LRH.2.20.1612211047200.13966@bofh.nohats.ca>
References: <C18E2D4E-EE89-4AF6-B4A0-FAD1A7A01B5E@vpnc.org> <5248A099-7E1F-437A-A1B7-C300F917D273@fl1ger.de> <CACfw2hj4VfuqsM-jRpxNc+bWNsUcSid+Y=r9U5jsA-0ZLbLRUg@mail.gmail.com> <20161221.163826.74705202.sthaug@nethelp.no> <alpine.LRH.2.20.1612211047200.13966@bofh.nohats.ca>
From: Matthew Pounsett <matt@conundrum.com>
Date: Wed, 21 Dec 2016 12:14:24 -0500
Message-ID: <CAAiTEH_-LGUkpmPjDRsKpnPhXev1sNdF_2yaVXKmeWMJ7vm_eg@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="001a114e2948e62a4b05442e48ea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/e2yrQ_sKklrhFU9JzS66W48Tz64>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Dec 2016 17:14:28 -0000

On 21 December 2016 at 10:53, Paul Wouters <paul@nohats.ca> wrote:

>
> And 1) should not need to break DNSSEC. IETF should come up with a
> better solution for signaling a DNS lookup might be unhealthy for
> the enduser.
>
> Other than returning an altered answer (pointing to an informational site)
or no answer at all, what would this look like in practice?

The signal probably needs to be in-band in the DNS response, and downstream
recursive/forwarding servers need to know to pass those data along with
certain responses. So there's a change to the protocol.

Libraries (glibc, etc.) need to be modified to receive and understand these
new data and pass them on as part of a gethostbyname() call, so there's a
change to all operating systems.

Applications that use the DNS need to understand this new signal and know
what to do with it, so there's a change to every application that uses the
DNS.

These are the things you need in place for an alternative to be effective.
I think that would be a fantastic way for things to work, but we haven't
even managed to get a majority of applications to implement DNSSEC yet.

If you think the above sounds silly, then please propose some other
alternative with a shorter path to deployment.  Taking it out of band of
the DNS probably makes things simpler, but then you still need to modify
every recursive server and every application.  In the intervening decades
while that is being designed and deployed, operators are going to continue
using RPZ or something like it, so why don't we document that, and how it
should work?