Re: one-zone-only forwarding DNS

[Kevin Darcy]

9.5.5 is old -- upgrade.

But, to the architecture issue... sounds like you need an "internal root
with forwarding exceptions" setup.

   - As per best practices, consider separating the recursive-resolver and
   hosting functions into separate views, separate named instances (listening
   on different IPs) or even separate server instances.
   - If you opt *not* to make such a separation, then at the very least,
   you'll need to replace "recursion no" with "allow-recursion", permitting
   localhost and internal clients. In the absence of recursion being allowed,
   none of your "type forward" zone definitions are going to work.
   - Define an internal root zone that contains delegations for the parts
   of the namespace that you want to resolve for your internal clients, either
   from authoritative data or via forwarding. Being delegated allows
   non-authoritative parts of the namespace to resolve sanely, via "type
   forward" (aka selective or conditional forwarding) definitions in
   named.conf. Queries for anything that doesn't fall under a delegation gets
   NXDOMAIN from your internal root zone, which I believe meets your
   requirements. Note that selective/conditional forwarding is for a whole
   branch of the namespace -- if you want to carve out some parts of a
   namespace that are forwarded, and others that aren't, or if the delegation
   hierarchy seen through forwarding differs from the structure you want
   internally, then it gets complicated, but I won't belabor the point here,
   since I don't know if you have such a requirement or not. Note also that
   when running an internal root, you'll need to make arrangements for reverse
   resolution (the in-addr.arpa and ip6.arpa namespaces).

In skeletal form, a view-based separation would look something like:

view internal
match-clients xxx # could also use match-destinations, if
listening on multiple IPs
recursion yes # the default
zone "." # with delegations
internal zone #1
internal zone #2
etc.
forwarded zone #1
forwarded zone #2
etc.
view hosting
match-clients all # if not matched above
recursion no
hosted zone #1
hosted zone #2
 etc.

If you separate by named instance and/or server instance, then each of
those views would just become the default view for each instance (with no
"match" clause obviously), and you would protect the "internal" listen-on
address from external queries via your normal access-control methods
(routing, firewalls, etc.)


  - Kevin

P.S. I assume that "corp.intranet.de" in your example config is one of the
domains you described as intended to be resolvable from the Internet, but
you don't show a zone-level "allow-query", so, as it stands, it wouldn't be
resolvable outside of your internal network. I'm guessing this was just an
oversight when you composed your example config...

On Tue, Nov 13, 2018 at 6:01 AM Sig Pam  wrote:

> Hi all!
>
>
>
> I’m really despairing on a configuration, and start to wonder if it is
> possible at all.
>
>
>
> Running Bind 9.5.5, I want to serve IP-Addresses for my internal network
> only, and none from the internet, except for a few domains. The idea is I
> don’t want any intranet client to be able to resolve Internet addresses,
> except for a few domains like Microsoft.com and others.
>
>
>
> My named.config looks like this (shortened, copied together from multiple
> files including others):
>
>
>
> acl intranet_nets {
>
>  192.168.94.0/24;
>
>  192.168.1.0/24;
>
>  192.168.5.0/24;
>
>  };
>
>
>
> options {
>
>  directory "/var/cache/bind";
>
>
>
>  allow-query { localhost; intranet_nets;};
>
>  allow-query-cache { localhost; intranet_nets;};
>
>
>
> recursion no;   # switching this on would resolve ANY Internet address,
> which I don’t want
>
>
>
>  dnssec-validation auto;
>
>
>
>  auth-nxdomain no;# conform to RFC1035
>
>  listen-on-v6 { any; };
>
>
>
> };
>
>
>
> zone "corp.intranet.de" {
>
>  type master;
>
>  file "/etc/bind/db.corp.intranet.de";
>
>  allow-transfer { 192.168.94.242; };
>
>  allow-update { none;};
>
>  };
>
>
>
> zone "94.168.192.in-addr.arpa" {
>
>  type master;
>
>  file "/etc/bind/db.94.168.192";
>
>  allow-transfer { 192.168.94.242; };
>
>  allow-update { none;};
>
>  };
>
>
>
> zone "microsoft.com" IN {
>
> type forward;
>
> forwarders { 9.9.9.9; 194.150.168.168;  8.8.8.8;  8.8.4.4; };
>
> };
>
>
>
>
>
> Running this configuration, my local addresses are correctly resolved,
> external addresses not (good), but DNS-requests for the domain
> Microsoft.com neither (bad!).
>
>
>
> I actually wonder if “forward” is the right keyword (is forward = answer
> to the client: “don’t ask me, ask one of the forwarders” ???), or if I’m
> totally on the wrong way.
>
>
>
> Any support 

