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

Ben Schwartz <> Mon, 23 November 2020 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AD793A129F for <>; Mon, 23 Nov 2020 13:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.7
X-Spam-Status: No, score=-15.7 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, 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 kLKEYqdakrns for <>; Mon, 23 Nov 2020 13:21:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C83993A12A4 for <>; Mon, 23 Nov 2020 13:21:21 -0800 (PST)
Received: by with SMTP id r9so19645885ioo.7 for <>; Mon, 23 Nov 2020 13:21:21 -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=mKGPBJD/+rZGeSCsUdYWyHK0vDXUytvjT1FuvohXBYY=; b=HMbE8hUu5V9vzE7FHCdSfTQfzBQrI8shqhi6W4arFqqW7bxz5Pgmzim4Bx+Kv1Tj3h vwMoJuYlFxasbsjObe7lt8qaVoizfvCZ8HnTMb6tmByTw4eRQD4yBrnQqFcNAmXyVXLQ 1idkWEJ3cEn3yfggFYGBd6zrYXotwmAtagTS3vNuFhUPX6gC8xcRUtHQhuCybyLwGlH7 SYIbnrEp45caAh7ODkSYJjqRJuc60ejCjMMqBP9/32sGKdTzOVyPfIzWwEtX+M61zCSP qyYwkcXa1EydcEr9RD4R2yQfe4VeJl+hRbWfBISsZJCJZQ20gw9AWMDrm66YFgErB0zT l4jg==
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=mKGPBJD/+rZGeSCsUdYWyHK0vDXUytvjT1FuvohXBYY=; b=ltT1aNrDU9xpO4TuCIm3vFVIxz2XNs1bVPnlNAYrqMa++sAssMYGa+0CRPvG17mRoO ocQJnB8KkE2K0dFMWB9+rN5ZVZkCfGKfzsftqXp6g5eA2JN4xkcsNI7vMIfrp1P30Kxh rtCA663mUtHOQPuT0x5966yZeuo4nnCcPQJvNoQnulDu+kQIqstHKmLaJI2y6HxgswhB t4feI/u3QrEWE6pAWZxt+At6dauMG0OTW/8yQBVdETIPOHel/QkNg1zioolHj/7JBlHI BrotQfvQca9VIx1seGaHkTCRSFzBUAA80RyYRGCGT8CpMWbN/71dMeMcYItZDN4w0/M0 OZhA==
X-Gm-Message-State: AOAM531qLHy9JqztOpnzYhzqiJpxd1yyMoaRqJe8d9tOVg3AQD/a7C2E KG1pi0osx04J6UxALWTzTPY4O/L/CYP9i50nw3UJKw==
X-Google-Smtp-Source: ABdhPJw+dYfSl80hTtLR0jfTVm+gc4VYdilQ3+lc/5dY5DM0zvsU+ydle813TjO/qDV4K9dvreKJu1yqxT4MJPNbA2k=
X-Received: by 2002:a6b:8b0d:: with SMTP id n13mr1450873iod.111.1606166480781; Mon, 23 Nov 2020 13:21:20 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 23 Nov 2020 16:21:09 -0500
Message-ID: <>
To: Brian Dickson <>
Cc: Manu Bretelle <>, dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000008fe7ac05b4ccc614"
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: Mon, 23 Nov 2020 21:21:23 -0000

On Fri, Nov 20, 2020 at 12:49 PM Brian Dickson <> wrote:

> 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.

I think it's worth focusing on the use case.  If the use case is traffic
optimization, then we want something more like ECG, even if the resolver
decides to label all queries with its own country code.

> 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)
> I don't think any of these use cases motivates an exit-IP-geolocation
design.  Instead, they motivate a hierarchical affinity or labeling design,
allowing the resolver operator to indicate which IP prefixes are managed
together as a group.  There's nothing necessarily geographical about this.
Cloud services often have several reliability "regions" that are within a
few kilometers of each other.  Some resolver operators deliberately use a
mix of nodes running different software stacks, spread out across their

In many deployments, geolocation of the exit IP is meaningless: the stub,
caching forwarders, recursive logic, and exit peering point can all be in
different countries!  This is green-field design, so we should take the
time to express the right semantics.

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.
> Brian