I have also been looking at DNS SEC to understand how to use it to enhance my security. There are three operating modes: DNS-unware requester. Sets no bits, so they default to DO=0 (DNS SEC unaware) and CD=0 (Please check signatures for me.) DNS-aware resolver. Checks the signatures, if valid, the resource record and AD=0 (no signature info) If invalid, returns a ServFail error, which causes the client to attempt the same query with an alternate DNS server. DNS-aware requester without signature checking. Sets DO=1 (DNS OK) and CD=0 (Please check signatures for me.) DNS-aware resolver. Checks the signatures, if valid, the resource record and AD=1 (signature checked) If invalid, returns a ServFail error, which causes the client to attempt the same query with an alternate DNS server. If no signature found, returns results and AD=0. DNS-aware requester with signature checkings. Sets DO=1 (DNS OK) and CD=1 (Checkinig disabled.) DNS aware resolver returns signature data as well as resource records. Flag AD=0 because the signatures have not been checked. There may be a ServFail scenario if the signatures cannot be obtained. Passing signatures might add a lot of traffic, especially if DNS SEC catches on much more than it has at present. So I would prefer to forward traffic to Google or CloudFlare and let them to the signature checking. With the UTM "DNS SEC" option disabled, I expected DNS to behave like option 2. Instead, I find that it behaves like option 1, and when Google returns a ServFail error, it apparently fails over to the root servers and obtains the invalidated answer because nobody does signature checking. I assume that if the UTM "DNS SEC" option is enabled, UTM will behave like option 3. However, I have not tested this because of overhead concerns, because of prior bad reports in this forum, and because of the help page warning that this may cause problems with internal DNS servers. I am trying to obtain clarification through Sophos Support, but the answers have been slow coming.

This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DNS SEC confusion and frustration

I have also been looking at DNS SEC to understand how to use it to enhance my security. There are three operating modes:

DNS-unware requester. Sets no bits, so they default to DO=0 (DNS SEC unaware) and CD=0 (Please check signatures for me.)
DNS-aware resolver. Checks the signatures, if valid, the resource record and AD=0 (no signature info) If invalid, returns a ServFail error, which causes the client to attempt the same query with an alternate DNS server.
DNS-aware requester without signature checking. Sets DO=1 (DNS OK) and CD=0 (Please check signatures for me.)
DNS-aware resolver. Checks the signatures, if valid, the resource record and AD=1 (signature checked) If invalid, returns a ServFail error, which causes the client to attempt the same query with an alternate DNS server. If no signature found, returns results and AD=0.
DNS-aware requester with signature checkings. Sets DO=1 (DNS OK) and CD=1 (Checkinig disabled.)
DNS aware resolver returns signature data as well as resource records. Flag AD=0 because the signatures have not been checked.
There may be a ServFail scenario if the signatures cannot be obtained.

Passing signatures might add a lot of traffic, especially if DNS SEC catches on much more than it has at present. So I would prefer to forward traffic to Google or CloudFlare and let them to the signature checking.

With the UTM "DNS SEC" option disabled, I expected DNS to behave like option 2. Instead, I find that it behaves like option 1, and when Google returns a ServFail error, it apparently fails over to the root servers and obtains the invalidated answer because nobody does signature checking.

I assume that if the UTM "DNS SEC" option is enabled, UTM will behave like option 3. However, I have not tested this because of overhead concerns, because of prior bad reports in this forum, and because of the help page warning that this may cause problems with internal DNS servers.

I am trying to obtain clarification through Sophos Support, but the answers have been slow coming.

This thread was automatically locked due to age.

Parents

0 DouglasFoster over 4 years ago
Given my post about the difficulty of using encryption for queries between internal DNS servers and Internet-based DNS servers, I probably need to pursue moving to configuration 3, despite my fears.

Below are some things I have learned during the research phase.

DNS host names with known behaviors

www.dnssec-failed.org is a canary which should always fail DNS SEC signature checking.

Sites with DNS SEC signatures are not easy to find.
pir.org is a DNS name that has DNS SEC configured correctly and should always validate. I know nothing about the site, but I found the reference on a post that seemed to be from the site owner.

Finding sites that do not use DNS SEC is pretty easy. I used www.ford.com for some of my tests.

Forwarder selection

Because signature problems cause a ServFail error, traffic is not automatically blocked. A client will try all available servers before giving up, so you want to ensure that all forwarders are DNS-SEC aware. As long as this is the case, even obsolete systems like XP will be protected from invalid results. I discovered that my ISP has not enabled DNS SEC on any of its DNS servers, so I am removing their servers from my configuration, at both work and home. Instead I will be using Neustar Public DNS and Quad9, as both of these provide bad-destination filtering as well as DNS SEC signature checking.

Utilities

Windows NSLOOKUP does not return any information about the AD bit because it is based on code from ISC.ORG, which has deprecated the utility. The provide (free) downloads of BIND 9 for many platforms, including Windows. You can install tools only, to obtain DIG as a replacement for NSLOOKUP. You can also install BIND 9 as a full DNS server.

