Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 18 replies
  • Subscribers 2 subscribers
  • Views 9386 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

Weird DNS issue

x12Mike
Greetings All,

  I ran into this today, and am kinda stumped.  I use the UTM at home for my house.  It runs DNS for my home network and forwards out to Google's (8.8.8.8 & 8.8.4.4) for non-internal resolution.

  DHCP is done by the UTM, and hands out the UTM IP for DNS to my LAN.

  I came home today and the UTM is not resolving any .tv domains (twit.tv, justin.tv, etc, etc).

  I have restarted it, flushed the resolver cache, yet nothing works.  I even went as far as taking my home domain (my.home) and put it in the DNS Request Routing section, with the IP being the UTM and set DHCP to hand out  Google's...  

  In that last example, I can resolve .tv domains, but my local zone (my.home) doesn't resolve...  (which may be an error in my understanding of how the DNS Request Routes work)

  It has always been working, so I am not sure how it stopped, but I cannot for the life of me resolve it...

  I also cannot seem to get more verbose logging for the bind log to see what is going on in the background...

Any suggestions?


This thread was automatically locked due to age.
  • 0 in reply to BarryG
    Hi,

    What do you have set in the firewall hostname in the Management section?


    utm.my.home


    This tcpdump looks like it's on the internal interface; is eth0 internal or external?
    Can you run it again on external, and add -n to show IPs instead of names?

    Barry


    DOH! You are correct, I ran it through the internal interface.  I reran it on eth1, however, and nothing at all showed up.
  • 0
    I ran this just to be safe:

    tcpdump -vvv -n -i any port 53


    It's all LAN based, nothing goes outside...  


    16:17:48.754916 IP (tos 0x0, ttl 128, id 710, offset 0, flags [none], proto UDP (17), length 70) 192.168.0.140.60220 > 192.168.0.1.53: [udp sum ok] 1+ PTR? 1.0.168.192.in-addr.arpa. (42)
    16:17:48.755418 IP (tos 0x0, ttl 64, id 43389, offset 0, flags [none], proto UDP (17), length 126) 192.168.0.1.53 > 192.168.0.140.60220: 1* q: PTR? 1.0.168.192.in-addr.arpa. 1/1/1 1.0.168.192.in-addr.arpa.[|domain]
    16:17:48.757067 IP (tos 0x0, ttl 128, id 712, offset 0, flags [none], proto UDP (17), length 62) 192.168.0.140.60221 > 192.168.0.1.53: [udp sum ok] 2+ A? twit.tv.my.home. (34)
    16:17:48.757388 IP (tos 0x0, ttl 64, id 43390, offset 0, flags [none], proto UDP (17), length 124) 192.168.0.1.53 > 192.168.0.140.60221: 2 NXDomain* q: A? twit.tv.my.home. 0/1/0 ns: tv.my.home. SOA[|domain]
    16:17:48.758322 IP (tos 0x0, ttl 128, id 714, offset 0, flags [none], proto UDP (17), length 62) 192.168.0.140.60222 > 192.168.0.1.53: [udp sum ok] 3+ AAAA? twit.tv.my.home. (34)
    16:17:48.758656 IP (tos 0x0, ttl 64, id 43391, offset 0, flags [none], proto UDP (17), length 124) 192.168.0.1.53 > 192.168.0.140.60222: 3 NXDomain* q: AAAA? twit.tv.my.home. 0/1/0 ns: tv.my.home. SOA[|domain]
    16:17:48.759526 IP (tos 0x0, ttl 128, id 716, offset 0, flags [none], proto UDP (17), length 53) 192.168.0.140.60223 > 192.168.0.1.53: [udp sum ok] 4+ A? twit.tv. (25)
    16:17:48.759831 IP (tos 0x0, ttl 64, id 43392, offset 0, flags [none], proto UDP (17), length 115) 192.168.0.1.53 > 192.168.0.140.60223: 4 NXDomain* q: A? twit.tv. 0/1/0 ns: tv. SOA[|domain]
    16:17:48.760807 IP (tos 0x0, ttl 128, id 718, offset 0, flags [none], proto UDP (17), length 53) 192.168.0.140.60224 > 192.168.0.1.53: [udp sum ok] 5+ AAAA? twit.tv. (25)
    16:17:48.761151 IP (tos 0x0, ttl 64, id 43393, offset 0, flags [none], proto UDP (17), length 115) 192.168.0.1.53 > 192.168.0.140.60224: 5 NXDomain* q: AAAA? twit.tv. 0/1/0 ns: tv. SOA[|domain]
    16:17:48.786549 IP (tos 0x0, ttl 128, id 720, offset 0, flags [none], proto UDP (17), length 70) 192.168.0.140.60225 > 192.168.0.1.53: [udp sum ok] 1+ PTR? 1.0.168.192.in-addr.arpa. (42)
    16:17:48.786877 IP (tos 0x0, ttl 64, id 43394, offset 0, flags [none], proto UDP (17), length 126) 192.168.0.1.53 > 192.168.0.140.60225: 1* q: PTR? 1.0.168.192.in-addr.arpa. 1/1/1 1.0.168.192.in-addr.arpa.[|domain]
    16:17:48.788557 IP (tos 0x0, ttl 128, id 722, offset 0, flags [none], proto UDP (17), length 66) 192.168.0.140.60226 > 192.168.0.1.53: [udp sum ok] 2+ A? geekbeat.tv.my.home. (38)
    16:17:48.788886 IP (tos 0x0, ttl 64, id 43395, offset 0, flags [none], proto UDP (17), length 128) 192.168.0.1.53 > 192.168.0.140.60226: 2 NXDomain* q: A? geekbeat.tv.my.home. 0/1/0 ns: tv.my.home. (100)
    16:17:48.790465 IP (tos 0x0, ttl 128, id 724, offset 0, flags [none], proto UDP (17), length 66) 192.168.0.140.60227 > 192.168.0.1.53: [udp sum ok] 3+ AAAA? geekbeat.tv.my.home. (38)
    16:17:48.790777 IP (tos 0x0, ttl 64, id 43396, offset 0, flags [none], proto UDP (17), length 128) 192.168.0.1.53 > 192.168.0.140.60227: 3 NXDomain* q: AAAA? geekbeat.tv.my.home. 0/1/0 ns: tv.my.home. (100)
    16:17:48.791574 IP (tos 0x0, ttl 128, id 725, offset 0, flags [none], proto UDP (17), length 57) 192.168.0.140.60228 > 192.168.0.1.53: [udp sum ok] 4+ A? geekbeat.tv. (29)
    16:17:48.791882 IP (tos 0x0, ttl 64, id 43397, offset 0, flags [none], proto UDP (17), length 119) 192.168.0.1.53 > 192.168.0.140.60228: 4 NXDomain* q: A? geekbeat.tv. 0/1/0 ns: tv. SOA[|domain]
    16:17:48.792976 IP (tos 0x0, ttl 128, id 727, offset 0, flags [none], proto UDP (17), length 57) 192.168.0.140.60229 > 192.168.0.1.53: [udp sum ok] 5+ AAAA? geekbeat.tv. (29)
    16:17:48.793280 IP (tos 0x0, ttl 64, id 43398, offset 0, flags [none], proto UDP (17), length 119) 192.168.0.1.53 > 192.168.0.140.60229: 5 NXDomain* q: AAAA? geekbeat.tv. 0/1/0 ns: tv. SOA[|domain]

  • 0
    OK... Presumably if you do a lookup on whitehouse.gov or something like that, you DO see external DNS traffic?

    Another thing to check: ssh in as loginuser, su to root, and look at 
    /var/sec/chroot-bind/etc/named.conf

    and see if anything is weird there. Especially check for any '.tv' entries (there should be none).

    also check 
    /var/sec/chroot-bind/zones
    for any .tv entries (should be none)

    Barry
  • 0
    Barry, you sir deserve a medal! [[:)]]

    So I have a fairly complex home setup, many machines, devices, etc, etc.  One of which is a SiliconDust HD Homerun Prime cable card TV Tuner...  (I can see the smirk on your face beginning, don't get ahead of me here...  )

    I had a static DNS entry for "tv.my.home".  I also had an additional hostname for the device as just "tv" (because I was lazy and wanted to confirm I could resolve devices by just hostname, not internal FQDN)  I never trusted search domains across multiple OS's and systems.

    The way the UTM does DNS, there was a tv.zone file for the tv entry..  Once I renamed the DNS entry to "tv-tuner" all my problems went away.

    What is interesting is that I had made the DNS entry WEEKS ago and never had issues.

    Yesterday I restarted the UTM due to updates, and that is where the problems began.  So the cache was still good until I rebooted, and then all of a sudden, I had a tv zone to break these lookups.

    And that also explains why when I did the tcpdump I never saw external traffic, there was a zone internal so it never forwarded...  

    So I am happy to report that everything is good now, DNS is functioning correct and everything is back to normal.  

    Very good call on checking the zone files, it's something I wouldn't have seen from the GUI, so it made more sense when I grep'd for tv. 

    Thank you VERY much for the help, it was greatly appreciated! [[:)]]
  • 0
    Barry hits another one out of the park!

    Cheers - Bob
  • 0
    Good...

    fwiw, I've never had any luck with static host entries UNLESS entering a full domain... e.g. a defintion as 'pc' doesn't work, but 'pc.mydomain.net' works fine (with a real domain; problems when I was using a bogus one).

    Barry
  • 0
    I'm seeing an inpromptu DNS failure today as well.
    I found the following errors in my logs:
    [FONT=monospace]2013:10:05-00:02:05  wahine named[4579]: error (unexpected RCODE SERVFAIL) resolving  '162.179.17.209.in-addr.arpa/PTR/IN': 209.135.99.3#53 [/FONT]
    [FONT=monospace]2013:10:05-00:02:06  s_local_asl@wahine named: Last message 'error (unexpected RC' repeated 1  times, supressed by syslog-ng on my.domain..com [/FONT]
    [FONT=monospace]2013:10:05-00:02:06  wahine named[4579]: lame server resolving '164.179.17.209.in-addr.arpa'  (in '179.17.209.in-addr.arpa'?): 139.142.2.3#53 [/FONT]
    [FONT=monospace]2013:10:05-00:02:07  wahine named[4579]: error (unexpected RCODE SERVFAIL) resolving  '164.179.17.209.in-addr.arpa/PTR/IN': 209.135.99.3#53 [/FONT]
    [FONT=monospace]2013:10:05-00:02:09  s_local_asl@wahine named: Last message 'error (unexpected RC' repeated 1  times, supressed by syslog-ng on wahine.ravennasprings.com [/FONT]
    [FONT=monospace]2013:10:05-00:20:04  wahine named[4579]: error (unexpected RCODE REFUSED) resolving  '146.115.155.206.in-addr.arpa/PTR/IN': 216.12.0.7#53 [/FONT]
    [FONT=monospace]2013:10:05-00:20:04  wahine named[4579]: lame server resolving  '146.115.155.206.in-addr.arpa' (in '115.155.206.in-addr.arpa'?):  204.70.57.242#53 [/FONT]
    [FONT=monospace]2013:10:05-00:20:05  wahine named[4579]: error (unexpected RCODE REFUSED) resolving  '146.115.155.206.in-addr.arpa/PTR/IN': 216.12.0.7#53 [/FONT]


    The one thing my config shares with yours is I believe we are both using Google as DNS forwarders (8.8.8.8, 8.8.4.4).   It's possible the problem is caused by something changing with this traffic or their servers.
  • 0
    Hi, these look like failed reverse lookups, probably from anti-spam checks. Nothing to worry about unless something else is wrong.

    Barry