canonical name d.root-servers.net. aliases addresses 2001:500:2d:[:D] 128.8.10.90It looks like this the device blocking access to DNS root servers. Is that a good thing? I don't have DNS specific rules in my firewall (save one machine which is off). In Network Services \ DNS I list Google's DNS servers. [feel free to comment]
I don't think the DNS requests by the firewall itself are logged in packet filter log and any other request will need a packet filter rule. Which interface does the 174.x.x.x IP belong to?
That is strange, isn't it, Bill. It looks like it's a DNS request by the Astaro as the packet is dropped out of the OUTPUT chain (rule="60003"). I think I'll learn something in this thread!
Cheers - Bob
Sophos UTM Community Moderator Sophos Certified Architect - UTM Sophos Certified Engineer - XG Gold Solution Partner since 2005
The packet in question is indeed coming from the Astaro device itself, not from an internal DNS server. I use Astaro as the internal DNS server. Therefore, in order to eliminate this sort of blockage, I would have to create a rule allowing DNS traffic from the ASG device which seems a bit curious.
That was why I suggested the Best Practices link - that block shouldn't occur, and the only thing I can imagine is that there's a configuration error. You also might look in the DNS log.
Cheers - Bob
Sophos UTM Community Moderator Sophos Certified Architect - UTM Sophos Certified Engineer - XG Gold Solution Partner since 2005
It's not clear to me what configuration I could do that would trigger [FONT=monospace]fwrule="60003".
As for best practices, I use the 2nd option, using Astaro as the official internal DNS source. Occassionally I fire up a Win Server box for testing which has it's own DNS server but that's not relevant here.
I may setup the request routing if I elect to use an internal DNS server. At present I define internally routed information as static entries in the DNS settings on the ASG which then routes internal queries just fine. This is a home config so the number of machines is limited so this is manageable. [/FONT]
If Astaro is functioning as the source of DNS information, it has a DNS server turned on. DNS servers query root servers as a standard function. At least that was my assumption if it doesn't get an acceptable response from the assigned forwarders.
I guess I don't understand why the Astaro would ask a root server for name resolution if DNS is configured correctly.
The way they have bind configured, it has a switch to query forwarders first which makes astaro query root servers if the forwarders fail for any reason including connectivity.
What is fascinating is the log entry for the interface.
@Dougga which interface is that exactly? Not an additional IP or anything of that sort is it?
Regards
Bill
Edit:
Why am I telling you about your systems. This is very strange.
Bob doesn't work for astaro and is a free helper so don't flame the messenger please.
See, Doug, I didn't even realize that you were frustrated - I'm a rose-colored-glasses kind of guy! [;)]
I normally use OpenDNS, and don't think I've gotten a root name server anywhere since I started using 208.67.222.222 and 208.67.220.220. You might see if that works better. I also usually uncheck the box for the ISP's name servers.
It is a bit of a mystery why the standard "invisible" Firewall rule for DNS seems to have been disabled. It would be interesting if you could find when the default drops started, and then restore a backup from before that to see if the problem persists.
Cheers - Bob
Sophos UTM Community Moderator Sophos Certified Architect - UTM Sophos Certified Engineer - XG Gold Solution Partner since 2005
I'll take a look. I've recently reset the configuration and restored from backup. This was due to the issues with the syslog routing being left on. That's on another thread. Interesting thread. Foreign governments have taken up the research on what's behind that.
Nuts. Because log management was taken off line and the need to reset, I no longer have my logs. I have a VM image with the old logs and the code that was sending them oubound to Symantec and others, but it's too much hassle for me to deal with given my other responsibilities.
Quote