detect if zone/s is frozen
Is there a nice way to tell if any zone is frozen (or a specific zone)? I'm hoping to implement a nagios check, since I have several times gotten distracted while making an update, and forgot to thawed the zone until something odd happens later on. Thanks, Justin ___ 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: Classless PTR query issue
I recommend dig +trace -x on one of your assigned IPs. Compare with
the result from a known-good sub-24 rev dns delegation. The ISP
should be returning something like:
162.48.168.205.in-addr.arpa. 43200 IN CNAME
162.160-175.48.168.205.in-addr.arpa.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns.norchemlab.com.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.norchemlab.com.
and your NS should respond for the 160-175 zone. The particular
naming convention doesn't matter, but has to be consistent between you
and your ISP. The filename of the zone doesn't need to match the zone
name, although that seems to be a popular misconception.. Slashes (as
in 160/28.48.168.205.in-addr.arpa) are mildly inconvenient convention
since, if the filename and zone DO match, they imply use of a
subdirectory.
Good luck,
Justin
On Tue, May 07, 2013 at 08:45:49AM -0700, Michael Varre wrote:
On Tuesday, May 7, 2013 11:34:07 AM UTC-4, Barry Margolin wrote:
In article mailman.240.1367938655.20661.bind-us...@lists.isc.org,
Michael Varre mva...@gmail.com wrote:
I'm setting up a new zone, similar to the many I've created successfully
on
other ISPs to answer with PTR records for a /26 the ISP has sub-delegated
to
my dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external:
query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried
setting up reverse dns to be setup by a cpanel server, but I'm not sure
this
is relevant. It creates two views, internal and external. This is
getting
serviced out of the external view, which really is just setup to answer
any
question for which it has an answer. So i _really_ don't think it's
relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
If you're getting queries for 90.1.1.1.in-addr.arpa from outside
clients, it means that the ISP has not set up the proper classless
reverse delegation. They're delegating 1.1.1.in-addr.arpa to you instead
of 64-26.1.1.1.in-addr.arpa.
But the client IP appears to be one of your own addresses. They should
be pointing to your caching server, not the authoritative server. It
should then follow the ISP's delegation. If you're using the same
server for auth and caching, you need to put the local IPs in the
allow-query ACL.
--
Barry Margolin
Arlington, MA
Thanks for the response Barry. First, I have a hunch they don't know how to
delegate classlessly. They seemed very confused at first.
Why would you think that queries for 90.1.1.1.in-addr.arpa from outside would
point to it being setup wrong by the ISP? .90 is one of my assigned IP's
withing my /26. My GW IP address is .65. Maybe that is where I've gone wrong?
I think my example may have confused things a bit. The 1.1.1.1 was just a
random number (one of the downfalls of obfuscating IP's on a mailing list).
consider that really 9.9.9.9, and that it is NOT one of my IP's - just a
client on the internet.
___
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
Re: Classless PTR query issue
On Tue, May 07, 2013 at 09:52:16AM -0700, Michael Varre wrote: Thanks Justin, I've been testing with dig and that's how I got the failed results posted previously. My digs lead me to believe their zones are named the same as mine, with -'s instead of /'s. dig -x 1.1.1.90 +trace snipped ;; Received 180 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 89 ms 1.1.1.in-addr.arpa. 86400 IN NS NS1.myisp.COM. 1.1.1.in-addr.arpa. 86400 IN NS NS2.myisp.COM. ;; Received 89 bytes from 199.180.180.63#53(r.arin.net) in 55 ms 90.1.1.1.in-addr.arpa. 3600 IN NS dns1.myns.com. ;; Received 75 bytes from 13.13.13.13#53(NS1.myisp.COM) in 84 ms ;; Received 44 bytes from 1.1.1.90#53(dns1.myns.com) in 80 ms end I've requested they confirm their setup, but I don't know how forthcoming they'll be. I don't see any - (or /) in your dig output, which indicates that the ISP delegation isn't using RFC2317-style delegation with CNAMES. It appears they may have manually added NS records for each of 64 IPs. That's messy and inelegant for them, and doesn't work right either. The ISP is responding with NS for 90.1.1.1, which means that the next query must ask a quesion *below* that: something.90.1.1.1. That's why a CNAME is needed, with an additional, artificial subzone, allowing proper delegation. Otherwise, it's a so-called horizontal referal. In the past, when I've requested RFC2317/sub-24 delegation of rev dns, I've included/suggested BIND syntax (but it's still sometimes taken multiple attempts to be correctly implemented). $ORIGIN 196.185.205.in-addr.arpa. 32-47 NS ns.norchemlab.com. 32-47 NS ns1.norchemlab.com. $GENERATE 32-47 $ CNAME $.32-47 Justin ___ 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: +, -, -E
On Mon, Jun 21, 2010 at 01:46:55PM -0500, Peter Laws wrote: What do they mean? I can't find them and yes, I've googled and also grepped the docs on isc.org ... Googling for symbols isn't easy.. http://www.isc.org/files/arm96.html#the_category_phrase |The query log entry reports the client's IP address and port number, |and the query name, class and type. It also reports whether the |Recursion Desired flag was set (+ if set, - if not set), if the query |was signed (S), EDNS was in use (E), if DO (DNSSEC Ok) was set (D), |or if CD (Checking Disabled) was set (C). Justin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Script to delete zone from named.conf
On Thu, Feb 04, 2010 at 06:19:07PM +, Evan Hunt wrote:
I know I can do that with grep, but you see I have 270 domains to delete
from my named.conf.
My question was more: has anyone got a working script that I can use in
order to delete name from my named.conf file ?
cat named.conf | \
awk 'BEGIN {suppress = 0}
/zone whatever.com/ {suppress = 1}
{if (suppress == 0) print; if ($1 == }; NF == 1) suppress = 0}'
Or words to that effect. Works as long as the zones are always formatted
the same way.
As an alternative:
To remove the toxtracker.info zone:
awk -v s=toxtracker.info 'BEGIN{RS=; s=zone \s\} $0~s{print $0\n}'
Justin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Script to delete zone from named.conf
On Thu, Feb 04, 2010 at 02:27:27PM -0700, Justin T Pryzby wrote:
awk -v s=toxtracker.info 'BEGIN{RS=; s=zone \s\} $0~s{print $0\n}'
Doh, should be:
awk -v s=toxtracker.info 'BEGIN{RS=; s=zone \s\} $0!~s{print $0\n}'
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
manually generating tsig keys
ARM9.5 still mentions manual generation of TSIG data: https://www.isc.org/software/bind/documentation/arm95#tsig Is there any advtantage to using -keygen ? ISTR some mention of an algorithm used to minimize the possibility of collisions. Or is that true for any key used with HMAC? Justin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
