This document aims to provide a location for documented production configurations and considerations. Including common misconfigurations, attack mitigation techniques, and other relevant tips.
Designate’s multi-tenant nature allows for any user to create (almost) any zone, which can result in the legitimate owner being unable to create the zone within Designate. There are several ways this can occur:
There is no automated mitigation that can reasonably be performed here, DNS providers have typically used a manual process, triggered through a support request, to identify the legitimate owner and request the illegitimate owner relinquish control, or action any other provider specific policy for handling these scenarios.
This scenario can be mitigated by ensuring Designate has been configured, and is updated periodically, with the latest list of gTLD’s published as the IANA TLD list. These TLDs can be entered into Designate through the TLD API
This is a variation on Scenario #3, where public registration is available for a second level domain, such as is the case with “co.uk.”. Due to the nature of public second level domains, where the IANA has no authority, these are not included in the IANA TLD list. A Mozilla sponsored initiative has stepped up to fill this gap, crowdsourcing the list of “public suffixes”, which includes both standard TLDs and public second level domains. We recommend configuring, and periodically updating, Designate with Mozilla’s Public Suffix list. These public suffixes can be entered into Designate through the TLD API
Multi-tenant nameservers can lead to an interesting variation of DNS Cache Poisoning if nameservers are configured without consideration. Two tenants, both owning different zones, can under the right circumstances inject content into DNS responses for the other tenants zone. Let’s consider an example:
Tenant A owns “example.com.”, and has created an additional NS record within their zone pointing to “ns.example.org.” Tenant B, the attacker in this example, can now create the “example.org.” zone within their tenant. Within this zone, they can legitimately create an A record with the name “ns.example.org.”. Under default configurations, many DNS servers (e.g. BIND), will now include Tenant B’s A record within responses for several queries for “example.com.”. Should the recursive resolver used by the end-user not be configured to ignore out-of-bailiwick responses, this potentially invalid A record for “ns.example.org.” will be injected into the resolvers cache, resulting in a cache poisoning attack.
This is an “interesting variation” of DNS cache poisoning, because the poison records are returned by the authoritative nameserver for a given zone, rather than in responses for the attackers zone.
Bug 1471159 includes additional worked examples of this attack.
BIND9 by default will include out-of-zone additionals, resulting is susceptibility to this attack. We recommend BIND is configured to send minimal responses - preventing the out-of-zone additionals from being processed.
In BIND’s global options clause, include the following statement:
minimal-responses yes;
PowerDNS by default will include out-of-zone additionals, resulting is susceptibility to this attack. We recommend setting the out-of-zone-additional-processing configuration flag set to “no” - preventing the out-of-zone additionals from being processed.
In the main PowerDNS configuration file, include the following statement:
out-of-zone-additional-processing=no