Hi, I do have a shorewall perimeter firewall connected with a 1GBit Internet connection. In my local lan I do have two bind redhat DNS servers. Today I got a problem which I''d like to share - maybe you have any cloue what''s going on? If I restart shorewall e.g. because I do have a new zone added or an IP blocken or added a rule for some services, sometimes(!) the dns resolving of clients on the same subnet as the dns servers is poor or fails completly. e.g. a dig www.google.con can take from 1 to 1000s of ms. Sometimes restarting the bind deamon solves the problem, sometimes I do have to restart the whole server. But sometimes after a shorewall restart there is no problem resolving names. Any idea?? I''m some sort of frustrated ... :-) Maybe I can tweak shorewall in some kind or pull some traffic information from the firewall as the bind logs aren''t very helpfull to me at the moment. So thanks for any tip or hint! Best regards Götz Reinicke -- Götz Reinicke IT Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke@filmakademie.de Filmakademie Baden-Württemberg GmbH Mathildenstr. 20 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzender des Aufsichtsrats: Dr. Christoph Palmer, MdL, Minister a.D. Geschäftsführer: Prof. Thomas Schadt ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Götz Reinicke wrote:> Hi, > > I do have a shorewall perimeter firewall connected with a 1GBit Internet > connection. In my local lan I do have two bind redhat DNS servers. > > Today I got a problem which I''d like to share - maybe you have any cloue > what''s going on? > > If I restart shorewall e.g. because I do have a new zone added or an IP > blocken or added a rule for some services, sometimes(!) the dns > resolving of clients on the same subnet as the dns servers is poor or > fails completly. e.g. a dig www.google.con can take from 1 to 1000s of ms. > > Sometimes restarting the bind deamon solves the problem, sometimes I do > have to restart the whole server.I can think of nothing that would require a reboot of the server.> > But sometimes after a shorewall restart there is no problem resolving names. > > Any idea?? I''m some sort of frustrated ... :-) Maybe I can tweak > shorewall in some kind or pull some traffic information from the > firewall as the bind logs aren''t very helpfull to me at the moment.Some of this is explainable if you are using Shoreall 3.x or Shorewall-shell and have a large and complex Shorewall configuration that takes a long time to restart. The DNS servers may time out trying to resolve names; when they do that, they add negative entries to their caches which take time to expire. Until they expire, requests for those host names will fail. Restarting the bind daemons will correct that condition. In the case where restarting the bind daemon doesn''t correct the problem, the only thing I can suggest is to use a packet sniffer to try to understand what is happening.> > So thanks for any tip or hint!I suspect that the best solution is to upgrade to Shorewall 4.0.6 and switch to using Shorewall-perl. That will avoid dropping any DNS request packets during ''shorewall restart''. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
On Thu, Nov 29, 2007 at 09:13:43AM -0800, Tom Eastep wrote:> > If I restart shorewall e.g. because I do have a new zone added or an IP > > blocken or added a rule for some services, sometimes(!) the dns > > resolving of clients on the same subnet as the dns servers is poor or > > fails completly. e.g. a dig www.google.con can take from 1 to 1000s of ms. > > > > Sometimes restarting the bind deamon solves the problem, sometimes I do > > have to restart the whole server. > > I can think of nothing that would require a reboot of the server.Buggy or defective network card would do it. Burn all realteks. ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Andrew Suffield wrote:> Burn all realteks.Except those that are on your Mother Board. Just don''t use those :-) -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
Hallo Tom, Tom Eastep schrieb:> Götz Reinicke wrote: >> Hi, >> >> I do have a shorewall perimeter firewall connected with a 1GBit Internet >> connection. In my local lan I do have two bind redhat DNS servers. >> >> Today I got a problem which I''d like to share - maybe you have any cloue >> what''s going on? >> >> If I restart shorewall e.g. because I do have a new zone added or an IP >> blocken or added a rule for some services, sometimes(!) the dns >> resolving of clients on the same subnet as the dns servers is poor or >> fails completly. e.g. a dig www.google.con can take from 1 to 1000s of ms. >> >> Sometimes restarting the bind deamon solves the problem, sometimes I do >> have to restart the whole server. > > I can think of nothing that would require a reboot of the server. > >> But sometimes after a shorewall restart there is no problem resolving names. >> >> Any idea?? I''m some sort of frustrated ... :-) Maybe I can tweak >> shorewall in some kind or pull some traffic information from the >> firewall as the bind logs aren''t very helpfull to me at the moment. > > Some of this is explainable if you are using Shoreall 3.x or Shorewall-shell > and have a large and complex Shorewall configuration that takes a long time > to restart. The DNS servers may time out trying to resolve names; when they > do that, they add negative entries to their caches which take time to > expire. Until they expire, requests for those host names will fail. > Restarting the bind daemons will correct that condition.I don''t think, that our configuration is that larg or complex yet, but as it will grow... So having a fast setup will always be good. Restarting takes about 10 to 20 seconds at the moment. The most confusing point to me ist the fact, that resolving may work after the shorewall restart or fails so I have to restart the bind servis or eaven the whole server ... The last option worked in any case.> In the case where restarting the bind daemon doesn''t correct the problem, > the only thing I can suggest is to use a packet sniffer to try to understand > what is happening. > >> So thanks for any tip or hint! > > I suspect that the best solution is to upgrade to Shorewall 4.0.6 and switch > to using Shorewall-perl. That will avoid dropping any DNS request packets > during ''shorewall restart''.I''ll do an upgrade soon an we will see. Thanks and best regards Götz -- Götz Reinicke IT Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke@filmakademie.de Filmakademie Baden-Württemberg GmbH Mathildenstr. 20 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzender des Aufsichtsrats: Dr. Christoph Palmer, MdL, Minister a.D. Geschäftsführer: Prof. Thomas Schadt ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4