Clarification about DNS notify
Hey Guys, I have an issue which need some help. I have two master DNS servers, say A B. A is running freebsd B is running centos. B is running BIND 9 also. Now, I want to add one more to this cluster say C. I have installed centos in C with BIND 9. Now, I have copied /etc/named.conf /var/name from B to C. Now I restarted named in C. Everything worked. Now, I have a question which may be quite simple, but I couldn't find an answer even after lot of googling. So, I would be extremely grateful for any advice you could offer. When I restarted named in C, I could see that C is sending DNS notifications and B is receiving it from /var/log/messages in C: Sep 9 23:53:44 serverC named[11844]: zone example.com/IN: sending notifies (serial 2005030401) from /var/log/messages in B: Sep 9 23:53:44 serverB named[30375]: client XX.XX.XX.XX#54546: received notify for zone 'example.com' I checked /etc/named.conf and I couldn't see any particular reason for C choosing to notify B. Any explanation to this behavior or a link to any relevant guide will be helpful. -- Regards, Sherin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification about DNS notify
Am Fri, 10 Sep 2010 12:51:11 +0530 schrieb Sherin George l...@sheringeorge.co.cc: Hey Guys, I have an issue which need some help. I have two master DNS servers, say A B. A is running freebsd B is running centos. B is running BIND 9 also. Now, I want to add one more to this cluster say C. I have installed centos in C with BIND 9. Now, I have copied /etc/named.conf /var/name from B to C. Now I restarted named in C. Everything worked. Now, I have a question which may be quite simple, but I couldn't find an answer even after lot of googling. So, I would be extremely grateful for any advice you could offer. When I restarted named in C, I could see that C is sending DNS notifications and B is receiving it from /var/log/messages in C: Sep 9 23:53:44 serverC named[11844]: zone example.com/IN: sending notifies (serial 2005030401) from /var/log/messages in B: Sep 9 23:53:44 serverB named[30375]: client XX.XX.XX.XX#54546: received notify for zone 'example.com' I checked /etc/named.conf and I couldn't see any particular reason for C choosing to notify B. Any explanation to this behavior or a link to any relevant guide will be helpful. Sharing your current configuration would help in helping you with your problem. ;) A wild guess would be that you're missing a notify no or notify master-only option on your slave servers. Ciao Torsten -- Regards, Sherin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification about DNS notify
Hello Torsten, Thanks for looking into this. Basically, my previous question came from my ignorance. But, I learned more and I think found the answer. The SOA MNAME field is used by NOTIFY and by dynamic update. Authoritative name servers send NOTIFY messages to all name servers in NS records that aren't in the MNAME field, and dynamic updaters try to send updates to the name server listed in the MNAME field first, if it's also listed in the NS records for the zone. I could confirm that most of the zones are configured such that serverB will receive NOTIFY as per above statement. So, if above statement is correct, I am with my answer :) Thank you so much for your help :) P.S: A wild guess would be that you're missing a notify no or notify master-only option on your slave servers. I have verified that notify no or notify master-only are not used in my named.conf file. -- Best Regards, Sherin On Fri, Sep 10, 2010 at 1:26 PM, Torsten t...@the-damian.de wrote: Am Fri, 10 Sep 2010 12:51:11 +0530 schrieb Sherin George l...@sheringeorge.co.cc: Hey Guys, I have an issue which need some help. I have two master DNS servers, say A B. A is running freebsd B is running centos. B is running BIND 9 also. Now, I want to add one more to this cluster say C. I have installed centos in C with BIND 9. Now, I have copied /etc/named.conf /var/name from B to C. Now I restarted named in C. Everything worked. Now, I have a question which may be quite simple, but I couldn't find an answer even after lot of googling. So, I would be extremely grateful for any advice you could offer. When I restarted named in C, I could see that C is sending DNS notifications and B is receiving it from /var/log/messages in C: Sep 9 23:53:44 serverC named[11844]: zone example.com/IN: sending notifies (serial 20050 30401) from /var/log/messages in B: Sep 9 23:53:44 serverB named[30375]: client XX.XX.XX.XX#54546: received notify for zone 'example.com' I checked /etc/named.conf and I couldn't see any particular reason for C choosing to notify B. Any explanation to this behavior or a link to any relevant guide will be helpful. Sharing your current configuration would help in helping you with your problem. ;) A wild guess would be that you're missing a notify no or notify master-only option on your slave servers. Ciao Torsten -- Regards, Sherin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
For lack of response here, the heimdal guys are putting in a work-around for this bind bug. Sam On 25/08/10 17:41, Sam Liddicott wrote: I've also reported this as a bind bug, but I'm posting it here as I think it answers the case for the BSD user in the thread entitled: Can't get BIND to use GSSAPI from /usr/local on FreeBSD (Patch attached which fixes it for me) I've traced my problem to what looks like a mismatch of expectations between heimdal 1.3.3 and bind 9 (BIND 9.7.1-P2) in lib/dns/openssl_link.c, entropy_get returns the number of bytes if successful - always equal to argument num (if successful). entropy_get is registered as a delegate for openSSL's RAND_bytes in dst__openssl_init. My man page for RAND_bytes states: RETURN VALUES RAND_bytes() returns 1 on success, 0 otherwise. The error code can be obtained by ERR_get_error(3). RAND_pseudo_bytes() returns 1 if the bytes generated are cryptographically strong, 0 otherwise. Both functions return -1 if they are not supported by the current RAND method. and entropy_get varies from that behaviour. This causes problems with heimdal 1.3.3, in heimdal's lib/krb5/crypto.c: 3995 if (RAND_bytes(buf, len) != 1) 3996 krb5_abortx(NULL, "Failed to generate random block"); So "nsupdate -g" fails when linked with heimdal 1.3.3 It looks like bind 9 is at fault even though heimdal could be more accepting. I don't know if there are other similar errors in other openssl_link.c ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ipv6 implementation in an ipv4 camp
I am curious if anyone can point out articles or deeper instructions regarding an implementation and launch of ipv6 in a fully ipv4 camp? If the upstream ISP still provides the end user an ipv4 number as a gateway, and the end user still has a /24 or /23 assigned by the ISP, need they be concerned with ipv6? would the ipv4 /23 subnet be 'translatable' to a corresponding ipv6 number? Any source documents would be greatly appreciated. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 implementation in an ipv4 camp
Jim Pazarena wrote: I am curious if anyone can point out articles or deeper instructions regarding an implementation and launch of ipv6 in a fully ipv4 camp? If the upstream ISP still provides the end user an ipv4 number as a gateway, and the end user still has a /24 or /23 assigned by the ISP, need they be concerned with ipv6? would the ipv4 /23 subnet be 'translatable' to a corresponding ipv6 number? Any source documents would be greatly appreciated. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users I used http://ipv6.he.net and http://www.sixxs.net for use to do a trial implementation of IPv6 in our network. Our upstream ISP has since provided us with native IPv6 and we are working on full implementation here. We have the infrastructure in place and are working on adding IPv6 addresses to all websites as time allows. It's not a high priority at this time. IMHO, it's good for an ISP operation to get on board and figure out how to implement IPv6. End users don't have that pressing of a need unless/until they are forced to by their upstream providers. There is a lot of good info at http://ipv6.he.net and at http://www.sixxs.net for getting a working IPv6 tunnel into their network and how to implement IPv6. Lyle Giese LCR Computer Services, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 implementation in an ipv4 camp
Although its not perfect, you can look into IP protocol 41 which is IPv6 in IPv4. Helps provide some functionality in a last resort case. Jim Pazarena b...@paz.bz wrote: I am curious if anyone can point out articles or deeper instructions regarding an implementation and launch of ipv6 in a fully ipv4 camp? If the upstream ISP still provides the end user an ipv4 number as a gateway, and the end user still has a /24 or /23 assigned by the ISP, need they be concerned with ipv6? would the ipv4 /23 subnet be 'translatable' to a corresponding ipv6 number? Any source documents would be greatly appreciated. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: DNSSEC, views trusted keys...
Mark,
I must be opaque; I don't see how to make this approach work in any
reasonable way.
I tried this:
(DLV is enabled, and my external keys for example.com are there.)
view r-internal in {
match-clients { !any_external; all_internal; };
match-recursive-only yes;
transfer-source 192.168.self;
query-source address 192.168.self; // This should make resolution match
internal
recursion yes;
allow-recursion { all_internal; };
allow-query-cache { all_internal; };
include internal_trusted_keys.conf; // contains trusted-keys {}; for
the internal zone apexes
// example.net,
10.in-addr.arpa, 168.192.in-addr.arpa, etc
};
view internal in {
(as before)
key-directory /xx../internal-keys;
match-clients { !any_external; all_internal; };
zone example.net {
auto-dnssec maintain;
type master;
...
};
zone 168.192.IN-ADDR.ARPA in {
auto-dnssec maintain;
type master;
...
};
zone xx.example.net in {...}
zone xx.168.192.IN-ADDR.ARPA in {...}
}
// This has to do with interfaces that have internal addresses, but
// see the DNS as if they were outside. Management tools...
view r-external in {
match-clients { any_external; };
match-recursive-only yes;
transfer-source 192.168.self-x;
query-source address 192.168.self-x;
recursion yes;
allow-recursion { any_external; };
allow-query-cache { any_external; };
// external trust comes thru the DNS (dlv)
};
view external in {
...
}
The number of active zones reported by rndc status doubled from 56 to 90!
I expected the r-internal view to see that it was serving no zones to
recursively resolve all the client requests with RR=0. Then the internal
view would catch them. But that seems to be wrong.
I did get AD set on the first few queries to example.net. But after a while
I started seeing SRVFAILs and claims that no trusted key matched rrsets.
Once I started querying the in-addr.arpa zone, things definitely fell apart.
It seems that the resolver was going outside - in fact, I saw trust chain
broken messages in the logs, where the address of the server was one of the
1918 blackhole servers and the query was to an internal 1918 address's PTR
record in a zone of the interal view. I also got these for example.net...
So it looks like the new (r-internal) view is starting at the root when it
resolves -- ignoring what it has data for locally. It sorta works for
example.net names because it happens that the internal and external views
use the same (nsx.example.net) names for their nameservers - but of course
the addresses are different! And NAT gets in the way. in-addr.arpa will
work for non-1918 addresses - mostly. But for private addresses, this won't
work at all...
It's all logical - but not productive. Even if the scheme works, it's
certainly going to put a lot of redundant data into memory. (Which is
limited on my embedded servers.)
I still think that BIND should look at RD on queries that it resolves from
an authoritative zone, and if set it should validate from the trust root to
the key it used to sign the zone. I can be persuaded that there's not much
point in actually verifying the signatures on the data in the response -
authoritative does mean that the file can be trusted about as much as that
BIND isn't lying about having validated...
Other ideas?
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Thursday, September 09, 2010 22:06
To: Phil Mayers
Cc: bind-us...@isc.org
Subject: Re: DNSSEC, views trusted keys...
In message 4c891404.3000...@imperial.ac.uk, Phil Mayers writes:
On 09/09/2010 03:45 PM, Timothe Litt wrote:
There is other advice in the ARM that says to put 'your
organization's public keys in the trusted-keys list'. That doesn't
help - and in fact, confuses me even more since example.net has TWO
different public keys - one for each view. And trusted-keys is a global
server option...
I must be missing something.
I don't think so. Currently AFAICT bind will not set AD on
authoritative zones, with any combination of options.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Add a match-recursion-only view;
view secure {
match-clients { internal; };
match-recursion-only yes;
recursion yes;
};
view internal {
match-clients { internal; };
recursion no;
};
view external {
match-clients { !internal; any };
recursion no;
};
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
