special solution needed please
Hello,
I'm using BIND as a caching resolver and also a authoritative DNS server
for a '.home.arpa' local used domain;
I have two BINDs, one as a master and the other as a slave;
also two views are used, because there are some zones
e.g. 100.168.192.in-addr.arpa or some public zones that a 'rewritten'
to be solved by a local web server e.g. msftncsi.com
they are only needed on one part of the LAN or are not wanted on the
other part of the LAN
lets say the master has 2001:db8:0:0:0::10 and the slave has
2001:db8:0:0:0::1;
the named.conf looks like this:
acl part-common { // this is the ACL for the common part, where
some zones are not wanted
localhost; // or shall this be at the other acl for
special part?
2001:db8:0:0:0::1; // I thought this would be a good idea
2001:db8:0:0:0::10;
!2001:db8:0:0:0::/80; // not for the special part, but there are
the DNS-servers itself, that are common to the complete LAN
2001:db8:0:0::/64;
};
acl part-spcl { // this is the ACL for special part of the lan,
which has some extra zones, that are not wanted to be in the common part
above;
!2001:db8:0:0:0::1; // the reason above
!2001:db8:0:0:0::10;
2001:db8:0:0:0::/80; // only the special part with some extra zones
};
acl slave-dns-ip {
2001:db8:0:0:0::1;
};
masters dns-master { 2001:db8:0:0:0::10; };
view "commonpart" {
match-clients { part-common; };
...
include "lan.zones";
};
view "spclpart" {
match-clients { part-spcl; };
...
include "lan.zones";
include "extra.zones"; // here are the extra zones
};
at the master the "lan.zones" looks like this:
zone "lan.home.arpa" IN {
type master;
notify yes;
file "named.zone-lan.home.arpa";
allow-transfer { slave-dns-ip; };
allow-update { none; };
};
at the slave the "lan.zones" looks like this:
zone "lan.home.arpa" IN {
type slave;
masters { dns-master; };
file "slaves/named.zone-lan.home.arpa";
};
and now the problem
when I modify 'named.zone-lan.home.arpa' and force the transfer to the
slave - 'rndc reload',
the test if this works, fails for clients from the special part
explicitly asking the slave - why?
nslookup www.lan.home.arpa 2001:db8:0:0:0::1
works only from clients not from the special part of the LAN,
even the zone is in both views ..., a complete restart of BIND resolves
this, but this can't be, as this throws away the cached part in memory ...
nslookup www.lan.home.arpa 2001:db8:0:0:0::10
this works from any client
how can I face this?
any hints/suggestions would be great;
Thanks,
Walter
smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarded lookup failing on no valid RRSIG
On Fri, 18 Dec 2020 at 18:08, Nicolas Bock wrote: > Thanks Mark. Am I correct then that I need to either convince the > administrator of that DNS to enable DNSSEC or configure my DNS with > `dnssec-validation = no`? > The upstream administrator isn't required to be validating DNSSEC for this to work, but in order for your DNS server to do DNSSEC validation, their DNS server must be DNSSEC aware enough to be requesting DNSSEC data when it queries the authoritative DNS servers. Of course, the resilience of the whole thing would also be improved by that server also validating. If they can't or won't update their server, then yes, you'll either have to disable validation yourself, or select a better upstream. Personally I'd go looking for a better upstream (or just stop using a forwarder entirely, and do your own direct recursion, if that's possible in your environment). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarded lookup failing on no valid RRSIG
> On 21 Dec 2020, at 06:04, Matthew Pounsett wrote: > > > > On Fri, 18 Dec 2020 at 18:08, Nicolas Bock wrote: > Thanks Mark. Am I correct then that I need to either convince the > administrator of that DNS to enable DNSSEC or configure my DNS with > `dnssec-validation = no`? > > The upstream administrator isn't required to be validating DNSSEC for this to > work, but in order for your DNS server to do DNSSEC validation, their DNS > server must be DNSSEC aware enough to be requesting DNSSEC data when it > queries the authoritative DNS servers. Of course, the resilience of the > whole thing would also be improved by that server also validating. Matthew, there is a difference between sometimes getting answers out of a forwarder that isn’t validating that validate and a system that is working. If the forwarder is not validating then the system cannot recover from situations that a iterative validating resolver can recover from. It is bad advice to deploy validating clients behind forwarders that are not validating. > If they can't or won't update their server, then yes, you'll either have to > disable validation yourself, or select a better upstream. Personally I'd go > looking for a better upstream (or just stop using a forwarder entirely, and > do your own direct recursion, if that's possible in your environment). -- 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
issue with domain forwarding
Hi, Just to let everyone know that I have solved my issue by upgrading to bind-9.16.10. It is working fine now. -- sysadm cronomagic.com e-mail ve2...@canasoft.net POWERED BY LINUX ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: special solution needed please
Firstly, read your logs, they will most probably tell you what is going wrong.
Secondly, use TSIG between primary and secondary to select views for zone
transfers. It is much more reliable.
Thirdly, errors are almost always typos. Using the documentation prefix hides
these. You are not writing documentation, you are asking for help with your
system. Show the real configuration details.
> On 20 Dec 2020, at 22:27, Walter H. wrote:
>
> Hello,
>
> I'm using BIND as a caching resolver and also a authoritative DNS server for
> a '.home.arpa' local used domain;
>
> I have two BINDs, one as a master and the other as a slave;
> also two views are used, because there are some zones
>
> e.g. 100.168.192.in-addr.arpa or some public zones that a 'rewritten' to be
> solved by a local web server e.g. msftncsi.com
>
> they are only needed on one part of the LAN or are not wanted on the other
> part of the LAN
>
> lets say the master has 2001:db8:0:0:0::10 and the slave has
> 2001:db8:0:0:0::1;
>
> the named.conf looks like this:
>
> acl part-common { // this is the ACL for the common part, where some
> zones are not wanted
> localhost; // or shall this be at the other acl for special
> part?
> 2001:db8:0:0:0::1; // I thought this would be a good idea
> 2001:db8:0:0:0::10;
> !2001:db8:0:0:0::/80; // not for the special part, but there are the
> DNS-servers itself, that are common to the complete LAN
> 2001:db8:0:0::/64;
> };
>
> acl part-spcl { // this is the ACL for special part of the lan, which has
> some extra zones, that are not wanted to be in the common part above;
> !2001:db8:0:0:0::1; // the reason above
> !2001:db8:0:0:0::10;
> 2001:db8:0:0:0::/80; // only the special part with some extra zones
> };
>
> acl slave-dns-ip {
> 2001:db8:0:0:0::1;
> };
>
> masters dns-master { 2001:db8:0:0:0::10; };
>
> view "commonpart" {
> match-clients { part-common; };
> ...
> include "lan.zones";
> };
>
> view "spclpart" {
> match-clients { part-spcl; };
> ...
> include "lan.zones";
> include "extra.zones"; // here are the extra zones
> };
>
> at the master the "lan.zones" looks like this:
>
> zone "lan.home.arpa" IN {
> type master;
> notify yes;
> file "named.zone-lan.home.arpa";
> allow-transfer { slave-dns-ip; };
> allow-update { none; };
> };
>
> at the slave the "lan.zones" looks like this:
>
> zone "lan.home.arpa" IN {
> type slave;
> masters { dns-master; };
> file "slaves/named.zone-lan.home.arpa";
> };
>
> and now the problem
>
> when I modify 'named.zone-lan.home.arpa' and force the transfer to the slave
> - 'rndc reload',
> the test if this works, fails for clients from the special part explicitly
> asking the slave - why?
You haven’t shown the slaves configuration. You have only show that of the
zone lan.home.arpa. The configuration is much more than that.
> nslookup www.lan.home.arpa2001:db8:0:0:0::1
> works only from clients not from the special part of the LAN,
> even the zone is in both views ..., a complete restart of BIND resolves this,
> but this can't be, as this throws away the cached part in memory ...
>
> nslookup www.lan.home.arpa2001:db8:0:0:0::10
> this works from any client
>
> how can I face this?
>
> any hints/suggestions would be great;
>
> Thanks,
> Walter
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> 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
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
