Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 2966 views
  • Users 0 members are here
Options
Suggested
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 Request Route Issue

Raharwa
I recently noticed that my virtual UTM (running 9.201-23) is having issues with DNS lookups.

There is an entry saying it should go look up ad.domain.com at 192.168.1.1. However if you run a query with nslookup on either the console or a remote client it comes back with no results.

I Googled and looked at the forum for known issues regarding this but nothing came up. I've seen the DNS guide on this forum however that doesnt seem help me at all.

In the end I ended up making a second virtual UTM running the same version. What I did first was enable IPv6 and setup the interfaces just like my current UTM has. Then I made the exact same DNS Request Route entry and I ran the DNS query. It works! Great!

After that I shut the virtual UTM down, took a snapshot and rebooted it. From there on I started rebuilding my current UTM on the newly created one and after I while I decided to run the DNS query again. However this time it failed.

I logged into the console checked the named.conf file to make sure the configuration in BIND is correct and it is.

My question are; has anyone ran into this issue too / am I doing something wrong / is this a bug?

If you need me to supply more information please ask!

René


This thread was automatically locked due to age.
  • 0
    For those interested I also have 2 config backup files one of them where it works and another where it doesnt work.
  • 0
    Same issues here with ASG525 running 9.201-23.

    Request routing to our internal AD DNS-Server didn't always work.

    Flushing the DNS cache on the UTM (one or two times) solves it for some time, but we have to flush it more often a day.

    Even disabling request routing and changing the forwarders to our 
    internal DNS-servers didn't solve the problem.

    - "dig servername.domain.tld" shows NXDOMAIN
    - "dig servername.domain.tld @internal-dns-server" works fine

    Tobias
  • 0 in reply to EIFOK
    In our case, it seems the UTM isn't the Problem.

    A tcpdump on the console shows that our DNS-Servers answers with an "NXDOMAIN" to some requests from the UTM.

    Tobias
  • 0
    Very interesting find there Tobias.

    What windows OS are you running and have you found a solution for this issue?

    René
  • 0
    We started to migrate our ADS/DNS from w2k3 to w2k8r2, few weeks ago.
    So the DNS-Servers running w2k8r2.
    Our DHCP-Server, in this case, is an ISC running on Linux.

    I recognized, that a firewall rules on the UTM wasn't running, where we are using a "dns host" definition. The definition of the host showed "unresolved". The host is a w2k8r2 with dynamic IP and a nslookup on my Client (Win7) resolved the host correctly against the same DNS servers.

    After the tcpdump, i looked in the DNS-MMC on our DCs and an entry for the host was missing. (Since we are using secure dynamic updates, i was a little bit confused...)

    So, in short, we are using WINS forward-lookup to resolve some lagacy clients/printers.
    The WINS registration for the host worked, what explained, why it could be resolved from my client (and sometimes from the UTM). 
    The "Register this connection's addresses in DNS" in the TCP/IP settings on the host wasn't checked (why ever). After checking it, the DNS entry was there again and the UTM resolved it correctly.
    After that I looked at the WINS forwardins setting and increased the cache timeout from 5 to 15 minutes. (I think WINS-forwarings should have worked for my w2k8r2 host previously)

    At the moment, it seems that even WINS-only clients can be resolved correctly by the UTM.

    By the way: the same settings worked well on w2k3.

    Tobias
  • 0
    Glad to hear this resolved your problem. I checked in my environment and sadly it does not apply.

    Still hoping Sophos will respond to this issue.
  • 0
    I found a solution to this issue. It seems that the object it was refering too somehow got a corrupted interface setting.

    Changing the interface to a different one and then changing it to the correct one fixed the issue.
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?