...

• 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

Image Removed
1032NIOS Administrator Guide (Rev. A)NIOS 8.1
Configuring Recursion and Validation for Signed Zones
3Figure 22.5

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

...

Anchor
Enabling Recursion and Validation for Si Enabling Recursion and Validation for Si

Anchor
bookmark2081 bookmark2081

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 Queries0.
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.

Anchor
Enabling DNSSEC Validation Enabling DNSSEC Validation

Anchor
bookmark2082 bookmark2082

Enabling DNSSEC Validation

...

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.

...

1. • .

...

...

1. • 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.
     • 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

...

1. • • 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:

       • dig . dnskey +multiline

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

...

1. • • • dig

...

1. • • • \[@server_address\]

...

1. • • • <zone>

...

1. • • • dnskey

...

1. • • • +multiline

...

1. • • • +dnssec

         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/draft-icann-dnssec-trust-anchor.txt.

...

1. • 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.

Anchor
Defining Negative Trust Anchors Defining Negative Trust Anchors

Anchor
bookmark2083 bookmark2083

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.
Image Removed
1034NIOS Administrator Guide (Rev. A)NIOS 8.1
Applying Policies and Rules to DNS Queries that Request DNSSEC Data
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:

...