Re: conflicting subdomain delegation

[Mark Andrews]

> On 14 Nov 2018, at 4:04 am, Frank Liu  wrote:
> 
> Hi,
> 
> Is there a RFC determining which nameserver to use if there is a conflicting 
> subdomain delegation?
> 
> eg:
> In the zone of a.com, there are two NS delegations

This one is used.

> b.a.com NS host1

This one is ignored as it is occluded data.

> c.b.a.com NS host2
> 
> On host1 in zone b.a.com, there is
> c.b.a.com NS host3

Which is occluded data or glue depending upon the rest of the contents of the 
zone.

> As you can see, there is a conflicting delegation for c.b.a.com. If I look a 
> name d.c.b.a.com, will the nameserver host2 or host3 be used?
> dig +trace seems to go to host2, but bind9 as a resolver goes to host3.
> (the test was done on a centos7).

dig +trace follows the returned delegations. 

> Any ideas?
> Thanks!
> ___
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
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: conflicting subdomain delegation

[Matus UHLAR - fantomas]

On 13.11.18 09:04, Frank Liu wrote:

Is there a RFC determining which nameserver to use if there is a
conflicting subdomain delegation?

eg:
In the zone of a.com, there are two NS delegations:

b.a.com NS host1
c.b.a.com NS host2


this should produce "out of zone data" error. Since the b.a.com is
delegated, no subdomains of it should appear in a.com zone.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
___
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: Common zone file, on multiple views

[Grant Taylor via bind-users]

On 11/12/2018 04:57 AM, Sabri MJAHED (VINC) wrote:

Hi all,


Hi,

I want to have the same zone on multiple views, but i didn't find any 
solution that ease the use of this.


I would think that the zone's "in-view" statement would do what you want.


I don't want to make 3 file of zone conf with multiple in-view statements.


But it sounds like your problem is that you dislike the overhead of 
managing the multiple "in-view" statements.


Here is the server-fault post with more information : 
https://serverfault.com/questions/939287/bind-common-zone-on-views-possibilities 


I might be misunderstanding you, but it seems like the following might work:

named.conf
--8<--
view "common-zones" {
zone "example.com" {…};
zone "example.net" {…};
zone "example.org" {…};
};

view "mordor" {
include common-zones.conf;
zone "mordor.example" {…};
}

view "gondor" {
include common-zones.conf;
zone "gondor.example" {…};
}

view "khand" {
include common-zones.conf;
zone "khand.example" {…};
}
-->8--

common-zones.conf
--8<--
zone "example.com" {
in-view "common-zones";
};

zone "example.net" {
in-view "common-zones";
};

zone "example.org" {
in-view "common-zones";
};
-->8--

Note:  This is untested and conceptual.

The idea being that you define the zones in the "common-zones" view, and 
then in-view them in the common-zones.conf file.  That way any view that 
includes the common-zones.conf file will include all the in-view(ed) 
zone definitions.


Does this do what you want?

I think it keeps you from needing to modify all the zones that include 
common-zones.conf when you add a zone to the common zones.  Which I 
think is your goal.



Thanks a lot.


Here's hoping this helps.  Good luck and you're welcome.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: conflicting subdomain delegation

[Frank Liu]

bind9 resolver a simple cache only with root hint. no local zones.

On Tue, Nov 13, 2018 at 9:18 AM Lyle Giese  wrote:

> On 11/13/2018 11:04 AM, Frank Liu wrote:
>
> Hi,
>
> Is there a RFC determining which nameserver to use if there is a
> conflicting subdomain delegation?
>
> eg:
> In the zone of a.com, there are two NS delegations:
>
> b.a.com NS host1
> c.b.a.com NS host2
>
> On host1 in zone b.a.com, there is
> c.b.a.com NS host3
>
> As you can see, there is a conflicting delegation for c.b.a.com. If I
> look a name d.c.b.a.com, will the nameserver host2 or host3 be used?
> dig +trace seems to go to host2, but bind9 as a resolver goes to host3.
> (the test was done on a centos7).
>
> Any ideas?
> Thanks!
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing 
> listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users
>
> I would expect that behavior if the Bind9 resolver was setup to query
> host1.  If bind9 queries a server that is authoritive for b.a.com, I
> would expect that result.  If the bind9 resolver is setup to query a
> recursive only server(other than host1), I would expect the same behavior
> as the +trace result.
>
> so I think the answer is dependant on how your bind9 resolver is
> configured.
>
> Lyle Giese
> ___
> 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: conflicting subdomain delegation

