When you enable recursion on a Grid member and it receives a recursive query for DNS data it does not have, it queries remote name servers that you specified in the Grid DNS Properties or Member DNS Properties editor. It then includes the DNSSEC data it retrieved through recursion in its responses to clients that requested DNSSEC RRs. You can enable the appliance to validate the responses of these servers for certain zones. On the appliance, you specify the zones to validate and configure their DNSKEY records as trust anchors. When the appliance validates a response for a zone configured with a trust anchor or for any of its child zones, the appliance starts with the DNSKEY that you configured and proceeds recursively down the DNS tree.
In the example shown in Figure 22.5, the following was configured on the NIOS appliance:

• Forwarder with the following IP address: 10.2.2.1
• Recursion was enabled
• DNSSEC and validation were enabled
• The corpxyz.com zone and its DNSKEY record were configured

Figure 22.5

Enabling Recursion and Validation for Signed Zones

The following are the tasks to enable recursion and validate recursively derived data:

1. Enable DNSSEC on the appliance. For information, see Enabling DNSSEC.
2. Enable validation and configure the trust anchor of each signed zone. For information, see Enabling DNSSEC Validation.  You must configure at least one trusted DNSKEY RR.
3. Enable recursion on the appliance. For information, see Enabling Recursive Queries.
4. Complete any of the following:

• • Configure the forward, delegated, stub or root zones for the signed zones. For information, see Configuring Delegated, Forward, and Stub Zones and Creating a Root Zone.
  • Configure global forwarders and custom root name servers, if needed. For information, see Using Forwarders and About Root Name Servers.

Enabling DNSSEC Validation

To configure trust anchors and enable Infoblox name servers to validate responses:

1. Grid: From the Data Management tab, select the DNS tab. Expand the Toolbar and click Grid DNS Properties. 
   Member: From the Data Management tab, select the Members tab -> member check box and click the Edit icon. 
   DNS View: From the Data Management tab, select the Zones tab -> dns_view check box and click the Edit icon. To override an inherited property, click Override next to the property to enable the configuration.
2. In the editor, click Toggle Expert Mode.
3. When the additional tabs appear, click DNSSEC.
4. In the DNSSEC tab, complete the following:
   • Enable DNSSEC validation: If you allow the appliance to respond to recursive queries, you can select this check box to enable the appliance to validate responses to recursive queries for domains that you specify. You must configure the DNSKEY RR of each domain that you specify.
   • Accept expired signatures: Click this check box to enable the appliance to accept responses with signatures that have expired. Though enabling this feature might be necessary to work temporarily with zones that have not had their signatures updated in a timely fashion, note that it could also increase the vulnerability of your network to replay attacks.
   • TrustAnchors: Configure the DNSKEY record that holds the KSK as a trust anchor for each zone for which the Grid member returns validated data. Click the Add icon and complete the following:
     • Zone: Enter the FQDN of the domain for which the member validates responses to recursive queries.
     • Secure Entry Point (SEP): This check box is enabled by default to indicate that you are configuring a KSK.
     • Responses must be secure: This check box is enabled by default. All responses to domains configured with a trust anchor must be DNSSEC secure and valid. When you enable this check box, the appliance returns SERVFAIL responses for the domains that are not DNSSEC secure.  
     • Algorithm: Select the algorithm of the DNSKEY record: RSA/SHA1(5), DSA (3), DSA/NSEC3 (6), RSA/MD5 (1), RSA/SHA1/NSEC3 (7), RSA/SHA-256 (8), or RSA-SHA-512 (10). This must be the same algorithm that was used to generate the keys that were used to sign the zones.
     • PublicKey: Paste the key into this text box. You can use either of the following commands to retrieve the key:

       • The above command retrieves root zone keys and is the only public key you require for full chain of trust validation.

       • The above command retrieves public keys from the zone you specify on the server and can be used if the parent zone is not signed.
         Note that the aforementioned command provides you with a key you need to cross validate against other servers to ensure you have an identical key.
         As an alternative, you can use http://data.iana.org/root-anchors/ to retrieve signed public keys. You can find the trust anchors in formats like XML and CSR. For more information, refer to http://data.iana.org/root-anchors/.

   • Negative Trust Anchors: Configure negative trust anchors to suppress DNSSEC validation for certain domains. Click the Add icon to add the domain name to the list. You can define negative trust anchors at the Grid level and override them at the member and DNS view levels. For more information about negative trust anchors, see Defining Negative Trust Anchors.
     To delete a negative trust anchor, select the check box adjacent to the Zone column and click the Delete icon.

     5. Save the configuration and click Restart if it appears at the top of the screen.

Defining Negative Trust Anchors

A DNSSEC misconfiguration is not uncommon, and it can lead to failures in validating clients for particular domains.
You can use negative trust anchors to enhance the deployment of DNSSEC validation even with misconfigured domains, as the administrator can enable DNSSEC validation without worrying about resolution failure for misconfigured signed domains that succeeds without DNSSEC validation.
A negative trust anchor is a domain name for which DNSSEC validation must be suppressed even if the domain name is listed under a trust anchor.
You can define a negative trust anchor at the Grid level and override it at the member and DNS view levels. You can define negative trust anchors within a view or at the Grid level. If you define it at both levels, only the configuration with the view will be effective for the respective view.
For any specific domain name, negative trust anchors are mutually exclusive of trusted anchors; if a negative trust anchor is specified for a domain name, you cannot configure a trust anchor using the same name. Likewise, if a trust anchor is configured for a domain name, you cannot configure negative trust anchor using the same name.
Note that if there is a trust anchor for a specific name under a negative trust anchor, that trust anchor will re-enable DNSSEC validation for query names covered by the trust anchor. For example, if you configure trust anchors for "." and "example.com," and "com" is in the negative trust anchor list, queries for "www.example.com" are subject to DNSSEC validation, while DNSSEC validation will be suppressed for www.insecure.com, even if "." is listed in the trust anchor.
The appliance does not support automatic cleanup of negative trust anchors, nor does it provide any information about their expiration. Administrators must manually keep track of the status of domains listed as a negative trust anchor, and must remove them from the list as soon as the domains become DNSSEC signed correctly. Infoblox recommends that you do not use negative trust anchors, and rather disable DNSSEC validation, if the administrator is not familiar with negative trust anchors or is not able to maintain the negative trust anchors properly; careless use of negative trust anchors would rather hinder the deployment of DNSSEC, which is the opposite to the purpose of negative trust anchors. For more information about general technical details of negative trust anchors, refer to http://tools.ietf.org/html/draft-livingood-negative-trust-anchors.
Note the following about negative trust anchors:

• You must restart the DNS service when you modify the list of negative trust anchors.
• The appliance displays an error message if an entry is present in both the trust anchors and the negative trust anchors list for the same FQDN.
• The appliance displays an error message if the same FQDN is present multiple times in a negative trust anchor.
• When DNSSEC validation is suppressed due to a negative trust anchor, the corresponding response from the validating resolver does not include the AD bit.