Re: DNS view "passthrough" and caching

[Mark Andrews]

In message <24234.1481320...@vindemiatrix.encs.concordia.ca>, Anne Bennett 
writes:
> 
> Mark Andrews  answers "Vladimir-M. Obelic" :
> 
> > Use 'zone "zonename" { in-view "namename"; };' and have all zones
> > that the view answers for be in that view.  "in-view" was introduced
> > in BIND 9.10.0.  Configure the zone (master/slave) in the first
> > view it appears in.
> 
> In that scenario, could one define the first view to match
> no clients but contain all the needed zones, then in each
> subsequent ("real") view, use the in "in-view" construct to
> pull in the zones appropriate for that view?

Yes.

> Anne.
> -- 
> Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 
> 1M8
> a...@encs.concordia.ca+1 514 848-2424 
> x2285
> ___
> 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: DNS view "passthrough" and caching

[Anne Bennett]

Mark Andrews  answers "Vladimir-M. Obelic" :

> Use 'zone "zonename" { in-view "namename"; };' and have all zones
> that the view answers for be in that view.  "in-view" was introduced
> in BIND 9.10.0.  Configure the zone (master/slave) in the first
> view it appears in.

In that scenario, could one define the first view to match
no clients but contain all the needed zones, then in each
subsequent ("real") view, use the in "in-view" construct to
pull in the zones appropriate for that view?


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
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: DNS view "passthrough" and caching

[Mark Andrews]

Use 'zone "zonename" { in-view "namename"; };' and have all zones
that the view answers for be in that view.  "in-view" was introduced
in BIND 9.10.0.  Configure the zone (master/slave) in the first
view it appears in.

view "view1" {
...

zone "example.com" {
...
};
};

view "view2" {
...

zone "example.com" {
in-view "view1";
};

zone "zone.com" {
...
}
};

For earlier versions of named transfer the zones between views.  If
you are supposed to be authoritative for a zone then it needs to
be configured in all appropriate views.  Remember to keep the file
names seperate.

Mark

In message 
, 
"Vladimir-M. Obelic" writes:
> Hello,
> 
> 
> I have two views configured, default (where the clients are first
> matched or denied) and view2 where only some clients should match
> (after being denied in default view match).
> 
> Only one zone "zone.com" is defined in view2, whereas default view has
> all the other zones including "zone.com" and "example.com".
> I've setup view2 with forwarders { localhost; } so that all other
> queries "fall through" to the default view so that other zones can be
> resolved.
> 
> Everything works as expected, except the caching issue.
> I.e. I update the "example.com" zone in the default view but clients
> that are matched in the view2 see the cached RRs for "example.com"
> zone.
> I guess this is because bind acts as a client to itself when the query
> gets forwarded to localhost from view2.
> Workaround is to exec rndc flushname example.com after i've updated the zone.
> Not pretty since i'd have to do it on master and all slaves.
> 
> Is there a way to prevent caching in this scenario?
> 
> Thanks!
> 
> BR,
> Vladimir
> ___
> 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

DNS view "passthrough" and caching

[Vladimir-M. Obelic]

Hello,


I have two views configured, default (where the clients are first
matched or denied) and view2 where only some clients should match
(after being denied in default view match).

Only one zone "zone.com" is defined in view2, whereas default view has
all the other zones including "zone.com" and "example.com".
I've setup view2 with forwarders { localhost; } so that all other
queries "fall through" to the default view so that other zones can be
resolved.

Everything works as expected, except the caching issue.
I.e. I update the "example.com" zone in the default view but clients
that are matched in the view2 see the cached RRs for "example.com"
zone.
I guess this is because bind acts as a client to itself when the query
gets forwarded to localhost from view2.
Workaround is to exec rndc flushname example.com after i've updated the zone.
Not pretty since i'd have to do it on master and all slaves.

Is there a way to prevent caching in this scenario?

Thanks!

BR,
Vladimir
___
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