Subject: [DNSOP] draft-bretelle-dnsop-recursive-iprange-location

From: Manu Bretelle <[email-masked]>
Date: Wed, 4 Nov 2020 15:00:01 -0800

Hi all,

There is currently no streamlined way for recursive resolver operators to
distribute the IP ranges/locations that their server farm may use. It is
currently a mixture of csv files shared over email, or web pages with
formats that may be unique to each provider and rarely directly parseable
by automation.

This document is an attempt to provide a consistent mechanism that
recursive providers can use to distribute their ranges/locations, and auth
providers can use to apply the policies they may wish to.

Thanks

Manu

---
A new version of I-D, draft-bretelle-dnsop-recursive-iprange-location-01.txt
has been successfully submitted by Emmanuel Bretelle and posted to the
IETF repository.

Name:           draft-bretelle-dnsop-recursive-iprange-location
Revision:       01
Title:          Recursive Resolvers IP Ranges location distribution and
discovery
Document date:  2020-10-29
Group:          Individual Submission
Pages:          6
URL:
https://www.ietf.org/archive/id/draft-bretelle-dnsop-recursive-iprange-location-01.txt
Status:
https://datatracker.ietf.org/doc/draft-bretelle-dnsop-recursive-iprange-location/
Html:
https://www.ietf.org/archive/id/draft-bretelle-dnsop-recursive-iprange-location-01.html
Htmlized:
https://tools.ietf.org/html/draft-bretelle-dnsop-recursive-iprange-location-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-bretelle-dnsop-recursive-iprange-location-01

Abstract:
   This document specifies a way for recursive resolvers operators to
   signal the IP ranges and locations used by their server pools.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/chantra/draft-dns-recursive-iprange-location.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Manu Bretelle <[email-masked]>
Date: Wed, 18 Nov 2020 17:28:09 -0800

Hey all,

Thanks a lot for providing feedback on the resolver IP ranges and location
distribution draft [0] during the dnsop meeting.

I gathered the feedbacks below as follow-ups, but, based on some of the
comments made at the "mic" or over Jabber, I would also to provide some
clarifications as to the intent of the draft.

The primary intent of this draft is for resolver DNS providers to be able
to share the list of IP ranges they operate under in a standardized way so
consumers of such list can rely on 1 consistent format to access and parse.
As mentioned in the draft introduction, currently this is a bit all over
the place.
RFC8805 [1] does provide this format (CSV)/medium (HTTPS).

Amongst the use cases:
* Being able to access/distribute IP ranges is mostly useful for
network/DDoS/Response Rate Limit policies.
* Location (optional in RFC8805) can be useful for Geo based DNS answers.

While there is work on finding geofeed in the OPSAWG [2], this would defeat
the original purpose of sharing resolver-only IP ranges. One could possibly
say that only ip ranges are distributed and geolocation would be fetched
from inetnum object but it seems to be adding more complexity in both term
of consuming and generating the data as we now deal with multiple
data-sources in different operational areas (DNS vs Network).

Addressing the feedback category received during the meeting.

# Geo location is not a good mechanism for providing customized answers

Ben Schwartz and others on Jabber commented that Geo location is not the
right thing to use.

This draft is in no-way recommanding use of country/region... as the way to
do so called "geotargeting" DNS, neither does it tries to solve this
problem. I do agree that
geolocation is different from network topology, latency. DNS targeting is
even more complex than that and would take into consideration capacity of
the destination (compute, backbone to origin), drain ratio, overall health
of the system, (paid) peering vs transit... and more.

The thing though, is that not everybody can build this type of
metric/feedback loop and instead a lot are relying on the location of the
resolver (based on its IP) as a proxy for where to send an end user. This
is pretty much all you can get at DNS level. If you are lucky enough to
receive and support ECS then you can go a step deeper. Eventually your most
granular level of traffic steering (for the web) is going to be once the
end user connects to your service and you can generate pages with customize
domain to send them to a specific POP, or Alt-SVC.

Route53 [3], NS1 [4], DynDNS [5], Akamai [6] to name a few, provide such
type of targeting.

Opensource authoritative name servers also support GeoIP answers: Bind [7],
PowerDNS [8], Knot DNS [9]. Typically based on a DB in MaxmindDB format.

Resolver IP could also be used by people implementing Geo targeted answers
to generate ipv{4,6}hint SvcParamsKey.

So, while using a resolver "location" may not be optimal, there is real
use-cases and needs that can be served by standardizing this which gives a
decent amount of bang for the buck.

# TXT record, no, please no.

I hear you and provided this as a potential mechanism knowing that it would
be controversial.
To "facilitate" discovery, the idea would be to have this behind a special
underscore label.

Ben Schwartz mentioned that HTTPS would not be a good candidate, SVCB
probably more [10].
I had originally thought of URI [11] but favors HTTPS for its potential
extensibility (ip hints, ech, alpn...), even though most of those may not
be strictly needed for this use case.

Mark Andrews commented that APL [12] could probably be a fit with new
custom address family. It would mean that the family needs to be registered
in IANA's address family numbers registry for something that does not feel
close an actual address family.
Also, this record could quickly grow in size. Unless the intent was to use
it in reverse lookup?

Alex Mayrhofer mentioned geo URI. Thanks for mentioning this. I am not sure
that going to the full extend of using geo coordinates would be useful for
this use case. Coarse geo location is enough I believe and also sufficiant
for the use cases. Also already fits within RFC8805 format.

# Use cases

