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

Comments on Root Key Rollover impact on BIND users

[Victoria Risk]

You all are probably aware of the plans for rolling the root dnssec key in 
2017.  ICANN is trying to ensure this goes smoothly and we are of course 
looking for ways ISC can help.

There is a draft blog post on the topic of the 2017 Root Key Rollover, kind of 
hidden on ISC’s web site here: 
https://www.isc.org/blogs/2017-root-key-rollover-what-does-it-mean-for-bind-users/
 

   We had to turn off comments on the web site because the spam was out of 
hand, but I welcome corrections, examples, or further suggestions from 
bind-users and will add them to the blog.

Towards the end of the blog, there is a short list of possible ‘corner cases’ 
that could trip people up during the rollover.  If you folks can think of 
others, please do share them.  ISC’s BIND test engineer, Curtis, is planning a 
thorough test of the BIND support for the root dnssec key rollover in 2017 Q1 
and he would appreciate any input into the test plan.

Please either post discussion here or unicast to vi...@isc.org 
 or c...@isc.org . 

Thank you,

Vicky Risk
Product Manager, 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: delegation broken after migrating to new BIND config

[Bob Harold]

On Thu, Dec 8, 2016 at 11:09 PM, blrmaani  wrote:

> I migrated our bind resolvers to a new config (new named.conf) and I see
> delegation broken. How do I trouble-shoot?
>
> - The resolvers (are slaves) and are authoritative for zone1.example.com
> and example.com
> - the resolvers forward queries to our companies DNS to resolve external
> names like microsoft.com, isc.com etc
> - The resolver has views and match same destinations in both old and new
> config.
>
>
>
> the zone is zone1.example.com which contains a record
> name1.zone1.example.com as below:
> name1.zone1.example.com. NS othername1.example.com.
> othername1.example.com.A   1.2.3.4
>
>
> dig @localhost  name1.zone1.example.com.  # this doesn't give any hint.
>
> Here are the steps I tried and still no luck:
>
> 1. Compared zone transfer output of zone1.example.com before and after
> migration, both look similar and contains delegation entry.
>
> 2. I tried this and works ok (before and after migration) in both cases
> indicating that the NS
> is still reachable and respond to DNS queries before and after
> migration.
>
> dig @othername1.example.com.  name1.zone1.example.com.
> ## Returns 5.6.7.8 as expected  ACLs broken
>
>
> 3. Checked cache dump file (db file) - I see the following entry when it
> works (pre-migration):
> cache_dump.db:; 1.2.3.4  [srtt 0] [flags ] [ttl 1797]
>
> however, the above entry is missing after I migrate to new BIND config.
>
>
> I compared the BIND configs before and after migration and I don't see any
> significant difference which might cause this issue.. wondering what am I
> missed?
>
> Thanks
> Blr
>

Looks to me like "othername1.example.com" is not in the zone "
zone1.example.com" and is not below that zone, so it is not proper glue,
and should not be in that zone at all.  The name server should ignore it.
It is in zone "example.com " and that zone
should be queried to find it.

-- 
Bob Harold
___
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