Recursive Resolver Facebook
chantra@fb.com
Internet dnsop Internet-Draft This document specifies a way for recursive resolvers operators to signal the IP ranges and locations used by their server pools. Discussion Venues Source for this draft and an issue tracker can be found at .
Introduction Big distributed recursive resolver pools tend to be distributed across the world, operating under multiple countries and possibly using IP ranges for which the country is not necessarily perfectly matching the location of the service. This has lead to sub-optimal answers being returned to those server pools. An solution to this problem has been to use EDNS Client Subnet (ECS) , but this require support from both the recursive resolvers and the name servers authorities, comes with its own Security Considerations, and increased resources usage. DNS server operators are commonly receiving spoofed DNS traffic over UDP, common techniques have been to reply with TC bit set to force legitimate clients to use TCP, if the load is still too high, they may start to drop traffic from selected subnets. While this may protect their resources, it has the possibility of denying the service to legitimate resolvers. So far, operators have resorted to ad-hoc mechanism, ranging from exchanging list by email, providing IP ranges and location via webpages, or specific DNS queries, like Google Public DNS, or Cloudflare, or OpenDNS. When web pages are available, they are rarely found at consistent locations, neither are they formatted in a uniform way, essentially making name server operators' task rather complicated and brittle. This document helps providing uniform solutions to let recursive server operators distribute the list of IP ranges under which their servers are operating as well as possibly location up to the postal code granularity by leveraging format.
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Publishing Resolver pool IP ranges An entity willing to share the IP ranges used by their recursive servers would publish a record under the special name _rdns.example.com. The IP ranges can be distributed either using a TXT record or HTTPS resource record An entity can share IP information in 2 ways: via an IP Geolocation Feed, or list of IP ranges in a TXT record.
TXT Resource Record An entity that wishes to share the IP ranges they are using with their recursive resolvers can distribute it via a TXT record. The record is expressed as a single line of text found in the RDATA. Multiple TXT resource records for the same owner name may be permitted. The record is made of a list of space separated IP ranges with optional comma separated Geolocation. The Geolocation field MUST be a 2-letter ISO country code conforming to ISO 3166-1 alpha 2 . Parsers SHOULD treat this field case-insensitively. This example illustrate a record without geolocation: This example illustrate a record with geolocation information: As the number of IP ranges increases, the size of the DNS response can become a source for amplification attacks. This is being discussed in .
HTTPS Resource Record Another approach is share an IP geolocation feed via an HTTPS Resource Record . This record has the benefit of providing a format which can provide more granularity if the entity sharing it wishes to, and can scale even when the number of IP ranges increases.
Security Considerations Unless the record is DNSSEC-signed , the answers returned cannot be trusted. In HTTPS Resource Record is requested, the client can possibly trust the content if the URI is within the same zone cut, and HTTPS can authenticate the domain. When using the TXT Resource Record, the answer returned can quickly become big and the name server operator should aggressively limit the size of the answer it will return to the client, and Truncate it if needed.
IANA Consideration
Underscored Node Name This document updates the IANA registry "Underscored and Globally Scoped DNS Node Names" at The following entries have been added to the registry:
URI DNS Service Parameter This document adds a parameter to the "Service Binding (SVCB) Parameter" registry. The allocation request is TBD, taken from the to the First Come First Served range. If present, this parameters indicates the URI template of an IP Geolocation feed. This is a string encoded as UTF-8 characters. Name: uri
Acknowledgments The authors would like to thank the following individuals for their useful input: John Todd.
References Normative References Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This proposal is inspired by and based on recent DNS usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to have SRV or a functional equivalent implemented for HTTP). These proposals each provide an important function but are potentially incompatible with each other, such as when an origin is load-balanced across multiple hosting providers (multi-CDN). Furthermore, these each add potential cases for adding additional record lookups in addition to AAAA/A lookups. This design attempts to provide a unified framework that encompasses the key functionality of these proposals, as well as providing some extensibility for addressing similar future challenges. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc [1]. The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. ISO 3166-1 decoding table ISO Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A Format for Self-Published IP Geolocation Feeds This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated. Informative References DNS Security Introduction and Requirements The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Client Subnet in DNS Queries This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.