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, 06 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
- [Doh] Servers offering responses for domaines the… Paul Hoffman
- Re: [Doh] Servers offering responses for domaines… Mark Nottingham
- Re: [Doh] [Ext] Servers offering responses for do… Paul Hoffman
- Re: [Doh] [Ext] Servers offering responses for do… Eliot Lear
- Re: [Doh] [Ext] Servers offering responses for do… Martin Thomson
- Re: [Doh] [Ext] Servers offering responses for do… Eliot Lear
- Re: [Doh] Servers offering responses for domaines… Eliot Lear
- Re: [Doh] Servers offering responses for domaines… Andrew Sullivan
- Re: [Doh] Servers offering responses for domaines… Eliot Lear