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 <chan...@gmail.com> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop