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

Huge UDP/53 (DNS) traffic

Lately I run in to a very strange behavior between Astaro and my DNS server.
My DNS server sits in a DMZ.
Quit often, when I look at the "Network Usage" log, I can see there was a huge amount of traffic between the DNS Server IP (show as Client) and the DMZ IP address  (show as Server).
I'm talking about 20-40 GB, while in a normal situation it's up to 400 MB.
At first I suspect that the reason is one of my clients, but after looking into the logs, it seems that all this transportation is only between Astaro and my DNS server.
ALL other DNS transportation (UDP/53) – from the internet and from my local net, seems normal.
I have checked and double checked my DNS server configuration, and it seems OK.
Mind you, this server (DNS) is running like this for about 2 years, without any problems.
It's look to me like kind of loop back.
Any  Idea?
[:$]


This thread was automatically locked due to age.
  • Lately I run in to a very strange behavior between Astaro and my DNS server.
    My DNS server sits in a DMZ.
    Quit often, when I look at the "Network Usage" log, I can see there was a huge amount of traffic between the DNS Server IP (show as Client) and the DMZ IP address  (show as Server).
    I'm talking about 20-40 GB, while in a normal situation it's up to 400 MB.
    At first I suspect that the reason is one of my clients, but after looking into the logs, it seems that all this transportation is only between Astaro and my DNS server.
    ALL other DNS transportation (UDP/53) – from the internet and from my local net, seems normal.
    I have checked and double checked my DNS server configuration, and it seems OK.
    Mind you, this server (DNS) is running like this for about 2 years, without any problems.
    It's look to me like kind of loop back.
    Any  Idea?
    [:$]


    There's probably a DNS tunnel active. Activate IPS and it's DNS rules to verify.

    there are different reasons for this. Probably some active malware, or are you using the UTM9 endpoint? The EP also can do as fallback it's live lookups via DNS if http fails.

    Wer Schreibfehler findet, darf sie behalten. Wenn ich via IPad poste, sind Verschreiber und grammatikalische Aussetzer irgendwie an der Tagesordnung.
  • Hi Sacha

    "There's probably a DNS tunnel active. Activate IPS and its DNS rules to verify"
    Do you mean Astaro tunneling?  If you do, then i hardly use it, and my client doesn't use it at all.

     " Probably some active malware" - unless it sits on my DNS server (which is hard to believe but I checked any way), if there were any abnormal activity from any of my clients, I think I would have seen it.

    "are you using the UTM9 endpoint?" - ASG 9x Dell PowerEdge 1900
  • Goldy, do you have DNS/DHCP set up like in DNS Best Practice?  If not, how is your setup different?

    Is there anything strange in the Intrusion Prevention log?

    Cheers - Bob
  • Hi Balfson.

    1. My DNS Setup:
    •All clients querying my internal DNS Server as primary and Astaro as secondary.
    •Internal DNS server Forwarder - AStaro.
    •AStaro Forwarders – List of external DNS server.
    •Request Routing in Astaro – my internal DNS server and "***.in-addr.arpa".
    •Astaro Static Entries – some Servers and some internal addresses.

    2. "Is there anything strange in the Intrusion Prevention log?" – Nothing as far as I could see.
  • On the days that the DNS traffic was heavy, are the DNS logfiles any different from the "normal" days?  If so, then I think you have to dig through one of them to see why.

    If not, then maybe you have a hardware problem - NIC, switch or cable???

    Cheers - Bob
  • I can see quit a lot of this:

    2012:10:08-00:14:29 nhgate named[4578]: unexpected RCODE (SERVFAIL) resolving '84.40.0.142.in-addr.arpa/PTR/IN': 204.124.182.253#53
    2012:10:08-00:14:30 nhgate named[4578]: unexpected RCODE (SERVFAIL) resolving '84.40.0.142.in-addr.arpa/PTR/IN': 199.19.111.7#53
  • Those are DNS4. and DNS3.volumedrive.com.  There was an attempt to do rDNS, and neither had a PTR.  Or, maybe their name servers are misconfigured.

    The only possible problem you might have would be your ISP might have changed something, and now you need a lower MTU.  If you aren't seeing slowness in surfing, then that's not it.

    In your SMTP log, do you show a reject for RDNS/HELO from 142.0.40.84 at 2012:10:08-00:14:30?

    Cheers - Bob
  • Hi Bob
    You are right.
    [:)]

    SMTP log:
    2012:10:08-00:24:08 nhgate exim-in[5587]: 2012-10-08 00:24:08 SMTP connection from [142.0.40.84]:36568 (TCP/IP connection count = 1) 
    2012:10:08-00:24:23 nhgate exim-in[30778]: 2012-10-08 00:24:23 H=(smtp.kshcd.net) [142.0.40.84]:36568 F=yora@***.xx @kshcd.net> temporarily rejected RCPT : failed to expand ACL string "${lookup dnsdb{ptr=$sender_host_address}{0}{1}}": lookup of "ptr=142.0.40.84" gave DEFER: 
    2012:10:08-00:24:24 nhgate exim-in[30778]: 2012-10-08 00:24:24 SMTP connection from (smtp.kshcd.net) [142.0.40.84]:36568 closed by QUIT
  • On the bottom of the 'Antispam' tab in Mail, what happens if you uncheck the 'Do strict RDNS checks' box?  If you haven't Up2Dated far enough to have that selection, try Reverting to pre 8.202 RDNS behavior.

    Did that make any difference?

    Cheers - Bob
  • "On the bottom of the 'Antispam' tab in Mail, what happens if you uncheck the 'Do strict RDNS checks' box?"
    - It was unchecked.

    "If you haven't Up2Dated far enough to have that selection, try Reverting to pre 8.202 RDNS behavior." -
    I'm having Astaro Ver 9.003.
    I think it's a bit too far.

    BTW never had this issues on Ver 8.***