DLV-based DNS blacklists

DLV-based DNS blacklists (DLVBLs) are DNS-based blacklists for preventing resolution of parts of the DNS trees in emergencies. They employ DNSSEC Lookaside Validation (DLV, see RFC 5074) to require that blacklisted zones specify syntactically impossible DNSSEC key material, which makes these zones impossible to resolve, unless proper DNSSEC key material can be obtained through other means.

Despite having severe limitations (as explained below), DLVBLs are simple to set up and attractive as an emergency blacklisting method.

Configuring a DLV blacklist

The following instructions assume that BIND is used as a resolver. DLV support was added to BIND in version 9.3.3, so most BIND versions used in production are technically capable of implementing DLVBLs. The steps are similar for other DLV-supporting resolvers, but the configuration syntax differs.

Two configuration changes are required to activate a DLVBL. Suppose the DLVBL is hosted in the dlvbl.example zone. First, you need to enable secure resolution for the DLV zone. Typically, you have to configure a trust anchor for the zone, using a trusted-keys statement in the named.conf file:

trusted-keys {
    dlvbl.example. 256 3 5 "AwEA...ji0=";
};

The part AwEA...ji0= has been abbreviated; it is the key you should have received from the DLVBL operator. Multiple keys can be configured for a single zone.

The second step configures this zone as a DLV zone and switches on DNSSEC validation, by adding the following statements to the options section in the named.conf configuration file (dnssec-validation is enabled by default starting with BIND 9.5):

options {
    ...
    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-lookaside . trust-anchor dlvbl.example;
    ...
};

It may be necessary to invoke the rndc flush command to remove previously cached records in blacklisted zones.

After that, resolution of DNS sub-trees listed in the DLVBL will not be possible, unless another DNSSEC trust path can be established (through DLV or secure delegation). See the next section for details.

Limitations of DLVBLs

DLVBLs are not a universal DNS blacklisting solution. Several issues are listed below.

No clear error indication is provided to the client. For instance, it is not possible to redirect web browser to an explanatory error page.
DLVBLs are effective not just at a particular name, but all its children. They apply to all record types.
Clients can bypass them by setting the CD (Checking Disabled) flag in DNS queries.
BIND does not cache this particular DNSSEC validation failure. Every query for a blacklisted domain results in an upstream DNS transaction, which can measurably increase load if busy domains are blacklisted.
There is no direct support for using multiple DLV zones in BIND or Unbound. You can configure only one DLVBL, and you cannot use any DLVBL if you already use another DLV service (like dlv.isc.org).
A blacklisted zone becomes visible again if the zone owner obtains a secure delegation to the blacklisted zone. In short, this approach only works if DNSSEC is not widely deployed.

Consequently, DLVBLs should be used with caution, and only in emergencies.

Creating your own DLVBL zones

This section is targeted at operators who want to create their own DLVBLs. Setting up a DLVBL zone is quite similar to creating an ordinary DLV zone. The only difference is that you add records such that the owner of a blacklisted zone cannot provide the indicated key material. For instance, a DLVBL zone blacklisting example.net would contain:


$TTL 600
$ORIGIN dlvbl.example.

...

example.net DLV 1 5 1 00

...

00 is not a valid hash of a RSA key, so any key the zone owner of example.net might configure will be invalid. The resulting delegation does not validate, so a DLV-enabled resolver will refuse to serve records within the blacklisted example.net zone.

After creating the zone, you need to sign it. The best approach depends on the BIND version and the tools you use. Keep in mind that you periodically need to resign the zones, otherwise it will cease to work.

Some implementations can run DLV against a non-secure zone. However, enabling DNSSEC reduces query load on the DLV zone because the negative signaling records (NSEC and NSEC3) can be used to avoid the majority of queries. It is not necessary that the authoritative name servers which serve the DLV zone support DLV (or the DLV record type) themselves, regular DNSSEC support is sufficient.

With BIND, it is also possible to transfer the zone using AXFR and make resolvers authoritative. However, you should make sure that BIND bug 2422 has been fixed in the version you use on your resolvers, otherwise this will not work and will blacklist many additional domains. (Florian Weimer)