"DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 23-Feb-08. ( bytes)

With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators.

"Preventing Use of Recursive Nameservers in Reflector Attacks", Joao Luis Damas, Frederico Neves, 3-Dec-07. ( bytes)

This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. Recommended configuration as measures to mitigate the attack are given.

"Locally-served DNS Zones", Mark Andrews, 3-Dec-07. ( bytes)

Experience has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should, unless configured otherwise, automatically serve. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics.

"Considerations for the use of DNS Reverse Mapping", Daniel Senie, Andrew Sullivan, 13-Mar-08. ( bytes)

Mapping of addresses to names is a feature of DNS. Many sites implement it, many others do not. Some applications attempt to use it as a part of a security strategy. This document outlines what should be taken into account when deciding whether to implement reverse mappings of addresses to names, suggests that site administrators implement reverse mappings if there are no strong considerations against such mappings, and provides considerations to be taken into account when using reverse mappings.

"I'm Being Attacked by PRISONER.IANA.ORG!", Joe Abley, William Maton, 18-Nov-07. ( bytes)

Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Hosts should never normally send reverse DNS queries for those addresses on the public Internet. However, such queries are frequently observed. Authority servers are deployed to provide authoritative answers to such queries as part of a loosely- coordinated effort known as the AS112 project. Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked. This document provides background information and technical advice to those firewall operators.

"AS112 Nameserver Operations", Joe Abley, William Maton, 16-Nov-07. ( bytes)

Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Devices in such environments may occasionally originate reverse DNS queries corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that they are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the root and IN-ADDR.ARPA authority servers. This document describes the steps required to install a new AS112 node, and offers advice relating to such a node's operation.

"DNSSEC Trust Anchor Configuration and Maintenance", Matt Larson, Olafur Gudmundsson, 11-Feb-08. ( bytes)

This document recommends a preferred format for specifying trust anchors in DNSSEC validating security-aware resolvers and describes how such a resolver should initialize trust anchors for use. This document also describes different mechanisms for keeping trust anchors up to date over time.

Return to Internet-Draft directory.

Return to IETF home page.