Recommendations on mitigating RFC-1918 DNS traffic Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [ [1] ]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract A set of methods to reduce DNS queries and Dynamic DNS update attempts for hosts using RFC-1918 prefixes. These methods should reduce traffic on service provider recursive DNS servers and on the root DNS servers. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ [2] ]. Table of Contents 2. How this affects service providers and end sites 3. Ways to mitigate RFC-1918 traffic, practical examples 3.1 Be Authoritative for RFC-1919 IN-ADDR.ARPA zones 3.2 Provide routing for the RFC-1918 IN-ADDR DNS Servers 4. Troubleshooting Techniques and other hazards 4.1 ANYCAST Deployment troubleshooting Internet users are connecting more private networks, with the use of NAT devices, to the global Internet. These devices typically make use of RFC-1918 address space and use DHCP to assign private addresses to hosts on these networks. Many applications and some operating systems will attempt to resolve names from the assigned private IP by sending queries to the service providers DNS servers. In addition the service provider's DNS server will also see Dynamic DNS UPDATE attempts for hosts within this RFC-1918 space. If the service provider's DNS is not authoritative for the these private IP zones, it will reject the requests (Dynamic DNS), or forward the PTR lookup, up the DNS tree. Ultimately this has a direct impact on the Root Servers and on the IN-ADDR servers for the RFC-1918 zones. If the service provider's DNS is not authoritative for the zones, the UPDATE request never goes to their DNS servers. The UPDATE request goes to the first enclosing scope with a delegation, e.g. if you're not locally AUTH for 12.10.in-addr.arpa, the attempt to UPDATE a name for 10.12.23.2 goes to the MNAME in the SOA for 10.in-addr.arpa. The system does ask its local resolver for 12.10.in-addr.arpa, so if the resolver it asks is AUTH for either 12.10.in-addr.arpa or for 10.in-addr.arpa, it gets an SOA with an MNAME and uses it. Sometime ago, in order to reduce the query load on the root name servers resulting from unanswerable queries for data in RFC-1918 derived DNS names, delegations were put in in-addr.arpa for the relevant zones. This reduced significant traffic loads on the root and in-addr.arpa name servers, but pushed large traffic flows towards the delegated servers. This document and the measures it describes represents attempts to further spread out and localize this traffic. This document provides ways that service providers and end organizations can mitigate this traffic and thus reduce egress packets, loads on root servers, and improve DNS services. 2. How this affects service providers and end sites Hackers, those that attempt DDOS and those that spoof source addresses from RFC-1918 can create secondary victims. This is caused when, for example, a .GOV org is DDOS'd (distributed denial of service) with source spoofed (RFC-1918) packets. The organization's IDS or firewall or other tools start to log and do lookups on these source IP's. This creates a load on their internal DNS servers and that load spreads up the tree towards the Root-Servers. This load can also impact transit links, upstream service provider DNS servers and their peering or transit links. Since filtering on port 53 is not effective in mitigating this traffic (you would have to examine each packet at the DNS application layer), the solutions are to: a) have your NS's be auth. This requires each NS to be changed. b) pretend to be the AUTH servers by locally routing the prefix c) join the official AS112 project and ANYCAST the prefix. Each of these methods are presented in the following sections. 3. Ways to mitigate RFC-1918 traffic, practical examples Each of the following methods assumes the reader has prior knowledge of DNS and understands how to configure their specific DNS server software. For name servers that are recursive for multiple different customers you SHOULD NOT list anything else in these zones. Service providers need to pay specific attention to the issue of different organizations and how they handle replies to queries. If you are an enterprise organization then you MAY list internal hosts as appropriate inside these zones. Any conflicts between different uses of the same prefixes within your organization are thus a strictly internal matter. 3.1 Be Authoritative for RFC-1918 IN-ADDR.ARPA zones The simplest way for an organization to mitigate these queries is to become authoritative for the RFC-1918 IN-ADDR zones. The zones are: 10.in-addr.arpa. 16.172.in-addr.arpa. 17.172.in-addr.arpa. 18.172.in-addr.arpa. 19.172.in-addr.arpa. 20.172.in-addr.arpa. 21.172.in-addr.arpa. 22.172.in-addr.arpa. 23.172.in-addr.arpa. 24.172.in-addr.arpa. 25.172.in-addr.arpa. 26.172.in-addr.arpa. 27.172.in-addr.arpa. 28.172.in-addr.arpa. 29.172.in-addr.arpa. 30.172.in-addr.arpa. 31.172.in-addr.arpa. 168.192.in-addr.arpa. 254.169.in-addr.arpa. Link Local Configuring your name servers to be authoritative for the above listed zones will prevent queries from flowing further up the DNS tree. This assumes you configure each and every recursive resolver used by your clients on your network with this data. This also assumes that your clients are not using their own DNS server. Should a DNS server exist on your network that you do not have administrative control over, it may recurs up the tree for any queries it receives. These issues are addressed later in this document. Assuming BIND8 or BIND9 style configurations: named.conf: zone "10.in-addr.arpa" { type master; file "slave/db.RFC-1918"; }; Repeat the above clause for each of the zones listed above. Create a file called db.RFC-1918 db.RFC-1918: @ SOA <YOUR NAME SERVER>. hostmaster.<YOUR DOMAIN>. ( 2002040100 ;serial 30m ;refresh 15m ;retry 1w ;expire 1w ;minimum ) NS <YOUR NAME SERVER> NS <YOUR SECOND NAME SERVER> ;<EOF> The above will cause the configured name server to respond NXDOMAIN to any PTR lookups in those zones. Dynamic DNS updates will be denied by default. You SHOULD list your name servers host name in the MNAME and a local helpdesk email address in the RNAME sections of the SOA. This will assist technical problem solving issues. 3.2 Provide routing for the RFC-1918 IN-ADDR DNS Servers The second way to gain more network wide control over this DNS traffic is to inject a routing announcement for 192.175.48.0/24. This prefix is used by the hosts delegated to service queries for RFC-1918 in-addr.arpa zones. You MUST NOT announce this prefix to any BGP peers. You SHOULD configure two hosts to answer, each, on 192.175.48.6 and 192.175.48.42. One of the hosts MUST also answer for 192.175.48.1 The host's 192.175.48.6 and 192.175.48.42 will mostly receive queries and the host with 192.175.48.1 will mostly receive Dynamic DNS updates. Configure your named.conf as follows. named.conf: zone "10.in-addr.arpa" { type master; file "slave/db.RFC-1918"; }; Repeat the above clause for each of the zones listed in section 3.1. On these hosts you MUST configure the db.RFC-1918 zone as follows: db.RFC-1918: @ SOA prisoner.iana.org. hostmaster.root-servers.org. ( 2002040100 ;serial 30m ;refresh 15m ;retry 1w ;expire 1w ;minimum ) NS blackhole-1.iana.org. NS blackhole-2.iana.org. ;<EOF> Traffic that has a destination for one of the "public" RFC-1918 IN-ADDR.ARPA servers will be routed to your local servers. You MAY place multiples of these servers across your network as a load sharing method. Organizations that create multiple servers within their network as a load balancing or traffic management technique SHOULD place a specific zone on each machine for troubleshooting purposes. See Section 4.0 on troubleshooting methods and suggestions. The AS112.NET project is based on using the ANYCAST method of deploying a diverse network of servers that answer authoritatively for the RFC-1918 IN-ADDR.ARPA zones. This solution is similar to that presented in Section 3.2, with the added requirement that the 192.175.48.0/24 prefix is advertised with the BGP AS of 112. This method is useful for service providers that wish to sink RFC-1918 IN-ADDR.ARPA DNS traffic from their BGP peers. For more information on this method implementers should review the project web site located at http://www.as112.net . Organizations MUST NOT advertise the 192.174.48.0/24 along with AS 112 unless they have coordinated directly with the project. 4. Troubleshooting Techniques and other hazards Given that general need for PTR or Dynamic DNS services are not needed for RFC-1918 IN-ADDR.ARPA DNS packets, failure modes have minimal impact. Organizations that make use of RFC-1918 prefixes as a way of numbering internal hosts MUST be cautious about these approaches. Dependency on host name to IP address and the reverse may break if NXDOMAIN answers are received. Therefore such organizations MUST specifically review their use of RFC-1918 addresses and any DNS requirements that use has before deploying these methods. 4.1 ANYCAST Deployment troubleshooting Organizations that make use of ANYCAST methods to share load or for traffic engineering purposes SHOULD embed additional data in each ANYCAST server so as to be able to identify specific hosts on the network. One possible way of embedding additional data is to create a sub zone and have queries for that sub-zone return unique answers for each ANYCAST server. For example, create the following zone: hostname.rfc1918-dns.example.com Each name server that is a member of the ANYCAST group will be authoritative for the rfc1918-dns.example.com zone. The data for the label hostname.rfc1918-dns.example.com would look like this. $ORIGIN rfc1918-dns.example.com. hostname IN TXT "Contact:rfc1918@example.com" IN TXT "RFC-1918 DNS Server, MGNT IP: 305.123.11.10" IN TXT "Server Location: ABQ-BIGBYTE-03" IN TXT "See: http://rfc1918.example.com for more details" The SOA MNAME for this zone MUST be the specific non-ANYCAST host name of the specific server and the RNAME is the email contact of the responsible party. Given that these are ANYCAST servers the entire response MUST fit within one 512 byte DNS/UDP packet. Downstream organizations are cautioned against advertising the 192.175.48.0/24 prefix to larger upstream organizations. Transit links could become congested if larger organizations are sending their queries to smaller organizations. To be clear, if you are a small end customer, or a small service provider, you SHOULD NOT announce this prefix to your upstream or larger peers. To do so could cause traffic overloads on your links. This document does not specifically address security issues. Improper configuration can cause DNS queries for RFC-1918 addresses to be redirected and could lead to unwanted self inflicted denial of service. By reducing the unneeded traffic on root servers, organizations improve the network and improve root server responsiveness and available bandwidth headroom. TBD John M. Brown Chagres Technologies, Inc 3500 Comanche NE, Suite A1 Albuquerque, New Mexico 87107 US Phone: +1 505 830 1200 Email: jmb-rfc@chagres.net |
||||||||||