In article ,
Jason Brandt wrote:
> For now, I've disabled DNS inspection on our firewall, as it is an ancient
> Cisco firewall services module, and that seems to have stabilized things,
> but it's only been 30 minutes or so. Until I get a few days in, I'll keep
> researching.
We used to run DN
Dear All,
Someone has resources, links or tutorial to understand and implement the
dynamic update zone files with BIND
Thank you!
Ramanou
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mai
Hi,
Look at the
Bind 9 ARM:
https://kb.isc.org/article/AA-00845/0/BIND-9.9-Administrator-Reference-Manual-ARM.html
and
O’Reilly book DNS and BIND: http://shop.oreilly.com/product/9780596100575.do
Best regards
Banana
On 26 Mar 2014, at 12:18, Ramanou Biaou wrote:
> Dear All,
> Someone has
Ramanou Biaou wrote:
> Someone has resources, links or tutorial to understand and implement the
> dynamic update zone files with BIND
If you search the web for [nsupdate howto] or [nsupdate tutorial] you
should find some useful resources.
If you are running BIND 9.7 or newer then it has a built
The code on our FWSMs isn't the latest release, so that could be part of
the issue, but it's been about 16 hours now since I shut it off, and so far
so good. I would say though with the other load on our firewalls, it's
highly possible that they were being overloaded. Unfortunately our MRTG
isn't
DNS inspection doesn't do anything useful; bind does enough validity
checking. UDP inspection suffices to let return packets thru.
Another thing to beware of is NAT - if you do static NAT translation for
your nameservers, be sure to specify no-payload (e.g.
ip nat inside source static tcp/ud
I had it set as:
policy-map global_policy
class inspection_default
inspect dns maximum-length 4096
Which is what Cisco recommends. EDNS tests worked fine, but the BIND
servers would still get backed up.
On Wed, Mar 26, 2014 at 7:35 AM, Thom, Paul E wrote:
> Do you have the FWSM DNS inspe
We don't do any NAT at the firewall level, they're all public IPs.
Thanks,
Jason
On Wed, Mar 26, 2014 at 7:51 AM, Timothe Litt wrote:
> DNS inspection doesn't do anything useful; bind does enough validity
> checking. UDP inspection suffices to let return packets thru.
>
> Another thing to bew
In article ,
Jason Brandt wrote:
> The code on our FWSMs isn't the latest release, so that could be part of
> the issue, but it's been about 16 hours now since I shut it off, and so far
> so good. I would say though with the other load on our firewalls, it's
> highly possible that they were bei
Here is a script I wrote to log and sent traps. I'm sure you'll have to make a
lot of changes but hopefully it can help you get started monitoring the FWSM.
You can use this as a template to expand upon.
#!/usr/bin/perl
use strict;
use Expect;
use Net::Telnet;
use Data::Dumper;
use POSIX qw(t
Thanks guys. I appreciate the input. I don't want to derail the list much
though, as this is supposed to be more BIND than Cisco :)
At this point my BIND installation seems to be stable, so we'll call it
case closed. We do plan on replacing our firewalls in the near future, so
hopefully we won'
This got me to take a look at "rndc recursing" on one of our servers.
It is disappointing that queries for the same FQDN/type/class from the same
client (different source port and query ID though) are handled individually
rather than being merged somehow. Is this because of the ID or the source
p
In message
, Scott
Bertilson writes:
>
> This got me to take a look at "rndc recursing" on one of our servers.
>
> It is disappointing that queries for the same FQDN/type/class from the same
> client (different source port and query ID though) are handled individually
> rather than being merge
Hi list,
Just wanted to check my understanding of BIND9's implementation of DNS64
against RFC 6147.
Currently BIND9's "break-dnssec" defaults to "no" - in this configuration, a
security-aware & validating recursive resolver with will never synthesise a
record via DNS64 when queried with D
In message , Tom Lanyon wri
tes:
> Hi list,
>
> Just wanted to check my understanding of BIND9's implementation of DNS64 agai
> nst RFC 6147.
>
> Currently BIND9's "break-dnssec" defaults to "no" - in this configuration, a
> security-aware & validating recursive resolver with will never synthes
On 27 Mar 2014, at 14:48, Mark Andrews wrote:
> No. If the answer is secure and DO=1 then it won't synthesis.
>
> RFC 6147 just gets DO and CD semantics completely wrong. The WG
> wanted there to be signaling that the client was going to validate
> and DNSSEC does not have such signaling. The
In message , Tom Lanyon wri
tes:
> On 27 Mar 2014, at 14:48, Mark Andrews wrote:
> > No. If the answer is secure and DO=1 then it won't synthesis.
> >
> > RFC 6147 just gets DO and CD semantics completely wrong. The WG
> > wanted there to be signaling that the client was going to validate
> > a
17 matches
Mail list logo
