RES: problem with bind9, view and nsupdate
Paula Saito Telloli Martins
pmartins at bmf.com.br
Tue Aug 2 17:02:53 UTC 2005
Bind considers each view as a separated nameserver (for different publics).
So, if you have three views, it considers you have three files (even though
they are all about the same zone). This way, you must have three different
files to answer the publics you have and, each one of them will make a
"zontransfer" according to your named.conf parameters. It means that you
need to define an IP address (specifically for allow-transfer) to each view
in order to get the correct zonetransfer and correct serial updates between
ns1 and ns2.
Paula.
-----Mensagem original-----
De: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] Em nome de
Sten Carlsen
Enviada em: terça-feira, 2 de agosto de 2005 13:09
Para: Michael Dosser
Cc: bind-users at isc.org
Assunto: Re: problem with bind9, view and nsupdate
Hi
As I see things, you update the internal view with nsupdate and that
operation works fine, the slave gets the new number etc.
You have to see the two views as separate nameservers, so what will update
the external view or tell it:
1- there are new data from nsupdate (which is not really true, nsupdate has
updated the other view (server))
2- where can they be found?
The first question could be solved by rndc.
The second question is important, where is this information stored? in the
inside RAM-based data of the internal view. There is no place that the
external view can see the new info, even if it was aware that it existed.
Michael Dosser wrote:
>Hello all,
>
>most probably I have a misconfiguration somewhere in my setup, but I
>cannot figure out where. I have a setup with the following two nameservers:
>
>---------------------------------------------------------------------
>ns1:
>OS: FreeBSD-4.11-RELEASE-p11
>bind9: 9.3.1
>
>ns2:
>OS: Debian GNU/Linux 3.1
>bind9: 9.2.4-1
>
>Both are started with the following command:
>/path/to/named -u bind
>
>Both hosts have a host based firewall. Port 53 udp/tcp is open in both
>directions.
>
>---------------------------------------------------------------------
>
>There is an application on ns2 which updates via nsupdate zonefiles on
>ns1. For debugging reasons I left the application aside, and tested as
>the user connecting via nsupdate. nsupdate itself is not the problem as
>I figured out (and so is the application launching nsupdate). But read,
>after showing you my configs I'll describe the problem.
>
>---------------------------------------------------------------------
>
>Setup on ns1 (named.conf):
>
>acl "nameservers" {
> localhost;
> <ip of ns1>;
> <ip of ns2>;
>};
>acl "internal" {
> <ips of servers>;
>};
>acl "customers" {
> <ips of customers>;
>};
>options {
> directory "/etc/namedb";
> pid-file "/var/run/named/pid";
> query-source address * port 53;
> dump-file "named_dump.db";
> allow-transfer { nameservers; };
> transfer-format many-answers;
> version "DNS server";
> // conform to RFC1035
> auth-nxdomain yes;
> datasize 256m;
> max-ncache-ttl 60;
> recursive-clients 5000;
> listen-on {
> <ip of nameserver>;
> 127.0.0.1;
> };
>};
>key "rndc-key" {
> algorithm hmac-md5;
> secret "<secret key>";
>};
>controls {
> inet 127.0.0.1 port 953
> allow { 127.0.0.1; } keys { "rndc-key"; }; };
>
>key updatekey. {
> algorithm hmac-md5;
> secret "<secret key>";
>};
>
>view "internal" {
> match-clients { "internal"; };
> recursion yes;
> include "named.local";
> include "named.internal";
> include "named.master";
> include "/path/to/nsupdate/managed/named.primary.conf";
> include "/path/to/nsupdate/managed/named.secondary.conf";
>};
>
>view "customers" {
> match-clients { "customers"; };
> recursion yes;
> include "named.local";
> include "named.internal";
> include "named.master";
> include "/path/to/nsupdate/managed/named.primary.conf";
> include "/path/to/nsupdate/managed/named.secondary.conf";
>};
>
>view "external" {
> match-clients { "any"; };
> recursion no;
> include "named.local";
> include "named.internal";
> include "named.master";
> include "/path/to/nsupdate/managed/named.primary.conf";
> include "/path/to/nsupdate/managed/named.secondary.conf";
>};
>---------------------------------------------------------------------
>The files named.local, named.internal and named.master are includes not
>managed by nsupdate. The other two (named.primary.conf and
>named.secondary.conf) are managed by nsupdate.
>the named.conf on ns2 looks exactly the same. Example entry for
>named.primary.conf on ns1 (which is managed by nsupdate):
>
>zone "blasdf.at" IN {
> type master;
> file "/path/to/nsupdate/managed/zones/hosts_blasdf.at";
> allow-update { key updatekey; };
>};
>
>and the zone itself:
>
>$ORIGIN .
>$TTL 86400 ; 1 day
>blasdf.at IN SOA ns1.domain.at. dns.domain.at. (
> 2004081817 ; serial
> 28800 ; refresh (8 hours)
> 7200 ; retry (2 hours)
> 604800 ; expire (1 week)
> 86400 ; minimum (1 day)
> )
> NS ns1.domain.at.
> NS ns2.domain.at.
> A 195.69.180.10
> MX 10 mail.domain.at.
>$ORIGIN blasdf.at.
>
>
>
>---------------------------------------------------------------------
>Problem description:
>
>If I update blasdf.at and add a new A record (or any other record) with
>nsupdate, the serial gets automagically - as expected - bumped higher
>by 1, so with the above example I get 2004081818. ns2 as a slave gets
>also the new serial and the new A record.
>
>If I launch dig on one of the nameservers all looks good:
>
>$ dig soa blasdf.at @localhost|grep -A 2 "ANSWER SECTION"
>;; ANSWER SECTION:
>blasdf.at. 86400 IN SOA ns1.domain.at.
>dns.domain.at. 2004081818 28800 7200 604800 86400
>
>But if I dig from a host defined in view external I get the old serial:
>
>$ dig soa blasdf.at @ns1.domain.at|grep -A 2 "ANSWER SECTION"
>;; ANSWER SECTION:
>blasdf.at. 86400 IN SOA ns1.domain.at.
>dns.domain.at. 2004081817 28800 7200 604800 86400
>
>If I dig from a host defined in view internal, I get the right serial,
>but not if I dig from a host in view customers.
>
>And this is true for both nameservers (ns1 and ns2). After one day on
>ns2 I get the right serial, on ns1 still the old serial.
>
>What is happening here? Where might be the misconfiguration?
>
>Thank you for your help,
>Michael Dosser
>
>
>
--
Best regards
Sten Carlsen
Let HIM who has an empty INBOX send the first mail.
More information about the bind-users
mailing list