AW: Too many connections on the same IP
Are you using iptables Firewall? Does the problem only occur on UDP connections to the problematic IP? Or also on TCP connections to the same IP? I had similar problems (not with bind) when the connection table of iptables "state" module were too small. Iptables started dropping packets, because it couldn't keep track of new connections. Since UDP is by definition stateless, the "state" module tries to invent some sort of connection status, based on source- and destination ports. This sometimes makes trouble. Especially when there are lots of concurrent connections and the same UDP-ports show up over and over again (e.g. when DNS-Clients do not use Source Port Randomization). You could try to remove the state module (-m state --state NEW) from your UDP firewall rule for BIND and see if that helps. I believe there are separate state tables for each network interface. This could explain, why your second IP is still responding. Regards, Stefan -Ursprüngliche Nachricht- Von: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] Im Auftrag von Job Gesendet: Mittwoch, 4. März 2015 00:41 An: Job; bind-users@lists.isc.org Betreff: R: Too many connections on the same IP I tried to tune kernel, with SOMAXCONN but with no solutions! When DNS queries raise up over 300 queries per second, bind has huge timeouts and often does not respond. If i work on an ip alias, everything is right! it seems bind has some limit based on local ip address. is there any solutions? Thank you again! Francesco Da: bind-users-boun...@lists.isc.org [bind-users-boun...@lists.isc.org] per conto di Job [j...@colliniconsulting.it] Inviato: martedì 3 marzo 2015 11.43 A: bind-users@lists.isc.org Oggetto: Too many connections on the same IP Hello, during a massive DNS utilization our Bind 9.10.1-P1 seems not to resolve anymore, neither local zone. We shutdown one of the two nodes and all queries arrived only on one node. CPU and memory load were not too overloaded, machine was quite fine. After some fast tests, i noticed that if from clients i used an ip alias of Bind server, it worked perfectly! Only on main ip there were congestion problems, but resolving on ip aliases worked fastly! Where was i wrong? Thank you! Francesco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
R: Too many connections on the same IP
Hello Stefan, and thank you for the reply. >>Are you using iptables Firewall? >>Does the problem only occur on UDP connections to the problematic IP? Or also >>on TCP >>connections to the same IP? At the beginning, i thought was an iptables-behind-firewall problem and i made massive dns resolutions locally, from the same lan where the dns server is located. Same results: after 300/400 query per second bind make difficult to respond on the first IP. But resolving on the secondary, alias ip, works perfectly! What a matter!! Thank you Francesco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Better debug of too many queries
Hello! I installed a 64bit Centos 6 operating system, with Postgresql 8.4.20 x64 and Bind, latest 9.10 version. I use Bind-DLZ in lots of view. In our lab we are simulating what happens with some hundred of queries per second. I notice that, when using BIND-DLZ, some queries does not resolve for timeout problems; but the DB is absolutely not overload! It works perfectly. If i try to resolve to another ip of the BIND machine (an alias ip), when the first returns bind resolution timeout, the other resolve perfectly without any delay! If so, the DB correctly respond, but it seems to be a limit on BIND with DLZ(Postgres) when lots of request arrive on the same machine ip. Anyone has met this problems? Thank you! Francesco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Too many connections on the same IP
On Wed, Mar 04, 2015 at 09:47:59AM +0100, stefan.las...@t-systems.com wrote: > Are you using iptables Firewall? > Does the problem only occur on UDP connections to the problematic > IP? Or also on TCP connections to the same IP? > > I had similar problems (not with bind) when the connection table of > iptables "state" module were too small. Iptables started dropping > packets, because it couldn't keep track of new connections. The ISC Knowledge Base has an article about this: https://kb.isc.org/article/AA-01183 > Since UDP is by definition stateless, the "state" module tries > to invent some sort of connection status, based on source- and > destination ports. Linux connection tracking is protocol-agnostic, but yes, aspects of the protocol (such as source and destination ports if applicable) are considered in defining a what is considered a "connection". > This sometimes makes trouble. Especially when there are lots of > concurrent connections and the same UDP-ports show up over and over > again (e.g. when DNS-Clients do not use Source Port Randomization). The trouble comes if/when the table is too small to account for many random ports. Each "connection" is only two packets: a query coming in, and a reply going out. > You could try to remove the state module (-m state --state NEW) > from your UDP firewall rule for BIND and see if that helps. It probably would not, because each query/reply is still seen as a "connection" to the kernel. A more sophisticated and effective approach is as described in the article above, using the "raw" table and "-j CT --notrack". > I believe there are separate state tables for each network > interface. This could explain, why your second IP is still > responding. There is a single conntrack table for the system, and all entries therein are based on packet header information: source and destination IP address (and ports if applicable.) We really don't have enough information in this thread to be able to answer the OP's questions. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
issue with dnssec, UDP using master/slave config
I am trying to configure DNSSEC as a master/slave. Following signing the zone and uploading the DS record to my provider, I am able to see what appears to be the proper output from dnssec-verify dnssec-verify -o ex-mailer.com ex-mailer.com.external.signed Loading zone 'ex-mailer.com' from file 'ex-mailer.com.external.signed' Verifying the zone using the following algorithms: RSASHA256. Zone fully signed: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked but 3rd party tools such as http://dnsviz.net/d/ex-mailer.com/dnssec/ and/or http://dnssec-debugger.verisignlabs.com/ex-mailer.com say that my configuration is very incorrect and that UDP is not responding netstat -an|grep 53 tcp4 0 0 127.0.0.1.953 *.*LISTEN tcp4 0 0 127.0.0.1.53 *.*LISTEN tcp6 0 0 ::1.53 *.*LISTEN tcp4 0 0 107.191.60.48.53 *.*LISTEN tcp6 0 0 2001:19f0:7000:8.53*.*LISTEN udp4 0 0 127.0.0.1.53 *.* udp6 0 0 ::1.53 *.* udp4 0 0 107.191.60.48.53 *.* udp6 0 0 2001:19f0:7000:8.53*.* But, after 10 min or so, UDP on my IPv4 address begins to fail and the port will close. I get these errors following # tail -f /var/log/named/named.log 04-Mar-2015 18:39:58.288 network: error: creating IPv4 interface vtnet0 failed; interface ignored 04-Mar-2015 18:39:58.288 network: error: creating IPv4 interface vtnet0 failed; interface ignored 04-Mar-2015 18:39:58.288 network: error: could not listen on UDP socket: permission denied 04-Mar-2015 18:39:58.288 network: error: could not listen on UDP socket: permission denied 04-Mar-2015 18:39:58.288 network: error: creating IPv4 interface vtnet0 failed; interface ignored 04-Mar-2015 18:39:58.288 network: error: creating IPv4 interface vtnet0 failed; interface ignored 04-Mar-2015 18:39:58.288 network: error: could not listen on UDP socket: permission denied 04-Mar-2015 18:39:58.288 network: error: could not listen on UDP socket: permission denied 04-Mar-2015 18:39:58.288 network: error: creating IPv4 interface vtnet0 failed; interface ignored 04-Mar-2015 18:39:58.288 network: error: creating IPv4 interface vtnet0 failed; interface ignored ^C # updatedb >>> WARNING >>> Executing updatedb as root. This WILL reveal all filenames >>> on your machine to all login users, which is a security risk. # locate named.pid /var/run/named/named.pid Yet dig appears to query just fine: dig ex-mailer.com ANY @108.61.190.64 ; <<>> DiG 9.9.5 <<>> ex-mailer.com ANY @108.61.190.64 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23061 ;; flags: qr aa rd; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ex-mailer.com. IN ANY ;; ANSWER SECTION: ex-mailer.com. 86400 IN SOA yoda.ex-mailer.com. admin\@ex-mailer.com. 2015030403 10800 3600 604800 3600 ex-mailer.com. 86400 IN RRSIG SOA 8 2 86400 2017030303 20150304023700 19359 ex-mailer.com. ov7ZA0ny6tYRsYIzupUsT6J8ncZRVqvZxwwxl2qonQ3Ou8hsblsZyDh7 sGehaI7To4w3dKWRlCoQoKCTE7McFHEv54ch4fOZv4dbZ2xgtXGdRHxp YoH4pNFQLnCMrU3hJSwcihYZb2P2q2Pf4qJu1qS/zxum3XyUO20xMu91 1hFyNsmBA2n4cNYfnMfZ6orQzhMzw72wzM+rMMkZhhQKtdWC5KO5Lzkx nRHpkGo4poMjuDoUidNwusANrkIlYVM1+NGLohaO5iQjJE7H5/m+I41v RoEdVycc5ujy9KANbmeLSXFYxH34s7H2N15d7Y2EfP/QMzSt9U/m+sbO wH5PBg== ex-mailer.com. 86400 IN NS r2d2.ex-mailer.com. ex-mailer.com. 86400 IN NS yoda.ex-mailer.com. ex-mailer.com. 86400 IN RRSIG NS 8 2 86400 2017030303 20150304023700 19359 ex-mailer.com. TG+HCKFevosp6b3dncH3wCrRh0iWr7Ud7nujCZpBZR8k/AET926adfY0 4YGdM8ZElAzLhPrjxE2DSLvueOFZAAnQZvNHyF7aAdz9qD73wK4iuK/d d4ZrUW8XrUWLUUNnJIIwofbUteX71zHcK44tsoqjBEXphS7YKCao/pAx QzyzzvRzbs0F18wviXvg1j+IDVdXV4spH6KiMluZuk/YHSm8FzbHbKps LYjxd40F0WLqSqdFavFklRzbudZLgsCYt6YaI8ZI/HXxFbJL6SoQs631 9M4ZfJWxv7S56lAZzShwxUR0zIaMhqVW2jBCyTiI5VgP23yZciQxzuSJ dCywCw== ex-mailer.com. 86400 IN A 108.61.175.20 ex-mailer.com. 86400 IN RRSIG A 8 2 86400 2017030303 20150304023700 19359 ex-mailer.com. ItLLkwdtNC0edk7v+7YYrhRmUwAy8LARmKfWMz/RWp4C3Jksv9m6Y78r QEJv0ydRxlQInd/CJjjHdDKxIyjXABqcSadJMMiEAz9Kj74oR5mPS+Aq LxZ6Lnua3KR5Soo9u9c5yvoQWzUrT+4pGGwiPofSf0A9QGJrGcN3a6kJ 96X/gmLkkYz6URO6gUR6c2eUb1fw7NcAEcDKsmMtSx9K/lYCy2fqX/su cqaUnEFUw9Qtzfw7stp2cJiNRomH3mpLGO+pbZteUFy6fUocVNbI7cF7 XahL8ObLK/HUkT/KgqJ01qzOD8Qgb2Auh6ofLLQ3+ZazhPAqqUhKpsOH gmFB3Q== ex-mailer.com. 86400 IN MX 0 r2d2.ex-mailer.com. ex-mailer.com. 864
