Re: [DNSOP] Meeting feedbacks/summary on draft-bretelle-dnsop-recursive-iprange-location

Brian Dickson <> Fri, 20 November 2020 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 627253A0CDC for <>; Fri, 20 Nov 2020 09:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hJqBPMHmOqAa for <>; Fri, 20 Nov 2020 09:49:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 022AE3A0CD7 for <>; Fri, 20 Nov 2020 09:49:54 -0800 (PST)
Received: by with SMTP id u24so5419012vsl.9 for <>; Fri, 20 Nov 2020 09:49:53 -0800 (PST)
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=TS8w8co495OgQu9+Mx5ouEtblXdUAuS/gWRBgtuU5FE=; b=YdukxS227VyDxzfRxfs33jBLhPDF/pGV37RiNY8SAZLuHTLEwjRtd1I+PUv1ctxVKL mh7oQdg1e6Ac/D1WZ0uXg+TQ/+WkjPuqZ+5BSI7thZ1jDHiHmf0pZkyyraEe4+Z1TOOU zC/X4INV1fTBxH+/t0uPN4ldar+1SXx0xp9H+gRFX9cytwTVqcqGiXszhBHf8hpRP0WA 3QpafUzMiHgsYdO/xGW/Fsf/ziP2NTEAqAsmRn6Vne+G2jkrhmh8wPHozrTY1TWU7YU7 7fp8AwLlKajfA5mCoXHQBQkTWzJtaLFUvyzEw45uqzJOIvRex57hfXYAzfnXDI+vl1y4 qk5g==
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=TS8w8co495OgQu9+Mx5ouEtblXdUAuS/gWRBgtuU5FE=; b=FJTAWpftayD7qdcO32lrY4dbKpSr8+foqNHz30pKy29L17/v/75x/5fPIhpx/b44BS Prc4EC+9R8g4lTSIahLGkvUUISvzhzlZP32aTLDAv8LxvT4jfy/PV66u948L0xOagQCC 3s5zkQmtKkcs7+B2Nfznzvg2D8yfBHXzFW33xmdUXAYtZFN7jBuFoCOM/quM00FSA3AR cFH5Arv4NNLnA91G00UxlL1B3AEcDzFyYMnBipfufgyEsC+u6CDvNU0QPd0ysCHf0OCa fHN/rNYR0JaKmBpZZrcZOYoYa/Wvtxo+PZM56RpbDYLgcipbL/DCx8E8q9CtM+bC6wQg F9IQ==
X-Gm-Message-State: AOAM533VV3w/hiwgRF9tuXUP3P/IYIQADRxgKtjM7TqHzbfhQoWrHbMx XNKeElYncCrAo+fGp1Wi+p4+Z3Htm+F9PxlnXS4=
X-Google-Smtp-Source: ABdhPJx/UYmdRELBXuWZQ0Al9zKLGW6xSDDEsMqqG3ZVQ4qiYXn27+i0ZEYnkStBS+eYr6C56v1m/ZmmnaAzUo6ll8Q=
X-Received: by 2002:a67:eb42:: with SMTP id x2mr13719534vso.41.1605894593085; Fri, 20 Nov 2020 09:49:53 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Fri, 20 Nov 2020 09:49:41 -0800
Message-ID: <>
To: Ben Schwartz <>
Cc: Manu Bretelle <>, dnsop <>
Content-Type: multipart/alternative; boundary="000000000000c4873b05b48d782a"
Archived-At: <>
Subject: Re: [DNSOP] Meeting feedbacks/summary on draft-bretelle-dnsop-recursive-iprange-location
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2020 17:49:58 -0000

On Thu, Nov 19, 2020 at 9:35 AM Ben Schwartz <bemasc=> wrote:

> I do not support the geolocation function.  I think the right solution
> here is ECS.  Even bad IP-geolocation from ECS will be better than using
> the recursive resolver's country-code; at least it will be estimating the
> location of the right entity.
> If ECS is not widely deployed enough for your purposes, I would focus on
> ways to increase support for ECS.  For example, we could work on ways
> to use shorter prefixes for improved privacy where appropriate, or provide
> guidance on how to use ECS for geo-based responses.

I agree with the sentiment against providing differentiated answers based
on the geo of the resolver (mostly).

However, geo has other valuable uses.
Thus, I'd like to retain geo as part of the standard.
I think recommending against using it as a proxy for ECS should be included
(with explanation, obviously).

One reason to have explicit geolocation is that the geoip of the resolver's
IP may not be accurate or timely, and for these use cases, explicit geo
info is always better.

One use case I raised at the meeting at the mic was grouping providers'
regional resolvers for various purposes on the authority servers' side.
Those things would include treating a regional group the same as a single
resolver, for purposes of white-listing, or rate-limiting, or other
operational activity.

There are other kinds of things that authority operators would be able to
do, some of which cannot be done today.
Those include:

   - Alerting on changes in affinity between resolver groups and authority
   instances (which might indicate a routing problem or outage)
   - Visibility on new deployments of resolver groups by a particular
   resolver operator (which might benefit from resource allocation work on the
   authority operator)
   - Ability to detect or prevent spoofing of resolver IP addresses
   - Ability to do cooperative work around ADoT
   - Ability to correlate oddities (e.g. unexpected DNS cookies, set by
   auth location A but seen by auth location B, associated with IP and
   resolver Geo info)

On the other hand, I could see a potential longer-term replacement of ECS
with ECG (EDNS client geo) once the geo stuff is standardized.

But let's not get distracted by that in the short term, where direct use of
resolver geo has real value.