Re: [Resolverless-dns] Paper on Resolver-less DNS

Fred Baker <fredbaker.ietf@gmail.com> Thu, 15 August 2019 22:01 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220721200C7 for <resolverless-dns@ietfa.amsl.com>; Thu, 15 Aug 2019 15:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bcl8N8Wsu6jV for <resolverless-dns@ietfa.amsl.com>; Thu, 15 Aug 2019 15:01:27 -0700 (PDT)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 044D91200EC for <resolverless-dns@ietf.org>; Thu, 15 Aug 2019 15:01:26 -0700 (PDT)
Received: by mail-ot1-x332.google.com with SMTP id b1so7860931otp.6 for <resolverless-dns@ietf.org>; Thu, 15 Aug 2019 15:01:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=G5ZwPRB9iaUY5cBWsH2UDIpXr6HVCaw0wbeAGQL+ZVc=; b=T3K6MOMJlIHEHrp1eZReHkxnKPlcNHV7pitTJRp9ec4o2SrjU5uHbCE/QZ+kYKxlrg yL2pgAygfcy2KyU3O2YtpIg4NO3H/D4WQkTYxjYlUIqIMqcWNdfIgRfQFvUtaD+LW5Yo 2g/LuyCaETBTNUVSUZsvWzF12+AjFuoGZZDywSeQ+YHLNBIIg6nEQx9sa01aasA/tCyU lhnd0gNPrphHPCwgq/+Q9xKehl5EJXMj7k9wMshFRoA86VCdJW6Xn3YqnzuA82RJwZ5X G1DDVDH6NhVH7WR2nCUOg2ZaJE9oxK3ST3tfnFqlPr9gzq7zhQCLHAJf6xIjYzkStV56 wUag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=G5ZwPRB9iaUY5cBWsH2UDIpXr6HVCaw0wbeAGQL+ZVc=; b=k3uR69gYyJqEUO2dv342k1U43u3pDqANeZrnzcGUas69B3yiUQWWetlK7BpYlCKv3L q89DoSUKsD1s3MXOXiwFtZbuvB+45D9a7WR1LO9OhlrTxBpfdUedr9pwT3VmimXDd/WY CxL7p5K2WdLI5gllAeYY+7uac8mTiSOb9HtWOf+SgeDtjCkunVPGyxDCmN7T1+eQYvFU c0ciqPfK6zFz/XkNBaDUs4ly3OHIyqbbKwvhufK4TTdq/fIaPSgMOn9J00erU/cve6os Qh6xa4/SlF2Dhr+kVdInm9WIlovjI56z9wfagx95lwDsMuFXyNKi4/U+F5kie1WBLQ0v Yrtg==
X-Gm-Message-State: APjAAAXEaHlyyTq48iJH6QYm0GkICXjzefqtqyXz9XvZ/dQkw+epcYNs Rl0uzwheafOsZBav7ovnpIU=
X-Google-Smtp-Source: APXvYqyjuxHIM+n98HL29LK9EPNKUG7x3V5nUMudIe7nYom7Tutg+p9nKJS+K0iDNRpcUpEX1tzMpQ==
X-Received: by 2002:a9d:5911:: with SMTP id t17mr4802690oth.159.1565906486273; Thu, 15 Aug 2019 15:01:26 -0700 (PDT)
Received: from ?IPv6:2600:8802:5903:df16::1052? ([2600:8802:5903:df16::1052]) by smtp.gmail.com with ESMTPSA id s5sm1398482otk.11.2019.08.15.15.01.25 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Thu, 15 Aug 2019 15:01:25 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-17E27551-4912-4816-BB97-9A4AFDD22795"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <CAMOjQcEnhov9AZMQSpDoF2k06P36bce0SNjKoLcquyDZk1q+KA@mail.gmail.com>
Date: Thu, 15 Aug 2019 15:01:24 -0700
Cc: John Levine <johnl@taugh.com>, Ben Schwartz <bemasc@google.com>, resolverless-dns@ietf.org
Message-Id: <AEF8A95A-212C-433B-9B22-9AB971F03491@gmail.com>
References: <CAMOjQcEnhov9AZMQSpDoF2k06P36bce0SNjKoLcquyDZk1q+KA@mail.gmail.com>
To: Eric Orth <ericorth=40google.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (17A5556d)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/FQHK0jiojXAqonLHO_-qHqrM5oM>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2019 22:01:29 -0000

One thing I would want to be certain of is that the host did DNSSEC validation. It’s the only way I know of to verify the validity of the RR.

Sent using a machine that autocorrects in interesting ways...

> On Aug 15, 2019, at 1:13 PM, Eric Orth <ericorth=40google.com@dmarc.ietf.org> wrote:
> 
> 
>> On Thu, Aug 15, 2019 at 12:39 PM John Levine <johnl@taugh.com> wrote:
> 
>> I also like the paper but it misses the largest concern with
>> resolverless DNS: it circumvents DNS based access controls.  I realize
>> this is not a popular position in the IETF, but there are lots of
>> perfectly good reasons that networks provide filtered DNS.  Even
>> though it has usually been technically easy to circumvent, most people
>> don't and it's been good enough.  If it's widely circumvented, we can
>> expect much more intrusive filtering with a lot more collateral damage.
> 
> From the Chrome perspective, this is a concern I partly share.  I'm mostly ignoring here the circumvention and forced-filtering issues of whether or not the network should be able to mandate filtering/manipulation or whether or not clients should be forced to comply with such things because that issue is being debated enough over in the ADD mailing list.
> 
> But if Chrome is using a particular filtering DNS server, especially if that server has been explicitly selected by the user or someone with authority over the user's device, seems like it would result in a bad user experience if we then bypassed that filtering by retrieving results outside the DNS server.  My initial thinking is that we would then ideally only use resolverless DNS if we had knowledge that the in-use recursive resolver is not doing significant filtering.  But such a signal does not currently generally exist, so would we be limited to only doing resolverless DNS when the resolver is on a hardcoded list of non-filtering resolvers?
> -- 
> Resolverless-dns mailing list
> Resolverless-dns@ietf.org
> https://www.ietf.org/mailman/listinfo/resolverless-dns