Windows implementation status

XP / Server 2003 - Are DNS-Unaware (DO=0)

Windows 7 and later desktops, and presumably Server 2008/2008R2 are DNS Aware as a stub resolver (DO=0 with CD=0)

Server 2012 has full support for DNS SEC. By default, signature checking is off. You have to use PowerShell to do your own signature checking (CD=1)

Server 2016 and later add support for signing internal domains, including signatures for DHCP-issued names and signature enforcement for internal domains, such as *.local, that do not have a parent structure to hold a trust anchor.

DNS Filtering options

There are multiple ways to implement filtering of high-risk DNS Names.

Quad9 returns NXDOMAIN (no such host name). This causes the client to get an immediate failure, and no other DNS servers will be attempted.

Neustar DNS returns an IP address for a web landing page on their servers. Non-web traffic will receive a host-not-reachable error. Web queries will receive a warning page. In either case, the client will get an immediate result. HTTPS sites will get a certificate error, so the landing page will only be displayed if the user clicks past the certificate error. This approach is only viable if the blacklisted site is not DNS SEC signed, which is likely to be true but cannot be assured. I have not determined how they behave if a domain is both signed and blacklisted. However, I have used the canary hostname to confirm that if a site is incorrectly signed and not blacklisted, they return ServFail as expected.

UTM IPS blocks the DNS reply for blacklisted host names. This eventually causes a timeout, which eventually be detected as a ServFail by the client. The client will then return any other available DNS servers. If UTM is filtering all outbound traffic, UTM IPS can be expected to block all of the retries, causing the client to finally quit trying. This is the slowest possible solution to DNS filtering, and provides no feedback to the user. If UTM IPS does not filter all DNS traffic, the requester will eventually find the query path that is not blocked, and the request will succeed even though UTM attempted to block it.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 DouglasFoster over 4 years ago
Given my post about the difficulty of using encryption for queries between internal DNS servers and Internet-based DNS servers, I probably need to pursue moving to configuration 3, despite my fears.

Below are some things I have learned during the research phase.

DNS host names with known behaviors

www.dnssec-failed.org is a canary which should always fail DNS SEC signature checking.

Sites with DNS SEC signatures are not easy to find.
pir.org is a DNS name that has DNS SEC configured correctly and should always validate. I know nothing about the site, but I found the reference on a post that seemed to be from the site owner.

Finding sites that do not use DNS SEC is pretty easy. I used www.ford.com for some of my tests.

Forwarder selection

Because signature problems cause a ServFail error, traffic is not automatically blocked. A client will try all available servers before giving up, so you want to ensure that all forwarders are DNS-SEC aware. As long as this is the case, even obsolete systems like XP will be protected from invalid results. I discovered that my ISP has not enabled DNS SEC on any of its DNS servers, so I am removing their servers from my configuration, at both work and home. Instead I will be using Neustar Public DNS and Quad9, as both of these provide bad-destination filtering as well as DNS SEC signature checking.

Utilities

Windows NSLOOKUP does not return any information about the AD bit because it is based on code from ISC.ORG, which has deprecated the utility. The provide (free) downloads of BIND 9 for many platforms, including Windows. You can install tools only, to obtain DIG as a replacement for NSLOOKUP. You can also install BIND 9 as a full DNS server.

Windows implementation status

XP / Server 2003 - Are DNS-Unaware (DO=0)

Windows 7 and later desktops, and presumably Server 2008/2008R2 are DNS Aware as a stub resolver (DO=0 with CD=0)

Server 2012 has full support for DNS SEC. By default, signature checking is off. You have to use PowerShell to do your own signature checking (CD=1)

Server 2016 and later add support for signing internal domains, including signatures for DHCP-issued names and signature enforcement for internal domains, such as *.local, that do not have a parent structure to hold a trust anchor.

DNS Filtering options

There are multiple ways to implement filtering of high-risk DNS Names.

Quad9 returns NXDOMAIN (no such host name). This causes the client to get an immediate failure, and no other DNS servers will be attempted.

Neustar DNS returns an IP address for a web landing page on their servers. Non-web traffic will receive a host-not-reachable error. Web queries will receive a warning page. In either case, the client will get an immediate result. HTTPS sites will get a certificate error, so the landing page will only be displayed if the user clicks past the certificate error. This approach is only viable if the blacklisted site is not DNS SEC signed, which is likely to be true but cannot be assured. I have not determined how they behave if a domain is both signed and blacklisted. However, I have used the canary hostname to confirm that if a site is incorrectly signed and not blacklisted, they return ServFail as expected.

UTM IPS blocks the DNS reply for blacklisted host names. This eventually causes a timeout, which eventually be detected as a ServFail by the client. The client will then return any other available DNS servers. If UTM is filtering all outbound traffic, UTM IPS can be expected to block all of the retries, causing the client to finally quit trying. This is the slowest possible solution to DNS filtering, and provides no feedback to the user. If UTM IPS does not filter all DNS traffic, the requester will eventually find the query path that is not blocked, and the request will succeed even though UTM attempted to block it.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data