• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Can someone confirm these BIND configs for me?

spyordie007

Diamond Member
I'm trying to help out someone who is having some BIND issues. They are running dual servers on two boxes (internal and external/primary and secondary).

The problem is that every couple of months their secondary server pulls from the external side on the primary server when doing a zone update and starts giving out their internal 10.x addresses for their servers. Every time this happens they have been able to stop and restart BIND on the secondary server and it starts pulling the zones from the correct servers.

Primary is 10.10.1.10 and 64.x.x.2
Secondary is 10.10.1.6 and 64.x.x.3

Here is the current config on the primary:
view "internal" {

match-clients { !10.10.1.6; 10.0.0.0/8; 64.x.x.0/20; 127.0.0.0/8; };
recursion yes;
allow-transfer { !10.10.1.6; };
allow-query { 10.0.0.0/8; 64.x.x.0/20; 127.0.0.0/8; };

zone "domain.com" {
// Our internal A RR zone. There may be several of these.
type master;
file "internal/db.domain.com";
};

reverse lookup omitted

};

view "external" {

match-clients { any; };
allow-transfer { 10.10.1.6; };
recursion no;

zone "domain.com" {
type master;
file "external/db.domain.com";
allow-query { any; };
};

omitted

};
And the current secondary config:
view "internal" {
match-clients { 127.0.0.0/8; 10.0.0.0/8; 64.x.x.0/20; };
recursion yes;

zone "domain.com" {
type slave;
file "slaves/internal/db.domain.com";
masters { 10.10.1.10; };
allow-transfer { none; };
};

omitted

};

view "external" {

match-clients { any; };
recursion no;

zone "domain.com" {
type slave;
file "slaves/external/db.domain.com";
masters { 10.10.1.10; };
allow-transfer { none; };
};

omitted

};
Now I dont have a ton of experience with BIND but it's my hunch when issues occur the slave is doing the zone update against the public IP of the primary server. Therefore my suggested changes are...

The primary:
view "internal" {

match-clients { 10.0.0.0/8; 127.0.0.0/8; };
recursion yes;
allow-transfer { 10.10.1.6; };
allow-query { 10.0.0.0/8; 127.0.0.0/8; };

zone "domain.com" {
// Our internal A RR zone. There may be several of these.
type master;
file "internal/db.domain.com";
};

omitted

};

view "external" {

match-clients { any; };
allow-transfer { 10.10.1.6; };
recursion no;

zone "domain.com" {
type master;
file "external/db.domain.com";
allow-query { any; };
};

omitted

};
And the secondary config:
view "internal" {
match-clients { 127.0.0.0/8; 10.0.0.0/8; };
recursion yes;

zone "domain.com" {
type slave;
file "slaves/internal/db.domain.com";
masters { 10.10.1.10; };
allow-transfer { none; };
};

omitted

};

view "external" {

match-clients { any; };
recursion no;

zone "domain.com" {
type slave;
file "slaves/external/db.domain.com";
masters { 10.10.1.10; };
allow-transfer { none; };
};

omitted

};
Does this sound like a reasonable possibility? Can anyone confirm that this would be the correct changes to make?

Thanks,

Erik
 
Is there some other dns server that will resolve the 64.x address for an outside client? If not, the changes you propose will break it for outside clients.
 
How do you figure? For the external zone I'm doing a match-clients match-clients { any; }, so any host (internal or external) could run a query against it.
 
Back
Top