[Lyle Giese]

On 11/13/2018 11:04 AM, Frank Liu wrote:

Hi,

Is there a RFC determining which nameserver to use if there is a 
conflicting subdomain delegation?


eg:
In the zone of a.com , there are two NS delegations:

b.a.com  NS host1
c.b.a.com  NS host2

On host1 in zone b.a.com , there is
c.b.a.com  NS host3

As you can see, there is a conflicting delegation for c.b.a.com 
. If I look a name d.c.b.a.com , 
will the nameserver host2 or host3 be used?

dig +trace seems to go to host2, but bind9 as a resolver goes to host3.
(the test was done on a centos7).

Any ideas?
Thanks!


___
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


I would expect that behavior if the Bind9 resolver was setup to query 
host1.  If bind9 queries a server that is authoritive for b.a.com, I 
would expect that result.  If the bind9 resolver is setup to query a 
recursive only server(other than host1), I would expect the same 
behavior as the +trace result.


so I think the answer is dependant on how your bind9 resolver is configured.

Lyle Giese

___
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

conflicting subdomain delegation

[Frank Liu]

Hi,

Is there a RFC determining which nameserver to use if there is a
conflicting subdomain delegation?

eg:
In the zone of a.com, there are two NS delegations:

b.a.com NS host1
c.b.a.com NS host2

On host1 in zone b.a.com, there is
c.b.a.com NS host3

As you can see, there is a conflicting delegation for c.b.a.com. If I look
a name d.c.b.a.com, will the nameserver host2 or host3 be used?
dig +trace seems to go to host2, but bind9 as a resolver goes to host3.
(the test was done on a centos7).

Any ideas?
Thanks!
___
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: Method of writing zone files

[Marcus Frenkel]

Thanks Matus.

Does bind keep the received messages for zone updates in queue during rndc
freeze, and apply them after rndc thaw? I think that while rndc freeze is
in effect, bind will ignore (and not keep) notify messages for zone
updates. The drawback in this case is that a zone will only update again
after the refresh interval. Please correct me if I'm wrong.

On Tue, Nov 13, 2018 at 1:08 PM Matus UHLAR - fantomas 
wrote:

> >On 12-Nov-18 14:39, Marcus Frenkel asked about backing up slave zone
> >files & bind's update mechanism:
>
> On 13.11.18 06:37, Timothe Litt wrote:
> >I believe you're asking the wrong questions and are likely to run into
> >complications.  You don't know when BIND will merge the journal, or that
> >rsync will atomically snapshot the zone file and the journal.  So you
> >will get a coherent copy of the the zone file - but it may be stale.
> >The journal may be earlier or later than the zone file, or it may be
> >incomplete. This means that a restore  may have the slave serve stale
> >data - until it queries the master for any updates & if necessary, fixes
> >the journal file.  If the master happens to be down, this is especially
> >suboptimal.
> >
> >So I would exclude both files from rsync, and use another approach to
> >save a coherent copy of the zone file(s) in my backup procedure.
>
> rndc freeze can cause all journals to be synced and files saved.
> You can call this before backup and call rndc thaw after.
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Linux IS user friendly, it's just selective who its friends are...
> ___
> 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: Method of writing zone files

[Matus UHLAR - fantomas]

On 12-Nov-18 14:39, Marcus Frenkel asked about backing up slave zone
files & bind's update mechanism:


On 13.11.18 06:37, Timothe Litt wrote:

I believe you're asking the wrong questions and are likely to run into
complications.  You don't know when BIND will merge the journal, or that
rsync will atomically snapshot the zone file and the journal.  So you
will get a coherent copy of the the zone file - but it may be stale. 
The journal may be earlier or later than the zone file, or it may be
incomplete. This means that a restore  may have the slave serve stale
data - until it queries the master for any updates & if necessary, fixes
the journal file.  If the master happens to be down, this is especially
suboptimal.