Some people came to the proverbial mic or commented in jabber about use
cases.

Joe Abley... thanks for commenting on the use-case.

Brian Dickson commented on Jabber:

> prefixes of resolver info including geo, allow identification of major
common resolver operator, which is very useful to classification/resource
reservation on authority side.

# Misc

Joe Abley... thanks for educating me on IATA not being a universal
nomenclature to reference a network location :). I will keep [15] in my
toolbelt. Hell, I grew up 70km from Andorra, I should have known better.

I would love to see how we can standardize the distribution of resolver IP
ranges/locations but I think we need to not focus on the details of using
geo location to perform DNS targeted answers as the goal of this document.
It is not, it is just an example use cases that is used in many places.
I should have probably left the geolocation part aside, but givemn that
RFC8805 was providing support to distribute the location at the same time,
I merged the geolocation with it.

Agreeing on using RFC8805 to distribute the data is probably not the most
difficult, but discovery mechanism it going to be more challenging. Should
there be 2 drafts? 1 that focuses on the medium/format and 1 that focuses
on the discovery?

Thanks all,

Manu

[0]
https://datatracker.ietf.org/doc/draft-bretelle-dnsop-recursive-iprange-location/
[1] https://www.rfc-editor.org/rfc/rfc8805.html
[2] https://tools.ietf.org/html/draft-ietf-opsawg-finding-geofeeds-00
[3]
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
[4] https://ns1.com/resources/understanding-ns1s-geofilters
[5] https://help.dyn.com/traffic-director-predefined-geographic-regions/
[6]
https://learn.akamai.com/en-us/webhelp/global-traffic-management/global-traffic-management-user-guide/GUID-65EB07B3-1BE3-40DB-8682-50E6836A8A78.html
[7] https://kb.isc.org/docs/aa-01149
[8] https://doc.powerdns.com/authoritative/backends/geoip.html
[9]
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#geoip-geography-based-responses
[10] https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
[11] https://tools.ietf.org/html/rfc7553
[12] https://tools.ietf.org/html/rfc3123
[13]
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml#address-family-numbers-2
[14] https://tools.ietf.org/html/rfc5870
[15] https://en.wikipedia.org/wiki/List_of_countries_without_an_airport

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 19 Nov 2020 12:35:04 -0500

I support the resolver IP range discovery function.  I don't think it will
be hard to come up with a reasonable format for that.  An APL record with
standard address families would seem fine.  A URI record pointed at a JSON
blob or a flat text file would be fine too.

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.

On Wed, Nov 18, 2020 at 8:28 PM Manu Bretelle <[email-masked]> wrote:

> While there is work on finding geofeed in the OPSAWG [2], this would
> defeat the original purpose of sharing resolver-only IP ranges. One could
> possibly say that only ip ranges are distributed and geolocation would be
> fetched from inetnum object but it seems to be adding more complexity in
> both term of consuming and generating the data as we now deal with multiple
> This draft is in no-way recommanding use of country/region... as the way
> to do so called "geotargeting" DNS, neither does it tries to solve this
> problem. I do agree that
> Opensource authoritative name servers also support GeoIP answers: Bind
> [7], PowerDNS [8], Knot DNS [9]. Typically based on a DB in MaxmindDB
> format.
>
> I hear you and provided this as a potential mechanism knowing that it
> would be controversial.
> Alex Mayrhofer mentioned geo URI. Thanks for mentioning this. I am not
> sure that going to the full extend of using geo coordinates would be useful
> for this use case. Coarse geo location is enough I believe and also
> sufficiant for the use cases. Also already fits within RFC8805 format.
>
>
> # Use cases
>
>> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 20 Nov 2020 09:49:41 -0800

On Thu, Nov 19, 2020 at 9:35 AM Ben Schwartz <bemasc=
[email-masked]> 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

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.

Brian

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 23 Nov 2020 11:55:23 +0100 (CET)

>     Il 20/11/2020 18:49 Brian Dickson <[email-masked]> ha scritto:
> 
>     But let's not get distracted by that in the short term, where direct use of resolver geo has real value.
> 
Also, legal/jurisdiction issues depend on geography and not on network topology. As data localization and privacy protection issues around resolvers are growing in importance, a systematic way of knowing which jurisdiction applies to a resolver may (hypothetically, with no immediate use cases right now) become useful.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Manu Bretelle <[email-masked]>
Date: Mon, 23 Nov 2020 11:36:10 -0800

Thanks both,

So, I seem to gather that the main problem is to put forward Geolocation as
a way to return pseudo-targeted answers to end-users by using the resolver
IP as a proxy for it. This was more meant to be a use-case as to how geo
location has been used, but It is by no means my intent to push this as a
recommended solution. I am happy to drop this or rephrase.

I do believe that Geo can have other useful properties as Brian has
highlighted, even more so in an infrastructure that heavily relies on
anycast. I suppose in most cases one could find other approaches to get
that information whether the traffic coming from a given network is
legitimate, but in many cases, this will involve having access/knowledge to
the full stack (routing tables, peering links, AS paths...) which may not
be readily available to the ones operating DNS. Likely geo is not a perfect
proxy, but it does provide high enough signal that one can leverage.

Manu

On Fri, Nov 20, 2020 at 9:49 AM Brian Dickson <[email-masked]>
wrote:

> 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.
>
>    - Alerting on changes in affinity between resolver groups and
>    authority instances (which might indicate a routing problem or outage)

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 23 Nov 2020 16:21:09 -0500

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

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

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.