We had a similar issue here (although the cause was CheckPoint's
SmartDefence being turned on for a business partner, which prevented
EDNS0 packets). The behaviour is that BIND 9 will attempt EDNS0 3 times,
then fail back to EDNS disabled. It will clear any backlog of queries
FOR THAT SAME NAME,
can control on a per-message basis either.
If I could get to my webmail account (also blocked) I'd send from there.
Welcome to corporate environments...
-Original Message-
From: Evan Hunt [mailto:e...@isc.org]
Sent: 2010, September, 29 7:25 PM
To: Taylor, Gord
Cc: bind-us...@isc.org
We recently ran into an intermittent problem sending queries to a
business partner. Turns out they had CheckPoint firewalls with
SmartDefense turned of for DNS traffic. This was blocking traffic going
to them with DO flag enabled. I could duplicate the problem from a
command line by issuing dig
My suggestion is to create a backup copy of the (current) zone files in
another directory. Only allow the users to edit those files, then
execute a shell script that checks them, and only moves them to the
production directory once the named-checkzone (and named-checkconf)
works correctly.
Cricket Liu documents some stuff around this in section 8.2 of O'Reilly
DNS and BIND - 5th edition. The info does not exist in 3rd edition. (I
happen to have access to both)
Not enough info to justify buying the book, but might help you if you're
not a UNIX guru, so visit the library or make
I've noticed that if I have default forwarders setup in the options
section of my named.conf, then BIND (9.4.1-P1) will forward to these
servers rather than following the delegations for zones where it's
authoritative (verified via sniffer trace). Is this true of all BIND
versions?
In my case,
Also need to ensure the allow-query-cache ACL on the recursive server allows
the client. Otherwise, name resolution may work the first time
(allow-recursion), but not the 2nd time (allow-query-cache) since the result is
cached.
Sent from my BlackBerry
- Original Message -
From:
I'm trying to put together a list of best practices for use in my org
around the use of split-dns (implementation, operational, technical,
etc.) . Obviously, I'd rather not start from scratch, and since I'd only
be basing the doc on my experience, there may be things I miss as well.
Does anyone
, CISSP, GEEK)
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Taylor, Gord
Sent: 2009, December, 11 10:56 AM
To: bind-users@lists.isc.org
Subject: Best practices or known issues with split-dns
I'm trying to put together a list
The company I work for uses a vendor solution which implements BIND
under the hood, though it's abstracted with a GUI interface. Knowing
which bugs may exist in the current release of BIND would be nice to
know; for example, if it's a feature of BIND we use, we may want to know
about bugs before
Try:
update add posse.okstate.edu. 10 IN TXT v=spf1 ip4:209.235.101.208/29
-all
Gord Taylor (CISSP, GCIH, GEEK)
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Martin McCormick
Sent: 2009, July, 17 3:04 PM
To:
I've frequently run into a problem that the stub resolver just isn't
very dynamic in its selection of name servers - especially when dealing
with time-sensitive apps. If the first DNS server in the list is down,
the applications may slow down due to the constant retransmits. Given a
resolv.conf
, GEEK)
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Taylor, Gord
Sent: 2009, July, 15 10:05 AM
To: bind-users@lists.isc.org
Subject: A smarter stub resolver??
I've frequently run into a problem that the stub resolver
13 matches
Mail list logo
