Re: hello bind network problem ipv6
In message <4cddeb9f.5030...@fakessh.eu>, "fakessh @" writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> hello bind network
> hello guru of bind
> hello everybody
>
> i have all a slice of ipv6 address 2001:41D0:2:3Dd6::/64
> and I would simply change it with my bind ipv6
named.conf:
zone "6.D.D.3.2.0.0.0.0.D.1.4.1.0.0.2.IP6.ARPA" {
type master;
file "6.D.D.3.2.0.0.0.0.D.1.4.1.0.0.2.IP6.ARPA";
};
6.D.D.3.2.0.0.0.0.D.1.4.1.0.0.2.IP6.ARPA:
$TTL
@ SOA ns1.example.net. hosmaster.example.net. 1 3600 1200 864000 3600
@ NS ns1.example.net.
@ NS ns1.example.net.
0.F.E.D.C.B.A.9.8.7.6.5.4.3.2.1 PTR host.example.net.
where host.example.net has a of 2001:41D0:2:3Dd6:1234:5678:9abc:def0
> please you have to be in your answer or I will not understand
> Please give concrete examples of config bind otherwise I would not
> understand
>
>
> very nice for all answers even the direct mailer in my mailbox
>
> - --
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7
> gpg --keyserver pgp.mit.edu --recv-key 092164A7
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org/
>
> iD8DBQFM3euftXI/OwkhZKcRAn9XAJ9yhjDo1C+Et/PYsloD7V8qXnD4IQCggMVn
> Al19iQHuOfqsGYDepFT60QA=
> =egd8
> -END PGP SIGNATURE-
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
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
Views and Updates with a twist
Hi, I'm currently using a BIND9 slave for two masters. Master 1 is using views (internal and external), master 2 doesn't have any views configured. This setup works for master 1 without any problems, for master 2 I have the slave configured to use the same configuration files for both views so the zones are identical in both views. When master 2 sends a notify to the slave, the slave refreshes the appropriate zone but only for the internal view. The external view continues serving the old zone even though the file contents are updated correctly. When I restart the slave (rather then reloading changed zones only) it serves identical data in both views again. I have read the FAQ entry at https://www.isc.org/faq/item/182 but this assumes views configured on both master and slave. Is there a way to have the slave update the zones on both views when receiving a notify or do I have to configure the same views on the master and have them serve identical data? cu, Bodo -- Bodo Bellut b...@bellut.net | USE PGP! +---+ Stangefolstr. 17 Fax/Mobile: just ask | (key via server|\ O---m /| 44141 Dortmund Fon: +49-700-77-BELLUT | or on request)|/-\| PGP: 768/FA18A639 AE 5A 47 40 5A A0 D6 15 8E 54 44 AA 8D DD 6E BD+---+ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Views and Updates with a twist
In message <201011141952.oaejqp2y009...@nermal.bellut.net>, Bodo Bellut writes:
>
> Hi,
>
> I'm currently using a BIND9 slave for two masters. Master 1 is
> using views (internal and external), master 2 doesn't have any
> views configured.
>
> This setup works for master 1 without any problems, for master 2 I have
> the slave configured to use the same configuration files for both views so
> the zones are identical in both views.
>
> When master 2 sends a notify to the slave, the slave refreshes the
> appropriate zone but only for the internal view. The external view
> continues serving the old zone even though the file contents are updated
> correctly.
Slave zone should NOT share files.
> When I restart the slave (rather then reloading changed zones
> only) it serves identical data in both views again.
>
> I have read the FAQ entry at https://www.isc.org/faq/item/182 but this
> assumes views configured on both master and slave.
>
> Is there a way to have the slave update the zones on both views when
> receiving a notify or do I have to configure the same views on the master
> and have them serve identical data?
If it is the same content, have one of the views on the slave transfer
from the other view. Here view "A" is the view that receives the notify
from the master. View "A" transfers the content from the master then
notifies view "B", which, in turn, transfers the content from view "A".
key "view-a" {
};
key "view-b" {
};
view "A" {
match-clients { key view-a; !key view-b; };
server 127.0.0.1 {
keys view-b;
};
zone "example.net" {
type slave;
masters { };
file "slave-a/example.net";
allow-transfer { key view-a; };
notify explict;
also-notify { 127.0.0.1; };
};
};
view "B" {
match-clients { ! key view-a; key view-b; };
zone "example.net" {
type slave;
file "slave-b/example.net";
masters { 127.0.0.1 key view-a; };
notify no;
allow-transfer { };
};
};
If each view has different content then you need to ensure that both
views receive notify messages from their respective sources.
One day we should extend also-notify to accept "key value" like masters
do so that server clause can be removed.
Mark
--
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
