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

[Ben Schwartz <[e-mail]>]

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 <[e-mail]> wrote:

> 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
>>
>> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>