So I would exclude both files from rsync, and use another approach to
save a coherent copy of the zone file(s) in my backup procedure.


rndc freeze can cause all journals to be synced and files saved.
You can call this before backup and call rndc thaw after.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux IS user friendly, it's just selective who its friends are...
___
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: Method of writing zone files

[Timothe Litt]

On 12-Nov-18 14:39, Marcus Frenkel asked about backing up slave zone
files & bind's update mechanism:

I believe you're asking the wrong questions and are likely to run into
complications.  You don't know when BIND will merge the journal, or that
rsync will atomically snapshot the zone file and the journal.  So you
will get a coherent copy of the the zone file - but it may be stale. 
The journal may be earlier or later than the zone file, or it may be
incomplete. This means that a restore  may have the slave serve stale
data - until it queries the master for any updates & if necessary, fixes
the journal file.  If the master happens to be down, this is especially
suboptimal.

So I would exclude both files from rsync, and use another approach to
save a coherent copy of the zone file(s) in my backup procedure.

One approach is to axfr the zone (from the slave, or any other server)
to your backup server.

You can do that directly with dig, or using a library (e.g. Perl's
Net::DNS).  Recent versions of BIND write slave zone files in a binary
format by default.  Just pipe the data through named-compilezone -F when
writing the file.  This has the advantage that it doesn't have to run on
the slave. (You can pull the data to your backup server, or push it from
a machine other than the slave.)

If you are dealing with very large files and/or a slow network link, you
may prefer to use named-compilezone -j to merge the zone & any journal
file into a temporary snapshot & back that up with rsync.  I'm not sure
how BIND's binary format interacts with rsync - it's possible that
outputting text format would be more efficient.  You'd have to benchmark
to decide.

If you restore from such a backup, you'll want to delete the journal
file to save named some work when it loads the zone.  And, of course,
make sure that named isn't running :-)  If you backup the zone in text
format, you can compile it only during restore to save time at the cost
of space.  (Backups should be frequent; restores rare.)

This assumes that your recovery strategy depends on being able to
restore the slave with the master down.

If you can assume that the master will be up (or restored first), by far
the simplest approach is not backup the zone data (file or journal) on
the slaves at all.  This is often the case, since restoring a master
tends to be higher priority than restoring slaves.  To restore, simply
start named.  If you are restoring over existing files, delete both zone
and journal files first.  Named will notice that it has no data, and
will do the axfr(s) & create the files in fairly short order.  Named
will spread the transfers of multiple zones out over time, but you'll
want to do some math to determine if the restore time and impact on your
network are acceptable.

Although you asked about slaves, note that masters have similar issues &
solutions.  Masters will also have journal files if they do dynamic
updates (including for DNSSEC).

For servers which are masters for some zones and slaves for others, the
strategy should be determined per-zone, not per server.

The bottom line: backups of databases (and DNS is a distributed
database) are complicated.  The best approach depends on the details of
your operational environment -- and not on the minutiae of BINDs
implementation.

Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 12-Nov-18 14:39, Marcus Frenkel wrote:
> Thank you for the quick reply Tony!
>
> Follow-up questions just to be sure:
> 1. The new zone file is renamed in the placed of the old one, only
> after all changes to the new file are written?
> 2. Is the zone file atomically replaced during the renaming process,
> in a sense that there is no window in which the file is empty or
> non-existent?
>
> I'm running BIND on Debian 9. Based on this
>  Linux man page,
> the rename function should be atomic. I would not imagine that BIND
> does it in different way, like the worst case scenario to first remove
> the current file and then move the new one to the same path. I know
> I'm too cautious, I'm just trying to avoid any chance for rsync to
> transfer incomplete or empty zone file, or maybe delete the file at
> the destination if it does not exist at the source for a short moment.
>
> Marcus
>
> On Mon, Nov 12, 2018 at 7:19 PM Tony Finch  > wrote:
>
> Marcus Frenkel  > wrote:
> >
> > I need to know how BIND writes to slave zone files after zone
> has been
> > updated. Does it modify the file in place or it replaces the
> file with
> > new one at once?
>
> Changes are written to a journal append-only style. Every so often the
> master file is rewritten to incorporate the contents of the
> journal; this
> is done by writing to a new file and renaming it in 

one-zone-only forwarding DNS

[Sig Pam]

