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

The sophos UTM DNS / DHCP ui is counter-intuitive to use. How do I make it easier?

The burr under my saddle all these years that I have been running a UTM has been the wonkyness of the UI for DNS and DHCP.  It has finally reached a point where I am tired of dealing with it.

:D

First is DNS.  I have the UTM's DNS forwarded to the domain controller on the network.  The domain controller is also providing DHCP services for the network.  Even though manual PTR lookups from any host on the network will return a valid name, the UTM chokes:

Does anyone know why I am getting "RESOLVING" as opposed to a valid hostname?

Thanks!

John



This thread was automatically locked due to age.
Parents
  • Hi John and welcome to the UTM Community!

    Try DNS best practice and let us know if your resolution times improve.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • So I have been a lurker since about 2010 and when the forums switched to the new format I guess my user account was blown out.  But thanks for the welcome!!

    :D

    Last night after I posted I found the recommendation to put in a request routing for the in-addr.arpa of the RFC1918 subnet in play.  Honestly, I do not understand the under-the-hood-reason why that needs to be done, but I went with it:

    But now the I am getting NXDOMAIN:

    That is clearly in error:

  • The older posts likely are associated to a different email address.

    Hmm, that is strange.  How does your setup differ from DNS best practice?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • All clients get DNS services from the domain controller.

    The domain controller is authoritative for its zone and gets its external DNS resolution from a FreeBSD box running BIND.

    The UTM is pointed to the domain controller via forwarding:

  • I am going to run tcpdump on the UTM and see if can some more insights as to where the NXDOMAIN is coming from.

    In the interim, can you provide some insights on the why the "request routing" for in-addr.arpa is needed?

    Thanks!

    John

  • dig on the UTM knows how to resolve the PTR record:

    Still feels like a UI config issue.

  • you want UTM to query Google or Quad9 DNs, with a special routing only for the internal domains and reverse lookups that it needs.

    You want the dimain contelets to forward to UTM

  • DouglasFoster said:
    you want UTM to query Google or Quad9 DNs, with a special routing only for the internal domains and reverse lookups that it needs.

    I agree that this type of configuration is certainly one way to do it.  However.  (grin)  By sending DNS traffic to Google means a) that you trust Google, b) you cannot run a DNS blacklist and c) you cannot run a split horizon DNS.

    I prefer to run my own DNS servers that query root, I run blacklists on said servers and I run a split horizon.  So sending DNS traffic out in this suggested manner is not really an option for me.  So that you all know, I have two egress points on my network.  The first is out through the UTM for content filtering and second egress has no content filtering but is port and rate restricted via PF.

    I know that you guys/gals have a ton of experience with the administration of UTM's and I reconize that the nuances can be subtle so I am grateful for continued input!

    That said, at a high level, I am hard pressed to see how my network configuration is unworkable.  Additionally, the tcpdump screenshot I pasted in clearly shows the UTM querying for a PTR and got a response.  Where we are at now is what did the UTM do with that response and on a technical level I still don't understand the concept of why "Request Routing" is even needed.  What problem does this solve?

    Thanks!

    John

  • John knows the following, but others might not...  WebAdmin and the config-daemon do create the iptables, bind and other configurations that allow the UTM to do what it does.  It's difficult to get the underlying tools to do what one might do at the command line.  Even doing them at the command line will require re-doing them in many cases unless there's a cc command that lets you change the underlying databases of settings.

    Just for grins, try changing the Forwarder in WebAdmin to your bind server, creating the Request Route for rDNS and making the UTM the first forwarder for your Windows server.  Does that change the performance?

    Cheers - Bob 

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • John knows the following, but others might not...  WebAdmin and the config-daemon do create the iptables, bind and other configurations that allow the UTM to do what it does.  It's difficult to get the underlying tools to do what one might do at the command line.  Even doing them at the command line will require re-doing them in many cases unless there's a cc command that lets you change the underlying databases of settings.

    Just for grins, try changing the Forwarder in WebAdmin to your bind server, creating the Request Route for rDNS and making the UTM the first forwarder for your Windows server.  Does that change the performance?

    Cheers - Bob 

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • BAlfson said:
    ... unless there's a cc command that lets you change ..

    Has someone put together a list of cc commands that are available?

    Just for grins, try changing the Forwarder in WebAdmin to your bind server, creating the Request Route for rDNS and making the UTM the first forwarder for your Windows server.

    It looks like your original suggestion to enable "request routing" for in-addr.arpa is what did the trick.  And I guess I needed to let some time pass because I was expecting instant results.

    (grin)

    For hosts that still were not getting PTR resolution I have adjusted DHCP to try and make sure the server registers all leases:

    Failing that my testing has indicated that static in-addr.arpa entries will work too.

    Thanks for all of the help!

    John