--- title: "DNS Advisor FAQs" canonical: "https://docs.infoblox.com/space/DNSAdvisorFAQ/501351403/DNS%20Advisor%20FAQs" format: markdown --- # Licensing 1. How can I tell how much longer my license will be valid? - Go to the “About” tab. At the bottom, just above the version number, you’ll see “Activation time remaining:” 2. How do I get a new license? - From the Activation screen (which you can currently only see if your license has expired), enter your email address in the field labeled “Email” and click on the “Generate” button to generate a serial number unique to your device. Copy the resulting text and email it to [dnsadvisor@infoblox.com](mailto:dnsadvisor@infoblox.com). We’ll send you an activation key that you can paste into the “Activation Key” field. # Requirements 3. Does DNS Advisor run on platforms other than macOS and Windows? - No, not yet. 4. Can I test my prospect’s or customer’s internal DNS servers and namespace from the comfort of my living room? - Unless your living room has direct IP connectivity to your prospect’s or customer’s internal network, no. # Testing a DNS Server Other Than the Default 5. What if I don’t want to run the infrastructure tests against the default DNS server (the DNS server the device DNS Advisor is running on is configured to query)? - Go to the “Exceptions” tab and enter the IP address of the DNS server you want to run the infrastructure tests against in the field labeled “Alternate name server to query for infrastructure tests:” # Selecting Tests 6. How can I prevent the tool from running certain tests? - Go to the “Cases” tab and scroll down to find the test or group of tests you don’t want to run, then uncheck the corresponding checkbox. 7. How can I configure the tool to only run security tests? - Go to the “Cases” tab and click “Deselect All.”  Then select the tests or groups of tests you want the tool to run.  You can then save that configuration using the “Save Configuration” button, and reload it later when you want to use it again. 8. DNS Advisor is automatically discovering the tested zone’s subzones and is testing (or trying to test) them.  How do I prevent this from happening? - Go to the “Exceptions” tab and enter “*.” (e.g., “*.nxdomain.com”) in the field labeled “Zones to skip during a test:” # Running Tests 9. How long should a test run take? - The test run should run fairly quickly, and of course you can watch its progress in real time in the progress window. To analyze my small zone, [nxdomain.com](http://nxdomain.com), DNS Advisor usually takes less than a minute. However, with larger zones that have more DNS servers or DNS servers that take longer to reply, a test run could take several minutes. 10. How much load does a test run place on the DNS servers it’s testing? - Very little. DNS Advisor does about 90 tests, some of which entail sending multiple queries, but the query load generated is a tiny fraction of what any competent DNS server can handle. # Viewing the Report 11. How can I view a report from a previous test run? - Go to the “General” tab and find the test run under “Test Run Results.”  Click on the summary information about the test run to open the corresponding report. 12. How can I suppress printing successful test results in the report? - At the top of the report, click on the “View Options” button.  Deselect the categories you don’t want displayed. 13. How can I suppress printing the description, implication and/or mitigation sections of the report? - At the top of the report, click on the “View Options” button.  Deselect the sections you don’t want displayed. 14. How can I save the report or send it to a customer or prospect? - At the top of the report, click “Print PDF.” # Troubleshooting 15. Why do many of DNS Advisor’s tests (zone tests from about T013A on) show black (incomplete) results? - DNS Advisor probably couldn’t transfer a copy of the zone, so it couldn’t complete those tests.  You should recheck the ACLs on the zone’s authoritative DNS servers to make sure they allow zone transfers from DNS Advisor’s IP address. 16. How can I get additional detail so I can see the response the DNS server sent? - At the top of the report, click on the “View Options” button.  Select “Trace.”  This will print dig-like tracing output for many tests. 17. Why is DNS Advisor running its infrastructure tests against the IP address 127.0.0.2? - See answer #5. Or see below. - Do you have BloxOne Endpoint installed? Try disabling it temporarily. On macOS, you can use the command `/Applications/Infoblox/BloxOne\ Endpoint.app/Contents/Resources/service_control.sh disable` # Tests 18. What tests are run? - Here’s a list of all the current tests, including: - the test ID, - a description of the test, - implications of failing the test and - instructions on mitigating a failure. - Section: Zone - Category: Configuration - Subcategory: Delegation - Test ID: T001A - Name: Lookup NS RRs at parent - Description: This test checks that delegation is in place from the tested zone's parent to the tested zone. - Implication: If this delegation isn't in place, other name servers won't be able to resolve domain names in the tested zone or its subzones. That means you'll effectively be unreachable: email won't be delivered and users won't be able to reach your web site. - Mitigation: If you find that delegation to the tested zone is missing, make sure you're testing the correct set of parent name servers. By default, the tool works its way down from the Internet's root name servers to find the tested zone's name servers. In split namespaces, this probably isn't the right thing to do. If you have a split namespace, you can use the "Internal root server addresses" section of the "Exceptions" tab to list your internal root name servers' addresses (if you have internal root name servers), or the addresses of your parent zone's name servers, or if none of those apply, just the addresses of your zone's authoritative name servers. If the tool tested the correct set of parent name servers, add the delegation to the parent zone. - Subcategory: Robustness - Test ID: T001B - Name: Check >1 NS RR - Description: This test checks that the delegation to the tested zone includes at least two NS records. Two authoritative name servers is the minimum to provide the necessary redundancy for your zone. - Implication: A single NS record isn't enough to ensure that domain names in your zone will be resolvable: The failure of a single name server will render your zone unreachable. - Mitigation: Change the domain names of the name servers in your zone's delegation by contacting the administrator of your zone's parent zone, and change the domain names in your zone's NS records, too (i.e., the "intrazone" NS records). - Subcategory: NS Records - Test ID: T002A - Name: Lookup NS RRs at auth. name servers - Description: This test checks that the name servers listed in the tested zone's delegation respond with the list of authoritative name servers for the zone. If a name server listed in the delegation for the tested zone doesn't respond with the list of authoritative name servers for the zone, it's probably either down or 'lame. ('Lame' means that the zone is delegated to the name server, but the name server isn't authoritative for the zone. That's a no-no.) - Implication: If your zone has one or more down or lame name servers, this will increase the time it takes for remote name servers to resolve your zone's domain names. - Mitigation: If it's down, of course, you should figure out why. Did it crash? Was it moved to another IP address? Was it decommissioned? If it's 'lame'--running a name server that's not authoritative for the zone--should the name server be reconfigured as authoritative for the zone? Or was it inadvertently listed in the delegation and should be removed? - Subcategory: Delegation - Test ID: T002D - Name: Compare auth and parent NS RR sets - Description: This test checks that the NS records that delegate the tested zone from its parent and the NS records in the tested zone match. The NS records that delegate your zone from its parent and the NS records in your zone should match. - Implication: Mismatched NS records will usually cause problems resolving domain names in your zone, including longer resolution times and reduced redundancy. - Mitigation: Adjust the NS records in your zone and those in your zone's parent so that they match. - Subcategory: NS Records - Test ID: T003A - Name: Lookup A RRs for NS names - Description: This test checks that each name server listed in an NS record has at least one A record (and hence at least one IP address) associated with it. If a name server is listed in an NS record and has no A record associated with it, there's no way for another name server to query it. - Implication: Listing a name server with no A record is effectively the same as not running that name server at all, and will lead to longer resolution times and reduced redundancy. - Mitigation: Check whether the domain name of the name server is misspelled in the NS record. If not, check whether the A record for the name server is missing. - Subcategory: Delegation - Test ID: T003B - Name: Check for matching glue records - Description: This test checks that the A records for each name server match in the delegation for the tested zone and in the tested zone itself. - Implication: Mismatched A records will usually cause problems resolving domain names in your zone, including longer resolution times and reduced redundancy. - Mitigation: Adjust the A records in your zone and those in your zone's parent so that they match. - Subcategory: Robustness - Test ID: T003C - Name: Check NS addresses on >1 network - Description: This test checks that the tested zone's authoritative name servers are on more than one network. (It uses a simpleminded check to determine whether two name servers are on the same network, comparing the first three octets of their IP addresses. If you know that your name servers are on different networks, despite the first three octets of their' IP addresses being the same, you can ignore this error.) - Implication: If all of your zone's authoritative name servers are on the same network, you have a single point of failure--perhaps several--in your zone's DNS infrastructure. The failure of a single leased line, router, hub, or switch could render the domain names in your zone unresolvable. - Mitigation: Add diversity to your zone's DNS infrastructure by adding a secondary name server on another network. This could be a new secondary you set up yourself or an existing name server that you configure to also be secondary for this zone. - Subcategory: NS Records - Test ID: T003D - Name: Lookup A RRs for NS names - Description: This test checks whether any of the tested zone's authoritative name servers are on RFC 1918 (private internal) networks. There are no routes on the Internet to RFC 1918 networks. - Implication: If your zone is entirely internal, you can ignore the results of this test. However, for zones that are resolved from the Internet, listing name servers on RFC 1918 networks is about as useful as not listing them at all (in fact, it's actually worse, since name servers on the Internet will waste time trying to query those name servers). - Mitigation: Remove any name servers on RFC 1918 networks from your zone's delegation and authoritative data, and replace them with name servers on networks reachable from the Internet. - Test ID: T003E - Name: Check for CNAMEs - Description: This test checks whether any of the tested zone's NS records lists the alias of a name server rather than its official name. - Implication: Most name servers on the Internet won't follow an alias to learn the address of a name server, so using an alias in an NS record is about as useful as not listing it at all. - Mitigation: Replace any aliases in NS records with the official (or 'canonical') domain names of the name servers. - Test ID: T003F - Name: Check for duplicate NS addrs - Description: This test looks up the addresses of the authoritative name servers for the zone and checks for duplicates. - Implication: Duplicate address records don't add any redundancy, and may in fact increase resolution time. - Mitigation: Remove NS records that point to duplicate addresses. - Category: Consistency - Subcategory: NS Records - Test ID: T004A - Name: Reverse map all NS A RRs - Description: This test checks whether the addresses of the tested zone's name servers map back to domain names. - Implication: This is really more of an aesthetic issue than anything else. Query tools like nslookup and dig work better if your name server's address maps back to a domain name. - Mitigation: If your name server's address doesn't map back to a domain name and you control the reverse-mapping zone the address is a part of, just add a PTR record for its address to the reverse-mapping zone. If someone else controls the reverse-mapping zone, ask them to add a PTR record for your name server. - Test ID: T004B - Name: Check NS address PTR matches NS name - Description: This test checks whether the addresses of a tested zone's name servers map back to the domain names of those name servers. - Implication: This is really more of an aesthetic issue than anything else. Query tools like nslookup and dig work better if your name server's address maps back to its domain name. - Mitigation: If your name server's address doesn't map back to a domain name and you control the reverse-mapping zone the address is a part of, just add a PTR record for its address to the reverse-mapping zone. If someone else controls the reverse-mapping zone, ask them to add a PTR record for your name server. - Section: Nameserver - Category: Security - Subcategory: Name Server - Test ID: T005A - Name: Fingerprint nameserver - Description: This test checks whether it's possible to fingerprint the tested zone's name servers (i.e., determine which name server software they run and its version). Almost every name server can be fingerprinted; the only question is how accurately. The tool we use for fingerprinting, *fpdns*, will occasionally get the make or model wrong. - Implication: If your name server can't be fingerprinted or our tool guesses wrong, that's better for you because it'll be harder for a hacker to tailor an attack to your particular make and model of name server. - Test ID: T005B - Name: Check fingerprint for vulnerable version - Description: This test cross-checks the version of the tested zone's authoritative name servers (as determined by test T005A) against ISC's Security Matrix. The cross-check isn't perfect, however. If the test flags yours as a vulnerable version of the BIND name server, verify that assessment against the matrix yourself. - Implication: Running a vulnerable or outdated name server implementation is very dangerous. A hacker could capitalize on a vulnerability to gain control of your name server, and possibly use your name server as a stepping stone to attack your other hosts. He could publish bogus data, directing your users and customers to your competition or to a fake copy of your web site or mail server, where their data could be harvested. - Mitigation: If you find that your name server is vulnerable, upgrade to a current version as soon as possible. - Test ID: T006A - Name: Send VERSION.BIND query - Description: This test checks whether it's possible to fingerprint the tested zone's name servers (i.e., determine which name server software they run and its version) by sending them queries for a TXT record attached to the pseudo-domain name *version.bind* in the CHAOSNET class. BIND name servers, unless otherwise configured, return their version as part of the response to these queries. - Implication: If your name server can be fingerprinted using this method, it's that much easier for a hacker to determine its vulnerabilities and then tailor an attack to your particular make and model of name server. - Mitigation: Configuring most name servers not to respond to these queries is easy. On most BIND 8 and 9 name servers, you can add a *version* substatement to your name server's *options* statement in *named.conf*, like so: `options {` ` version 'None of your business'; ` `}; ` On BIND 9.3.x and later name servers, you can also use: `options {` ` version none;` `};` - Section: Zone - Category: Configuration - Subcategory: SOA Records - Test ID: T007A - Name: Send SOA query - Description: This test sends each of the tested zone's authoritative name servers a nonrecursive query for the zone's SOA record. All of your name servers should respond authoritatively to such a query. - Implication: If any of your zone's name servers don't respond, or don't respond authoritatively to such a query, they're misconfigured. This will prevent other name servers from using them to resolve domain names in your zone and will lengthen the time it takes to resolve those domain names. - Mitigation: If the tested zone's authoritative name servers don't respond, there's probably an operational problem with those name servers. If your name servers return an error, such as SERVFAIL, that's an indication of a configuration error. Check your name servers' syslog output for a description of the error. - Section: Nameserver - Category: Performance - Subcategory: Query - Test ID: T007B - Name: Measure response time - Description: This test sends each of the tested zone's authoritative name servers a query and times the responses. If you're performing the test from your own network and the authoritative name servers aren't too distant, the response times should be low-- generally, less than 100ms. - Implication: Longer response times mean longer name resolution times and reduced performance for applications. - Mitigation: If you find one or more of your name servers are responding slowly, you need to determine why before you can address the problem. Is the name server simply a long way away from the querier? Is the name server overloaded? You might check how many queries it's receiving per second or how much CPU it's using. For details on how to measure query load on a name server, see the recipe titled *[Measuring a Name Server’s Performance](https://learning.oreilly.com/library/view/dns-bind/0596004109/ch05.html#dnsbindckbk-CHP-5-SECT-14)* from the *[DNS & BIND Cookbook](https://learning.oreilly.com/library/view/dns-bind/0596004109/)*. - Section: Zone - Category: Configuration - Subcategory: Authority - Test ID: T007C - Name: Check for AA bit - Description: This test sends each of the tested zone's authoritative name servers a nonrecursive query for the zone's SOA record and checks that the responses are authoritative (i.e., have the AA bit set in the DNS message header). - Implication: Name servers that don't return authoritative responses are 'lame,' and can cause long resolution times and decreased resiliency. - Mitigation: Authoritative name servers should return--no surprise here--authoritative responses to SOA queries for data in the zone. If they return a nonauthoritative response, that's an indication that the name server isn't configured as an authoritative for the zone, or that there's an error in the zone data file. Check your name server's syslog output for an error message. If your name servers return an error, such as SERVFAIL, that's also an indication of a configuration error. - Category: Consistency - Subcategory: SOA Record - Test ID: T007D - Name: Compare all SOA MNAME fields - Description: This test compares the MNAME fields of the SOA records returned from the tested zone's authoritative name servers. The MNAME field, which by convention contains the domain name of the zone's primary name server, should match on all authoritative name servers." - Implication: If your authoritative name servers are returning different answers, this could cause inconsistent resolver behavior, and could cause dynamic updates to be sent to different name servers. - Mitigation: If the MNAME field doesn't match on all of your zone's authoritative name servers and you haven't recently changed the field, your name servers might be out of synch. Check your secondary name servers' syslog output for errors indicating a failure to transfer the zone. Another possibility is that you run more than one primary for your zone. Active Directory-integrated zones have multiple primaries, for example. - Test ID: T007E - Name: Compare all SOA RNAME fields - Description: This test compares the RNAME fields of the SOA records returned from the tested zone's authoritative name servers. The RNAME field, which by convention contains the email address of a technical contact for the zone, should match on all authoritative name servers. Implication: If your authoritative name servers are returning different answers, this could cause inconsistent resolver behavior. - Mitigation: If the RNAME field doesn't match on all of your zone's authoritative name servers and you haven't recently changed the field, your name servers might be out of synch. Check your name servers' syslog output for errors indicating a failure to transfer the zone. - Test ID: T007F - Name: Compare all SOA SERIAL fields - Description: This test compares the serial numbers in the SOA records returned from the tested zone's authoritative name servers. The serial number should match on all authoritative name servers, except for brief inconsistencies after you've changed the zone data. - Implication: If your authoritative name servers are returning different answers, this could cause inconsistent behavior on secondary name servers. - Mitigation: If the serial numbers don't match on all of your zone's authoritative name servers and you haven't recently changed the field, your name servers might be out of synch. Check your name servers' syslog output for errors indicating a failure to transfer the zone. Another possibility is that you run more than one primary for your zone. Active Directory-integrated zones have multiple primaries, for example, and each may have a different serial number. - Test ID: T007G - Name: Compare all SOA REFRESH fields - Description: This test compares the REFRESH fields of the SOA records returned from the tested zone's authoritative name servers. The REFRESH field, which tells secondary name servers how often to check for changes to the zone on the primary, should match on all authoritative name servers. - Implication: If your authoritative name servers are returning different answers, this could cause inconsistent behavior on secondary name servers. - Mitigation: If the REFRESH field doesn't match on all of your zone's authoritative name servers and you haven't recently changed the field, it could be that your name servers are out of synch. Check your name servers' syslog output for errors indicating a failure to transfer the zone. - Test ID: T007H - Name: Compare all SOA RETRY fields - Description: This test compares the RETRY fields of the SOA records returned from the tested zone's authoritative name servers. The RETRY field, which tells secondary name servers how often to check for changes to the zone on the primary after a refresh query has failed, should match on all authoritative name servers. - Implication: If your authoritative name servers are returning different answers, this could cause inconsistent behavior on secondary name servers. - Mitigation: If the RETRY field doesn't match on all of your zone's authoritative name servers and you haven't recently changed the field, it could be that your name servers are out of synch. Check your name servers' syslog output for errors indicating a failure to transfer the zone. - Test ID: T007I - Name: Compare all SOA EXPIRE fields - Description: This test compares the EXPIRE fields of the SOA records returned from the tested zone's authoritative name servers. The EXPIRE field, which tells secondary name servers how long they can answer queries without successfully refreshing the zone, should match on all authoritative name servers. - Implication: If your authoritative name servers are returning different answers, this could cause inconsistent behavior on secondary name servers. - Mitigation: If the EXPIRE field doesn't match on all of your zone's authoritative name servers and you haven't recently changed the field, it could be that your name servers are out of synch. Check your name servers' syslog output for errors indicating a failure to transfer the zone. - Test ID: T007J - Name: Compare all SOA NEGTTL numbers - Description: This test compares the NEGTTL fields of the SOA records returned from the tested zone's authoritative name servers. The NEGTTL field, which tells remote name servers how long they can cache negative answers (e.g., NXDOMAIN and NODATA) from your zone's authoritative name servers, should match on all authoritative name servers. - Implication: If your authoritative name servers are returning different answers, this could cause inconsistent resolver behavior. - Mitigation: If the EXPIRE field doesn't match on all of your zone's authoritative name servers and you haven't recently changed the field, it could be that your name servers are out of synch. Check your name servers' syslog output for errors indicating a failure to transfer the zone. - Category: Configuration - Subcategory: SOA Record - Test ID: T007K - Name: Examine SOA refresh - Description: This test checks whether the tested zone's REFRESH value falls within the range recommended by RFC 1912 (20m-2h or 2h-12h). - Implication: REFRESH values outside of this range will either cause secondary name servers to check too frequently (less than 20 minutes) or too infrequently (more than 12 hours) for new zone data on their master name server. - Mitigation: If your zone's REFRESH value is outside the recommended range, you can set it to a more acceptable value by editing the SOA record on the zone's primary name server. Don't forget to increment the serial number! (On a zone that uses NOTIFY, however, the value you choose for REFRESH isn't that important.) - Test ID: T007L - Name: Examine SOA retry - Description: This test checks whether the tested zone's RETRY value falls within the range recommended by RFC 1912 (a fraction of the zone's REFRESH value). - Implication: RETRY values outside of this range will either cause secondary name servers to check too frequently or too infrequently for new zone data on their master name server. - Mitigation: If your zone's RETRY value is outside the recommended range, you can set it to a more acceptable value by editing the SOA record on the zone's primary name server. Don't forget to increment the serial number! (On a zone that uses NOTIFY, however, the value you choose for RETRY isn't that important.) - Test ID: T007M - Name: Examine SOA expire - Description: This test checks whether the tested zone's EXPIRE value falls within the range recommended by RFC 1912 (2w-4w). - Implication: EXPIRE values outside of this range will either cause secondary name servers to expire the zone too quickly or to continue responding for too long after failing to refresh the zone. - Mitigation": "If your zone's EXPIRE value is outside the recommended range, you can set it to a more acceptable value by editing the SOA record on the zone's primary name server. Don't forget to increment the serial number! - Test ID: T007N - Name: Examine SOA negttl - Description: This test checks whether the tested zone's NEGTTL value falls within a sane range (5m-1h). - Implication: NEGTTL values outside of this range will either cause remote name servers to cache negative answers for too long, impairing your ability to modify your zone data, or will cause remote name servers to query your name servers too frequently, placing added load on them. - Mitigation": "If your zone's NEGTTL value is outside the recommended range, you can set it to a more acceptable value by editing the SOA record on the zone's primary name server. Don't forget to increment the serial number! - Test ID: T007O - Name: Check SOA MNAME also in NS RR RDATA - Description: This test checks whether the MNAME field in the tested zone's SOA record matches one of the name servers listed in the zone's NS records. - Implication: If your zone's MNAME field isn't set to a name server in one of the zone's NS records, some dynamic updaters (particularly non-Microsoft updaters) may have trouble identifying the zone's primary name server and updating it. There's one case in which the MNAME shouldn't be set to the domain name of the zone's primary: If you use a hidden primary configuration-- which we can't detect--the MNAME field shouldn't contain the name of one of the name servers listed in the NS records. - Mitigation: You can set the MNAME field by editing the SOA record on the zone's primary name server. - Test ID: T007P - Name: Check syntax of SOA MNAME - Description: This test checks the syntax of the MNAME field of the tested zone's SOA record for validity. The MNAME field must contain a valid host name. - Implication: If the MNAME field doesn't contain a valid host name, dynamic updates may not work, and secondary name servers may unnecessarily send NOTIFY messages to the zone's primary. - Mitigation: Edit the zone's data file on the primary name server and change the MNAME field to a valid value. - Test ID: T007Q - Name: Check syntax of SOA RNAME - Description: This test checks the syntax of the RNAME field of the tested zone's SOA record for validity. It also checks whether the RNAME is set to the default value for Infoblox appliances. The RNAME field requires a special syntax: an Internet email address, but with a dot ('.') substituted for the at-sign ('@'). - Implication: If the RNAME field doesn't contain a valid entry, or is uninitialized, it may not be possible for other DNS administrators to find the person responsible for management of your zone--you, presumably. - Mitigation: Edit the zone's data file on the primary name server and change the RNAME field to a valid value. - Section: Nameserver - Category: Compliance - Subcategory: Protocol - Test ID: T008A - Name: Send TCP-based SOA query - Description: This test checks whether the tested zone's authoritative name servers respond to a TCP-based query for the zone's SOA record. While DNS messages (queries and responses) are normally sent over UDP, there are occasions when TCP is used. For example, if one of your zone's authoritative name servers can't fit all of the records in a response into a UDP-based DNS message, it will make the response as truncated. The querier may then retry the query over TCP. - Implication: Not serving TCP-based queries will cause your name server to fail to answer in seemingly random situations, such as when an answer exceeds a certain size. - Mitigation: If one or more of your name servers aren't responding to TCP-based queries, it's probably due to access controls on a router or firewall. You can adjust your router's or firewall's access controls to allow TCP connections to the DNS port, port 53, on your name servers. - Section: Zone - Category: Compliance - Subcategory: Protocol - Test ID: T009A - Name: Send query from low-numbered port - Description: This test checks whether the tested zone's authoritative name servers respond to a UDP-based query sent from a low-numbered port (below port 1024). While most resolvers and name servers send queries from high-numbered ports, some older name servers send queries from low-numbered ports, especially port 53. - Implication: Not accepting queries from these ports will prevent such name servers from using your zone's authoritative name servers. - Mitigation: If one or more of your name servers aren't responding to UDP-based queries from low- numbered ports, it's probably due to access controls on a router or firewall. You can adjust your router's or firewall's access controls to allow UDP connections from low- numbered ports to the DNS port, port 53, on your name servers. - Category: Security - Subcategory: Zone - Test ID: T010A - Name: Try AXFR for zone - Description: This test tries to transfer the tested zone from its authoritative name servers. - Implication: Allowing zone transfers from arbitrary IP addresses (like ours) increases your name servers' vulnerability to denial of service attacks and makes it easier for a would-be hacker to 'map' your network. (Of course, in order to facilitate this tool's checks of zone data, you've probably opened up transfers from at least one of your; zone's authoritative name servers. You can safely ignore that instance of this message as it applies to the name server you're allowing the tool to transfer from.) - Mitigation: To lock down zone transfers, you can use the *allow-transfer* substatement in *named.conf*, like so: `options { allow-transfer { 10.0.0.1 }; };` - Subcategory: Recursion - Test ID: T011A - Name: Test for open recursion - Description: This test checks whether the name servers for the tested zone respond to recursive queries from arbitrary IP addresses. - Implication: Allowing recursive queries from arbitrary IP addresses (like ours) increases your name servers' vulnerability to cache poisoning attacks and use in denial of service attacks against others. - Mitigation: If your authoritative name servers don't serve any legitimate resolvers and aren't used as forwarders, you can disable recursion like this: `options { recursion no; };` If your authoritative name servers are used by legitimate resolvers or are used as forwarders, you should consider splitting the recursive and authoritative functions between two sets of name servers. If you can't do that, at least use the *allow-recursion* substatement to restrict which clients get recursive name servers, like so: `options { allow-transfer { localnets; }; };` For more information, see the recipe *[Restricting the Queries a Name Server Answers](https://learning.oreilly.com/library/view/dns-bind/0596004109/ch07.html#dnsbindckbk-CHP-7-SECT-12)* from the *[DNS & BIND Cookbook](https://learning.oreilly.com/library/view/dns-bind/0596004109/)*. - Section: Nameserver - Category: Compliance - Subcategory: Protocol - Test ID: T012A - Name: Test for EDNS0 support - Description: This test checks whether the tested zone's authoritative name servers respond to a EDNS0 query for the zone's SOA record. EDNS0 is used by modern name servers to carry large payloads over UDP. Traditionally, UDP-based DNS messages have been limited to 512 bytes. With EDNS0, UDP-based DNS messages can be as large as 4KB. As we begin storing more complex records in DNS to support new applications such as SPF, DKIM and ENUM, EDNS0 support will be increasingly important. - Implication: Not supporting EDNS0 will make it difficult, or at least more costly, for your name servers to support new DNS applications such as SPF, DKIM and ENUM. - Mitigation: If your name servers don't support EDNS0, the only solution is to upgrade to a name server that does. - Section: Zone - Category: Configuration - Subcategory: Mail - Test ID: T014A - Name: Count number of MX records - Description: This test simply counts the number of MX records the tested zone has. If the domain name of your zone is also an email destination, you should have an MX record for it. (If the domain name of your zone isn't an email destination, there's no point in adding an MX record for it, of course.) - Implication: In most cases, listing only a single MX record (or multiple MX records, all with the same preference) is a good idea, as spammers frequently target backup mail exchangers. - Mitigation: You can add or delete MX records by editing your zone's data file on the primary name server. Don't forget to increment the zone's serial number after you've made changes! - Test ID: T014B - Name: Check MX RDATA format Description: This test checks that the MX records for the tested zone have sensible-looking preference and mail exchanger values. - Implication: Using IP addresses or other semantically incorrect values in MX records can prevent mail servers from sending you email. - Mitigation: You can correct any mistakes in your MX records by editing them in your zone's data file on the primary name server. Don't forget to increment the zone's serial number after you've made changes! - Test ID: T014C - Name: Check MX name for validity - Description: This test checks that the mail exchangers listed in the tested zone's MX records have valid domain names. Legal domain names contain alphanumeric characters (A to Z upper- and lowercase, and 0 to 9) and dash. You may not use the IP address of a mail exchanger in an MX record. - Implication: Using an invalid domain name for a mail exchanger can prevent mail servers from sending you email. - Mitigation: Change the domain names of the mail exchangers in your zone by editing your zone's data file on the primary name server. Don't forget to increment the zone's serial number after you've made changes! - Test ID: T014D - Name: Check for duplicate MX names - Description: This test checks that no mail exchangers are listed more than once in the tested zone's MX records. - Implication: A mail exchanger listed more than once doesn't add any redundancy and in fact can slow mail delivery. - Mitigation: Remove duplicate MX records from your zone's data. - Test ID: T014E - Name: Count unique MX preferences - Description: This test counts the number of unique preference values in the tested zone's MX records. - Implication: In most cases, listing only a single MX record (or multiple MX records, all with the same preference) is a good idea, as spammers frequently target backup mail exchangers. - Mitigation: You can add or delete MX records by editing your zone's data file on the primary name server. Don't forget to increment the zone's serial number after you've made changes! - Test ID: T015A - Name: Check MX addresses for RFC1918 - Description: This test checks whether any of the addresses of the tested zone's mail exchangers are on RFC 1918 networks. - Implication: A mail exchanger on an RFC 1918 network isn't reachable from the Internet. Listing it will slow mail delivery. Of course, if your mail destination is solely internal, you can ignore the results of this test. - Mitigation: Remove MX records pointing to mail exchangers on RFC 1918 networks from your zone's data. - Test ID: T015B - Name: Check MX name is not a CNAME - Description: This test checks whether any of the domain name of the tested zone's mail exchangers are aliases. - Implication: Using an alias as the domain name of a mail exchanger can cause mail to loop. - Mitigation: Replace any aliases in MX records with the official domain name of the mail exchanger. - Test ID: T015C - Name: Check for duplicate MX addresses - Description: This test checks that no mail exchangers with the same address appear in the tested zone's MX records. - Implication: A mail exchanger listed more than once doesn't add any redundancy and in fact can slow mail delivery. - Mitigation: Remove duplicate MX records from your zone's data. - Category: Consistency - Subcategory: Mail - Test ID: T016A - Name: Reverse map MX name - Description: This test checks that the addresses of the tested zone's mail exchangers reverse map to domain names. - Implication: If a mail exchanger's address doesn't reverse map to a domain name, this can cause delays in mail delivery and can cause email to fail anti-spam checks. - Mitigation: Add a PTR record to the appropriate reverse-mapping zone to map your mail exchanger's address back to its domain name. - Test ID: T016B - Name: Check MX address PTR matches MX name - Description: This test checks that the addresses of the tested zone's mail exchangers reverse map to their domain names. - Implication: If a mail exchanger's address doesn't reverse map to its domain name, this can cause email to fail anti-spam checks. - Mitigation: Add a PTR record to the appropriate reverse-mapping zone to map your mail exchanger's address back to its domain name. - Test ID: T017A - Name: Connect to mail exchanger - Description: This test checks that the tested zone's mail exchangers are running SMTP servers. - Implication: Unresponsive mail exchangers will slow or prevent delivery of email. - Mitigation: If SMTP servers on your zone's mail exchangers aren't responding, you should find out whether there's been a failure of some kind. Has your SMTP server crashed? If your mail exchanger doesn't run SMTP, well, it shouldn't be listed in an MX record. - Test ID: T017B - Name: Check MX name appears in SMTP greeting - Description: This test checks whether the domain names of the tested zone's mail exchangers appear in their SMTP greeting. - Implication: None. - Mitigation: This test is mostly aesthetic. There are valid reasons to have your mail exchanger return a greeting with a domain name other than what appears in your zone's MX records. - Test ID: T017D - Name: Try to deliver some mail - Description: This test attempts to deliver electronic mail to the mail exchanger listed in an MX record. This helps determine whether the mail exchanger is correctly configured to accept mail addresses to the domain name in the MX record. - Implication: If the mail exchanger isn't correctly configured to accept mail addressed to the domain name that owns the MX record, mail sent to that domain name will bounce. - Mitigation: If the mail exchanger rejects the attempt because it thinks the domain name in the email address isn't local, check the documentation for your email software for instructions on how to configure local domain names. - Category: Security - Subcategory: Mail - Test ID: T018A - Name: Lookup MX address in common RBLs - Description: This test looks up the addresses of the tested zone's mail exchangers in several popular Real-time Blackhole Lists. If the address of one of your mail exchangers appears in a Real-time Blackhole List, the maintainers of that list think it's an open relay or that it's been sending spam. The RBLs we check are [sbl.spamhaus.org](http://sbl.spamhaus.org), [cbl.abuseat.org](http://cbl.abuseat.org), and [bl.spamcop.net](http://bl.spamcop.net). - Implication: You may have trouble sending mail from your mail server, since receiving mail servers won't allow connections from it, or will more frequently categorize mail coming from it as spam. - Mitigation: If you've inadvertently been listed or have changed your ways and want to be removed, click on the links above. - Category: Configuration - Subcategory: Zone - Test ID: T021A - Name: Identify uncommon record types (e.g., NAPTR, AAAA, LOC) - Description: This test transfers a copy of the tested zone and identifies uncommon record types (all those except SOA, NS, A, AAAA, PTR, MX, CNAME, SRV, SVCB, HTTPS, and TXT). - Implication: While there's nothing wrong, *per se*, with using these record types, there's a good chance they aren't being used. Leaving them in the zone makes the zone larger, and therefore more resource-intensive to load and transfer. - Mitigation: Remove any unused, uncommon record types. - Category: Security - Subcategory: Zone - Test ID: T022A - Name: Try an UPDATE - Description: This test attempts to dynamically update the tested zone. (If it successfully adds a record, it then deletes it. Wouldn’t want to leave a mess.) - Implication: Allowing dynamic updates--especially from random addresses like the one this tool is running from--is an enormous security exposure. An updater has almost complete control over a zone: He can delete the entire contents of the zone, except for the SOA record and one NS record, and add completely different records. - Mitigation: Apply access controls to dynamic updates to your zone, or if there are no authorized updaters, deny updates to the zone entirely. On a BIND name server, you can use the *allow-updates* substatement to restrict updates to certain addresses. For example: `zone 'test.example' { ` `type master; ` ` file 'db.test.example'; ` ` allow-update { 10.0.0.1; }; ` `}; ` To deny updates entirely, you can use: `zone 'test.example' { ` ` type master; ` ` file 'db.test.example'; ` ` allow-update { none; }; ` }; - Category: Configuration - Subcategory: Zone - Test ID: T023A - Name: Look for Subdomains - Description: This test identifies delegated subdomains of the tested zone. - Implication: Unless those subdomains are explicitly excluded from testing, the tool will test them, too. - Mitigation: If you don't want particular delegated subdomains tested, list them on the tool's 'Exceptions' tab. - Category: Consistency - Subcategory: Zone - Test ID: T029A - Name: Check for different zone data with same serial number - Description: This test checks whether the zone data returned by different authoritative name servers is different, though the serial numbers returned by those authoritative name servers are the same. This indicates that someone modified zone data on the primary but forgot to increment the zone's serial number. - Implication: This can cause inconsistent answers depending on which authoritative name server you query. - Mitigation: Increment the zone's serial number on the primary name server. - Category: Configuration - Subcategory: Zone - Test ID: T030A - Name: Count hosts - Description: This test counts the number of A records in the zone. This is purely statistical. - Implication: None. - Mitigation: None. - Test ID: T031A - Name: Zone contents PTR RR sanity checks - Description: This test performs sanity checks on each PTR record in the tested zone. For each PTR record mapping address X to domain name Y: Check whether Y owns an A record that points back to X. Check whether Y owns a CNAME record. (It shouldn't.) Check whether Y owns any other PTR records. (It shouldn't--see T031B.) - Implication: Any of these conditions can cause problems reverse mapping the address. - Mitigation: Make sure that, for each PTR record mapping address X to domain name Y, there's a symmetric A record mapping Y to X. Make sure that every domain name that owns a PTR record owns only one PTR record. - Test ID: T031B - Name: Count number of PTR RRs in an RRSET - Description: This test counts the number of PTR records attached to each domain name in the tested zone. - Implication: While attaching multiple PTR records to a single domain name is legal, it can lead to unpredictable results when reverse mapping an address. - Mitigation: Determine which domain name you want each address to reverse map to and remove all PTR records attached to that address but that one. - Test ID: T031C - Name: Zone contents CNAME RR sanity checks - Description: This test performs sanity checks on each CNAME record in the tested zone. For each CNAME record aliasing X to Y: Check whether Y exists. (It should.) Check whether Y owns a CNAME record itself. (It probably shouldn't.) - Implication: Either of these conditions can prevent the alias from resolving properly. - Mitigation: Make sure that, for each CNAME record aliasing X to Y, Y exists and doesn't own a CNAME record itself. If Y doesn't exist, determine whether the CNAME record should be deleted or corrected to point to a different Y. If Y owns a CNAME record, make sure it doesn't create an alias loop or a chain of aliases longer than three or four records. - Test ID: T031D - Name: Zone contents MX RR sanity checks - Description: This test performs sanity checks on each MX record in the tested zone. For each MX record pointing domain name X to mail exchanger Y: Check that Y exists and owns at least one A record. Check that Y doesn't own a CNAME record. Check that Y is a legal hostname. - Implication: Any of these conditions can prevent the MX record from working properly. - Mitigation: Make sure that, for each MX record pointing domain name X to mail exchanger Y, that Y exists and owns at least one A record, not an alias, and that Y is a legal hostname. - Test ID: T031E - Name: Zone contents A RR sanity checks - Description: This test performs sanity checks on each A record in the tested zone. For each A record pointing domain name X to address Y: Check that Y reverse maps to X (that is, that Y owns a PTR record the maps back to X). Check that X is a legal hostname. - Implication: Illegal hostnames can prevent an A record from resolving, and a missing symmetric PTR record can cause the A record to fail 'double-reverse'-style checks. - Mitigation: Make sure that, for every A record pointing domain name X to address Y, that Y reverse maps to X and that X is a legal hostname. - Test ID: T031F - Name: Zone contents AAAA RR sanity checks - Description: This test performs a sanity check on each AAAA record in the tested zone, checking that the domain name that owns the AAAA record is a legal hostname. - Implication: Illegal hostnames can prevent an AAAA record from resolving. - Mitigation: Make sure that all domain names that own AAAA records are legal hostnames. - Test ID: T031G - Name: Zone contents NS RR sanity checks - Description: This test performs a sanity check on each NS record in the tested zone, checking that the domain name on the right side of the NS record is a legal hostname. - Implication: Illegal hostnames can prevent an NS record from resolving. - Mitigation: Make sure that all domain names listed in NS records are legal hostnames. - Test ID: T031H - Name: Zone contents SRV RR sanity checks - Description: This test performs a sanity check on each SRV record in the tested zone, checking that the domain name in the target field of the SRV record is a legal hostname. - Implication: Illegal hostnames can prevent an SRV record from resolving. - Mitigation: Make sure that all domain names listed in the target fields of SRV records are legal hostnames. - Test ID: T032A - Name: Check that domain name isn't repeated - Description: This test checks whether the domain name of the zone appears repeated in any domain names (for example, *ns1.test.example.test.example*). - Implication: Repeated domain names like this are usually an indication of a missing trailing dot in the zone data file, like so: `test.example. NS ns1.test.example` If the default origin in the zone data file is *test.example*, the right side of the NS record expands to *ns1.test.example.test.example*. - Mitigation: Find the offending record in the zone data file on the primary name server and add the missing trailing dot. - Test ID: T033A - Name: Check for obsolete or deprecated RR types - Description: This test transfers a copy of the tested zone and identifies uncommon record types (all those except SOA, NS, A, PTR, AAAA, MX, CNAME, SRV, SVCB, HTTPS and TXT). - Implication: While there's nothing wrong, per se, with using these record types, there's a good chance they aren't being used. Leaving them in the zone makes the zone larger, and therefore more resource-intensive to load and transfer. - Mitigation: Remove any unused, uncommon record types. - Test ID: T034A - Name: Check for wildcards - Description: This test checks for the presence of wildcards in the tested zone. - Implication: Wildcards have very limited uses, and can interact badly with search lists. Unless you're sure of what you're doing, you probably shouldn't use wildcards. - Mitigation: Remove any unnecessary wildcards from your zone data. - Test ID: T035A - Name: Check for unusual TTLs (very low, very high) - Description: This test checks for either very low or very high TTLs on records in the tested zone. 'Very low' is currently defined as less than 30 seconds, while 'very high' is more than one week. - Implication: Except for special circumstances, such as load balancing, very low TTLs are unnecessary and can increase load on authoritative name servers. Using a TTL of zero can even prevent some older name servers from resolving a record. Very high TTLs will impair your ability to modify data. - Mitigation: Increase or reduce TTLs on identified records as necessary. - Section: Infrastructure - Category: Infrastructure - Subcategory: Security - Test ID: T100A - Name: Malicious domain check - Description: This test checks whether the default recursive name server will resolve a known malicious domain name. - Implication: Name servers that don't prevent the resolution of known malicious domain names allow users and devices to communicate with dangerous resources on the Internet. - Mitigation: To prevent your name servers from resolving known malicious domain names, configure them with Response Policy Zones (or some equivalent policy mechanism) that block such resolution or forward to a recursive DNS service that blocks such resolution. - Section: Zone - Category: Other - Subcategory: Zone - Test ID: T100B - Name: Check for orphaned PTR RRs - Description: This test checks whether the zone contains any orphaned CNAME records, which are aliases that point to non-existent domain names - Implication: Orphaned CNAME records are at best useless and at worst can be a security issue, especially if the alias points to a domain name outside of the organization's control, such as a domain name in AWS's namespace. A malicious party could gain control of the target domain name and masquerade as the organization. - Mitigation: Delete the orphaned CNAME record or update the target domain name to one that exists. - Section: Infrastructure - Category: Infrastructure - Subcategory: DoT/DoH - Test ID: T100C - Name: Check whether the network permits queries to external DoT/DoH providers - Description: This test checks whether the network permits querying popular external DoT and DoH providers. The providers we check are Cloudflare, Quad9 and Google Public DNS. - Implication: Networks that don't prevent the use of Internet-based DoT and DoH providers allow users to bypass internal DNS infrastructure, thereby circumventing security and making troubleshooting difficult. - Mitigation: To prevent internal clients from using external DoT and DoH providers, block traffic to their IP addresses on ports 443/tcp and 853/tcp. - Section: Zone - Category: Infrastructure - Subcategory: Zone - Test ID: T100D - Name: Resolution of SVCB/HTTP (TYPE64/TYPE65) RRs - Description: This test checks whether the default recursive name servers can resolve SVCB and HTTPS records by looking up known SVCB and HTTPS records on the Internet. - Implication: HTTPS records, in particular, are a relatively new way to discover attributes of a web site before connecting to it, including which web servers support it, the 'dialects' of HTTP they speak, and more. Without the ability to resolve these records, users on the network will not be able to take advantage of the speed, security and reliability improvements in HTTP/3, and may not be able to access some web sites at all. - Mitigation: If the name server software doesn't support resolution of SVCB and HTTPS records, it will have to be upgraded or replaced to support it. - Section: Infrastructure - Category: Infrastructure - Subcategory: EDNS0 - Test ID: T100E - Name: Check whether the name server supports large UDP-based DNS messages - Description: This test checks whether the name server supports returning large UDP-based DNS messages to clients. - Implication: A low limit on the size of UDP-based DNS messages could cause queriers to retry their queries over TCP, incurring heavier load on the name server. - Mitigation: If the name server software doesn't support EDNS0, it will have to be upgraded or replaced to support it. If the name server has just been configured with a limit for UDP-based DNS messages that is too low, simply configure it with a higher limit. - Section: Zone - Category: Other - Subcategory: Zone - Test ID: T100F - Name: Limits Large UDP-based DNS message - Description: This test checks whether the name server supports returning large UDP-based DNS messages to clients. - Implication: Modern name servers should support returning UDP-based DNS messages as large as 4000 bytes or so. - Mitigation: Unless the size of the DNS message is being artificially limited by your configuration, you'll need to upgrade to a more modern name server to address this. - Section: Infrastructure - Category: Infrastructure - Subcategory: DNSSEC - Test ID: T100G - Name: Check whether the name server supports DNSSEC validation - Description: This test checks whether the name server supports DNSSEC validation by sending a query for data in a known, DNSSEC-signed zone (in this case, the root zone) and examining the answer to determine whether that answer was validated. - Implication: Name servers that don't support DNSSEC validation are susceptible to cache poisoning attacks. - Mitigation: If the name server software supports DNSSEC but it isn't configured, configure the software to perform DNSSEC validation. Generally, this requires both configuring the root zone's Key-Signing Key as a trust anchor and changing the name server's configuration to enable DNSSEC validation. If the name server software doesn't support DNSSEC validation, it will have to be upgraded or replaced to support it. - Section: Zone - Category: Other - Subcategory: Nameserver - Test ID: T100H - Name: Test whether zone is DNSSEC-signed - Description: This is determines whether the tested zone is signed using DNSSEC by looking up DNSKEY records for the zone. - Implication: Signing a zone using DNSSEC can make it more difficult to spoof data in the zone. However, internal zones are not generally signed. - Mitigation: If this is an Internet-facing zone that should be protected against spoofing and therefore signed using DNSSEC, check your name server's documentation on generating keys and signing zones. - Section: Infrastructure - Category: Infrastructure - Subcategory: Tunneling - Test ID: T100I - Name: Check whether the DNS infrastructure or network detects known DNS tunneling algorithms - Description: This test sends several queries for domain names that are part of a known DNS tunneling algorithm. If results are returned for all these queries, the DNS infrastructure is assumed not to recognize or block the tunneling algorithm. Some other device may recognize the algorithm, of course, but if all results are returned, the resolution wasn't blocked. - Implication: DNS infrastructure that doesn't block DNS tunneling allows bidirectional communication between internal devices and the Internet, possibly for malicious purposes, and likely unobserved. - Mitigation: To prevent your name servers from resolving known DNS tunneling algorithms, configure them with Response Policy Zones (or some equivalent policy mechanism) that block such resolution or forward to a recursive DNS service that blocks such resolution. - Subcategory: DoT/DoH - Test ID: T100J - Name: Check whether Firefox's canary domain is configured - Description: The test checks whether the Firefox web browser's canary domain, *[use-application-dns.net](http://use-application-dns.net)*, is configured to prevent Firefox from using DoH, DNS over HTTPS. - Implication: Without the proper configuration of Firefox's canary domain, the browser will try to use DoH to communicate with external DoH providers, circumventing security and making troubleshooting difficult. - Mitigation: To prevent Firefox from using DoH, queries for *[use-application-dns.net](http://use-application-dns.net)** *should return either an error such as NXDOMAIN or SERVFAIL or an empty answer (NOERROR and 0 answers). To configure this, either use a Response Policy Zone or create a *[use-application-dns.net](http://use-application-dns.net)** *zone that contains no A or AAAA records for the apex domain name. - Test ID: T100K - Name: Check whether the name servers supports DoT - Description: This test checks whether the name server supports DoT, DNS over TLS. - Implication: Name servers that support DoT allow secure communication between DNS clients and the name server. - Mitigation: If the name server software supports DoT but it isn't configured, configure the software to support DoT on port 853/tcp. If the name server software doesn't support DoT, it will have to be upgraded or replaced to support the new protocol. - Subcategory: Security - Test ID: T100M - Name: Lookup newly registered domain name - Description: This test checks whether the name server will resolve a newly registered domain name. A high percentage of newly registered domain names will be used maliciously but haven't been yet. Blocking their resolution gives security organizations time to investigate the domain name to determine if it's malicious in nature. - Implication: A high percentage of newly registered domain names will be used maliciously but lack any reputation. Name servers that don't prevent the resolution of newly registered domain names allow users and devices to communicate with dangerous resources on the Internet. - Mitigation: To prevent your name servers from resolving newly registered domain names, configure them with Response Policy Zones (or some equivalent policy mechanism) that block such resolution or forward to a recursive DNS service that blocks such resolution. - Test ID: T100N - Name: Lookup known suspicious domain name - Description: This test checks whether the default recursive name server will resolve a known suspicious domain name. - Implication: Name servers that don't prevent the resolution of suspicious domain names allow users and devices to communicate with potentially dangerous resources on the Internet. - Mitigation: To prevent your name servers from resolving known suspicious domain names, configure them with Response Policy Zones (or some equivalent policy mechanism) that block such resolution or forward to a recursive DNS service that blocks such resolution. - Test ID: T100O - Name: Lookup known malicious lookalike domain name - Description: This test checks whether the default recursive name server will resolve a known malicious lookalike domain name. - Implication: Name servers that don't prevent the resolution of known malicious domain names allow users to be fooled into communicate with dangerous resources on the Internet masquerading as legitimate destinations. - Mitigation: To prevent your name servers from resolving known malicious lookalike domain names, configure them with Response Policy Zones (or some equivalent policy mechanism) that block such resolution or forward to a recursive DNS service that blocks such resolution. - Test ID: T100P - name": "Checks whether the network allows clients to query public DNS providers", "description": "This test checks whether the network permits querying popular external DNS providers. The providers we check are Cloudflare and Google Public DNS.", "implication": "Networks that don't prevent the use of Internet-based DNS providers allow users to bypass internal DNS infrastructure, thereby circumventing security and making troubleshooting difficult. ", "mitigation": "To prevent internal clients from using external DNS providers, block traffic to their IP addresses on ports 53/udp and 53/tcp. - Section: Zone - Category: Other - Subcategory: Zone - Test ID: T100Q - Name: Check whether any CNAME records point to non-existent domain names - Description: This test checks whether the zone contains any CNAME records that point to nonexistent domain names. - Implication: At best, these CNAME records serve no useful purpose. At worst, they pose a security risk, since it's possible a malicious actor could assume control of the target of the CNAME record and point it to a dangerous resource. - Mitigation: If the CNAME records are no longer necessary, delete them. If they are needed, correct the domain names they point to. - Section: Infrastructure - Category: Infrastructure - Subcategory: Security - Test ID: T100R - Name: Check whether the DNS infrastructure or network detects known DGAs - Description: This test sends several queries for domain names that are part of a known Domain Generation Algorithm. If results are returned for all these queries, the DNS infrastructure is assumed not to recognize or block the DGA. Some other device may recognize the DGA, of course, but if all results are returned, the resolution wasn't blocked. - Implication: Allowing DGAs to operate unhindered allows malware to rendezvous with command and control infrastructure on the Internet. - Mitigation: To prevent your name servers from resolving known DGAs, configure them with Response Policy Zones (or some equivalent policy mechanism) that block such resolution or forward to a recursive DNS service that blocks such resolution. # Other Questions 19. What if I have a question that isn’t answered here? - Send it to [dnsadvisor@infoblox.com](mailto:dnsadvisor@infoblox.com).