Hi all!

 
I’m really despairing on a configuration, and start to wonder if it is possible 
at all.

 
Running Bind 9.5.5, I want to serve IP-Addresses for my internal network only, 
and none from the internet, except for a few domains. The idea is I don’t want 
any intranet client to be able to resolve Internet addresses, except for a few 
domains like Microsoft.com and others.

 
My named.config looks like this (shortened, copied together from multiple files 
including others):

 
acl intranet_nets {

 192.168.94.0/24;

 192.168.1.0/24;

 192.168.5.0/24;

 };

 
options {

 directory "/var/cache/bind";

 
 allow-query { localhost; intranet_nets;};

 allow-query-cache { localhost; intranet_nets;};

 
recursion no;   # switching this on would resolve ANY Internet address, which I 
don’t want

 
 dnssec-validation auto;

 
 auth-nxdomain no;    # conform to RFC1035

 listen-on-v6 { any; };

 
};

 
zone "corp.intranet.de" { 

 type master; 

 file "/etc/bind/db.corp.intranet.de";

 allow-transfer { 192.168.94.242; }; 

 allow-update { none;};

 };

 
zone "94.168.192.in-addr.arpa" { 

 type master; 

 file "/etc/bind/db.94.168.192"; 

 allow-transfer { 192.168.94.242; }; 

 allow-update { none;}; 

 };

 
zone "microsoft.com" IN {

type forward;

forwarders { 9.9.9.9; 194.150.168.168;  8.8.8.8;  8.8.4.4; }; 

};

 
 
Running this configuration, my local addresses are correctly resolved, external 
addresses not (good), but DNS-requests for the domain Microsoft.com neither 
(bad!).

 
I actually wonder if “forward” is the right keyword (is forward = answer to the 
client: “don’t ask me, ask one of the forwarders” ???), or if I’m totally on 
the wrong way.

 
Any support on how to implement this setup is highly appreciated,

 
   Sig

___
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: Common zone file, on multiple views

[Tony Finch]

Sabri MJAHED (VINC)  wrote:
>
> I dont have the -l option on the named-checkconf command.
>
> My version of bind is 9.11

Oh, it seems you need 9.12.

Your other option is to parse a zone list out of your other config files
with a bit of perl, which is what I did previously.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression
___
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: forwarder selection logic by bind9

[József Lázár]

Ok, I see. However, could you please specify this "time to time" period?
Does it depends of the dns traffic which the bind receives?
I've tried the following scenario:
Configured two dns forwarders, both of them worked at the beginning. After
one minute I turned off the first dns forwarder and after an another minute
I restarted it.
Then I sent one dns request to bind in every 1,5 second for over one hour,
but the first dns server didn't receive any request after the restart.

Thanks, Joe

On Sun, 11 Nov 2018 at 15:06, Matus UHLAR - fantomas 
wrote:

> On 10.11.18 15:59, József Lázár wrote:
> >I'm wondering what the selection logic in bind for forwarders. I tried to
> >look for this information in the official documentation but couldn't find
> >it. Could you please describe it for me briefly?
> >
> >Actually, the scenario is that I have two DNS servers and I'm using bind
> to
> >forward only the incoming DNS requests and if the "primary" one is failed
> >for a short period of time then the bind will try to use the "secondary"
> >one, but when the "primary" comes back, then it doesn't try to connect to
> >it at all, only if the connection breaks for the "secondary" server.
> >
> >Is there any way to configure this logic somehow?
>
> No. BIND technically choses server that responds faster. If one of servers
> doesn't respond (it's down), BIND uses the another one. However, time to
> time, BIND rechecks the other server(s) to see if situation has changed.
>
> BIND does not differ between servers as primary and secondary.
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
> ___
> 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: Common zone file, on multiple views

[Sabri MJAHED (VINC)]

Hi Tony,

I dont have the -l option on the named-checkconf command.

My version of bind is 9.11

Sabri.

On 12/11/2018 13:09, Tony Finch wrote:

Sabri MJAHED (VINC)  wrote:


I want to have the same zone on multiple views, but i didn't find any solution
that ease the use of this.

I have scripts that generate in-view configurations. In order to make
these scripts easier to write, I contributed the `named-checkconf -l`
feature which lists the configured zones. e.g.

named-checkconf -l | sed '
/ IN common slave/!d
s// { in-view common; };/
s/^/zone /
' > /etc/bind/in-view.conf

Tony.


___
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