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

[Manu Bretelle <[e-mail]>]

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

On Wed, Nov 4, 2020 at 3:00 PM Manu Bretelle <[e-mail]> wrote:

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