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

Eric Orth <> Thu, 15 August 2019 20:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B05E1200CC for <>; Thu, 15 Aug 2019 13:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G0TgAT5qzSaZ for <>; Thu, 15 Aug 2019 13:13:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD99712007C for <>; Thu, 15 Aug 2019 13:13:43 -0700 (PDT)
Received: by with SMTP id g17so3306301wrr.5 for <>; Thu, 15 Aug 2019 13:13:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ha+OZlJ5KFkeL/s3fKphvME3dQrXp0vwQ8J08v2AETU=; b=ZbO21nHL9x+gDnUl9SIM5JsqSN8FA36TFmLgoJTfGfJXjAyANGPJIDoi4l2kK5zM36 0hKkz/njl5g4WlOm8fWlQy6mNRuL/JNaowyC2Ov27byZs6ZZt+aOgtbnj+f2TknEXbSr pzM91etCyloZEE5886lr7Lzubhh4wHF6v1P0loaiSp/YW5PJQb5u+MbB10Eb4MkStF5J HXFAO1sQ7BJa7HlBERlTBZedWJ1JEL01F/FuLDnqcHV7au1E+FS7riFGujD/7K+lS05b WMKAdvXjGHL4RWtfeRf0GqxmyuBfVJ46bs+o6NJeylsgHKgcOub523nZUkAtw8jQ3ILa FVmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ha+OZlJ5KFkeL/s3fKphvME3dQrXp0vwQ8J08v2AETU=; b=MoOywq+3CIc4YhCTsVP3ADvVBCb6APtiLKLO+Xt4ucYybFC7gP7QuZox6tAPygYpoi jzh07t6yt687wVbkhQskCjIdWzQ8MgBY+UtLhyY531YN8LpJmlEXjEV2OzMzJMEzY1rv 6rUDgSlY0lS9bH72dzcn4092sm2OawZjnKFqRENO8RbBHraYTxNOrBneExdFeCbTWuCb LB9H9/i2C/zwZurqFYaMfpb3STBIxruGrRRIeoJrYDQE6qqx/VouEIjCJ9J/l2Ik7N2g jCQacPQGn4Zt61fNf3mR7584hSg2/PyhxgWtaZ6IzQIsOHsdg8q0y07YAOasK64CXZdG Xk5g==
X-Gm-Message-State: APjAAAXfXEyyglOXu89V3yRMInZe714Abwui3uETDifE9VDyjUFFhMOt wS0dVSiCMJqcJifvfWO607Wdj1cP3wa+ot2L10oEaw==
X-Google-Smtp-Source: APXvYqxAjJFU8ts5QHkC03wO3JLnCVxmDDHBZz1TtnhbYWZIETmpXbgAXaCdGHPrqvRnYsBlv710qC2IJN2UAnhGxw0=
X-Received: by 2002:a5d:634c:: with SMTP id b12mr6883693wrw.127.1565900021920; Thu, 15 Aug 2019 13:13:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <20190815163938.CF9CB85D108@ary.local>
In-Reply-To: <20190815163938.CF9CB85D108@ary.local>
From: Eric Orth <>
Date: Thu, 15 Aug 2019 16:13:30 -0400
Message-ID: <>
To: John Levine <>
Cc:, Ben Schwartz <>
Content-Type: multipart/alternative; boundary="0000000000008fde3905902d82b5"
Archived-At: <>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Aug 2019 20:13:46 -0000

On Thu, Aug 15, 2019 at 12:39 PM John Levine <> 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?