Re: [Doh] Servers offering responses for domaines they are not responsible for

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 06 November 2017 12:07 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B444F13FBE9 for <doh@ietfa.amsl.com>; Mon, 6 Nov 2017 04:07:25 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=HTannUPr; dkim=pass (1024-bit key) header.d=yitter.info header.b=L2hiikOD
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 U5_ojzkVaitN for <doh@ietfa.amsl.com>; Mon, 6 Nov 2017 04:07:19 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9D713FB9E for <doh@ietf.org>; Mon, 6 Nov 2017 04:07:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9D9B7BF56B for <doh@ietf.org>; Mon, 6 Nov 2017 12:07:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1509970038; bh=05uzazE/bTjzLpNhNMVAc7MjqbtW3U4ejb6l/YOu7ao=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HTannUPrIamZAPzqltenXkSzfG0WhEHF0hji41EURDnjAOJgfz1aPQ+9Cl12/CNYB IXaz0xG/AzCPt6C0JCByySyih0xR/vXGm2qChzMQu9f2ogz8LCncVMfgqRBPNqcUez Qtcd0ygF6n6souZXTJzmTX9yH19YLYO/jU46mpXU=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id masGpBr8-SJZ for <doh@ietf.org>; Mon, 6 Nov 2017 12:07:12 +0000 (UTC)
Date: Mon, 6 Nov 2017 07:07:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1509970032; bh=05uzazE/bTjzLpNhNMVAc7MjqbtW3U4ejb6l/YOu7ao=; h=Date:From:To:Subject:References:In-Reply-To:From; b=L2hiikODd3Z8SMbQoQHNlTaBWF8N3P1StyCbRbFFDVWuvUUXIYU00oeI5qeT9oGdl fedtZnEtduoYQhXhIUHUgaV2Bt6nGoPwJJy4r2FdZNPLN3kNUUqM+p0wX3meAb0Mbf 7m4DjrPAJP322/Jl6HKO+sjjG/CG1ErwXE+kv9rY=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: doh@ietf.org
Message-ID: <20171106120714.jxhnxoc4b4kv6wtt@mx4.yitter.info>
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org> <E304CB00-95E6-4868-B3C4-FDF4049F6492@mnot.net> <202fca9c-d9e3-7a11-3cc7-2cc61b59a84f@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <202fca9c-d9e3-7a11-3cc7-2cc61b59a84f@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/gjpifxRp0XmiTlQGU-MKCZzg2t8>
Subject: Re: [Doh] Servers offering responses for domaines they are not responsible for
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 12:07:26 -0000

On Mon, Nov 06, 2017 at 08:25:17AM +0100, Eliot Lear wrote:
> 
> It is a *a* remedy, and could certainly be mentioned.  However,
> precisely because of the warnings in that document, it probably
> shouldn't be listed on its own as the sole recommended approach.

It's the only thing we have that solves this problem today, however.
If you want geo- or even (and more accurately) network-topologically
sensitive answers to work, you need to know where the query originator
was.  For years we used the network address of the resolver as a proxy
for the location of the query originator, but in a world where
resolvers may be quite distant from the query originator that doesn't
work, and it doesn't matter whether the query travels via UDP port 53
or some other mechanism.

And indeed, given the DOH use case (which as we're currently
discussing it is really just last hop), I'm not sure what the problem
is.  This is directly analagous to a stub contacting a full service
resolver, and that's exactly the problem the large authoritative DNS
tricks have and that edns-client-subnet addresses.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com