Re: How to validate SRV record?
On Fri, Aug 24, 2012 at 8:38 PM, Kevin Darcy wrote: > Fine, the validator would confirm that the SRV's owner name is compliant > with RFC 6335, no more, no less. You seem to completely ignore the idea of non-standard, locally defined services, but they really exist and are used. If you insist on only registered services, BIND will no longer work for those and they are explicitly allowed by RFC2782 and people expect them to continue to work. RFC635 clearly states that service names SHOULD be registered with IANA, but any enterprise using a locally developed and quite possibly proprietary service is quite unlikely to register it or want to do so. After all, it would serve no purpose at all, even if the SRV records were used between enterprise facilities over the wider Internet. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: How to validate SRV record?
Fine, the validator would confirm that the SRV's owner name is compliant with RFC 6335, no more, no less. - Kevin On 8/23/2012 7:01 PM, Doug Barton wrote: On 8/23/2012 3:49 PM, Kevin Darcy wrote: Sorry, I meant to say that it's pretty clear that it *restricts* what a Service Label may contain. It's even a "MUST". Sure, but you're omitting the (typically unstated) part of the MUST, "a compliant implementation." So it depends on the OP's purpose. Is it to "validate" what will work on the wire, or to validate what is likely to be accepted outside of their organization? There are a non-zero number of special-purpose SRV records in use that aren't related to published service names. Where do you draw the line? Doug ___ 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: Zone Transfer issue on BIND9
- Original Message
Da: Jeremy C. Reed
To:
Cc: bind-users@lists.isc.org
Oggetto: Re: Zone Transfer issue on BIND9
Data: 24/08/12 15:39
>
>
>
> On Fri, 24 Aug 2012, sn...@email.it wrote:
>
> > view "internal" {
>
> ...
> > zone "1.16.172.in-addr.arpa" IN {
> > type master;
> > file
"/etc/namedb/master/1.16.172.in-addr.arpa.ext.zone";
>
> Previous zone file names in this same view were called "int". Why the
> filename change? (ext means "external" even though in the internal
> view?)
>
You're right. It is a bit misleading but it is as such also because I've
already shrunk the configuration file consistently already. It's marked as
"ext" because that IP range is geographically somewhere else ... reachable
via VPN tunnelling. Which makes it basically internal even though it has
been called as such just for practical reasons (to remind me that the
network is not "here"). That's why it's in the "internal" view. Perhaps
another abbreviation would have been more appropriate.
> > ***SLAVE server (FreeBSD 9.0-RELEASE-p3 (amd64)|| BIND 9.8.1-P1)***
>
> > key TSIG-KEY. {
> ...
>
> > allow-notify { 171.XX.YY.27; 10.0.0.15; };
>
> > listen-on { 171.XX.YY.27; 127.0.0.1; };
>
> Is the allow-notify 171.XX.YY.27 address same as the listen-on
> 171.XX.YY.27 address? This is confusing as the allow-notify is a
> different server and listen-on is this server.
>
True that.
I've put that IP address there as a test yesterday (or the day before) I
believe because I was having a problem in the logs showing the following
message:
"refused notify from non-master: 171.XX.YY.27#52860"
Problem that I've fixed in this way, putting the IP address of the server
itself in the allow-notify field along with the IP address of the master
one. Not sure that's a fix or a workaround, but I don't think that might
cause harm anyhow. Of course I might be wrong. :)
> > view "internal" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
> What defines that TSIG-KEY? Notice it doesn't have the trailing period
> "TSIG-KEY." as defined earlier.
>
> From your later email:
>
> > Files are identical within the DOMAIN, not the VIEW.
> > For example, on the slave server:
> > DOMAIN01.eu.int.zone
> > DOMAIN01.eu.ext.zone
> >
> > are exactly the same (also same checksum)
>
> Are they a copy of the internal or external view's zone on the master?
>
I apologise. The trailing period got lost during the name substitution with
vi. It's just a "typo". In normal config there's not such a thing.
Basically if I've the directive "!key TSIG-KEY." in the match-client field,
all affected files get the content of the external view's zone. If there's
"key TSIG-KEY." instead I've got all the affected files with the internal
view's zone.
> It is a little difficult to follow the configuration when using maybe
> fake IP addresses, fake zone names, and fake filenames. You may want to
> simplify your named.conf to bare minimum (two views and one zone each)
> for initial testing.
It is.
But the only things that I've changed are the public IP addresses and the
domain names which affect also file names and the TSIG name.
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte last minute Rimini, Riccione, Cattolica e Misano negli hotel per
famiglie con pacchetti tutto compreso per le vacanze al mare con bambini.
Animazione e servizio spiaggia
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12534&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte hotel + parco per pacchetti con ingresso incluso ai parchi
divertimento della romagna, negli hotel Rimini, Riccione, Cattolica e Misano
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12536&d=24-8
___
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: Zone Transfer issue on BIND9
On Fri, 24 Aug 2012, sn...@email.it wrote:
> view "internal" {
...
> zone "1.16.172.in-addr.arpa" IN {
> type master;
> file "/etc/namedb/master/1.16.172.in-addr.arpa.ext.zone";
Previous zone file names in this same view were called "int". Why the
filename change? (ext means "external" even though in the internal
view?)
> ***SLAVE server (FreeBSD 9.0-RELEASE-p3 (amd64)|| BIND 9.8.1-P1)***
> key TSIG-KEY. {
...
> allow-notify { 171.XX.YY.27; 10.0.0.15; };
> listen-on { 171.XX.YY.27; 127.0.0.1; };
Is the allow-notify 171.XX.YY.27 address same as the listen-on
171.XX.YY.27 address? This is confusing as the allow-notify is a
different server and listen-on is this server.
> view "internal" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
What defines that TSIG-KEY? Notice it doesn't have the trailing period
"TSIG-KEY." as defined earlier.
>From your later email:
> Files are identical within the DOMAIN, not the VIEW.
> For example, on the slave server:
> DOMAIN01.eu.int.zone
> DOMAIN01.eu.ext.zone
>
> are exactly the same (also same checksum)
Are they a copy of the internal or external view's zone on the master?
It is a little difficult to follow the configuration when using maybe
fake IP addresses, fake zone names, and fake filenames. You may want to
simplify your named.conf to bare minimum (two views and one zone each)
for initial testing.
___
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: Zone Transfer issue on BIND9
Unfortunately that cannot be the root cause because (as stated in my first
email) I've also tried to remove completely the dmz view from both servers
leaving just the internal and the external one. And I had the same issue
still.
But as I've just wrote a minute ago I've made a mistake in my first
description of the issue.
Files are identical within the DOMAIN, not the VIEW.
For example, on the slave server:
DOMAIN01.eu.int.zone
DOMAIN01.eu.ext.zone
are exactly the same (also same checksum)
so the other zone files of the same domains are:
DOMAIN02.net.int.zone
DOMAIN02.net.ext.zone
and so on.
Thanks.
- Original Message
Da: Jeremy C. Reed
To:
Cc: bind-users@lists.isc.org
Oggetto: Re: Zone Transfer issue on BIND9
Data: 24/08/12 14:43
>
>
>
> On Fri, 24 Aug 2012, sn...@email.it wrote:
>
> > ***MASTER server (FreeBSD 9.0-RELEASE-p3 (i386)|| BIND 9.8.3-P2)***
>
> > view "internal" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
> ...
>
> > view "dmz" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
>
> A client request will be resolved in the context of the first view that
> it matches. The above match-clients are identical for different views so
> the dmz view is not used.
>
>
> > ***SLAVE server (FreeBSD 9.0-RELEASE-p3 (amd64)|| BIND 9.8.1-P1)***
>
> > view "internal" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
> > view "dmz" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
>
>
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte all inclusive in Romagna.Speciale Agosto da Euro 480,00 Speciale
Settembre da Euro 295,00. Terzo letto Gratis e Quarto scontato al 50%
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12545&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte settimana benessere con i pacchetti terme degli hotel della riviera
romagnola. Rimini, Riccione, Cattolica e Misano. Chiama lo 0541607636 Consorzio
Costahotels
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12533&d=24-8
___
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: Zone Transfer issue on BIND9
I believe I did specify how: "The main issue is that all my zones get
transferred to the slave properly but all the files related to the same view
are identical.". But I've realised I've not explained it properly.
My issue is that files transferred on the slave are identical but within
DOMAINS, not VIEWS. I apologise for my mistake.
For example, on the slave:
DOMAIN01.eu.int.zone
DOMAIN01.eu.ext.zone
are identical just as like as the other internal/external zone files for the
other domains.
Anyway, another user pointed me to the fact that I've used the
allow-transfer at the zone level, not at the view level.
That might be a good start.
I'm gonna try that ASAP as a start. Any other idea is more than welcome.
Thanks in advance for your time Phil.
- Original Message
Da: Phil Mayers
To: bind-users@lists.isc.org
Oggetto: Re: Zone Transfer issue on BIND9
Data: 24/08/12 13:41
>
>
>
> On 24/08/12 12:09, sn...@email.it wrote:
> > Hi there,
> > I have an issue related to zone transfer which I couldn't fix. I've
found a
> > "presumable" fix googling a lot but it doesn't seem to work.
>
> You haven't said *how* it isn't working. Be specific.
>
> Note that the FAQ link you reference puts the "server {}" block INSIDE
> the view. You have it in the global config. That seems like something to
> investigate.
> ___
> 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
>
>
>
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte all inclusive in Romagna. Speciale Agosto da Euro 480,00 Speciale
Settembre da Euro 295. Terzo letto Gratis e Quarto scontato al 50%
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12596&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte last minute Rimini, Riccione, Cattolica e Misano negli hotel per
famiglie con pacchetti tutto compreso per le vacanze al mare con bambini.
Animazione e servizio spiaggia
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12534&d=24-8
___
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: Zone Transfer issue on BIND9
On Fri, 24 Aug 2012, sn...@email.it wrote:
> ***MASTER server (FreeBSD 9.0-RELEASE-p3 (i386)|| BIND 9.8.3-P2)***
> view "internal" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
...
> view "dmz" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
A client request will be resolved in the context of the first view that
it matches. The above match-clients are identical for different views so
the dmz view is not used.
> ***SLAVE server (FreeBSD 9.0-RELEASE-p3 (amd64)|| BIND 9.8.1-P1)***
> view "internal" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
> view "dmz" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
___
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: Zone Transfer issue on BIND9
Hi, thanks for replying,
I'll try to use the allow-transfer at the view level. Never tried that, not
even sure it works. But I'll try.
About the IP, according to my understanding, it was necessary to use
different IPs (virtual or not) on BIND prior version 9.3.
- Original Message
Da: Lightner Jeff
To: Phil Mayers , bind-users@lists.isc.org
Oggetto: RE: Zone Transfer issue on BIND9
Data: 24/08/12 14:16
>
>
>
> You're putting the allow transfer on each zone? I don't think that's
your issue but it seems odd to me. Here we do it at the view level.
>
> Also it appears you're using the same IP for at least two of your views -
for view transfers to work properly here we setup virtual IPs on the DNS
servers and set the ACLs appropriately.
> i.e. our "real" IPs are in the ACL we used prior to setting up views and
are now only used for the main [external] view and we have different ACLs
for the virtual IPs used within the internal view.
>
>
>
>
>
> -Original Message-
> From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of
Phil Mayers
> Sent: Friday, August 24, 2012 7:41 AM
> To: bind-users@lists.isc.org
> Subject: Re: Zone Transfer issue on BIND9
>
> On 24/08/12 12:09, sn...@email.it wrote:
> > Hi there,
> > I have an issue related to zone transfer which I couldn't fix. I've
> > found a "presumable" fix googling a lot but it doesn't seem to work.
>
> You haven't said *how* it isn't working. Be specific.
>
> Note that the FAQ link you reference puts the "server {}" block INSIDE the
view. You have it in the global config. That seems like something to
investigate.
> ___
> 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
>
>
>
>
> Athena(r), Created for the Cause(tm)
> Making a Difference in the Fight Against Breast Cancer
>
> -
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you
have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Thank you.
> --
>
> ___
> 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
>
>
>
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte all inclusive in Romagna. Speciale Agosto da Euro 480,00 Speciale
Settembre da Euro 295. Terzo letto Gratis e Quarto scontato al 50%
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12601&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte settimana benessere con i pacchetti terme degli hotel della riviera
romagnola. Rimini, Riccione, Cattolica e Misano. Chiama lo 0541607636 Consorzio
Costahotels
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12533&d=24-8
___
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: Zone Transfer issue on BIND9
You're putting the allow transfer on each zone? I don't think that's your
issue but it seems odd to me. Here we do it at the view level.
Also it appears you're using the same IP for at least two of your views - for
view transfers to work properly here we setup virtual IPs on the DNS servers
and set the ACLs appropriately.
i.e. our "real" IPs are in the ACL we used prior to setting up views and are
now only used for the main [external] view and we have different ACLs for the
virtual IPs used within the internal view.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Phil
Mayers
Sent: Friday, August 24, 2012 7:41 AM
To: bind-users@lists.isc.org
Subject: Re: Zone Transfer issue on BIND9
On 24/08/12 12:09, sn...@email.it wrote:
> Hi there,
> I have an issue related to zone transfer which I couldn't fix. I've
> found a "presumable" fix googling a lot but it doesn't seem to work.
You haven't said *how* it isn't working. Be specific.
Note that the FAQ link you reference puts the "server {}" block INSIDE the
view. You have it in the global config. That seems like something to
investigate.
___
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
Athena(r), Created for the Cause(tm)
Making a Difference in the Fight Against Breast Cancer
-
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
--
___
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: Zone Transfer issue on BIND9
On 24/08/12 12:09, sn...@email.it wrote:
Hi there,
I have an issue related to zone transfer which I couldn't fix. I've found a
"presumable" fix googling a lot but it doesn't seem to work.
You haven't said *how* it isn't working. Be specific.
Note that the FAQ link you reference puts the "server {}" block INSIDE
the view. You have it in the global config. That seems like something to
investigate.
___
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
Zone Transfer issue on BIND9
7.172.in-addr.arpa.ssl-vpn.zone";
masters { 10.0.0.15; };
};
zone "2.17.172.in-addr.arpa" {
type slave;
file "/etc/namedb/slave/2.17.172.in-addr.arpa.dmz.zone";
masters { 10.0.0.15; };
};
zone "YY.XX.171.in-addr.arpa" {
type slave;
file
"/etc/namedb/slave/YY.XX.171.in-addr.arpa.masterdc.zone";
masters { 10.0.0.15; };
};
/ SECURITY BLOCK /
...
OMITTED
...
};
view "dmz" {
match-clients { !key TSIG-KEY; internal; datacentre; };
recursion yes;
allow-query { dmz; };
zone "DOMAIN01.eu" {
type slave;
file "/etc/namedb/slave/DOMAIN01.eu.dmz.zone";
masters { 10.0.0.15; };
};
zone "2.17.172.in-addr.arpa" {
type slave;
file "/etc/namedb/slave/2.17.172.in-addr.arpa.dmz.zone";
masters { 10.0.0.15; };
};
/ SECURITY BLOCK /
...
OMITTED
...
};
view "external" {
match-clients { key TSIG-KEY.; internal; datacentre; };
allow-query { any; };
zone "DOMAIN01.eu" {
type slave;
file "/etc/namedb/slave/DOMAIN01.eu.ext.zone";
masters { 10.0.0.15; };
};
zone "DOMAIN02.net" {
type slave;
file "/etc/namedb/slave/DOMAIN02.net.ext.zone";
masters { 10.0.0.15; };
};
zone "DOMAIN03.net" {
type slave;
file "/etc/namedb/slave/DOMAIN03.net.ext.zone";
masters { 10.0.0.15; };
};
zone "YY.XX.171.in-addr.arpa" {
type slave;
file "/etc/namedb/slave/YY.XX.171.in-addr.arpa.ext.zone";
masters { 10.0.0.15; };
};
/ SECURITY BLOCK /
...
OMITTED
...
};
logging {
...
OMITTED
...
};
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte all inclusive in Romagna. Speciale Agosto da Euro 480,00 Speciale
Settembre da Euro 295. Terzo letto Gratis e Quarto scontato al 50%
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12601&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte all inclusive in Romagna.Speciale Agosto da Euro 480,00 Speciale
Settembre da Euro 295,00. Terzo letto Gratis e Quarto scontato al 50%
*
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12546&d=24-8
___
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: Static-stub zones and forwarding
-Original Message-
From: Mark Picone
Date: Thursday, August 23, 2012 10:45 PM
To: "bind-users@lists.isc.org"
Subject: Static-stub zones and forwarding
>Hi All,
>
>I am in the process of migrating all of our client facing resolver hosts
>back to BIND (from unbound) and have hit a roadblock.
>I wanted to confirm if I have missed something in my BIND configuration
>or I have hit some sort of limitation in BIND.
>
>It appears as if BIND is ignoring the static-stub zone and just
>forwarding all queries to the specified forwarders.
>
>The reason that I require a static-stub and not a forward zone is that
>our internal name servers have delegated zones (to Cisco GSS/F5 devices)
>which return site-specific answers; If I allow the client facing
>resolvers to recursively query the internal name servers I will get back
>the site-specific answer for the internal name server instead of the
>client facing resolver.
>Using a static-stub zone forces the client facing resolver to use
>iterative queries which will eventually lead it to query the Cisco GSS/F5
>device for itself.
Going out on a limb (we have something similar, but there might be small
implementation details that are different) -- have you tried making master
zones vs stubs, where you can use forwarders {}; to override the global
list, and then place NS delegations and glue pointing to the GSS/F5
devices?
___
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
