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

Martin Thomson <martin.thomson@gmail.com> Mon, 06 November 2017 05:18 UTC

Return-Path: <martin.thomson@gmail.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 6C27113FB78 for <doh@ietfa.amsl.com>; Sun, 5 Nov 2017 21:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 8XYT8so-JTu7 for <doh@ietfa.amsl.com>; Sun, 5 Nov 2017 21:18:46 -0800 (PST)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 B12D713FB0B for <doh@ietf.org>; Sun, 5 Nov 2017 21:18:46 -0800 (PST)
Received: by mail-oi0-x22d.google.com with SMTP id q4so6220867oic.7 for <doh@ietf.org>; Sun, 05 Nov 2017 21:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aqJXSevCZXvhlqw0DQTj8pSKUQen/FP7/Y/d2hRaXpk=; b=cA685ThD2TSrBGyPMn/EgMyl2FogeIUe8yI40gColRyIz6v3Jcllg2SIhEQbf39Gmf ZQKWKAj7k6BIfjmVrE47rp45SWIPH0IbhSgmHL9ZQtYbMPazIw6tccKAOJjLbshupO/W x2Gr4Ys/9lO+iybNMHLzYQgMbcRyXFti8xb7LmaSKWEMV3D8xcOOOeZ2tM8oKT3l96JD djNcJW/qa+ISA87qIoyoTHttPPKoW9aZqXLm2tvtMYtp+DZsUS/NsaYSQYW8aTB02tFB tcgzwGBVPeY03f63ufhASDtp9WJTmjtaFkpAFthU6ygEQJHYjwb4ldhzzJlTqASx9bGy AJgA==
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=aqJXSevCZXvhlqw0DQTj8pSKUQen/FP7/Y/d2hRaXpk=; b=qRwKiG0f0RKrId0XTxmev4AvyWz0auXAf09wRpcBBVkwntDMOrXlrZ4eHlpr/+VRqG Jnzuh462FmqmWHj6ZEfBAaqMOWBptnQFXHuRoBhJrBiWgmiIKrztaDmFcBykhoyPse+W TW9Dm8S1SOV/KThPbkwG+E/YoDgdzRlTrgD3ahGlhCK8p/BshzdlvHjqYhBWucLL7MxI 5XCFFeSLo9c4Tm3O428HVkq//nb9vIwvc+9hJ2peEph60iPkBiFrr2HTXI8OLyfCzpQQ 6khtPEVSuLmhhedA659AVekF6NcXmbGf2uMJxPgWgS6oI360ZgQhSFvoHr8d4zf5qpyV dqkw==
X-Gm-Message-State: AMCzsaVHamOicE1dLb8i49QEBQUPv1I4CCpJJkWq3cb5IjZms2qdG1t3 fqXJK7Y/zO8ozkbA477IqRcnUUNu8nZdI3SeCwk=
X-Google-Smtp-Source: ABhQp+RugMzavL1zoEmBoQKwTdMucROjpFHzRaf/NLIR0hgUAh/N8c/gtbMQg/CsER/MClIcZaUKWxfG1UzMMMFmTvU=
X-Received: by 10.202.75.140 with SMTP id y134mr7609504oia.3.1509945525986; Sun, 05 Nov 2017 21:18:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.15.155 with HTTP; Sun, 5 Nov 2017 21:18:45 -0800 (PST)
In-Reply-To: <06878054-f48c-0877-d556-a108a6241d01@cisco.com>
References: <16B93F04-FE24-4C61-94F3-87EF7707F10E@vpnc.org> <E304CB00-95E6-4868-B3C4-FDF4049F6492@mnot.net> <1819FF02-9147-48A8-867E-82BA58AC332A@icann.org> <06878054-f48c-0877-d556-a108a6241d01@cisco.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 6 Nov 2017 16:18:45 +1100
Message-ID: <CABkgnnXYrNqZeyUQ8E7F61mCAd-8GywduuAJx7sQLkWDUuXdUA@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, "doh@ietf.org" <doh@ietf.org>, Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/DgAJcvKos_JOIayYDl9d-jIQvOY>
Subject: Re: [Doh] [Ext] 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 05:18:48 -0000

Eliot, are you assuming that the DNS client will be looking at
responses from origins other than the one it has configured as a DOH
server?

That is, say that https://example.net is configured (or just
example.net), but if I talk to https://somesite.example and it
provides what is an otherwise valid DOH response, are you assuming
that this response is used?

Generally speaking, even if the DNS client shared a cache with a web
browser, this wouldn't happen without the DNS client taking special
steps to enable it, so I'm not sure why you would be specially
concerned about this.

Of course, I would still be supportive of text that made it clear that
this particular model is not in scope.

I don't want to categorically rule this possibility out forever.  For
instance, we might be able to convince ourselves that
https://somesite.example can be trusted to speak for itself.  But I
agree that anything that differs from the accepted model would be
difficult to get right for more than just this reason.

FWIW, I think that the notion that we use HTTP caching ultimately
enables better operational stories here, not worse.  Tighter control
over caching might avoid certain performance problems.  See for
example the stale-while-revalidate option previously mentioned .

On Mon, Nov 6, 2017 at 3:57 PM, Eliot Lear <lear@cisco.com> wrote:
> Hi Paul,
>
>> In fact, I don't understand Eliot's concern here. DNS recursive resolvers (which is what a DOH server would be fronting for) are not "responsible for domains". Authoritative servers are responsible for domains.
>>
>> Eliot: can you say more about your concern here?
>
> Sure.  DNS-based load balancing mechanisms assume that the source of a
> query is going to be proximate to the originator.  Use of DoH may upset
> that assumption.  In the extreme case, imagine having just one DoH
> caching resolver out there, and all queries flowing to it, from anywhere
> in the world.  Especially if it is caching, any number of queries would
> end up returning addresses that are local to that one DoH server and not
> to the originator.
>
> I mentioned authority here only in as much as I don't care what a DoH
> server does for services that are related to it, but if they are not,
> and if it really is just acting as a caching resolver, then this issue
> comes into play.
>
> Eliot
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>