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

DNSSEC, need digest of UTM to add trust anchor

I'm trying to enable DNSSEC on my network.  I have Cloudflare -> Sophos UTM -> Windows AD.

Windows AD is in request routing from the UTM.

Windows machines have to use the AD servers for DNS, which point to UTM, which point to Cloudflare.

 

The problem I have is how do I configure the Windows 2016 DNS to trust UTM as a DS trust anchor?  It is asking for the UTM digest and key tag, which I cannot find anywhere.

For Cloudflare it is right there on the dashboard, no problem. Without it, how can I make the chain work?



This thread was automatically locked due to age.
Parents
  • If you already have DNSSEC selected on the 'Global' tab of DNS and all of the Forwarders are DNSSEC capable, this may be a question that might find an answer in a Windows 2016 forum.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I think I need to rephrase the question.  I'm not asking anything about Windows.

    I'm asking for information from Sophos UTM.

    When I enable DNSSEC with request routing, all internal dns resolution goes down.  Everything fails.  The UTM request routing cannot reach the internal DNS servers.

    All internal DNS servers are now bypassing UTM and going outside for DNS.  I had to disable DNSSEC to get the LAN back.

    With Sophos DNSSEC on, all users lose internal address resolution.  Turn it off, and the network comes back up in about 10 seconds.

  • I have been studying this for days now.

    It appears to me that the Sophos DNSSEC trust system ONLY works with IANA trust anchors.

    If true, then it would not be usable for your local network.  Unless I am totally misunderstanding something.

    As far as I can tell there is no way to give it your local trust anchors.

  • Further update.  I don't think the problem is trust anchors.

    I can logon to the UTM as root and from the command line, DNSSEC seems to work.

        dig server.domain.local +dnssec

    This returns success.  However, the dns proxy fails to work.

  • My internal dns zone is not signed, but I would guess a resolution by request routing should be trusted. Question is only if no signature is used or in your case with an untrusted signature too. That was my guess, but this seems not to work.

    There should be more documentation about this available.

    Thanks for posting your information so far.

    BR

    Alex

    -

  • My communication with support ended today. Support stated that it's not possible to use UTM DNSSEC without usage of DNSSEC an all resolvers. So on internal resolvers too. How to import the keys for this wasn't answered.
    So after this I would doubt that anyone is using DNSSEC productively.
    But I like to be convinced the opposite.

    Best regards

    Alex

    -

  • Alexander Busch said:

    My communication with support ended today. Support stated that it's not possible to use UTM DNSSEC without usage of DNSSEC an all resolvers. So on internal resolvers too. How to import the keys for this wasn't answered.
    So after this I would doubt that anyone is using DNSSEC productively.
    But I like to be convinced the opposite.

    Best regards

    Alex

     

     

    But I DO have DNSSEC on all resolvers.  As I stated earlier.

  • My understanding is that AD servers are not full implementations of DNS SEC.

    One cannot implement a signed domain on an internal-only domain, (e.g. Example.local), because it is not externally registered.   There is also no good way to sign DNS entries associated with DHCP addresses, which is usually desired for internal servers.   Addressing differences between internal and external references also break DNS SEC signatures.  Consequently, DNS SEC signing of internal destinations does not make sense.   My understanding is that AD understands DNS SEC (accepts the data structures in a query reply), but does not enforce signatures.   A middleman like UTM would be needed to obtain enforcement.   Perhaps someone else can expand or correct me on this point.   

    Based on this understanding of AD behavior and  your understanding of the Support response, it seems impossible to implement UTM DNS SEC if UTM needs to perform any internal DNS lookups against an AD server.   Maybe its possible if you use a Linux box as your internal DNS server, or as a bridge between an AD server and the UTM.

    This becomes another place where product management fails to understand the importance of documentation.   You should not have been forced to suffer so much testing and related disruption to find out the design constraints of the product.   

  • Thanks for the explanation.  It is interesting.

  • I have done some more experimenting today. Note that I am not attempting to implement DNS SEC for my own domain, I simply want to be protected from results that fail DNS SEC validation.   Here are the results of my test.

    Most of the commonly-used public DNS servers appear to be DNSSEC-aware.   This includes 1.1.1.1 (CloudFlare), 8.8.8.8 (Google), 9.9.9.9 (Quad9), and 156.154.70.4 (Neustar's filtering DNS)

    Test condition:

    • You are using a DNS client configuration that is not fully DNSSEC-aware (Windows Desktop connected to Active Directory DNS server)
    • You query a web address that is not correctly signed (www.dnssec-failed.org)

    Results:

    • The DNSSEC-aware server will refuse to answer, returning a result of "Server Failed".]
    • The DNS client will try another server.
    • When all forwarders have been tried, it will use its root-hint server (which do not implement DNS SEC).
    • The root-hint servers will help the client obtain an address.

    Consequently, if we disable the root-hint servers and repeat the test:

    • All forwarders will be attempted in sequence.
    • The client will receive a lookup failure result.

    To test this, I used a standalone PC, and configured both of the DNS server values to be one of the above server addresses.  It behaved as expected.

    If you run a DNSSEC-aware DNS server inside your network,  you have to worry about the extra bandwidth consumed by DNS SEC results.   If you keep your internal network stupid, you let the remote server shelter you from that extra bandwidth.

    Have to decide if we are gutsy enough to remove the root-hint list from all of our Active Directory DNS servers.

    Also need find out if it is possible to disable the UTM root hints, for traffic handled by UTM.

  • Six years ago here, member Billybob gave a prescription for disabling root hints.  Named.conf is regenerated every time you make a change to the DNS configuration in WebAdmin.  Possibly also at reboot.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • So I think we are stuck.

    UTM with DNSSEC protection OFF will use non-DNSSEC root servers, and the root servers cannot be reasonably disabled, so it will resolve names with invalid DNSSEC signatures.

    UTM with DNSSEC protection ON will only talk to full DNSSEC servers, so it will not accept results from Active Directory DNS.

    So either way, it cannot be used?  This would explain why I have had so much trouble finding someone on this forum who has used it succesfully.

Reply
  • So I think we are stuck.

    UTM with DNSSEC protection OFF will use non-DNSSEC root servers, and the root servers cannot be reasonably disabled, so it will resolve names with invalid DNSSEC signatures.

    UTM with DNSSEC protection ON will only talk to full DNSSEC servers, so it will not accept results from Active Directory DNS.

    So either way, it cannot be used?  This would explain why I have had so much trouble finding someone on this forum who has used it succesfully.

Children
No Data