DNS Blacklists and Whitelists
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them. This document is not an Internet Standards Track specification; it is published for informational purposes.
Informational, not a standard. Published for the record and carrying no standards weight. Worth knowing before citing it as a requirement.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 15 must, 9 should, 5 may.
2.1 IP Address DNSxL
- MUSTEach entry in the DNSxL MUST have an A record.
- SHOULDDNSBLs SHOULD have a TXT record that describes the reason for the entry.
- MAYDNSWLs MAY have a TXT record that describes the reason for the entry.
- MUST NOTThe contents of the A record MUST NOT be used as an IP address.
- MAYThe A record contents conventionally have the value 127.0.0.2, but MAY have other values as described below in Section 2.3.
- MUSTClient software MUST check the A record and MAY check the TXT record.
- MUSTIf a range of addresses is listed in the DNSxL, the DNSxL MUST contain an A record (or a pair of A and TXT records) for every address in the DNSxL.
- MUST NOTConversely, if an IP address is not listed in the DNSxL, there MUST NOT be any records for the address.
2.3 Combined IP Address DNSxL
- SHOULDDNSxLs with sublists SHOULD use both subdomains and one of the other methods.
- MUSTIf a DNSxL contains both entries for a main domain and for sublists, sublist names MUST be at least two characters and contain non-digits, so there is no problem of name collisions with entries in the main domain, where the IP addresses consist of digits or single hex characters.
- SHOULDThere is no widely used convention for mapping sublist names to bits or values, beyond the convention that all A values SHOULD be in the 127.0.0.0/8 range to prevent unwanted network traffic if the value is erroneously used as an IP address.
2.4 IPv6 DNSxLs
- MUSTEach entry's name MUST be a 32-component hex nibble-reversed IPv6 address suffixed by the DNSxL domain.
3 Domain Name DNSxLs
- MUSTThe names of their entries MUST contain the listed domain name followed by the name of the DNSxL.
4 DNSxL Cache Behavior
- SHOULDThe Time to Live (TTL) and refresh times SHOULD be chosen to reflect the expected rate of change of the DNSxL.
5 Test and Contact Addresses
- MUSTIPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.
- MUST NOTIPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1.
- SHOULDDNSBLs that return multiple values SHOULD have multiple test addresses so that, for example, a DNSBL that can return 127.0.0.5 would have a test record for 127.0.0.5 that returns an A record with the value 127.0.0.5, and a corresponding TXT record.
- MUSTIPv6-based DNSxLs MUST contain an entry for ::FFFF:7F00:2 (::FFFF: 127.0.0.2), and MUST NOT contain an entry for ::FFFF:7F00:1 (::FFFF: 127.0.0.1), the IPv4-Mapped IPv6 Address [RFC4291] equivalents of the IPv4 test addresses.
- MUSTDomain-name-based DNSxLs MUST contain an entry for the [RFC2606] reserved domain name "TEST" and MUST NOT contain an entry for the reserved domain name "INVALID".
- MAYDNSxLs also MAY contain A and/or AAAA records at the apex of the DNSxL zone that point to a web server, so that anyone wishing to learn about the bad.example.net DNSBL can check http://bad.example.net.
- MUSTThe combination of a test address that MUST exist and an address that MUST NOT exist allows a client system to check that a domain still contains DNSxL data, and to defend against DNSxLs that deliberately or by accident install a wildcard that returns an A record for all queries.
- SHOULDDNSxL clients SHOULD periodically check appropriate test entries to ensure that the DNSxLs they are using are still operating.
6 Typical Usage of DNSBLs and DNSWLs
- MAYIf a /24 or larger range of addresses is listed, and the zone's server uses traditional zone files to represent the DNSxL, the DNSxL MAY use wildcards to limit the size of the zone file.
- MUSTA client MUST interpret any returned A record as meaning that an address or domain is listed in a DNSxL.
- SHOULDDNSxL clients SHOULD be able to use bit masks and value range tests on returned A record values in order to select particular sublists of a combined list.
- MAYLong-running mail servers MAY cache DNSxL data internally, but MUST respect the TTL values and discard expired records.
- MUSTPackages that test multiple header fields MUST be able to distinguish among values in lists with sublists because, for example, an entry indicating that an IP address is assigned to dialup users might be treated as a strong indication that a message would be rejected if the IP address sends mail directly to the recipient system, but not if the message were relayed through an ISP's mail server.
7 Security Considerations
- SHOULDAny system manager that uses DNSxLs is entrusting part of his or her server management to the parties that run the lists, and SHOULD ensure that the management policies for the lists are consistent with the policies the system manager intends to use.
- SHOULDTo avoid this situation, systems that use DNSxLs SHOULD check for the test entries described in Section 5 to ensure that a domain actually has the structure of a DNSxL, and SHOULD NOT use any DNSxL domain that does not have correct test entries.