Re: Re: Re: zone not loaded in one of view

[liudonghua]

Hi,



I do have two `named`, one is original /usr/sbin/named installed via `yum 
install bind bind-utils` a few years ago, and another /usr/local/sbin/named 
which I build from source.

I did not remember when the jnl file generated, maybe in the first run of new 
named, I never saw jnl file in the past. When I using the older named, 
/etc/named.data/db.ynu.edu.cn.intranet always got updated unexpected, detailed 
information is on Zone file got updated via named process unexpected (isc.org), 
so I update the named, but this problem still exists. After I make some changes 
to named.conf like disable DNSSEC or DLV or something else manually or 
explicitly. The file not changed anymore, but resulted in `zone not loaded`.

Now I removed the jnl file and it worked well now.

[root@pridns ~]# /usr/sbin/named -v
BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.15 (Extended Support Version) 

[root@pridns ~]# /usr/local/sbin/named -v
BIND 9.18.20 (Extended Support Version) 
[root@pridns ~]#
[root@pridns ~]# ll ~/db.ynu.edu.cn.intranet.jnl 
/etc/named.data/db.ynu.edu.cn.intranet

-rw-r--r-- 1 root  root  1.3K Dec 16 16:00 
/etc/named.data/db.ynu.edu.cn.intranet
-rw-r--r-- 1 named named 1.1K Dec 15 17:48 /root/db.ynu.edu.cn.intranet.jnl
[root@pridns ~]#






2023-12-19 16:43:36 "Greg Choules"  写道：
Hi.
The existence of a `.jnl` file for the zone means that, at some point in the 
past anyway, you *did* allow dynamic updates to this zone and some updates were 
made, which were stored in the journal file.


I would like to ask a couple of questions:
1) What is the timeline of your investigation? Map out file creation and 
modification dates and times along with log messages and times you made changes 
to see if you can build a picture of what actually happened when.
2) How many instances of 'named' are running on this server? I have seen in the 
past people have two or more 'named' processes running that they were not aware 
of, which *might* cause problems if they are trying to use the same data files.


Cheers, Greg


On Tue, 19 Dec 2023 at 08:26,  wrote:

I found there was a db.ynu.edu.cn.intranet.jnl beside db.ynu.edu.cn.intranet, I 
tried to remove it, then restarted and checked the new cache_dump.db, no `zone 
not loaded` anymore.

For the original problem, because I modified serial of SOA and updated bind9 to 
the latest version, it could not reproduce. Maybe it's also the similar issue, 
but in the older bind 9.11, no jnl file generated via named.





2023-12-17 15:47:43 "Mark Andrews"  写道：
Read your logs and/or use named-checkzone and/or tell name-checkconf to load 
the zones. 


-- 
Mark Andrews

On 17 Dec 2023, at 15:22, liudong...@ynu.edu.cn wrote:


Hi, I have a bind9 authoritative name server running, but I found a strange 
problem. One of zone in a specific view not loaded when I view the 
cache_dump.db after I execute `rndc dumpdb -all`.


The zone data file is almost the same for difference views execpted some few 
domain resolution.


[root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.cernet
$TTL 86400  ; 1 day
@   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
2023121601;   serial number
10800   ;   Refresh interval, every 3 hours
3600;   Retry interval, every 30 minutes 
604800  ;   Expire after 1 week
86400 ) ;Minimum TTL of 1 day


$INCLUDE /etc/named.data/db.ynu.edu.cn.common




; RR of type A
; 
vpn110800   IN  A   113.55.110.251
; 
lb-http-jz  IN  A   113.55.14.52
ynucdn  600 IN  A   202.203.208.4
; 
vpn2IN  A   202.203.208.9


[root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.intranet
$TTL 86400  ; 1 day
@   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
2023121601;   serial number
10800   ;   Refresh interval, every 3 hours
3600;   Retry interval, every 30 minutes 
604800  ;   Expire after 1 week
86400 ) ;Minimum TTL of 1 day


$INCLUDE /etc/named.data/db.ynu.edu.cn.common




; RR of type A
; 
lb-http-jz  IN  A   113.55.14.52
; 
vpn110800   IN  A   192.168.208.3
ynucdn  600 IN  A   202.203.208.4
; 
vpn2IN  A   202.203.208.9


[root@pridns data]#
[root@pridns data]# named-checkconf /etc/named.conf
[root@pridns data]# echo $?
0
[root@pridns data]# 
[root@pridns data]# rndc zonestatus ynu.edu.cn in CERNET
name: ynu.edu.cn
type: primary
files: db.ynu.edu.cn.cernet, /etc/named.data/db.ynu.edu.cn.common
serial: 2023121601
nodes: 576
last loaded: Sat, 16 Dec 2023 08:00:49 GM

Re: Re: zone not loaded in one of view

[Greg Choules via bind-users]

Hi.
The existence of a `.jnl` file for the zone means that, at some point in
the past anyway, you *did* allow dynamic updates to this zone and some
updates were made, which were stored in the journal file.

I would like to ask a couple of questions:
1) What is the timeline of your investigation? Map out file creation and
modification dates and times along with log messages and times you made
changes to see if you can build a picture of what actually happened when.
2) How many instances of 'named' are running on this server? I have seen in
the past people have two or more 'named' processes running that they were
not aware of, which *might* cause problems if they are trying to use the
same data files.

Cheers, Greg

On Tue, 19 Dec 2023 at 08:26,  wrote:

> I found there was a db.ynu.edu.cn.intranet.jnl beside db.ynu.edu.cn.intranet, 
> I tried to remove it, then restarted and checked the new cache_dump.db, no 
> `zone not loaded` anymore.
>
> For the original problem, because I modified serial of SOA and updated bind9 
> to the latest version, it could not reproduce. Maybe it's also the similar 
> issue, but in the older bind 9.11, no jnl file generated via named.
>
>
>
>
> 2023-12-17 15:47:43 "Mark Andrews"  写道：
>
> Read your logs and/or use named-checkzone and/or tell name-checkconf to
> load the zones.
>
> --
> Mark Andrews
>
> On 17 Dec 2023, at 15:22, liudong...@ynu.edu.cn wrote:
>
> Hi, I have a bind9 authoritative name server running, but I found a
> strange problem. One of zone in a specific view not loaded when I view the
> cache_dump.db after I execute `rndc dumpdb -all`.
>
>
> The zone data file is almost the same for difference views execpted some
> few domain resolution.
>
>
> [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.cernet
> $TTL 86400  ; 1 day
> @   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
> 2023121601;   serial number
> 10800   ;   Refresh interval, every 3 hours
> 3600;   Retry interval, every 30
> minutes
> 604800  ;   Expire after 1 week
> 86400 ) ;Minimum TTL of 1 day
>
>
> $INCLUDE /etc/named.data/db.ynu.edu.cn.common
>
>
>
>
> ; RR of type A
> ;
> vpn110800   IN  A   113.55.110.251
> ;
> lb-http-jz  IN  A   113.55.14.52
> ynucdn  600 IN  A   202.203.208.4
> ;
> vpn2IN  A   202.203.208.9
>
>
> [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.intranet
> $TTL 86400  ; 1 day
> @   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
> 2023121601;   serial number
> 10800   ;   Refresh interval, every 3 hours
> 3600;   Retry interval, every 30
> minutes
> 604800  ;   Expire after 1 week
> 86400 ) ;Minimum TTL of 1 day
>
>
> $INCLUDE /etc/named.data/db.ynu.edu.cn.common
>
>
>
>
> ; RR of type A
> ;
> lb-http-jz  IN  A   113.55.14.52
> ;
> vpn110800   IN  A   192.168.208.3
> ynucdn  600 IN  A   202.203.208.4
> ;
> vpn2IN  A   202.203.208.9
>
>
> [root@pridns data]#
> [root@pridns data]# named-checkconf /etc/named.conf
> [root@pridns data]# echo $?
> 0
> [root@pridns data]#
> [root@pridns data]# rndc zonestatus ynu.edu.cn in CERNET
> name: ynu.edu.cn
> type: primary
> files: db.ynu.edu.cn.cernet, /etc/named.data/db.ynu.edu.cn.common
> serial: 2023121601
> nodes: 576
> last loaded: Sat, 16 Dec 2023 08:00:49 GMT
> secure: no
> dynamic: no
> reconfigurable via modzone: no
> [root@pridns data]#
> [root@pridns data]# rndc zonestatus ynu.edu.cn in INTRANET
> rndc: 'zonestatus' failed: zone not loaded
> [root@pridns data]#
> [root@pridns data]# named-checkzone ynu.edu.cn
> /etc/named.data/db.ynu.edu.cn.intranet
> zone ynu.edu.cn/IN: loaded serial 2023121601
> OK
> [root@pridns data]#
> [root@pridns data]# ll /etc/named.data/db.ynu.edu.cn.cernet
> /etc/named.data/db.ynu.edu.cn.intranet
> -rw-r--r-- 1 root root 1.3K Dec 16 16:00
> /etc/named.data/db.ynu.edu.cn.cernet
> -rw-r--r-- 1 root root 1.3K Dec 16 16:00
> /etc/named.data/db.ynu.edu.cn.intranet
> [root@pridns data]#
>
>
> And here is parts of content in /var/named/data/cache_dump.db
>
>
> ; Zone dump of 'ynu.edu.cn/IN/INTRANET'
> ;
> ; zone not loaded
> ;
> ; Z

Re: Re: zone not loaded in one of view

[liudonghua]

I found there was a db.ynu.edu.cn.intranet.jnl beside db.ynu.edu.cn.intranet, I 
tried to remove it, then restarted and checked the new cache_dump.db, no `zone 
not loaded` anymore.

For the original problem, because I modified serial of SOA and updated bind9 to 
the latest version, it could not reproduce. Maybe it's also the similar issue, 
but in the older bind 9.11, no jnl file generated via named.




2023-12-17 15:47:43 "Mark Andrews"  写道：
Read your logs and/or use named-checkzone and/or tell name-checkconf to load 
the zones. 


-- 
Mark Andrews

On 17 Dec 2023, at 15:22, liudong...@ynu.edu.cn wrote:


Hi, I have a bind9 authoritative name server running, but I found a strange 
problem. One of zone in a specific view not loaded when I view the 
cache_dump.db after I execute `rndc dumpdb -all`.


The zone data file is almost the same for difference views execpted some few 
domain resolution.


[root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.cernet
$TTL 86400  ; 1 day
@   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
2023121601;   serial number
10800   ;   Refresh interval, every 3 hours
3600;   Retry interval, every 30 minutes 
604800  ;   Expire after 1 week
86400 ) ;Minimum TTL of 1 day


$INCLUDE /etc/named.data/db.ynu.edu.cn.common




; RR of type A
; 
vpn110800   IN  A   113.55.110.251
; 
lb-http-jz  IN  A   113.55.14.52
ynucdn  600 IN  A   202.203.208.4
; 
vpn2IN  A   202.203.208.9


[root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.intranet
$TTL 86400  ; 1 day
@   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
2023121601;   serial number
10800   ;   Refresh interval, every 3 hours
3600;   Retry interval, every 30 minutes 
604800  ;   Expire after 1 week
86400 ) ;Minimum TTL of 1 day


$INCLUDE /etc/named.data/db.ynu.edu.cn.common




; RR of type A
; 
lb-http-jz  IN  A   113.55.14.52
; 
vpn110800   IN  A   192.168.208.3
ynucdn  600 IN  A   202.203.208.4
; 
vpn2IN  A   202.203.208.9


[root@pridns data]#
[root@pridns data]# named-checkconf /etc/named.conf
[root@pridns data]# echo $?
0
[root@pridns data]# 
[root@pridns data]# rndc zonestatus ynu.edu.cn in CERNET
name: ynu.edu.cn
type: primary
files: db.ynu.edu.cn.cernet, /etc/named.data/db.ynu.edu.cn.common
serial: 2023121601
nodes: 576
last loaded: Sat, 16 Dec 2023 08:00:49 GMT
secure: no
dynamic: no
reconfigurable via modzone: no
[root@pridns data]#
[root@pridns data]# rndc zonestatus ynu.edu.cn in INTRANET
rndc: 'zonestatus' failed: zone not loaded
[root@pridns data]#
[root@pridns data]# named-checkzone ynu.edu.cn 
/etc/named.data/db.ynu.edu.cn.intranet
zone ynu.edu.cn/IN: loaded serial 2023121601
OK
[root@pridns data]# 
[root@pridns data]# ll /etc/named.data/db.ynu.edu.cn.cernet 
/etc/named.data/db.ynu.edu.cn.intranet
-rw-r--r-- 1 root root 1.3K Dec 16 16:00 /etc/named.data/db.ynu.edu.cn.cernet
-rw-r--r-- 1 root root 1.3K Dec 16 16:00 /etc/named.data/db.ynu.edu.cn.intranet
[root@pridns data]# 


And here is parts of content in /var/named/data/cache_dump.db


; Zone dump of 'ynu.edu.cn/IN/INTRANET'
;
; zone not loaded
;
; Zone dump of 'rpz/IN/INTRANET'





--
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
-- 
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: zone not loaded in one of view

[Mark Andrews]

Read your logs and/or use named-checkzone and/or tell name-checkconf to load 
the zones. 

-- 
Mark Andrews

> On 17 Dec 2023, at 15:22, liudong...@ynu.edu.cn wrote:
> 
> 
> Hi, I have a bind9 authoritative name server running, but I found a strange 
> problem. One of zone in a specific view not loaded when I view the 
> cache_dump.db after I execute `rndc dumpdb -all`.
> 
> 
> The zone data file is almost the same for difference views execpted some few 
> domain resolution.
> 
> 
> [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.cernet
> $TTL 86400  ; 1 day
> @   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
> 2023121601;   serial number
> 10800   ;   Refresh interval, every 3 hours
> 3600;   Retry interval, every 30 minutes 
> 604800  ;   Expire after 1 week
> 86400 ) ;Minimum TTL of 1 day
> 
> 
> $INCLUDE /etc/named.data/db.ynu.edu.cn.common
> 
> 
> 
> 
> ; RR of type A
> ; 
> vpn110800   IN  A   113.55.110.251
> ; 
> lb-http-jz  IN  A   113.55.14.52
> ynucdn  600 IN  A   202.203.208.4
> ; 
> vpn2IN  A   202.203.208.9
> 
> 
> [root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.intranet
> $TTL 86400  ; 1 day
> @   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
> 2023121601;   serial number
> 10800   ;   Refresh interval, every 3 hours
> 3600;   Retry interval, every 30 minutes 
> 604800  ;   Expire after 1 week
> 86400 ) ;Minimum TTL of 1 day
> 
> 
> $INCLUDE /etc/named.data/db.ynu.edu.cn.common
> 
> 
> 
> 
> ; RR of type A
> ; 
> lb-http-jz  IN  A   113.55.14.52
> ; 
> vpn110800   IN  A   192.168.208.3
> ynucdn  600 IN  A   202.203.208.4
> ; 
> vpn2IN  A   202.203.208.9
> 
> 
> [root@pridns data]#
> [root@pridns data]# named-checkconf /etc/named.conf
> [root@pridns data]# echo $?
> 0
> [root@pridns data]# 
> [root@pridns data]# rndc zonestatus ynu.edu.cn in CERNET
> name: ynu.edu.cn
> type: primary
> files: db.ynu.edu.cn.cernet, /etc/named.data/db.ynu.edu.cn.common
> serial: 2023121601
> nodes: 576
> last loaded: Sat, 16 Dec 2023 08:00:49 GMT
> secure: no
> dynamic: no
> reconfigurable via modzone: no
> [root@pridns data]#
> [root@pridns data]# rndc zonestatus ynu.edu.cn in INTRANET
> rndc: 'zonestatus' failed: zone not loaded
> [root@pridns data]#
> [root@pridns data]# named-checkzone ynu.edu.cn 
> /etc/named.data/db.ynu.edu.cn.intranet
> zone ynu.edu.cn/IN: loaded serial 2023121601
> OK
> [root@pridns data]# 
> [root@pridns data]# ll /etc/named.data/db.ynu.edu.cn.cernet 
> /etc/named.data/db.ynu.edu.cn.intranet
> -rw-r--r-- 1 root root 1.3K Dec 16 16:00 /etc/named.data/db.ynu.edu.cn.cernet
> -rw-r--r-- 1 root root 1.3K Dec 16 16:00 
> /etc/named.data/db.ynu.edu.cn.intranet
> [root@pridns data]# 
> 
> 
> And here is parts of content in /var/named/data/cache_dump.db
> 
> 
> ; Zone dump of 'ynu.edu.cn/IN/INTRANET'
> ;
> ; zone not loaded
> ;
> ; Zone dump of 'rpz/IN/INTRANET'
> 
> 
> 
> 
> -- 
> 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
-- 
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

zone not loaded in one of view

[liudonghua]

Hi, I have a bind9 authoritative name server running, but I found a strange 
problem. One of zone in a specific view not loaded when I view the 
cache_dump.db after I execute `rndc dumpdb -all`.


The zone data file is almost the same for difference views execpted some few 
domain resolution.


[root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.cernet
$TTL 86400  ; 1 day
@   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
2023121601;   serial number
10800   ;   Refresh interval, every 3 hours
3600;   Retry interval, every 30 minutes 
604800  ;   Expire after 1 week
86400 ) ;Minimum TTL of 1 day


$INCLUDE /etc/named.data/db.ynu.edu.cn.common




; RR of type A
; 
vpn110800   IN  A   113.55.110.251
; 
lb-http-jz  IN  A   113.55.14.52
ynucdn  600 IN  A   202.203.208.4
; 
vpn2IN  A   202.203.208.9


[root@pridns data]# head -n 20 /etc/named.data/db.ynu.edu.cn.intranet
$TTL 86400  ; 1 day
@   IN  SOA pridns.ynu.edu.cn. root.pridns.ynu.edu.cn. (
2023121601;   serial number
10800   ;   Refresh interval, every 3 hours
3600;   Retry interval, every 30 minutes 
604800  ;   Expire after 1 week
86400 ) ;Minimum TTL of 1 day


$INCLUDE /etc/named.data/db.ynu.edu.cn.common




; RR of type A
; 
lb-http-jz  IN  A   113.55.14.52
; 
vpn110800   IN  A   192.168.208.3
ynucdn  600 IN  A   202.203.208.4
; 
vpn2IN  A   202.203.208.9


[root@pridns data]#
[root@pridns data]# named-checkconf /etc/named.conf
[root@pridns data]# echo $?
0
[root@pridns data]# 
[root@pridns data]# rndc zonestatus ynu.edu.cn in CERNET
name: ynu.edu.cn
type: primary
files: db.ynu.edu.cn.cernet, /etc/named.data/db.ynu.edu.cn.common
serial: 2023121601
nodes: 576
last loaded: Sat, 16 Dec 2023 08:00:49 GMT
secure: no
dynamic: no
reconfigurable via modzone: no
[root@pridns data]#
[root@pridns data]# rndc zonestatus ynu.edu.cn in INTRANET
rndc: 'zonestatus' failed: zone not loaded
[root@pridns data]#
[root@pridns data]# named-checkzone ynu.edu.cn 
/etc/named.data/db.ynu.edu.cn.intranet
zone ynu.edu.cn/IN: loaded serial 2023121601
OK
[root@pridns data]# 
[root@pridns data]# ll /etc/named.data/db.ynu.edu.cn.cernet 
/etc/named.data/db.ynu.edu.cn.intranet
-rw-r--r-- 1 root root 1.3K Dec 16 16:00 /etc/named.data/db.ynu.edu.cn.cernet
-rw-r--r-- 1 root root 1.3K Dec 16 16:00 /etc/named.data/db.ynu.edu.cn.intranet
[root@pridns data]# 


And here is parts of content in /var/named/data/cache_dump.db


; Zone dump of 'ynu.edu.cn/IN/INTRANET'
;
; zone not loaded
;
; Zone dump of 'rpz/IN/INTRANET'




-- 
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: in-view RPZ definitions

[Lannar Dean via bind-users]

Thanks for the confirmation.

I'm going to continue to try to find alternate solutions to my problem.  I
considered trying to use a DLZ against a postgres database, which would
avoid the slow startup times, but that also would drastically reduce the
overall performance, as well as add complexity for getting this all going.
I'm also not sure if it would actually solve my problems, since I need to
provide different responses based on which view/user population the request
comes from, and it doesn't look like the client IP is made available to any
of the SQL queries that run when querying a DLZ (except for zone
transfers), so I can't easily vary the response.  I'd also entertain any
other ideas such as somehow chaining forwarders to run the request through
a few separate server processes, each of which is configured for a specific
subset of the RPZ.  I'm not sure if this approach will work, but at this
point I'm grasping at straws.

Thanks for your help

PS - sorry for the double post to the mailing list, I wasn't sure if my
last message in this thread went through.

On Sat, Nov 11, 2023 at 11:31 AM Evan Hunt  wrote:

> On Fri, Nov 10, 2023 at 05:24:59PM -0500, Lannar Dean via bind-users wrote:
> > This is a continuation of a very old thread from this mailing list found
> > here:
> > https://groups.google.com/g/comp.protocols.dns.bind/c/nAHtXSDcDl4?pli=1
> >
> > It appears that what I'm attempting to do did not work at the time of
> this
> > thread 8 years ago, but I'm wondering if anything has changed by now.
>
> Many things have, but not this particular thing yet.
>
> To explain the problem, each view has an "RPZ summary database" which is
> an index of all the rules in the response-policy zones configured for that
> view. It makes it possible to determine quickly which policy zone or zones
> have matching rules for a query; that way we don't have to waste time
> trying the query against *all* of the policy zones.
>
> The summary database is populated by the policy zone when it's loaded.
> In your example, zone cf1 was in view1, so it sent its summary information
> to view1.  It doesn't know that it's also in view2.
>
> I've been thinking for a while about the best way to address this, and
> there might be some news coming in the not-too-distant future, but I don't
> have a good solution for you right now, sorry.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>


-- 

<https://www.rgnets.com/>

*LANNAR DEAN*

Director of Product Engineering




<https://www.linkedin.com/company/rgnets> <https://twitter.com/rgnets>
<https://www.youtube.com/channel/UCY1FGrqtlcYQGiICvgRZ5VA>
<https://www.facebook.com/rg.nets.inc> <https://www.reddit.com/r/RGNets/>
-- 
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: in-view RPZ definitions

[Evan Hunt]

On Fri, Nov 10, 2023 at 05:24:59PM -0500, Lannar Dean via bind-users wrote:
> This is a continuation of a very old thread from this mailing list found
> here:
> https://groups.google.com/g/comp.protocols.dns.bind/c/nAHtXSDcDl4?pli=1
> 
> It appears that what I'm attempting to do did not work at the time of this
> thread 8 years ago, but I'm wondering if anything has changed by now.

Many things have, but not this particular thing yet.

To explain the problem, each view has an "RPZ summary database" which is
an index of all the rules in the response-policy zones configured for that
view. It makes it possible to determine quickly which policy zone or zones
have matching rules for a query; that way we don't have to waste time
trying the query against *all* of the policy zones.

The summary database is populated by the policy zone when it's loaded.
In your example, zone cf1 was in view1, so it sent its summary information
to view1.  It doesn't know that it's also in view2.

I've been thinking for a while about the best way to address this, and
there might be some news coming in the not-too-distant future, but I don't
have a good solution for you right now, sorry.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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

in-view RPZ definitions

[Lannar Dean via bind-users]

This is a continuation of a very old thread from this mailing list found
here:
https://groups.google.com/g/comp.protocols.dns.bind/c/nAHtXSDcDl4?pli=1

It appears that what I'm attempting to do did not work at the time of this
thread 8 years ago, but I'm wondering if anything has changed by now.

I am attempting to use views to offer different configurations of RPZ
filtering to different subsets of my user population.  My original approach
was having multiple named processes running on different ports, with PF
redirecting port 53 to the appropriate port based on the user's source IP.

Some of my RPZ zones are quite large, and if the same zone records exist
for multiple configurations, this means loading a lot of the same data into
multiple processes, resulting in long startup times and very high memory
utilization.  So I wanted to use views to reduce named to a single process,
and define RPZ zones that can be shared among multiple views using the
"in-view" config.

I'm attempting to use a config like the following:

view Child {
  match-clients { Child; };
  allow-recursion { any; };
  response-policy { zone "cf1"; zone "cf2"; };
  zone "cf1" {
  type master;
  file "cf1";
  };
  zone "cf2" {
  type master;
  file "cf2";
  };
};

view Teen {
  match-clients { Teen; };
  allow-recursion { any; };
  response-policy { zone "cf1"; };
  zone "cf1" {
in-view Child;
  };
};

Since the rpz for cf1 is large, I want to only have to load/keep a single
copy of it in memory and reference it from both the Child and Teen views.
However the above configuration gives me the error:
response-policy zone 'cf1' for view B is not a master or slave zone

If I add "type master;" to the cf1 zone in view B, I get
zone 'cf1': 'in-view' used with incompatible zone options

So it appears my goal is still not achievable, unless I'm missing
something.  Is there some other mechanism to achieve this end result
(sharing some zones between different user populations without loading
multiple copies of the zone into memory)?

I am currently running BIND 9.16.44 by the way.

Thanks for any advice!
-- 
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: BIND-9.10.2-P4: Cannot use in-view to refer to RPZ zone definitions: "'$RPZ_ZONE' is not a master or slave zone"

[Lannar Dean via bind-users]

I know this is an incredibly old thread, but I was wondering if there has been 
any progress on this topic within the last 8 years. 

I am attempting to use views to offer different configurations of RPZ filtering 
to different subsets of the user population.  My original approach was having 
multiple named processes running on different ports, with PF redirecting port 
53 to the appropriate port based on the user's source IP. 

Some of my RPZ zones are quite large, and if the same zone records exist for 
multiple configurations, this means loading a lot of the same data into 
multiple processes, resulting in long startup times and very high memory 
utilization.  So I wanted to use views to reduce named to a single process, and 
define RPZ zones that can be shared among multiple views using the "in-view" 
config.

I'm using a config like the following:

view Child {
  match-clients { Child; };
  allow-recursion { any; };
  response-policy { zone "cf1"; zone "cf2"; };
  zone "cf1" {
  type master;
  file "cf1";
  };
  zone "cf2" {
  type master;
  file "cf2";
  };
};

view Teen {
  match-clients { Teen; };
  allow-recursion { any; };
  response-policy { zone "cf1"; };
  zone "cf1" {
in-view Child;
  };
};

Since the rpz for cf1 is large, I want to only have to load/keep a single copy 
of it in memory and reference it from both the Child and Teen views.  However 
the above configuration gives me the error:
response-policy zone 'cf1' for view B is not a master or slave zone

If I add "type master;" to the cf1 zone in view B, I get
zone 'cf1': 'in-view' used with incompatible zone options

So it appears my goal is still not achievable, unless I'm missing something.  
Is there some other mechanism to achieve this end result (sharing zones between 
different user populations without loading multiple copies of the zone into 
memory)?

I am currently running BIND 9.16.44 by the way.

Thanks for any advice!
-- 
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

Fwd: In-View Support for RPZ Slave Zones

[Mohammed W]

> Hello Gurus,
> 
> I am in an urgent need to have a workaround of getting the in-view feature 
> supported for RPZ slave zones which I know isn’t supported by default. 
> 
> I am implementing a multi tenant recursive DNS where I have multiple views 
> and I need to unify the memory allocation for RPZ in memory so I can scale 
> with the DNS views. 
> 
> Appreciate your help for sharing any approach or workaround to achieve this 
> taking in consideration that my ultimate goal is to load a certain RPZ once 
> but may reference it thru multiple views matching clients based on source IPs 
> !
> 
> Regard,
> Mohammed 
> 
> 
> Sent from my iPhone
-- 
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: In-View Support for RPZ Slave Zones

[Mohammed W]

Hello Gurus,
> 
> I am in an urgent need to have a workaround of getting the in-view feature 
> supported for RPZ slave zones which I know isn’t supported by default. 
> 
> I am implementing a multi tenant recursive DNS where I have multiple views 
> and I need to unify the memory allocation for RPZ in memory so I can scale 
> with the DNS views. 
> 
> Appreciate your help for sharing any approach or workaround to achieve this 
> taking in consideration that my ultimate goal is to load a certain RPZ once 
> but may reference it thru multiple views matching clients based on source IPs 
> !
> 
> Regard,
> Mohammed 
> 
> 
> Sent from my iPhone
-- 
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: dnssec-policy syntax error in options but not in view

[Matthijs Mekking]

What Mark said.

So that would become:

dnssec-policy "mydefault" {
keys {
csk key-directory lifetime unlimited algorithm ecdsa256;
};
};

options {
dnssec-policy "mydefault";
};


On 8/4/23 01:32, Mark Andrews wrote:
You can’t define a policy there. You can tell named to use the policy. 
Move the definition outside of options.


--
Mark Andrews


On 4 Aug 2023, at 08:26, E R  wrote:


My understanding from the ARM is that the dnssec-policy can be in the 
"options", "view" or "zone".  I have mine in "view" and when I try to 
move into "options" I get a syntax error that I cannot seem to 
understand what is wrong.  I stripped out all other statements and 
reduced the dnssec-policy to just a handful of items to KISS and I 
still do not see why why I get the error from named-checkconf.  I can 
move the block from under "options" to the "view" and it just works so 
I am not sure why named-checkconf thinks there is a missing 
semicolon?  Bind 9.16.23-RH.


# named-checkconf 1.conf
1.conf:3: missing ';' before '{'
1.conf:3: '}' expected near '{'

# cat 1.conf
options {
   dnssec-policy "mydefault" {
     keys {
         csk key-directory lifetime unlimited algorithm ecdsa256;
     };
   };
 };


--
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



--
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: dnssec-policy syntax error in options but not in view

[Mark Andrews]

You can’t define a policy there. You can tell named to use the policy. Move the 
definition outside of options. 

-- 
Mark Andrews

> On 4 Aug 2023, at 08:26, E R  wrote:
> 
> 
> My understanding from the ARM is that the dnssec-policy can be in the 
> "options", "view" or "zone".  I have mine in "view" and when I try to move 
> into "options" I get a syntax error that I cannot seem to understand what is 
> wrong.  I stripped out all other statements and reduced the dnssec-policy to 
> just a handful of items to KISS and I still do not see why why I get the 
> error from named-checkconf.  I can move the block from under "options" to the 
> "view" and it just works so I am not sure why named-checkconf thinks there is 
> a missing semicolon?  Bind 9.16.23-RH.
> 
> # named-checkconf 1.conf
> 1.conf:3: missing ';' before '{'
> 1.conf:3: '}' expected near '{'
> 
> # cat 1.conf
> options {
>dnssec-policy "mydefault" {
>  keys {
>  csk key-directory lifetime unlimited algorithm ecdsa256;
>  };
>};
>  };
> 
> 
> -- 
> 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
-- 
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

dnssec-policy syntax error in options but not in view

[E R]

My understanding from the ARM is that the dnssec-policy can be in the
"options", "view" or "zone".  I have mine in "view" and when I try to move
into "options" I get a syntax error that I cannot seem to understand what
is wrong.  I stripped out all other statements and reduced the
dnssec-policy to just a handful of items to KISS and I still do not see why
why I get the error from named-checkconf.  I can move the block from under
"options" to the "view" and it just works so I am not sure why
named-checkconf thinks there is a missing semicolon?  Bind 9.16.23-RH.

# named-checkconf 1.conf
1.conf:3: missing ';' before '{'
1.conf:3: '}' expected near '{'

# cat 1.conf
options {
   dnssec-policy "mydefault" {
 keys {
 csk key-directory lifetime unlimited algorithm ecdsa256;
 };
   };
 };
-- 
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: ,Re: caching does not seem to be working for internal view

[Paul Kosinski via bind-users]

On Wed, 3 Aug 2022 15:10:39 -0400
Timothe Litt  wrote:

> Hmm.  Your resolv.conf says that it's written by NetworkManager.
> 
> What I suggested should have stopped it from updating resolv.conf.
> 
> See 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/manually-configuring-the-etc-resolv-conf-file_configuring-and-managing-networking
> 
> After restarting the service, did you edit (or replace) resolv.conf to 
> remove the AT address?
> 
> If not, stop here & edit the file.
> 
> If so, perhaps some other manager is editing the file without replacing 
> the comment.
> 
> Check to see if resolv.conf is a symlink - some managers (e.g. 
> systemd-resolved) will do that.  Not sure when/if it found its way to 
> centos (I don't run it), but if it's there, systemctl stop & disable 
> it.  It would be running on 127.0.0.53:53, but it usually points 
> resolv.conf to itself.
> 
> The other managers that I know of aren't in redhat distributions.
> 
> You may need to use auditing to identify what is writing the file.
> 
> Timothe Litt
> ACM Distinguished Engineer


"Helpful" software such as NetworkManager has a habit of getting in the way of 
figuring out what is wrong with systems, especially networked ones. Since none 
of the 8 computers on my home LAN are ever used in different locations, I don't 
use NetworkManager (etc.): I don't see why such add-ons are useful unless the 
computer is used on multiple networks. But distros install a lot of stuff in an 
attempt to "simplify" Linux for newbies. (Even Windows, which now may have more 
millions of experienced users than brand new users, acts as if no one has ever 
used a computer before.)

-- 
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: caching does not seem to be working for internal view

[Lee]

On 8/3/22, Robert Moskowitz via bind-users wrote:
> thanks Greg.  Yes I need to figure out how to troubleshoot this. But
> here is some stuff:
>
> # cat resolv.conf
> # Generated by NetworkManager
> search attlocal.net htt-consult.com
> nameserver 23.123.122.146
> nameserver 2600:1700:9120:4330::1
>
> My server is 23.123.122.146.  That IPv6 addr is my ATT router.
>
> # cat named.conf
>  include "/etc/named/named.acl";
>
> options {
>  listen-on port 53 { any; };
>  listen-on-v6 port 53 { any; };
>  use-v4-udp-ports { range 10240 65535; };
>  use-v6-udp-ports { range 10240 65535; };
>  directory "/var/named";
>  dump-file "/var/named/data/cache_dump.db";
>  statistics-file "/var/named/data/named_stats.txt";
>  memstatistics-file "/var/named/data/named_mem_stats.txt";
>  allow-query { localhost; };

seems wrong, shouldn't that be
  allow-query{ httnets; };

Lee
-- 
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: caching does not seem to be working for internal view

[Greg Choules via bind-users]

Hi Robert.
Turn on query logging by doing "rndc querylog". You should see a message
saying that has been done in "named.log", to where each query will now be
logged. If you have views, part of the query log will contain which view
was matched. So this will tell you two things:

   1. If the queries you are making are actually being handled by BIND at
   all.
   2. If they are, which view handled them.

Try that and see what you discover.

By the way, if you want to see a snapshot of the cache you will have to
dump it to disk using "rndc dumpdb -all", This will produce a file called
"named_dump.db" in the working directory. Commonly this will be the same
location as your zone files. It's a text file, so you can look through it
with cat/more/less etc.

Cheers, Greg

On Wed, 3 Aug 2022 at 21:23, Robert Moskowitz  wrote:

> This is boarderline not thinking on my part.
>
> OF COURSE those FQDNs resolve fast; they are in local ZOne files.  No
> lookup needed.
>
> Sheesh.
>
> "Slow down, you move to fast.  Got to make the Mornin' last!"  :)
>
> On 8/3/22 14:43, Robert Moskowitz wrote:
>
> Perhaps this is only caching the zones in the Internal View, not all
> public stuff looked up by internal clients?
>
> I say this because I get fast responses to internal servers, but slow if
> at all to external ones.
>
> Grasping here because my search foo is weak and I can't find where it is
> defined exactly what IS cached.
>
> On 8/3/22 10:52, Robert Moskowitz via bind-users wrote:
>
> thanks Greg.  Yes I need to figure out how to troubleshoot this.  But here
> is some stuff:
>
> # cat resolv.conf
> # Generated by NetworkManager
> search attlocal.net htt-consult.com
> nameserver 23.123.122.146
> nameserver 2600:1700:9120:4330::1
>
> My server is 23.123.122.146.  That IPv6 addr is my ATT router.
>
> # cat named.conf
> include "/etc/named/named.acl";
>
> options {
> listen-on port 53 { any; };
> listen-on-v6 port 53 { any; };
> use-v4-udp-ports { range 10240 65535; };
> use-v6-udp-ports { range 10240 65535; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { localhost; };
>
> dnssec-enable no;
> dnssec-validation no;
> bindkeys-file "/etc/named.iscdlv.key";
> managed-keys-directory "/var/named/dynamic";
> pid-file "/run/named/named.pid";
> session-keyfile "/run/named/session.key";
> };
>
> logging {channel default_debug {
> file "data/named.run";
> severity dynamic;};};
>
> view "internal"
> {include "/etc/named/named.internal";};
>
> view"external"
> {include "/etc/named/named.external";};
>
> include "/etc/named/rndc.key";
> include "/etc/named.root.key";
>
> # cat named.acl
> acl "httslaves"  {
> //address of NSs
> 208.83.69.35;// ns1.mudkips.net
> 208.83.66.130;// ns2.mudkips.net
> 63.68.132.50;// ns1.icsl.net
> 2607:f4b8:2600:1::1;// ns1.mudkips.net
> 2607:f4b8:2600:6::1;// ns2.mudkips.net
> };
>
> acl "httnets" {
> 127.0.0.1;
> 23.123.122.144/28;
> 192.168.32.0/24;
> 192.168.64.0/24;
> 192.168.96.0/24;
> 192.168.160.0/23;
> 192.168.128.0/23;
> 192.168.192.0/22;
> 192.168.224.0/24;
> ::1;
> 2600:1700:9120:4330::/64;
> };
>
>
> # cat named.internal
>
> match-clients{ httnets; };
> match-destinations{ httnets; };
> allow-query{ httnets; };
> allow-query-cache{ httnets; };
> allow-recursion{ any; };
> recursion yes;
> empty-zones-enable yes;
>
> zone "." IN {
> type hint;
> file "named.ca";};
>
> include "/etc/named.rfc1912.zones";
>
> zone "htt-consult.com" {
> type master;
> file "httin-consult.com.zone";};
>
> zone "labs.htt-consult.com" {
> type master;
> file "labs.htt-consult.com.hosts";};
> zone "intelcon.htt-consult.com" {
> type master;
> file "intelcon.htt-consult.com.hosts";};
> zone "mobile.htt-consult.com" {
> type master;
> f

Re: caching does not seem to be working for internal view

[Robert Moskowitz]

This is boarderline not thinking on my part.

OF COURSE those FQDNs resolve fast; they are in local ZOne files. No 
lookup needed.


Sheesh.

"Slow down, you move to fast.  Got to make the Mornin' last!"  :)

On 8/3/22 14:43, Robert Moskowitz wrote:
Perhaps this is only caching the zones in the Internal View, not all 
public stuff looked up by internal clients?


I say this because I get fast responses to internal servers, but slow 
if at all to external ones.


Grasping here because my search foo is weak and I can't find where it 
is defined exactly what IS cached.


On 8/3/22 10:52, Robert Moskowitz via bind-users wrote:
thanks Greg.  Yes I need to figure out how to troubleshoot this.  But 
here is some stuff:


# cat resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 2600:1700:9120:4330::1

My server is 23.123.122.146.  That IPv6 addr is my ATT router.

# cat named.conf
    include "/etc/named/named.acl";

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    use-v4-udp-ports { range 10240 65535; };
    use-v6-udp-ports { range 10240 65535; };
    directory     "/var/named";
    dump-file     "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query { localhost; };

    dnssec-enable no;
    dnssec-validation no;
    bindkeys-file "/etc/named.iscdlv.key";
    managed-keys-directory "/var/named/dynamic";
    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
};

logging {    channel default_debug {
    file "data/named.run";
    severity dynamic;    };};

view "internal"
{    include "/etc/named/named.internal";};

view    "external"
{    include "/etc/named/named.external";};

include "/etc/named/rndc.key";
include "/etc/named.root.key";

# cat named.acl
acl "httslaves"  {
//    address of NSs
    208.83.69.35;    // ns1.mudkips.net
    208.83.66.130;    // ns2.mudkips.net
    63.68.132.50;    // ns1.icsl.net
    2607:f4b8:2600:1::1;    // ns1.mudkips.net
    2607:f4b8:2600:6::1;    // ns2.mudkips.net
};

acl "httnets" {
    127.0.0.1;
    23.123.122.144/28;
    192.168.32.0/24;
    192.168.64.0/24;
    192.168.96.0/24;
    192.168.160.0/23;
    192.168.128.0/23;
    192.168.192.0/22;
    192.168.224.0/24;
    ::1;
    2600:1700:9120:4330::/64;
};


# cat named.internal

    match-clients        { httnets; };
    match-destinations    { httnets; };
    allow-query        { httnets; };
    allow-query-cache    { httnets; };
    allow-recursion        { any; };
    recursion yes;
    empty-zones-enable yes;

    zone "." IN {
    type hint;
    file "named.ca";    };

    include "/etc/named.rfc1912.zones";

    zone "htt-consult.com" {
    type master;
    file "httin-consult.com.zone";    };

    zone "labs.htt-consult.com" {
    type master;
    file "labs.htt-consult.com.hosts";    };
    zone "intelcon.htt-consult.com" {
    type master;
    file "intelcon.htt-consult.com.hosts";    };
    zone "mobile.htt-consult.com" {
    type master;
    file "mobile.htt-consult.com.hosts";    };
    zone "test.htt-consult.com" {
    type master;
    file "test.httin-consult.com.hosts";    };
    zone "128.168.192.in-addr.arpa" {
    type master;
    file "128.168.192.in-addr.arpa.zone";  };
    zone "0-24.128.168.192.in-addr.arpa" {
    type master;
    file "0-24.128.168.192.in-addr.arpa.zone";    };
    zone "htt" {
    type master;
    file "htt.zone";  };
    zone "home.htt" {
    type master;
    file "home.htt.zone";    };


Do you also want my named.external?


On 8/3/22 09:39, Greg Choules wrote:

Hi Robert.
May we see the file /etc/resolv.conf and your BIND configuration? 
It's difficult to guess what might be going on with only a small 
snippet of information.
If you "ping somewhere" (or "ssh a-server", or whatever) the OS will 
consult resolv.conf to determine where to send DNS queries. If 
that's not your local instance of BIND then you could be looking for 
trouble in the wrong place.


If you *do* have an address of the local machine as the first 
'nameserver' entry in resolv.conf you will need to know what that 
query looks like to determine how BIND is going to handle it.
You also need to know what BIND will try and do when it does receive 
queries

Re: ,Re: caching does not seem to be working for internal view

[Timothe Litt]

Hmm.  Your resolv.conf says that it's written by NetworkManager.

What I suggested should have stopped it from updating resolv.conf.

See 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/manually-configuring-the-etc-resolv-conf-file_configuring-and-managing-networking


After restarting the service, did you edit (or replace) resolv.conf to 
remove the AT address?


If not, stop here & edit the file.

If so, perhaps some other manager is editing the file without replacing 
the comment.


Check to see if resolv.conf is a symlink - some managers (e.g. 
systemd-resolved) will do that.  Not sure when/if it found its way to 
centos (I don't run it), but if it's there, systemctl stop & disable 
it.  It would be running on 127.0.0.53:53, but it usually points 
resolv.conf to itself.


The other managers that I know of aren't in redhat distributions.

You may need to use auditing to identify what is writing the file.

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

On 03-Aug-22 14:39, Robert Moskowitz wrote:



On 8/3/22 12:59, Timothe Litt wrote:


Try

echo -e "[main]\ndns=none" > /etc/NetworkManager/conf.d/no-dns.conf
systemctl restart NetworkManager.service



Same content in resolv.conf.  BTW this is on Centos7.


Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 03-Aug-22 12:36, Robert Moskowitz wrote:



On 8/3/22 11:35, Timothe Litt wrote:

On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote:

# cat resolv.conf

My server is 23.123.122.146.  That IPv6 addr is my ATT router.



You don't want to do that.  The ATT router will not know how to 
resolve internal names.  There is no guarantee that your client 
resolver will try nameservers in order.  If you want a backup, run 
a second instance of named.


As for the intermittent issues with resolving external names, 
that's frequently a case of hitting different nameservers.  Or a 
firewall.


Get rid of the ATT router first.  Then as suggested, a packet trace 
will show what happens (if it still does - it could be that the ATT 
router's resolver is at fault).




Thank you for your advice.  my ifcfg-eth0 has:

DEVICE="eth0"
BOOTPROTO=none
ONBOOT="yes"
TYPE="Ethernet"
NAME="eth0"
MACADDR=02:67:15:00:00:02
MTU=1500
DNS1=23.123.122.146
GATEWAY="23.123.122.158"
IPADDR="23.123.122.146"
NETMASK="255.255.255.240"
IPV6INIT="yes"

And I am ASSuMEing that it is that IPV6INIT that is providing that 
IPv6 addr in resolv.cat.  So I added:


DNS2=192.168.224.2

And now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1

ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want 
that IPv6 nameserver!


So I added the IPv6 address for my server.  I had not done this as 
ATT has said there is no assurance with the IPv6 addresses may 
change.  So I added:


DNS3=2600:1700:9120:4330::49

and now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2600:1700:9120:4330::49

Sigh.  I have to take that dynamic IPv6 assignment.  But I want to 
stop it pushing into my resolv.conf.






OpenPGP_signature
Description: OpenPGP digital signature
-- 
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: caching does not seem to be working for internal view

[Robert Moskowitz]

Perhaps this is only caching the zones in the Internal View, not all 
public stuff looked up by internal clients?


I say this because I get fast responses to internal servers, but slow if 
at all to external ones.


Grasping here because my search foo is weak and I can't find where it is 
defined exactly what IS cached.


On 8/3/22 10:52, Robert Moskowitz via bind-users wrote:
thanks Greg.  Yes I need to figure out how to troubleshoot this. But 
here is some stuff:


# cat resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 2600:1700:9120:4330::1

My server is 23.123.122.146.  That IPv6 addr is my ATT router.

# cat named.conf
    include "/etc/named/named.acl";

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    use-v4-udp-ports { range 10240 65535; };
    use-v6-udp-ports { range 10240 65535; };
    directory     "/var/named";
    dump-file     "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query { localhost; };

    dnssec-enable no;
    dnssec-validation no;
    bindkeys-file "/etc/named.iscdlv.key";
    managed-keys-directory "/var/named/dynamic";
    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
};

logging {    channel default_debug {
    file "data/named.run";
    severity dynamic;    };};

view "internal"
{    include "/etc/named/named.internal";};

view    "external"
{    include "/etc/named/named.external";};

include "/etc/named/rndc.key";
include "/etc/named.root.key";

# cat named.acl
acl "httslaves"  {
//    address of NSs
    208.83.69.35;    // ns1.mudkips.net
    208.83.66.130;    // ns2.mudkips.net
    63.68.132.50;    // ns1.icsl.net
    2607:f4b8:2600:1::1;    // ns1.mudkips.net
    2607:f4b8:2600:6::1;    // ns2.mudkips.net
};

acl "httnets" {
    127.0.0.1;
    23.123.122.144/28;
    192.168.32.0/24;
    192.168.64.0/24;
    192.168.96.0/24;
    192.168.160.0/23;
    192.168.128.0/23;
    192.168.192.0/22;
    192.168.224.0/24;
    ::1;
    2600:1700:9120:4330::/64;
};


# cat named.internal

    match-clients        { httnets; };
    match-destinations    { httnets; };
    allow-query        { httnets; };
    allow-query-cache    { httnets; };
    allow-recursion        { any; };
    recursion yes;
    empty-zones-enable yes;

    zone "." IN {
    type hint;
    file "named.ca";    };

    include "/etc/named.rfc1912.zones";

    zone "htt-consult.com" {
    type master;
    file "httin-consult.com.zone";    };

    zone "labs.htt-consult.com" {
    type master;
    file "labs.htt-consult.com.hosts";    };
    zone "intelcon.htt-consult.com" {
    type master;
    file "intelcon.htt-consult.com.hosts";    };
    zone "mobile.htt-consult.com" {
    type master;
    file "mobile.htt-consult.com.hosts";    };
    zone "test.htt-consult.com" {
    type master;
    file "test.httin-consult.com.hosts";    };
    zone "128.168.192.in-addr.arpa" {
    type master;
    file "128.168.192.in-addr.arpa.zone";  };
    zone "0-24.128.168.192.in-addr.arpa" {
    type master;
    file "0-24.128.168.192.in-addr.arpa.zone";    };
    zone "htt" {
    type master;
    file "htt.zone";  };
    zone "home.htt" {
    type master;
    file "home.htt.zone";    };


Do you also want my named.external?


On 8/3/22 09:39, Greg Choules wrote:

Hi Robert.
May we see the file /etc/resolv.conf and your BIND configuration? 
It's difficult to guess what might be going on with only a small 
snippet of information.
If you "ping somewhere" (or "ssh a-server", or whatever) the OS will 
consult resolv.conf to determine where to send DNS queries. If that's 
not your local instance of BIND then you could be looking for trouble 
in the wrong place.


If you *do* have an address of the local machine as the first 
'nameserver' entry in resolv.conf you will need to know what that 
query looks like to determine how BIND is going to handle it.
You also need to know what BIND will try and do when it does receive 
queries.


Packet captures are your friend here, using tcpdump (to disk, not to 
screen). Gather evidence first, then make theories.


Cheers, Greg

On Wed, 3 Aug 2022 at 14:29, Robert Moskowitz  
wrote:


Part of my problem is that caching does not

Re: ,Re: caching does not seem to be working for internal view

[Robert Moskowitz]

On 8/3/22 12:59, Timothe Litt wrote:


Try

echo -e "[main]\ndns=none" > /etc/NetworkManager/conf.d/no-dns.conf
systemctl restart NetworkManager.service



Same content in resolv.conf.  BTW this is on Centos7.


Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 03-Aug-22 12:36, Robert Moskowitz wrote:



On 8/3/22 11:35, Timothe Litt wrote:

On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote:

# cat resolv.conf

My server is 23.123.122.146.  That IPv6 addr is my ATT router.



You don't want to do that.  The ATT router will not know how to 
resolve internal names.  There is no guarantee that your client 
resolver will try nameservers in order.  If you want a backup, run a 
second instance of named.


As for the intermittent issues with resolving external names, that's 
frequently a case of hitting different nameservers.  Or a firewall.


Get rid of the ATT router first.  Then as suggested, a packet trace 
will show what happens (if it still does - it could be that the ATT 
router's resolver is at fault).




Thank you for your advice.  my ifcfg-eth0 has:

DEVICE="eth0"
BOOTPROTO=none
ONBOOT="yes"
TYPE="Ethernet"
NAME="eth0"
MACADDR=02:67:15:00:00:02
MTU=1500
DNS1=23.123.122.146
GATEWAY="23.123.122.158"
IPADDR="23.123.122.146"
NETMASK="255.255.255.240"
IPV6INIT="yes"

And I am ASSuMEing that it is that IPV6INIT that is providing that 
IPv6 addr in resolv.cat.  So I added:


DNS2=192.168.224.2

And now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1

ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want that 
IPv6 nameserver!


So I added the IPv6 address for my server.  I had not done this as 
ATT has said there is no assurance with the IPv6 addresses may 
change.  So I added:


DNS3=2600:1700:9120:4330::49

and now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2600:1700:9120:4330::49

Sigh.  I have to take that dynamic IPv6 assignment.  But I want to 
stop it pushing into my resolv.conf.






--
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: ,Re: caching does not seem to be working for internal view

[Robert Moskowitz]

On 8/3/22 13:10, Anand Buddhdev wrote:

On 03/08/2022 18:36, Robert Moskowitz wrote:

Hi Robert,

[snip]


ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want that 
IPv6 nameserver!


Calm down. Just add "PEERDNS=no" in your ifcfg-eth0 file. This way, 
the resolv.conf file will only contain your specified DNS servers, and 
nothing else.


I was excited to see this simple approach.  did systemctl restart 
NetworkManager.service


And no change.  :(

I will try Timothe's recommendation next.

BTW, it seems on top of everything else my fiber connect was going south 
to the point that firefox browsing was interspersed by the ATT firewall 
with a message to reset my fiber broadband router! That has helped.  Some.


Multiple failings which is often the case.


--
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: ,Re: caching does not seem to be working for internal view

[Anand Buddhdev]

On 03/08/2022 18:36, Robert Moskowitz wrote:

Hi Robert,

[snip]


ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want that 
IPv6 nameserver!


Calm down. Just add "PEERDNS=no" in your ifcfg-eth0 file. This way, the 
resolv.conf file will only contain your specified DNS servers, and 
nothing else.


Regards,
Anand
--
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: ,Re: caching does not seem to be working for internal view

[Timothe Litt]

Try

echo -e "[main]\ndns=none" > /etc/NetworkManager/conf.d/no-dns.conf
systemctl restart NetworkManager.service

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

On 03-Aug-22 12:36, Robert Moskowitz wrote:



On 8/3/22 11:35, Timothe Litt wrote:

On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote:

# cat resolv.conf

My server is 23.123.122.146.  That IPv6 addr is my ATT router.



You don't want to do that.  The ATT router will not know how to 
resolve internal names.  There is no guarantee that your client 
resolver will try nameservers in order.  If you want a backup, run a 
second instance of named.


As for the intermittent issues with resolving external names, that's 
frequently a case of hitting different nameservers.  Or a firewall.


Get rid of the ATT router first.  Then as suggested, a packet trace 
will show what happens (if it still does - it could be that the ATT 
router's resolver is at fault).




Thank you for your advice.  my ifcfg-eth0 has:

DEVICE="eth0"
BOOTPROTO=none
ONBOOT="yes"
TYPE="Ethernet"
NAME="eth0"
MACADDR=02:67:15:00:00:02
MTU=1500
DNS1=23.123.122.146
GATEWAY="23.123.122.158"
IPADDR="23.123.122.146"
NETMASK="255.255.255.240"
IPV6INIT="yes"

And I am ASSuMEing that it is that IPV6INIT that is providing that 
IPv6 addr in resolv.cat.  So I added:


DNS2=192.168.224.2

And now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1

ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want that 
IPv6 nameserver!


So I added the IPv6 address for my server.  I had not done this as ATT 
has said there is no assurance with the IPv6 addresses may change.  So 
I added:


DNS3=2600:1700:9120:4330::49

and now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2600:1700:9120:4330::49

Sigh.  I have to take that dynamic IPv6 assignment.  But I want to 
stop it pushing into my resolv.conf.




OpenPGP_signature
Description: OpenPGP digital signature
-- 
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: ,Re: caching does not seem to be working for internal view

[Robert Moskowitz]

On 8/3/22 11:35, Timothe Litt wrote:

On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote:

# cat resolv.conf

My server is 23.123.122.146.  That IPv6 addr is my ATT router.



You don't want to do that.  The ATT router will not know how to 
resolve internal names.  There is no guarantee that your client 
resolver will try nameservers in order.  If you want a backup, run a 
second instance of named.


As for the intermittent issues with resolving external names, that's 
frequently a case of hitting different nameservers.  Or a firewall.


Get rid of the ATT router first.  Then as suggested, a packet trace 
will show what happens (if it still does - it could be that the ATT 
router's resolver is at fault).




Thank you for your advice.  my ifcfg-eth0 has:

DEVICE="eth0"
BOOTPROTO=none
ONBOOT="yes"
TYPE="Ethernet"
NAME="eth0"
MACADDR=02:67:15:00:00:02
MTU=1500
DNS1=23.123.122.146
GATEWAY="23.123.122.158"
IPADDR="23.123.122.146"
NETMASK="255.255.255.240"
IPV6INIT="yes"

And I am ASSuMEing that it is that IPV6INIT that is providing that IPv6 
addr in resolv.cat.  So I added:


DNS2=192.168.224.2

And now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1

ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want that 
IPv6 nameserver!


So I added the IPv6 address for my server.  I had not done this as ATT 
has said there is no assurance with the IPv6 addresses may change.  So I 
added:


DNS3=2600:1700:9120:4330::49

and now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2600:1700:9120:4330::49

Sigh.  I have to take that dynamic IPv6 assignment.  But I want to stop 
it pushing into my resolv.conf.



--
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: caching does not seem to be working for internal view

[Timothe Litt]

On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote:

# cat resolv.conf

My server is 23.123.122.146.  That IPv6 addr is my ATT router.



You don't want to do that.  The ATT router will not know how to resolve 
internal names.  There is no guarantee that your client resolver will 
try nameservers in order.  If you want a backup, run a second instance 
of named.


As for the intermittent issues with resolving external names, that's 
frequently a case of hitting different nameservers.  Or a firewall.


Get rid of the ATT router first.  Then as suggested, a packet trace will 
show what happens (if it still does - it could be that the ATT router's 
resolver is at fault).


Intermediate step would be to use dig.

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



OpenPGP_signature
Description: OpenPGP digital signature
-- 
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: caching does not seem to be working for internal view

[Robert Moskowitz via bind-users]

thanks Greg.  Yes I need to figure out how to troubleshoot this. But 
here is some stuff:


# cat resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 2600:1700:9120:4330::1

My server is 23.123.122.146.  That IPv6 addr is my ATT router.

# cat named.conf
    include "/etc/named/named.acl";

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    use-v4-udp-ports { range 10240 65535; };
    use-v6-udp-ports { range 10240 65535; };
    directory     "/var/named";
    dump-file     "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query { localhost; };

    dnssec-enable no;
    dnssec-validation no;
    bindkeys-file "/etc/named.iscdlv.key";
    managed-keys-directory "/var/named/dynamic";
    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
};

logging {    channel default_debug {
    file "data/named.run";
    severity dynamic;    };};

view "internal"
{    include "/etc/named/named.internal";};

view    "external"
{    include "/etc/named/named.external";};

include "/etc/named/rndc.key";
include "/etc/named.root.key";

# cat named.acl
acl "httslaves"  {
//    address of NSs
    208.83.69.35;    // ns1.mudkips.net
    208.83.66.130;    // ns2.mudkips.net
    63.68.132.50;    // ns1.icsl.net
    2607:f4b8:2600:1::1;    // ns1.mudkips.net
    2607:f4b8:2600:6::1;    // ns2.mudkips.net
};

acl "httnets" {
    127.0.0.1;
    23.123.122.144/28;
    192.168.32.0/24;
    192.168.64.0/24;
    192.168.96.0/24;
    192.168.160.0/23;
    192.168.128.0/23;
    192.168.192.0/22;
    192.168.224.0/24;
    ::1;
    2600:1700:9120:4330::/64;
};


# cat named.internal

    match-clients        { httnets; };
    match-destinations    { httnets; };
    allow-query        { httnets; };
    allow-query-cache    { httnets; };
    allow-recursion        { any; };
    recursion yes;
    empty-zones-enable yes;

    zone "." IN {
    type hint;
    file "named.ca";    };

    include "/etc/named.rfc1912.zones";

    zone "htt-consult.com" {
    type master;
    file "httin-consult.com.zone";    };

    zone "labs.htt-consult.com" {
    type master;
    file "labs.htt-consult.com.hosts";    };
    zone "intelcon.htt-consult.com" {
    type master;
    file "intelcon.htt-consult.com.hosts";    };
    zone "mobile.htt-consult.com" {
    type master;
    file "mobile.htt-consult.com.hosts";    };
    zone "test.htt-consult.com" {
    type master;
    file "test.httin-consult.com.hosts";    };
    zone "128.168.192.in-addr.arpa" {
    type master;
    file "128.168.192.in-addr.arpa.zone";  };
    zone "0-24.128.168.192.in-addr.arpa" {
    type master;
    file "0-24.128.168.192.in-addr.arpa.zone";    };
    zone "htt" {
    type master;
    file "htt.zone";  };
    zone "home.htt" {
    type master;
    file "home.htt.zone";    };


Do you also want my named.external?


On 8/3/22 09:39, Greg Choules wrote:

Hi Robert.
May we see the file /etc/resolv.conf and your BIND configuration? It's 
difficult to guess what might be going on with only a small snippet of 
information.
If you "ping somewhere" (or "ssh a-server", or whatever) the OS will 
consult resolv.conf to determine where to send DNS queries. If that's 
not your local instance of BIND then you could be looking for trouble 
in the wrong place.


If you *do* have an address of the local machine as the first 
'nameserver' entry in resolv.conf you will need to know what that 
query looks like to determine how BIND is going to handle it.
You also need to know what BIND will try and do when it does receive 
queries.


Packet captures are your friend here, using tcpdump (to disk, not to 
screen). Gather evidence first, then make theories.


Cheers, Greg

On Wed, 3 Aug 2022 at 14:29, Robert Moskowitz  wrote:

Part of my problem is that caching does not seem to be working in my
internal view.

Something is happening such that my internal systems AND the server
itself cannot resolve names and looses it even 5 min later,
indicating
not caching.

I read https://kb.isc.org/docs/aa-00851

In my include for the internal view (named.internal) I have:

 match-clients        { httnets; };
     match-destinat

Re: caching does not seem to be working for internal view

[Greg Choules via bind-users]

Hi Robert.
May we see the file /etc/resolv.conf and your BIND configuration? It's
difficult to guess what might be going on with only a small snippet of
information.
If you "ping somewhere" (or "ssh a-server", or whatever) the OS will
consult resolv.conf to determine where to send DNS queries. If that's not
your local instance of BIND then you could be looking for trouble in the
wrong place.

If you *do* have an address of the local machine as the first 'nameserver'
entry in resolv.conf you will need to know what that query looks like to
determine how BIND is going to handle it.
You also need to know what BIND will try and do when it does receive
queries.

Packet captures are your friend here, using tcpdump (to disk, not to
screen). Gather evidence first, then make theories.

Cheers, Greg

On Wed, 3 Aug 2022 at 14:29, Robert Moskowitz  wrote:

> Part of my problem is that caching does not seem to be working in my
> internal view.
>
> Something is happening such that my internal systems AND the server
> itself cannot resolve names and looses it even 5 min later, indicating
> not caching.
>
> I read https://kb.isc.org/docs/aa-00851
>
> In my include for the internal view (named.internal) I have:
>
>  match-clients{ httnets; };
>  match-destinations{ httnets; };
>  allow-query{ httnets; };
>  allow-query-cache{ httnets; };
>  allow-recursion{ any; };
>  recursion yes;
>  empty-zones-enable yes;
>
> Yet I get on my DNS server:
>
> ping www.google.com
> ping: www.google.com: Name or service not known
>
> Then later it works.
>
> Then later it doesn't again.
>
> Sigh.  If at least caching was working for internal use, I would be able
> to work more smoothy?
>
>
>
>
> --
> 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
>
-- 
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

caching does not seem to be working for internal view

[Robert Moskowitz]

Part of my problem is that caching does not seem to be working in my 
internal view.


Something is happening such that my internal systems AND the server 
itself cannot resolve names and looses it even 5 min later, indicating 
not caching.


I read https://kb.isc.org/docs/aa-00851

In my include for the internal view (named.internal) I have:

    match-clients        { httnets; };
    match-destinations    { httnets; };
    allow-query        { httnets; };
    allow-query-cache    { httnets; };
    allow-recursion        { any; };
    recursion yes;
    empty-zones-enable yes;

Yet I get on my DNS server:

ping www.google.com
ping: www.google.com: Name or service not known

Then later it works.

Then later it doesn't again.

Sigh.  If at least caching was working for internal use, I would be able 
to work more smoothy?





--
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: Rear View RPZ: PTR records from local knowledge

[Fred Morris]

I posted just such a thing a few weeks ago on the dnsrpz list at
redbarn. Hrm, seems to be down at the moment.

On 12/2/21 11:00 AM, Grant Taylor via bind-users wrote:
> On 12/2/21 9:59 AM, Fred Morris wrote:
>> Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now
>> generally available: turn your local BIND resolver into a network
>> investigation enabler with locally generated PTR records.
>
> Would you please elaborate on what Rear View RPZ does?
>
> It seems as if it synthetically fabricates PTR records (which are
> served via RPZ) with some additional information for subsequent use by
> investigators.
>
> If that is correct, please provide an example of the original PTR and
> the synthetic augmented PTR.

\/    \/    \/    \/    \/ (ob ascii art!)

 Forwarded Message 

Subject:[DNSfirewalls] I've got smoke! Re: Using DnsTap to populate a
reverse DNS RPZ
Date:   Mon, 15 Nov 2021 09:49:26 -0800
From:   Fred Morris 
To: dnsfirewa...@lists.redbarn.org



Hi. It's been a while.

Anyway, I did this. It'll be going up on GitHub. I'll post another
announcement here, and probably on dnstap and bind-users, when it's got
training wheels.

The way this works is a "sputnik" which consumes BIND's Dnstap telemetry
and uses it to populate the RPZ using dynamic updates.

--

FWM

On 3/19/21 12:57 PM, Fred Morris wrote:
> This is a tactical defender-centric tool, intended to augment everyday
> tools' usability, e.g. "iptables -L -v". It's an RPZ, but it's not a
> ban hammer.
>
> On Fri, 19 Mar 2021, Andrew Fried wrote:
>> [...]
>> You will often see generic 4-3-2-1.some.domain ptr records despite an
>> actual host/domain points at the ip, particularly in cloud environments.
>
> Exactly the point!
>
--

m3047@sophia:~/GitHub/rear_view_rpz/python> dig @127.0.0.1 www.cnn.com

; <<>> DiG 9.12.3-P1 <<>> @127.0.0.1 www.cnn.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54804
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 04b5f7fa4c6aded4a8b6a4b3619299ce772407a3c447a114 (good)
;; QUESTION SECTION:
;www.cnn.com.   IN  A

;; ANSWER SECTION:
www.cnn.COM.    297 IN  CNAME   turner-tls.map.fastly.net.
turner-tls.map.fastly.net. 27   IN  A   151.101.53.67

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 15 09:33:02 PST 2021
;; MSG SIZE  rcvd: 134

m3047@sophia:~/GitHub/rear_view_rpz/python> dig @127.0.0.1
rearview.m3047.net axfr

; <<>> DiG 9.12.3-P1 <<>> @127.0.0.1 rearview.m3047.net axfr
; (1 server found)
;; global options: +cmd
REARVIEW.M3047.NET. 600 IN  SOA DEV.NULL.
M3047.M3047.NET. 2 600 60 86400 600
REARVIEW.M3047.NET. 600 IN  NS  LOCALHOST.
67.53.101.151.in-addr.arpa.rearview.m3047.net. 600 IN TXT
"depth=2,first=1636997584.330454,last=1636997584.330457,count=1,trend=0.0,score=0."
67.53.101.151.in-addr.arpa.rearview.m3047.net. 600 IN PTR www.cnn.com.
REARVIEW.M3047.NET. 600 IN  SOA DEV.NULL.
M3047.M3047.NET. 2 600 60 86400 600
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 15 09:33:10 PST 2021
;; XFR size: 5 records (messages 1, bytes 382)

m3047@sophia:~/GitHub/rear_view_rpz/python> dig @127.0.0.1 infoblox.com

; <<>> DiG 9.12.3-P1 <<>> @127.0.0.1 infoblox.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36850
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 666ea36e97a11479a198007e61929a416afc140bc683c5cc (good)
;; QUESTION SECTION:
;infoblox.com.  IN  A

;; ANSWER SECTION:
infoblox.com.   3600    IN  A   23.185.0.3

;; Query time: 109 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 15 09:34:57 PST 2021
;; MSG SIZE  rcvd: 85

m3047@sophia:~/GitHub/rear_view_rpz/python> dig @127.0.0.1
rearview.m3047.net axfr

; <<>> DiG 9.12.3-P1 <<>> @127.0.0.1 rearview.m3047.net axfr
; (1 server found)
;; global options: +cmd
REARVIEW.M3047.NET. 600 IN  SOA DEV.NULL.
M3047.M3047.NET. 3 600 60 86400 600
REARVIEW.M3047.NET. 600 IN  NS  LOCALHOST.
67.53.101.151.in-addr.arpa.rearview.m3047.net. 600 IN TXT
"depth=2,first=1636997584.330454,last=1636997584.330457,count=1,trend=0.0,score=0."
67.53.101.151.in-addr.arpa.rearview.m3047.net. 600 IN PTR www.cnn.com.
3.0.185.23.in-addr.arpa.rearview.m3047.net. 600 IN TXT
"depth=1,first=1636997699.3390522,last=1636997699.3390543,count=1

Re: Rear View RPZ: PTR records from local knowledge

[Grant Taylor via bind-users]

On 12/2/21 9:59 AM, Fred Morris wrote:
Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now 
generally available: turn your local BIND resolver into a network 
investigation enabler with locally generated PTR records.


Would you please elaborate on what Rear View RPZ does?

It seems as if it synthetically fabricates PTR records (which are served 
via RPZ) with some additional information for subsequent use by 
investigators.


If that is correct, please provide an example of the original PTR and 
the synthetic augmented PTR.


Aside:  Creative use and combination of DNSTap and RPZ.  



--
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

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: Rear View RPZ: PTR records from local knowledge

[Greg Rivers via bind-users]

On Thursday, 2 December 2021 10:59:17 CST Fred Morris wrote:
> And I have one small favor to ask: if you know of a Linux distribution
> which ships BIND compiled with Dnstap support, please let me know!
> 
The Linux packages that ISC provide[1] all have dnstap enabled. Also, the 
FreeBSD BIND port and packages have had dnstap enabled by default since August 
2020[2].


[1] 
[2] 

-- 
Greg


___
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

Rear View RPZ: PTR records from local knowledge

[Fred Morris]

Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now
generally available: turn your local BIND resolver into a network
investigation enabler with locally generated PTR records.

Ok, sure, some of you may be using it as a network investigation tool
already. If so, you're probably well aware of the problems with PTR
records for local visibility:

  * Whoever controls the address space, not the domain, controls the PTR
record.
  * They don't necessarily get updated when domains get updated.
  * Network owners lie.
  * The records are just ignored.
  * Many FQDNs can point at an address (vhosting).
  * CNAMEs confound the intent of PTR records.

What FQDN did /YOUR/ users look up which resolved to that address? Rear
View RPZ can tell you.

To have success with it in its present state:

  * You should be familiar with configuring BIND.
  * You should be capable of building it from source.
  * You should be capable of resolving prerequisites (e.g. frame
streams, protobuf) when doing so.
  * You should be familiar with Python syntax.
  * You should understand a systemd service file.

And I have one small favor to ask: if you know of a Linux distribution
which ships BIND compiled with Dnstap support, please let me know!

Cheers...

--

Fred Morris

This is being posted to the Dnstap, RPZ and BIND Users mailing lists.


___
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: Possible to condition a view based on the interface the query comes in on?

[Fred Morris]

Thanks for the suggestions, folks. Using views with RPZs just gets
problematic.

Sharing vs forwarding: forwarding seems cleaner and although there are
two copies of /BIND/ I don't know that that visibility really hurts
anything. Plus that potentially allows the "rear view" resolver to live
on a different machine.

https://github.com/m3047/rear_view_rpz/blob/main/install/Optional_DNS_Service.md

--

Fred Morris


___
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: Possible to condition a view based on the interface the query comes in on?

[Evan Hunt]

On Thu, Nov 18, 2021 at 04:06:01PM -0800, Fred Morris wrote:
> Thanks for the encouragement folks, I forged ahead and I've got a
> different error now:
> 
> "response-policy zone 'rpz1.m3047.net' for view standard is not a
> master or slave zone"
> 
> That's the final denoument. There are several intermediate steps, such
> as moving all zone definitions into the views and converting all zone
> references in the second view to "in-view standard;" (where "standard"
> is the name of the first view).
> 
>   * There are a total of three RPZs.
>   * Two are utilized in the first view. (actually this is a lie)
>   * All three are utilized in the second view.
> 
> and the "lie" is that the "unused" RPZ is dynamically updated in the
> first view (that's where update requests are sent); I suppose I could
> jigger that so that the updates happen in the second view. But the
> stopper is that error message, and that RPZ is common to both views.
> 
> This is 9.12 FWIW.

(That's pretty outdated, BTW. End of life was 2.5 years ago.)

You can set things up so that one view will transfer a copy of a zone
from another, by using a TSIG key so that transfer requests from localhost
to localhost will be routed to the correct view:

key them-key { ... };
acl our-clients { ... };

view us {
match-clients { !key them-key; our-clients; };

zone example.com {
type secondary;
    file "example-secondary.db";
primaries { 127.0.0.1 key them-key; };
};
};

view them {
match-clients { any; };

zone example.com {
type primary;
file "example-primary.db";
allow-transfer { localhost; };
};
};

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: Possible to condition a view based on the interface the query comes in on?

[Fred Morris]

Thanks for the encouragement folks, I forged ahead and I've got a
different error now:

"response-policy zone 'rpz1.m3047.net' for view standard is not a
master or slave zone"

That's the final denoument. There are several intermediate steps, such
as moving all zone definitions into the views and converting all zone
references in the second view to "in-view standard;" (where "standard"
is the name of the first view).

  * There are a total of three RPZs.
  * Two are utilized in the first view. (actually this is a lie)
  * All three are utilized in the second view.

and the "lie" is that the "unused" RPZ is dynamically updated in the
first view (that's where update requests are sent); I suppose I could
jigger that so that the updates happen in the second view. But the
stopper is that error message, and that RPZ is common to both views.

This is 9.12 FWIW.

--

Fred Morris


___
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: Possible to condition a view based on the interface the query comes in on?

[stuart@registry.godaddy]

Look in to "match-destination" in a view, i.e.

acl abcd.anycast {
10.10.10.1;     
};
view "abcd" {
match-clients {
any;
};
match-destinations {
abcd.anycast;
};
...
};

The response-policy definition (and associated zone) can go into a view, 
instead of global options.

Stuart

On 19/11/21, 7:40 am, "bind-users on behalf of Fred Morris" 
 wrote:

[You don't often get email from m3...@m3047.net. Learn why this is 
important at http://aka.ms/LearnAboutSenderIdentification.]

Caution: This email is from an external sender. Please do not click links 
or open attachments unless you recognize the sender and know the content is 
safe. Forward suspicious emails to isitbad@.



I wanted to provide enhanced recursive DNS to (internal) clients on an
"opt in" basis, which is to say that clients could choose whether or not
to receive enhanced replies based on what they configured as their local
caching resolver. The enhanced services come in the form of a Response
Policy Zone (RPZ).

Didn't see any reason that it had to be separate instances of BIND,
thought maybe I could do it with views, but I've run into a couple of
roadblocks:

1. listen-on isn't supported in views.
2. internet wisdom augurs that response-policy isn't supported either.

Is there a way to do this or should I bite the bullet and run two copies
of BIND?

Thanks in advance...

--

Fred Morris


___
Please visit 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Gjtq6vOlM%2BQIHcqfrVgJD%2Fzbjm3vLdF%2BKg74%2FtPQsuA%3Dreserved=0
 to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2Fdata=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xptHiGDaNrn7P99mhYJrI%2Fbw2nAf%2FH7%2FJCRFUvabkrc%3Dreserved=0
 for more information.


bind-users mailing list
bind-users@lists.isc.org

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=04%7C01%7Cstuart%40registry.godaddy%7Cdad3a7b53cce4d00c11708d9aad39ccd%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637728648249954539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Gjtq6vOlM%2BQIHcqfrVgJD%2Fzbjm3vLdF%2BKg74%2FtPQsuA%3Dreserved=0


___
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: Possible to condition a view based on the interface the query comes in on?

[Tony Finch]

Fred Morris  wrote:
>
> Didn't see any reason that it had to be separate instances of BIND,
> thought maybe I could do it with views, but I've run into a couple of
> roadblocks:
>
> 1. listen-on isn't supported in views.

Right, listen-on is for the server as a whole.

To control which view is used to answer a query based on the server
address, use the `match-destinations` option. For details see
https://bind9.readthedocs.io/en/v9_16_23/reference.html#view-statement-grammar

> 2. internet wisdom augurs that response-policy isn't supported either.

Don't believe everything you read on the internet :-)

Yes, you can have different RPZ configurations in different views.

Another trick that's useful for the kind of setup you are planning is to
use the `attach-cache` option so that your views can share the same cache.
This improves performance and reduces memory usage. It still works with
differing RPZ policies because RPZ only affects the responses sent to
clients; RPZ doesn't change how recursion works or what records are saved
in the cache.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Fair Isle, Faeroes: Westerly or southwesterly 7 to severe gale 9,
occasionally storm 10 for a time in Faeroes, decreasing 5 to 7 later.
Rough or very rough, becoming high for a time. Occasional rain.
Moderate, occasionally poor.

___
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: Possible to condition a view based on the interface the query comes in on?

[Niall O'Reilly]

match-destinations ?

⁣---
>From an Android device, using BlueMail, which forces top-posting.​

On 18 Nov 2021, 20:40, at 20:40, Fred Morris  wrote:
>I wanted to provide enhanced recursive DNS to (internal) clients on an
>"opt in" basis, which is to say that clients could choose whether or
>not
>to receive enhanced replies based on what they configured as their
>local
>caching resolver. The enhanced services come in the form of a Response
>Policy Zone (RPZ).
>
>Didn't see any reason that it had to be separate instances of BIND,
>thought maybe I could do it with views, but I've run into a couple of
>roadblocks:
>
>1. listen-on isn't supported in views.
>2. internet wisdom augurs that response-policy isn't supported either.
>
>Is there a way to do this or should I bite the bullet and run two
>copies
>of BIND?
>
>Thanks in advance...
>
>--
>
>Fred Morris
>
>
>___
>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
___
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

Possible to condition a view based on the interface the query comes in on?

[Fred Morris]

I wanted to provide enhanced recursive DNS to (internal) clients on an
"opt in" basis, which is to say that clients could choose whether or not
to receive enhanced replies based on what they configured as their local
caching resolver. The enhanced services come in the form of a Response
Policy Zone (RPZ).

Didn't see any reason that it had to be separate instances of BIND,
thought maybe I could do it with views, but I've run into a couple of
roadblocks:

1. listen-on isn't supported in views.
2. internet wisdom augurs that response-policy isn't supported either.

Is there a way to do this or should I bite the bullet and run two copies
of BIND?

Thanks in advance...

--

Fred Morris


___
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: Logging statements w.r.t. view in Bind 9.16.18

[Chris Buxton]

The rationale to separate recursive and non-recursive (typically authoritative) 
services as you describe is largely to do with separating logging, exactly as 
in this use case. There are also reasons of performance sometimes, but it 
doesn’t sound like this fits that reason.

You could also see these queries from the outside world with dnstap or similar, 
logging packets possibly without even involving named. You certainly would not 
need a view for that. If your clients are not hitting your public address, you 
could also tell named not to listen on the public address, so that those 
queries to the public address would be ignored by the operating system. Or you 
could use iptables, perhaps, to filter out those queries from the public (and 
even log them…).

As you noted in your initial message, though, logging is global, not per-view. 
You either have to prevent named from seeing them, or perhaps live with the log 
messages from that public view. Perhaps your SIEM (if you use one) could split 
the data based on the view name in the log messages.

Regards,
Chris Buxton

> On Aug 24, 2021, at 7:44 AM, Gaurav Kansal  wrote:
> 
> Hi Ged, 
> 
> Actually recursion is only enabled for selected set of users , using geo ip 
> feature of bind.
> As server is on public IP, i have added PUBLIC view to log the users who are 
> scanning/attempting to connect my server.
> 
> I hope i have explained my use case.
> 
> Thanks.
> 
> - Original Message -
> From: bind-users@lists.isc.org
> To: bind-users@lists.isc.org
> Sent: Tuesday, August 24, 2021 5:37:35 PM
> Subject: Re: Logging statements w.r.t. view in Bind 9.16.18
> 
> Hi there,
> 
> On Tue, 24 Aug 2021, Gaurav Kansal wrote:
> 
>> I want a clarity whether we can have individual logging statement
>> per view basis ? Whatever i found on google, i think we can't.  My
>> use case for separate logging statement is as follows -
>> 
>> In my recursive server, i have 2 views, one for my internal clients
>> and one for Internet ; i am running Internet view just for catch
>> hold of scanning IPs (type of honeypot).
>> 
>> Syntax of 2 views are as follows -
>> 
>> view "INTRANET" {
>> match-clients { PRIVATE.SEGMENTS ; };
>> recursion yes;
>> };
>> 
>> view "PUBLIC" {
>> match-clients { any; };
>> allow-query { none; } ;
>> recursion no;
>> };
> 
> You have recursion turned off for PUBLIC.  As I understand it, the
> conventional wisdom is not to run recursive and non-recursive services
> on the same BIND instance.  Would it make sense then, in your case, to
> run two separate instances of BIND?  Separating logs is then trivial.
> 
> -- 
> 
> 73,
> Ged.
> ___
> 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
> 
> 
> ___
> 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
> 

___
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: Logging statements w.r.t. view in Bind 9.16.18

[Gaurav Kansal]

Hi Ged, 

Actually recursion is only enabled for selected set of users , using geo ip 
feature of bind.
As server is on public IP, i have added PUBLIC view to log the users who are 
scanning/attempting to connect my server.

I hope i have explained my use case.

Thanks.

- Original Message -
From: bind-users@lists.isc.org
To: bind-users@lists.isc.org
Sent: Tuesday, August 24, 2021 5:37:35 PM
Subject: Re: Logging statements w.r.t. view in Bind 9.16.18

Hi there,

On Tue, 24 Aug 2021, Gaurav Kansal wrote:

> I want a clarity whether we can have individual logging statement
> per view basis ? Whatever i found on google, i think we can't.  My
> use case for separate logging statement is as follows -
>
> In my recursive server, i have 2 views, one for my internal clients
> and one for Internet ; i am running Internet view just for catch
> hold of scanning IPs (type of honeypot).
> 
> Syntax of 2 views are as follows -
>
> view "INTRANET" {
> match-clients { PRIVATE.SEGMENTS ; };
> recursion yes;
> };
>
> view "PUBLIC" {
> match-clients { any; };
> allow-query { none; } ;
> recursion no;
> };

You have recursion turned off for PUBLIC.  As I understand it, the
conventional wisdom is not to run recursive and non-recursive services
on the same BIND instance.  Would it make sense then, in your case, to
run two separate instances of BIND?  Separating logs is then trivial.

-- 

73,
Ged.
___
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


___
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: Logging statements w.r.t. view in Bind 9.16.18

[G.W. Haywood via bind-users]

Hi there,

On Tue, 24 Aug 2021, Gaurav Kansal wrote:


I want a clarity whether we can have individual logging statement
per view basis ? Whatever i found on google, i think we can't.  My
use case for separate logging statement is as follows -

In my recursive server, i have 2 views, one for my internal clients
and one for Internet ; i am running Internet view just for catch
hold of scanning IPs (type of honeypot).

Syntax of 2 views are as follows -

view "INTRANET" {
match-clients { PRIVATE.SEGMENTS ; };
recursion yes;
};

view "PUBLIC" {
match-clients { any; };
allow-query { none; } ;
recursion no;
};


You have recursion turned off for PUBLIC.  As I understand it, the
conventional wisdom is not to run recursive and non-recursive services
on the same BIND instance.  Would it make sense then, in your case, to
run two separate instances of BIND?  Separating logs is then trivial.

--

73,
Ged.
___
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

Logging statements w.r.t. view in Bind 9.16.18

[Gaurav Kansal]

Hi guys, 

I want a clarity whether we can have individual logging statement per view 
basis ? Whatever i found on google, i think we can't. 
My use case for separate logging statement is as follows - 

In my recursive server, i have 2 views, one for my internal clients and one for 
Internet ; i am running Internet view just for catch hold of scanning IPs (type 
of honeypot). 

Syntax of 2 views are as follows - 

view "INTRANET" { 
match-clients { PRIVATE.SEGMENTS ; }; 
recursion yes; 
}; 

view "PUBLIC" { 
match-clients { any; }; 
allow-query { none; } ; 
recursion no; 
}; 

My logging config is - 

channel queries { 
file "/var/log/log/queries"; 
severity info; 
print-time yes; 
print-category yes; 
print-severity yes; 
}; 
category queries { 
queries; 
}; 
channel query-errors { 
file "/var/log/log/query-errors" versions 5 size 20m; 
severity dynamic; 
print-time yes; 
print-category yes; 
print-severity yes; 
}; 
category query-errors { 
query-errors; 
}; 

channel default { file "/var/log/log/default" versions 5 size 20m; severity 
info; print-time yes; print-category yes; print-severity yes; }; 
category client { default ; } ; 
category general { default ; } ; 
category unmatched { default ; } ; 



By this config, i am getting all the query logs (for both the views) in a 
single file and also i am getting REFUSED statements in query-errors category 
file. 
I want to achieve to have separate query log file for each view and doesn't 
want to log REFUSED queries (which are for PUBLIC view) in query-error 
category. 

please help how can i achieve this. 

Thanks, 
Gaurav Kansal 




Disclaimer:

This e-mail and its attachments may contain official Indian Government 
information. If you are not the intended recipient, please notify the sender 
immediately and delete this e-mail. Any dissemination or use of this 
information by a person other than the intended recipient is unauthorized. The 
responsibility lies with the recipient to check this email and any attachment 
for the presence of viruses.   
___
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: Expert view of core dump related to catalog zone

[Ondřej Surý]

Hi Scott,

the latest upstream release is 9.16.16 where we fixed deadlock in 
addzone/modzone/delzone interaction.

If you can I would recommend waiting until Wednesday where 9.16.17 will be 
published.

If you still encounter the assertion failure, feel free to fill an issue with 
us at gitlab.isc.org with a reproducer, full backtrace and coredump (you can 
use pandora.isc.org for large uploads).

It might be problematic to debug this as we don’t have any ppc64el hardware 
available at our disposal.

Ondřej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 14. 6. 2021, at 15:57, Scott Strattner  wrote:
> 
> 1. I looked at the release notes for 9.16.8 and didn't think it is related to 
> any of the bug fixes mentioned, but could it be?

___
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

Expert view of core dump related to catalog zone

[Scott Strattner]

Hello,
 
Last week I moved one of our primary DNS servers to 9.16.7 (and also changed the underlying OS to RedHat 8.3). The platform it is running on is Power (ppc64le).
 
This morning I discovered that named had failed. It was triggered from a request to delete a subdomain (managed through catalog zone).
 
That's all I can gather from reading the system logs (see below). I am hoping someone more knowledgeable about this can provide guidance. Specifically:
 
1. I looked at the release notes for 9.16.8 and didn't think it is related to any of the bug fixes mentioned, but could it be?
2. Has anyone seen anything similar to this, is there anything specific I should look at to debug further?
 
Jun 13 03:50:35 ns1 named[3500]: received control channel command 'delzone p1305.cecc.ihost.com'Jun 13 03:50:35 ns1 named[3500]: zone p1305.cecc.ihost.com scheduled for removal via delzoneJun 13 03:50:35 ns1 named[3500]: deleting zone p1305.cecc.ihost.com in view public via delzoneJun 13 03:50:35 ns1 named[3500]: client @0x7fff245997a0 127.0.0.1#56939/key rndc-key: view public: signer "rndc-key" approvedJun 13 03:50:35 ns1 named[3500]: client @0x7fff245997a0 127.0.0.1#56939/key rndc-key: view public: updating zone 'catalog.cecc/IN': deleting an RR at efa050aa1c661b474801a5dad3555943c4f59897.zones.catalog.cecc PTRJun 13 03:50:35 ns1 named[3500]: catz: updating catalog zone 'catalog.cecc' with serial 10803Jun 13 03:50:35 ns1 named[3500]: view.c:611: INSIST(__v > 0 && __v < (4294967295U)) failed, back traceJun 13 03:50:35 ns1 named[3500]: #0 0x1003a43c in assertion_failed()+0x7cJun 13 03:50:35 ns1 named[3500]: #1 0x102af6e8 in isc_assertion_failed()+0x28Jun 13 03:50:35 ns1 named[3500]: #2 0x1020db64 in dns_view_attach()+0xf4Jun 13 03:50:35 ns1 named[3500]: #3 0x1003d8a8 in catz_create_chg_task()+0xe8Jun 13 03:50:35 ns1 named[3500]: #4 0x100cdd04 in dns_catz_zones_merge()+0x6b4Jun 13 03:50:35 ns1 named[3500]: #5 0x100d200c in dns_catz_update_from_db()+0x3ecJun 13 03:50:35 ns1 named[3500]: #6 0x100d24d8 in dns_catz_update_taskaction()+0x68Jun 13 03:50:35 ns1 named[3500]: #7 0x102e692c in run()+0x78cJun 13 03:50:35 ns1 named[3500]: #8 0x7fff8b738878 in __do_global_dtors_aux_fini_array_entry()+0x7fff7b32d9a0Jun 13 03:50:35 ns1 named[3500]: #9 0x7fff8b5e32c8 in __do_global_dtors_aux_fini_array_entry()+0x7fff7b1d83f0Jun 13 03:50:35 ns1 named[3500]: exiting (due to assertion failure)Jun 13 03:50:36 ns1 systemd[1]: named.service: Main process exited, code=killed, status=6/ABRTJun 13 03:50:36 ns1 systemd[1]: named.service: Failed with result 'signal'.Jun 13 03:50:37 ns1 systemd-coredump[229571]: Process 3500 (named) of user 25 dumped core.#012#012Stack trace of thread 3540:#012#0  0x7fff8b4f43d8 raise (libc.so.6)#012#1  0x7fff8b4d448c abort (libc.so.6)#012#2  0x1003a66c assertion_failed (named)#012#3  0x102af6e8 isc_assertion_failed (named)#012#40x1020db64 dns_view_attach (named)#012#5  0x1003d8a8 catz_create_chg_task (named)#012#6  0x100cdd04 dns_catz_zones_merge (named)#012#7  0x100d200c dns_catz_update_from_db (named)#012#80x100d24d8 dns_catz_update_taskaction (named)#012#9  0x102e692c dispatch (named)#012#10 0x7fff8b738878 start_thread (libpthread.so.0)#012#11 0x7fff8b5e32c8 __clone (libc.so.6)
 
 
Scott Strattner
Garage for Systems | Systems Technology Architect
IBM Technology Sales
845-433-4505 Office (Jabber)
sstra...@us.ibm.com

___
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: reverse lookup for RFC1918 in view failed

[MAYER Hans]

Dear Tony, 

Many thanks for your really very detailed answer. 
I will take a look into details and let you know within the next days.

Kind regards 
Hans 



-Original Message-
From: Tony Finch  On Behalf Of Tony Finch
Sent: Sunday, June 6, 2021 10:54 PM
To: MAYER Hans 
Cc: bind-users@lists.isc.org
Subject: Re: reverse lookup for RFC1918 in view failed 

MAYER Hans  wrote:
>

I can see why the behaviour of your server is confusing! I'll explain what is 
happening in detail below, but here's the basic idea:

Each view in a configuration is separate from the others: `named` first chooses 
which view to use (based on match-clients etc.) then handles the query purely 
within that view. If a zone is only configured in one view then that zone 
configuration will not be used to answer queries that are handled by another 
view.

By itself, that basic idea isn't enough to explain what's happening with your 
server, so let's look at the details, then I'll outline some solutions.

> Now the behaviour is the following: When I query from the local IPv6 
> or
> IPv4 network with „dig -x“ for an IP address I get back „status:
> NXDOMAIN“

In this case your query is matching the "intern" view, which doesn't know about 
your RFC 1918 reverse DNS zone, so it resolves the query using the public DNS, 
which says NXDOMAIN.

> But when I do the same on the server itself using the loopback 
> addresses for IPv6 or IPv4 it works fine. It also works, if the query 
> comes from the Internet over IPv4 with NAT or with the public IPv6 address.

In these cases your query is reaching the "fueralle" view, which does know 
about your reverse DNS zone.

> If I query „normal forward“ for an IP with a given name then it works 
> in any case and from every location. This is interesting because the 
> reverse lookup zone and the normal forward zone are both in the same 
> view „fueralle“.

This is where it gets complicated! There are two cases:

When you query your forward zone from an external IP address, or from a 
loopback IP address, the query is handled by the "fueralle" view, which knows 
about your forward zone, so it can answer the query.

When you query from an internal IP address, it is handled by the "intern"
view which doesn't know about your forward zone. So it does normal recursive 
resolution, which (I guess!) eventally tells the server to query itself via the 
public NAT or IPv6 addresses, so the recursive query is answered by the 
"fueralle" view.

If you turn on query logging (and if my guess is right) you should see two 
entries in the query log for this last kind of query, one in the "intern" view, 
and a matching one in the "fueralle" view.

To make your views behave more consistently, the solution is to make sure that 
each view knows about all the zones that it needs to.

So your "intern" view should have your forward zone and your RFC 1918 reverse 
zone, and your "fueralle" view should only have your forward zone (because you 
don't want to publish a private zone on a public server).

There are a couple of ways to make the forward zone appear in both views.

You can use the "in-view" zone configuration option, which makes this view 
re-use a zone configuration from another view.

You can continue to rely on the resolver, but that is less reliable because it 
will not work if/when your network loses external connectivity.

What you must not do is simply copy the same primary or secondary zone 
configuration into multiple views: if you do that, you will have multiple zone 
configurations trying to use the same files, and they will conflict with each 
other.

Tony.
--
f.anthony.n.finchhttps://dotat.at/ Plymouth, Biscay: 
Variable 2 to 4. Slight or moderate. Mainly fair.
Moderate or good.
___
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: reverse lookup for RFC1918 in view failed

[Tony Finch]

MAYER Hans  wrote:
>

I can see why the behaviour of your server is confusing! I'll explain what
is happening in detail below, but here's the basic idea:

Each view in a configuration is separate from the others: `named` first
chooses which view to use (based on match-clients etc.) then handles the
query purely within that view. If a zone is only configured in one view
then that zone configuration will not be used to answer queries that are
handled by another view.

By itself, that basic idea isn't enough to explain what's happening with
your server, so let's look at the details, then I'll outline some
solutions.

> Now the behaviour is the following: When I query from the local IPv6 or
> IPv4 network with „dig -x“ for an IP address I get back „status:
> NXDOMAIN“

In this case your query is matching the "intern" view, which doesn't know
about your RFC 1918 reverse DNS zone, so it resolves the query using the
public DNS, which says NXDOMAIN.

> But when I do the same on the server itself using the loopback addresses
> for IPv6 or IPv4 it works fine. It also works, if the query comes from
> the Internet over IPv4 with NAT or with the public IPv6 address.

In these cases your query is reaching the "fueralle" view, which does know
about your reverse DNS zone.

> If I query „normal forward“ for an IP with a given name then it works in
> any case and from every location. This is interesting because the
> reverse lookup zone and the normal forward zone are both in the same
> view „fueralle“.

This is where it gets complicated! There are two cases:

When you query your forward zone from an external IP address, or from a
loopback IP address, the query is handled by the "fueralle" view, which
knows about your forward zone, so it can answer the query.

When you query from an internal IP address, it is handled by the "intern"
view which doesn't know about your forward zone. So it does normal
recursive resolution, which (I guess!) eventally tells the server to query
itself via the public NAT or IPv6 addresses, so the recursive query is
answered by the "fueralle" view.

If you turn on query logging (and if my guess is right) you should see
two entries in the query log for this last kind of query, one in the
"intern" view, and a matching one in the "fueralle" view.

To make your views behave more consistently, the solution is to make sure
that each view knows about all the zones that it needs to.

So your "intern" view should have your forward zone and your RFC 1918
reverse zone, and your "fueralle" view should only have your forward zone
(because you don't want to publish a private zone on a public server).

There are a couple of ways to make the forward zone appear in both views.

You can use the "in-view" zone configuration option, which makes this view
re-use a zone configuration from another view.

You can continue to rely on the resolver, but that is less reliable
because it will not work if/when your network loses external connectivity.

What you must not do is simply copy the same primary or secondary zone
configuration into multiple views: if you do that, you will have multiple
zone configurations trying to use the same files, and they will conflict
with each other.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Plymouth, Biscay: Variable 2 to 4. Slight or moderate. Mainly fair.
Moderate or good.
___
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

reverse lookup for RFC1918 in view failed

[MAYER Hans]

Dear All,

I have a strange behaviour which I can’t explain. So I am asking for help.
In my named.conf I have two views. One view is called „intern“ ( German 
internally ) and the other is called „fueralle“ ( German "for everyone" )
In the internal view I have a response-policy with two zones, a „drop“ zone and 
a „passthru“ zone where I rewrite some IP addresses for internal use. The 
"match-clients“ definition is defined with „lokal“ which is the local IPv4 
address range 192.168.0.0/16  and the public IPv6 address but no loopback, 
either IPv6 or IPv4.
The "for everyone“ zone has everything else. It has the domain name as master 
and some others as slave and also "168.192.IN-ADDR.ARPA“ ; match-clients is 
defined with „any“
The server is physically located in network 192.168.0.0 and reachable from the 
world via NAT and has also a public available IPv6 address.

Now the behaviour is the following: When I query from the local IPv6 or IPv4 
network with „dig -x“ for an IP address I get back „status: NXDOMAIN“
But when I do the same on the server itself using the loopback addresses for 
IPv6 or IPv4 it works fine. It also works, if the query comes from the Internet 
over IPv4 with NAT or with the public IPv6 address. If I query  „normal 
forward“ for an IP with a given name then it works in any case and from every 
location. This is interesting because the reverse lookup zone and the normal 
forward zone are both in the same view „fueralle“.

If I remove the views it works as I would expect.

I am using BIND 9.16.16 (Stable Release)  running on Linux x86_64 
4.19.0-16-amd64

Any help is welcome.


Kind regards
Hans

--

Ing. Dipl.-Ing. Hans Mayer
Systems Analyst
Network Unix Security Team (NUST)
Information and Communication Technologies (ICT)

International Institute for Applied Systems Analysis (IIASA)
Schlossplatz 1
A-2361 Laxenburg, Austria
Phone: +43 2236 807 Ext 215
Mobile: +43 676 83 807 215
Web: http://www.iiasa.ac.at
E-Mail: hans.ma...@iiasa.at<mailto:hans.ma...@iiasa.at>

Note: If there is a disclaimer or other legal boilerplate in the above message, 
it is NULL AND VOID.  You may ignore it.





On 01.06.2021, at 17:31, Anand Buddhdev 
mailto:ana...@ripe.net>> wrote:

On 01/06/2021 17:18, Cuttler, Brian R (HEALTH) via bind-users wrote:

Hi Brian,

From what I'm reading I should be sending a notify from the primary
to the secondary when a dynamic zone is updated but I don't seem to be
doing that.

Would someone please point me to the option I'm missing to do so?
I've either completely missed it, mis-understood what I read or am going in
the wrong direction.

You need an "also-notify" option for that zone. Read more about this in
the BIND documentation:

https://bind9.readthedocs.io/en/v9_16_16/reference.html#zone-transfers

While this documentation refers to the latest stable version of BIND, it
should still apply to the older version you're using.

Regards,
Anand
___
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

___
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: Does bind9 support adding acl and view through commands, not by updating config file?

[Evan Hunt]

On Thu, Apr 15, 2021 at 03:35:38PM +0800, Zhengyu Pan wrote:
> I want to implement intelligent DNS through bind9. I need to add a custom
> line(IP address ranges) to bind9 using acl and view when add a user.
> Because when add a tenant, i need to define a new acl and view. I don't
> want to update named.conf config file frequently.
> 
>  Does bind9 support adding acl and view through commands or API, not by
>  updating config file? 
> 
>  like the command "rndc addacl" or "rndc addview". 

No, and I wouldn't recommend doing this via "reconfig" either. Views
don't scale well. Finding the correct view for a query is a linear search,
so your performance will decline quite badly if you have more than a few
views to search through.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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:Re: Re: Does bind9 support adding acl and view through commands, not by updating config file?

[Zhengyu Pan]

>do you mean, the same domains with different content, depending on clients'
>IPs? That's common multiple-view setup
>(nothing special or intelligent).

Yes, I will create a view and acl for every client. Because every client has 
the unique IP address.


>Why? Do you have that many clients constantly with changing IPs?
>
>Maybe they could use local DNS server talking to your DNS server using TSIG,

>and instead of IPs you'd define TSIG keys.


My client vm directly connect the dns server. There are no local servers on the 
road.
Different client may create the same domain. So I must use IP to limit who use 
which view. client view can't use TSIG key.
>I'm afraid for now there's no  way to make this via rndc.
>You'll have to generate named config per-client.
I wan to know whether per-client can have own confile file that contains view 
and acl. Not put view and acl in named.conf.


>>Updating config file frequently may affect other zones in this dns server.
>
>I don't understand how/why it should affect other zones.

Yes, updating config file don't affect other zones.













--

Thanks.
Zhengyu





At 2021-04-15 23:28:15, "Matus UHLAR - fantomas"  wrote:
>On 15.04.21 20:53, Zhengyu Pan wrote:
>>The  "intelligent" means that dns server return the corresponding A record IP 
>>address according  to the source IP address of the tenants.
>>My dns server is an Authoritative dns server. It hosts the zones of different 
>>tenants.
>
>do you mean, the same domains with different content, depending on clients'
>IPs? That's common multiple-view setup
>(nothing special or intelligent).
>
>>I need to update config file name.conf frequently Because The views and ACLS 
>>are added frequently.
>
>Why? Do you have that many clients constantly with changing IPs?
>
>Maybe they could use local DNS server talking to your DNS server using TSIG,
>and instead of IPs you'd define TSIG keys.
>
>>So i want to know whether have commands or API to add acl and view like the 
>>command "rndc addacl" or "rndc addview"?
>
>I'm afraid for now there's no  way to make this via rndc.
>You'll have to generate named config per-client.
>
>>Updating config file frequently may affect other zones in this dns server.
>
>I don't understand how/why it should affect other zones.
>
>
>
>>At 2021-04-15 15:08:26, "Matus UHLAR - fantomas"  wrote:
>>>On 15.04.21 15:35, Zhengyu Pan wrote:
>>>>I want to implement intelligent DNS through bind9.
>>>
>>>>I need to add a custom line(IP address ranges) to bind9 using acl and view
>>>> when add a user.  Because when add a tenant, i need to define a new acl
>>>> and view.  I don't want to update named.conf config file frequently.
>>>
>>>what is supposed to be intelligent there?
>>>
>>>I mean, why?  are you going to provide recursive service to someone who pays
>>>for that?
>>>
>>>> Does bind9 support adding acl and view through commands or API, not by 
>>>> updating config file?
>>>> like the command "rndc addacl" or "rndc addview".
>>>
>>>I don't think so, looks a bit too complicated.
>
>
>-- 
>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.
>- Have you got anything without Spam in it?
>- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.
>___
>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
___
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: Re: Does bind9 support adding acl and view through commands, not by updating config file?

[Matus UHLAR - fantomas]

On 15.04.21 20:53, Zhengyu Pan wrote:

The  "intelligent" means that dns server return the corresponding A record IP 
address according  to the source IP address of the tenants.
My dns server is an Authoritative dns server. It hosts the zones of different 
tenants.


do you mean, the same domains with different content, depending on clients'
IPs? That's common multiple-view setup
(nothing special or intelligent).


I need to update config file name.conf frequently Because The views and ACLS 
are added frequently.


Why? Do you have that many clients constantly with changing IPs?

Maybe they could use local DNS server talking to your DNS server using TSIG,
and instead of IPs you'd define TSIG keys.


So i want to know whether have commands or API to add acl and view like the command "rndc 
addacl" or "rndc addview"?


I'm afraid for now there's no  way to make this via rndc.
You'll have to generate named config per-client.


Updating config file frequently may affect other zones in this dns server.


I don't understand how/why it should affect other zones.




At 2021-04-15 15:08:26, "Matus UHLAR - fantomas"  wrote:

On 15.04.21 15:35, Zhengyu Pan wrote:

I want to implement intelligent DNS through bind9.



I need to add a custom line(IP address ranges) to bind9 using acl and view
when add a user.  Because when add a tenant, i need to define a new acl
and view.  I don't want to update named.conf config file frequently.


what is supposed to be intelligent there?

I mean, why?  are you going to provide recursive service to someone who pays
for that?


Does bind9 support adding acl and view through commands or API, not by updating 
config file?
like the command "rndc addacl" or "rndc addview".


I don't think so, looks a bit too complicated.



--
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.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.
___
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:Re: Does bind9 support adding acl and view through commands, not by updating config file?

[Zhengyu Pan]

The  "intelligent" means that dns server return the corresponding A record IP 
address according  to the source IP address of the tenants.
My dns server is an Authoritative dns server. It hosts the zones of different 
tenants.


I need to update config file name.conf frequently Because The views and ACLS 
are added frequently.
So i want to know whether have commands or API to add acl and view like the 
command "rndc addacl" or "rndc addview"?
Updating config file frequently may affect other zones in this dns server.

At 2021-04-15 15:08:26, "Matus UHLAR - fantomas"  wrote:
>On 15.04.21 15:35, Zhengyu Pan wrote:
>>I want to implement intelligent DNS through bind9.
>
>>I need to add a custom line(IP address ranges) to bind9 using acl and view
>> when add a user.  Because when add a tenant, i need to define a new acl
>> and view.  I don't want to update named.conf config file frequently.
>
>what is supposed to be intelligent there?
>
>I mean, why?  are you going to provide recursive service to someone who pays
>for that?
>
>> Does bind9 support adding acl and view through commands or API, not by 
>> updating config file?
>> like the command "rndc addacl" or "rndc addview".
>
>I don't think so, looks a bit too complicated.
>
>-- 
>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.
>Save the whales. Collect the whole set.
>___
>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
___
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: Does bind9 support adding acl and view through commands, not by updating config file?

[Matus UHLAR - fantomas]

On 15.04.21 15:35, Zhengyu Pan wrote:

I want to implement intelligent DNS through bind9.



I need to add a custom line(IP address ranges) to bind9 using acl and view
when add a user.  Because when add a tenant, i need to define a new acl
and view.  I don't want to update named.conf config file frequently.


what is supposed to be intelligent there?

I mean, why?  are you going to provide recursive service to someone who pays
for that?


Does bind9 support adding acl and view through commands or API, not by updating 
config file?
like the command "rndc addacl" or "rndc addview".


I don't think so, looks a bit too complicated.

--
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.
Save the whales. Collect the whole set.
___
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

Does bind9 support adding acl and view through commands, not by updating config file?

[Zhengyu Pan]

Hi,

I want to implement intelligent DNS through bind9. I need to add a custom 
line(IP address ranges) to bind9 using acl and view when add a user. Because 
when add a tenant, i need to define a new acl and view. I don't want to update 
named.conf config file frequently.

 Does bind9 support adding acl and view through commands or API, not by 
updating config file? 

 like the command "rndc addacl" or "rndc addview". 




 Thanks

 Zhengyu
















--

Thanks！
Zhengyu___
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: "in-view" behavior

[Mark Andrews]

> On 31 Oct 2020, at 06:07, John Thurston  wrote:
> 
> 
> I need to define several views. They will be largely identical, probably 
> differing in only one zone definition. What I had hoped to do was define all 
> the common zones in an unused-view, and then use "in-view" to reference the 
> several zones in the other views.
> 
> view "initial" { {match-clients "none"; };
>  zone foo { . . .};
>  zone bar { . . .};
> };
> 
> view "v1" { {match-clients key v1-key; };
>  allow-transfer { key v1-key; };
>  zone foo { in-view initial; };
>  zone bar { in-view initial; };
>  zone baz { . . .};
> };
> 
> I had expected the zones foo and bar to be shared from a single instance in 
> memory, that BIND would use the match-client to get the traffic to the 
> appropriate view, and then use that view's allow-transfer list. But the 
> behavior I'm observing is the allow-transfer of view v1 isn't being used.
> 
> When I use:
>  rndc zonestatus bar IN v1
> I can see the zone is defined on the primary. But when I try to transfer it 
> to the secondary using the v1-key, the request is REFUSED.
> 
> When I stuff the allow-transfer line from the "v1" view into the "initial" 
> view, the transfer initiated with v1-key succeeds.
> 
> I had been thinking of "allow-transfer" to be a property of a _view_, but it 
> now appears it may be assigned as a property to the _zones_ defined in that 
> view.
> 
> So my specific questions are:
> A) When I reference a zone with "in-view", can any properties be
>   superseded?

No.

> B) If so, which properties?

None.

> (FWIW, BIND version 9.11.24 on the primary and 9.16.8 on the secondary.)
> 
> 
> -- 
> --
> Do things because you should, not just because you can.
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> ___
> 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

"in-view" behavior

[John Thurston]

I need to define several views. They will be largely identical, probably 
differing in only one zone definition. What I had hoped to do was define 
all the common zones in an unused-view, and then use "in-view" to 
reference the several zones in the other views.


view "initial" { {match-clients "none"; };
  zone foo { . . .};
  zone bar { . . .};
};

view "v1" { {match-clients key v1-key; };
  allow-transfer { key v1-key; };
  zone foo { in-view initial; };
  zone bar { in-view initial; };
  zone baz { . . .};
};

I had expected the zones foo and bar to be shared from a single instance 
in memory, that BIND would use the match-client to get the traffic to 
the appropriate view, and then use that view's allow-transfer list. But 
the behavior I'm observing is the allow-transfer of view v1 isn't being 
used.


When I use:
  rndc zonestatus bar IN v1
I can see the zone is defined on the primary. But when I try to transfer 
it to the secondary using the v1-key, the request is REFUSED.


When I stuff the allow-transfer line from the "v1" view into the 
"initial" view, the transfer initiated with v1-key succeeds.


I had been thinking of "allow-transfer" to be a property of a _view_, 
but it now appears it may be assigned as a property to the _zones_ 
defined in that view.


So my specific questions are:
A) When I reference a zone with "in-view", can any properties be
   superseded?
B) If so, which properties?


(FWIW, BIND version 9.11.24 on the primary and 9.16.8 on the secondary.)


--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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: Dynamic update rejected within a view

[Per Weisteen]

On 14.07.2020 18:11, Zhiyong Cheng wrote:

在 2020年7月14日 +0800 PM9:06，Per Weisteen ，写道：

Hi

I've a BIND setup with my ISP with two views, one external and one 
internal. At the same time I also need to be able to do a dynamic 
update from some addresses within the internal range. This worked ok 
before I had to define my two views.


I'd be very grateful if someone could suggest what I'm doing wrong. 
My ISP is running BIND 9.11.4.


 Due to the ISPs need to have control over the BIND setup I'm just 
allowed to add my config via include files.



Zones.mydomains.config file contains:

include "keys/mydomains-keys.conf";

include "keys/zone1-keys.conf";

include "keys/zone2-keys.conf";

acl external { 10.222.33.0/18; 10.222.44.0/18; };

acl internal { 10.11.0.0/16; 10.12.0.0/16; };

//

// zone1 and zone2 keys used to ensure correct zone transfer from slave

//

view "external-sites" {

match-clients { !key zone2.key; key zone1.key; external; };

zone "aa.example.net" {

type master;

file "zones.master/aa-view1.example.net";

notify explicit;

also-notify { 10.12.143.56 key zone1.key; };

update-policy {

grant "ext-update.key." name web.aa.example.net. CNAME;

};

};

include "zones.common.config.view1";

}; // End view "external-sites"

view "internal-sites" {

match-clients { !key zone1.key; key zone2.key; internal; localhost; };

zone "aa.example.net" {

type master;

file "zones.master/aa-view2.example.net";

notify explicit;

also-notify { 10.12.143.56 key zone2.key; };

update-policy {

grant "int-update.key." name web.aa.example.net. CNAME;

};

};

include "zones.common.config.view2";

}; // End view "grus-zone2"

view "default" {

match-clients { any; };

include "zones.common.config.view2";

}; // End view "default"

mydomains-keys.conf file contains :

key ext-update.key. {

algorithm HMAC-SHA512;

secret "secret2";

};

key int-update.key. {

algorithm HMAC-SHA512;

secret "secret3";

};

Error message in /var/log/named/named.log is :


10-Jul-2020 13:27:14.695 update: info: client @0x7f0a200a9b30 
10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)


10-Jul-2020 13:28:13.883 update: info: client @0x7f0a200a9b30 
10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)




It seems that you have used a key named arc-zone2.key for updating but 
only

allow int-update.key for updating in configuration?


--
Best regards,
Per Weisteen


___
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


Zhiyong Cheng



Hi

I've managed to paste wrong error messages. The correct was :

10-Jul-2020 13:21:24.571 update: info: client @0x7f09500f432c 
10.11.131.23#5175/key int-update.key: view internal-sites: updating zone 
'aa.example.net/IN': update failed: rejected by secure update (REFUSED)


10-Jul-2020 13:21:24.759 update: info: client @0x7f09500f432c 
10.11.131.23#5175/key int-update.key: view internal-sites: updating zone 
'aa.example.net/IN': update failed: rejected by secure update (REFUSED)



I'll try Mark's suggestion.

Per W.
___
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: Dynamic update rejected within a view

[Zhiyong Cheng]

在 2020年7月14日 +0800 PM9:06，Per Weisteen ，写道：
> Hi
>
> I've a BIND setup with my ISP with two views, one external and one internal. 
> At the same time I also need to be able to do a dynamic update from some 
> addresses within the internal range. This worked ok before I had to define my 
> two views.
>
> I'd be very grateful if someone could suggest what I'm doing wrong. My ISP is 
> running BIND 9.11.4.
>
>  Due to the ISPs need to have control over the BIND setup I'm just allowed to 
> add my config via include files.
>
>
> Zones.mydomains.config file contains:
> include "keys/mydomains-keys.conf";
> include "keys/zone1-keys.conf";
> include "keys/zone2-keys.conf";
> acl external { 10.222.33.0/18; 10.222.44.0/18; };
> acl internal { 10.11.0.0/16; 10.12.0.0/16; };
> //////
> // zone1 and zone2 keys used to ensure correct zone transfer from slave
> //
> view "external-sites" {
> match-clients { !key zone2.key; key zone1.key; external; };
> zone "aa.example.net" {
> type master;
> file "zones.master/aa-view1.example.net";
> notify explicit;
> also-notify { 10.12.143.56 key zone1.key; };
> update-policy {
> grant "ext-update.key." name web.aa.example.net. CNAME;
> };
> };
> include "zones.common.config.view1";
> }; // End view "external-sites"
> view "internal-sites" {
> match-clients { !key zone1.key; key zone2.key; internal; localhost; };
> zone "aa.example.net" {
> type master;
> file "zones.master/aa-view2.example.net";
> notify explicit;
> also-notify { 10.12.143.56 key zone2.key; };
> update-policy {
> grant "int-update.key." name web.aa.example.net. CNAME;
> };
> };
> include "zones.common.config.view2";
> }; // End view "grus-zone2"
> view "default" {
> match-clients { any; };
> include "zones.common.config.view2";
> }; // End view "default"
> mydomains-keys.conf file contains :
> key ext-update.key. {
> algorithm HMAC-SHA512;
> secret "secret2";
> };
> key int-update.key. {
> algorithm HMAC-SHA512;
> secret "secret3";
> };
> Error message in /var/log/named/named.log is :
>
> 10-Jul-2020 13:27:14.695 update: info: client @0x7f0a200a9b30 
> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
> 'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)
> 10-Jul-2020 13:28:13.883 update: info: client @0x7f0a200a9b30 
> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
> 'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)
>

It seems that you have used a key named arc-zone2.key for updating but only
allow int-update.key for updating in configuration?

> --
> Best regards,
> Per Weisteen
>
>
> ___
> 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

Zhiyong Cheng
___
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: Dynamic update rejected within a view

[Sten Carlsen]

-- 
Best regards 
Sten Carlsen 


For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken


> On 14 Jul 2020, at 16.25, Mark Andrews  wrote:
> 
> Include the update keys in the view selection. 
> 
> -- 
> Mark Andrews
> 
>> On 14 Jul 2020, at 23:06, Per Weisteen  wrote:
>> 
>> Zones.mydomains.config file contains:
>> 
>>  
>> include "keys/mydomains-keys.conf";
>> include "keys/zone1-keys.conf";
>> include "keys/zone2-keys.conf";
>>  
>> view "external-sites" {
>> match-clients { !key zone2.key; key zone1.key; external; };

   -
>>  
>> zone "aa.example.net" {
>> Error message in /var/log/named/named.log is :
>> 
>> 
>> 10-Jul-2020 13:27:14.695 update: info: client @0x7f0a200a9b30 
>> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
>> 'pacs.telenor.net/IN': update
>> 


-----
Key names do not match.
>> failed: rejected by secure update (REFUSED)
>> 
>> 10-Jul-2020 13:28:13.883 update: info: client @0x7f0a200a9b30 
>> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
>> 'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)
>> 
>>  
>> 
>> 
>> 
>> -- 
>> Best regards,
>> Per Weisteen
>> 
>> 
>> ___
>> 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
> ___
> 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

___
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: Dynamic update rejected within a view

[Mark Andrews]

Include the update keys in the view selection. 

-- 
Mark Andrews

> On 14 Jul 2020, at 23:06, Per Weisteen  wrote:
> 
>  Hi
> 
> I've a BIND setup with my ISP with two views, one external and one internal. 
> At the same time I also need to be able to do a dynamic update from some 
> addresses within the internal range. This worked ok before I had to define my 
> two views. 
> 
> I'd be very grateful if someone could suggest what I'm doing wrong. My ISP is 
> running BIND 9.11.4.
> 
>  Due to the ISPs need to have control over the BIND setup I'm just allowed to 
> add my config via include files.
> 
>  
> Zones.mydomains.config file contains:
> 
>  
> include "keys/mydomains-keys.conf";
> include "keys/zone1-keys.conf";
> include "keys/zone2-keys.conf";
>  
> acl external { 10.222.33.0/18; 10.222.44.0/18; };
> acl internal { 10.11.0.0/16; 10.12.0.0/16; };
>  
> //
> // zone1 and zone2 keys used to ensure correct zone transfer from slave
> //
>  
> view "external-sites" {
> match-clients { !key zone2.key; key zone1.key; external; };
>  
> zone "aa.example.net" {
> type master;
> file "zones.master/aa-view1.example.net";
> notify explicit;
> also-notify { 10.12.143.56 key zone1.key; };
>     update-policy {
>     grant "ext-update.key." name web.aa.example.net. CNAME;
> };
> };
>  
> include "zones.common.config.view1";
>  
> }; // End view "external-sites"
>  
> view "internal-sites" {
> match-clients { !key zone1.key; key zone2.key; internal; localhost; };
>  
> zone "aa.example.net" {
> type master;
> file "zones.master/aa-view2.example.net";
> notify explicit;
> also-notify { 10.12.143.56 key zone2.key; };
> update-policy {
> grant "int-update.key." name web.aa.example.net. CNAME;
> };
> };
>  
> include "zones.common.config.view2";
>  
> }; // End view "grus-zone2"
>  
>  
>  
> view "default" {
> match-clients { any; };
>  
> include "zones.common.config.view2";
>  
> }; // End view "default"
>  
> 
> mydomains-keys.conf  file contains :
> 
>  
> 
> key ext-update.key. {
> algorithm HMAC-SHA512;
> secret "secret2";
> };
>  
> key int-update.key. {
> algorithm HMAC-SHA512;
> secret "secret3";
> };
>  
> 
> Error message in /var/log/named/named.log is :
> 
> 
> 
> 10-Jul-2020 13:27:14.695 update: info: client @0x7f0a200a9b30 
> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
> 'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)
> 
> 10-Jul-2020 13:28:13.883 update: info: client @0x7f0a200a9b30 
> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
> 'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)
> 
>  
> 
> 
> 
> -- 
> Best regards,
> Per Weisteen
> 
> 
> ___
> 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
___
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

Dynamic update rejected within a view

[Per Weisteen]

Hi

I've a BIND setup with my ISP with two views, one external and one 
internal. At the same time I also need to be able to do a dynamic update 
from some addresses within the internal range. This worked ok before I 
had to define my two views.


I'd be very grateful if someone could suggest what I'm doing wrong. My 
ISP is running BIND 9.11.4.


 Due to the ISPs need to have control over the BIND setup I'm just 
allowed to add my config via include files.



Zones.mydomains.config file contains:

include "keys/mydomains-keys.conf";

include "keys/zone1-keys.conf";

include "keys/zone2-keys.conf";

acl external { 10.222.33.0/18; 10.222.44.0/18; };

acl internal { 10.11.0.0/16; 10.12.0.0/16; };

//

// zone1 and zone2 keys used to ensure correct zone transfer from slave

//

view "external-sites" {

    match-clients { !key zone2.key; key zone1.key; external; };

zone "aa.example.net" {

type master;

    file "zones.master/aa-view1.example.net";

    notify explicit;

    also-notify { 10.12.143.56 key zone1.key; };

    update-policy {

    grant "ext-update.key." name web.aa.example.net. CNAME;

    };

    };

    include "zones.common.config.view1";

}; // End view "external-sites"

view "internal-sites" {

    match-clients { !key zone1.key; key zone2.key; internal; localhost; };

    zone "aa.example.net" {

    type master;

    file "zones.master/aa-view2.example.net";

    notify explicit;

    also-notify { 10.12.143.56 key zone2.key; };

    update-policy {

    grant "int-update.key." name web.aa.example.net. CNAME;

    };

    };

    include "zones.common.config.view2";

}; // End view "grus-zone2"

view "default" {

    match-clients { any; };

    include "zones.common.config.view2";

}; // End view "default"

mydomains-keys.conf  file contains :

key ext-update.key. {

algorithm HMAC-SHA512;

secret "secret2";

};

key int-update.key. {

algorithm HMAC-SHA512;

secret "secret3";

};

Error message in /var/log/named/named.log is :


10-Jul-2020 13:27:14.695 update: info: client @0x7f0a200a9b30 
10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)


10-Jul-2020 13:28:13.883 update: info: client @0x7f0a200a9b30 
10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)



--
Best regards,
Per Weisteen


___
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: Localhost view is not working for me SOLVED!

[Marc Chamberlin via bind-users]

Thanks Bob,  while your suggestions didn't help directly they did put me
on a path that eventually lead to the solution.  Turns out I had an ill
defined SOA record along with a ill defined NS record (copy/paste error)
that was the problem in my localhost zone.  I think I am once again a
happy camper.

 Marc..

On 3/30/20 11:42 AM, Bob Harold wrote:
> Try without the "match-destinations".  Only use match-clients to
> determine the view.  (Or try only match-destinations as a separate test.)
> (I have never used match-destinations.)
> Turn on query logging and see what source and destination your queries
> are using.  Make fake queries to unique names just to be sure which
> queries you are looking at.
> That's the best that I can suggest.
>
> -- 
> Bob Harold
>
>
> On Mon, Mar 30, 2020 at 1:07 PM Marc Chamberlin via bind-users
> mailto:bind-users@lists.isc.org>> wrote:
>
> Hello -  I am running the Bind server
>
> > named -v
> BIND 9.11.2 
>
> under OpenSuSE Leap 15.0. In order to support other servers
> running on the same system that my Bind server is running on I am
> trying to set up 3 views, one for the localhost, one for my
> internal network to use, and one for the external Internet.  (yes
> this is also a gateway system with 2 NIC cards.) What I am having
> troubles with is getting the localhost view to work properly. I
> have tried a number of ways to get this to work and will show the
> apropos segment of my named.conf file below.  Commented out
> sections show things I have tried already but rejected because the
> results I get from queries, from other servers on this
> gateway/localhost system, that are not what I want.  For example
> if I use the definition in with localhost is defined, rather than
> 127.0.0.1, I will get results that are defined by my internal view
> which is not acceptable.  If I use 127.0.0.1 instead, lookup query
> results from/for the other servers running on my gateway/localhost
> fail completely with no results returned.  I don't understand why
> 127.0.0.1 fails, it seems like this should be the proper way to
> limit the scope of localhost queries so that they are answered by
> definitions defined in my "localhost_resolver" view.  What am I
> missing? How to I set up the "localhost_resolver" view so that it
> will answer queries from localhost without falling through to my
> "internal" view?   (The keys are also necessary to restrict
> certain types of queries but I tried not using them and got the
> same inadequate responses to  queries from the localhost.)
>
> I have also used dig to show exactly what view was answering
> queries from localhost and it verified that the queries were
> indeed being answered by my internal view when I used localhost in
> the match-clients and match-destinations statements.  If necessary
> I can post other files, such as the local_zones.conf or some of
> the domain definition files themselves but will have to edit them
> to remove actual URLs and other sensitive information.  I checked
> the log files also, after setting the debug level to 10, and the
> Bind server reports no errors or warnings when it is started up.
> Thanks for any help offered, and below is what I think is the
> relevant part of my named.conf file.
>
>  Marc
>
>> view "localhost_resolver"
>> {
>> //    match-clients   { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>> //    match-destinations  { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>>
>>     match-clients   { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; 127.0.0.1; };
>>     match-destinations  { ! key letsencrypt.; ! key
>> rndc-key.; ! key letsencrypt_amcrest.; 127.0.0.1; };
>>
>>     // match-clients   { 127.0.0.1; };
>>     // match-destinations  { 127.0.0.1; };
>>
>>     recursion yes;
>>     zone "." in {
>>     type hint;
>>     file "root.hint";
>>     };
>>     zone "localhost" in {
>>     type master;
>>     file "localhost.zone";
>>     allow-update { none; };
>>     };
>>     zone "0.0.127.in-addr.arpa" in {
>>     type master;
>>     file "127.0.0.zone";
>>  

Re: Localhost view is not working for me

[Bob Harold]

Try without the "match-destinations".  Only use match-clients to determine
the view.  (Or try only match-destinations as a separate test.)
(I have never used match-destinations.)
Turn on query logging and see what source and destination your queries are
using.  Make fake queries to unique names just to be sure which queries you
are looking at.
That's the best that I can suggest.

-- 
Bob Harold


On Mon, Mar 30, 2020 at 1:07 PM Marc Chamberlin via bind-users <
bind-users@lists.isc.org> wrote:

> Hello -  I am running the Bind server
>
> > named -v
> BIND 9.11.2 
>
> under OpenSuSE Leap 15.0. In order to support other servers running on the
> same system that my Bind server is running on I am trying to set up 3
> views, one for the localhost, one for my internal network to use, and one
> for the external Internet.  (yes this is also a gateway system with 2 NIC
> cards.) What I am having troubles with is getting the localhost view to
> work properly. I have tried a number of ways to get this to work and will
> show the apropos segment of my named.conf file below.  Commented out
> sections show things I have tried already but rejected because the results
> I get from queries, from other servers on this gateway/localhost system,
> that are not what I want.  For example if I use the definition in with
> localhost is defined, rather than 127.0.0.1, I will get results that are
> defined by my internal view which is not acceptable.  If I use 127.0.0.1
> instead, lookup query results from/for the other servers running on my
> gateway/localhost fail completely with no results returned.  I don't
> understand why 127.0.0.1 fails, it seems like this should be the proper way
> to limit the scope of localhost queries so that they are answered by
> definitions defined in my "localhost_resolver" view.  What am I missing?
> How to I set up the "localhost_resolver" view so that it will answer
> queries from localhost without falling through to my "internal" view?
> (The keys are also necessary to restrict certain types of queries but I
> tried not using them and got the same inadequate responses to  queries from
> the localhost.)
>
> I have also used dig to show exactly what view was answering queries from
> localhost and it verified that the queries were indeed being answered by my
> internal view when I used localhost in the match-clients and
> match-destinations statements.  If necessary I can post other files, such
> as the local_zones.conf or some of the domain definition files themselves
> but will have to edit them to remove actual URLs and other sensitive
> information.  I checked the log files also, after setting the debug level
> to 10, and the Bind server reports no errors or warnings when it is started
> up. Thanks for any help offered, and below is what I think is the relevant
> part of my named.conf file.
>
>  Marc
>
> view "localhost_resolver"
> {
> //match-clients   { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localhost; };
> //match-destinations  { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localhost; };
>
> match-clients   { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 127.0.0.1; };
> match-destinations  { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 127.0.0.1; };
>
> // match-clients   { 127.0.0.1; };
> // match-destinations  { 127.0.0.1; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> zone "localhost" in {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> allow-update { none; };
> };
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" in
> {
> type master;
> file "127.0.0.zone";
> };
> include "/etc/named.d/local/local_zones.conf";
> };
>
> view "internal" { // What the home network will see
> //  match-clients  { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; localnets; localhost; };
> //  match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; localnets; localhost; };
>
> //  match-clients  { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
> //  match-destinations {

Localhost view is not working for me

[Marc Chamberlin via bind-users]

Hello -  I am running the Bind server

> named -v
BIND 9.11.2 

under OpenSuSE Leap 15.0. In order to support other servers running on
the same system that my Bind server is running on I am trying to set up
3 views, one for the localhost, one for my internal network to use, and
one for the external Internet.  (yes this is also a gateway system with
2 NIC cards.) What I am having troubles with is getting the localhost
view to work properly. I have tried a number of ways to get this to work
and will show the apropos segment of my named.conf file below. 
Commented out sections show things I have tried already but rejected
because the results I get from queries, from other servers on this
gateway/localhost system, that are not what I want.  For example if I
use the definition in with localhost is defined, rather than 127.0.0.1,
I will get results that are defined by my internal view which is not
acceptable.  If I use 127.0.0.1 instead, lookup query results from/for
the other servers running on my gateway/localhost fail completely with
no results returned.  I don't understand why 127.0.0.1 fails, it seems
like this should be the proper way to limit the scope of localhost
queries so that they are answered by definitions defined in my
"localhost_resolver" view.  What am I missing? How to I set up the
"localhost_resolver" view so that it will answer queries from localhost
without falling through to my "internal" view?   (The keys are also
necessary to restrict certain types of queries but I tried not using
them and got the same inadequate responses to  queries from the localhost.)

I have also used dig to show exactly what view was answering queries
from localhost and it verified that the queries were indeed being
answered by my internal view when I used localhost in the match-clients
and match-destinations statements.  If necessary I can post other files,
such as the local_zones.conf or some of the domain definition files
themselves but will have to edit them to remove actual URLs and other
sensitive information.  I checked the log files also, after setting the
debug level to 10, and the Bind server reports no errors or warnings
when it is started up. Thanks for any help offered, and below is what I
think is the relevant part of my named.conf file.

 Marc

> view "localhost_resolver"
> {
> //    match-clients   { ! key letsencrypt.; ! key
> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
> //    match-destinations  { ! key letsencrypt.; ! key
> rndc-key.; ! key letsencrypt_amcrest.; localhost; };
>
>     match-clients   { ! key letsencrypt.; ! key rndc-key.;
> ! key letsencrypt_amcrest.; 127.0.0.1; };
>     match-destinations  { ! key letsencrypt.; ! key rndc-key.;
> ! key letsencrypt_amcrest.; 127.0.0.1; };
>
>     // match-clients   { 127.0.0.1; };
>     // match-destinations  { 127.0.0.1; };
>
>     recursion yes;
>     zone "." in {
>     type hint;
>     file "root.hint";
>     };
>     zone "localhost" in {
>     type master;
>     file "localhost.zone";
>     allow-update { none; };
>     };
>     zone "0.0.127.in-addr.arpa" in {
>     type master;
>     file "127.0.0.zone";
>     allow-update { none; };
>     };
>     zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
> in {
>     type master;
>     file "127.0.0.zone";
>     };
>     include "/etc/named.d/local/local_zones.conf";
> };
>
> view "internal" { // What the home network will see
> //  match-clients  { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localnets; localhost; };
> //  match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localnets; localhost; };
>
> //  match-clients  { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
> //  match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
>
>   match-clients  { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
>   match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; };
>
> //   match-clients  { 192.168.10.0/24; };
> //   match-destinations { 192.168.10.0/24; };
>
>    recursion yes;
>    zone "." in {
>    type hint;
>    file "root.hint";
>    };
>    include "/etc/named.d/internal/internal_zones.conf";
> };
> view "external" { // What the 

Re: What is wrong in the view matching below

[Niall O'Reilly]

On 5 Dec 2019, at 13:49, Harshith Mulky wrote:

> view "external" {
>
>   match-clients { any; };
>
>   recursion no;
>
> zone "nixcraft.com" IN {
>
>     type master;
>
>     file "internet.master.nixcraft.com";
>
>   };
>
> };
>
> view "internal" {
>
> match-clients { internal; };
>
> allow-recursion { any; };
>
 ...
> };

With the views in this order, the external view will always be used.

This is because the configuration is scanned from the top until a view
is found whose `match-clients` specification matches the requesting
client; that view is then used. Since you have `match-clients { any; };`
in the first view, scanning will stop there.

Niall O'Reilly
___
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: What is wrong in the view matching below

[Bob Harold]

On Thu, Dec 5, 2019 at 8:49 AM Harshith Mulky 
wrote:

> Thank you. I corrected this
>
> acl internal {
>10.54.8.0/24;
>localhost;
> };
>
> view "external" {
>   match-clients { any; };
>   recursion no;
> zone "nixcraft.com" IN {
> type master;
> file "internet.master.nixcraft.com";
>   };
> };
> view "internal" {
> match-clients { internal; };
> allow-recursion { any; };
> zone "." in {
> type hint;
> file "root.hint";
> };
>
> zone "localhost" in {
> type master;
> file "localhost.zone";
> };
>
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> };
>
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN
> {
> type master;
> file "127.0.0.zone";
> };
>
> zone "internal.nixcraft.com" IN {
> type master;
> file "lan.master.nixcraft.com";
>   };
> };
>
>
> But still getting same error
>
> /var/lib/named # named-checkzone internal.nixcraft.com
> lan.master.nixcraft.com
> lan.master.nixcraft.com:3: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:10: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:11: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:13: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:14: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:16: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:17: ignoring out-of-zone data (ns1.nixcraft.com)
> lan.master.nixcraft.com:18: ignoring out-of-zone data (ns2.nixcraft.com)
> lan.master.nixcraft.com:19: ignoring out-of-zone data (mail1.nixcraft.com)
> lan.master.nixcraft.com:20: ignoring out-of-zone data (mail2.nixcraft.com)
> lan.master.nixcraft.com:21: ignoring out-of-zone data (
> out-router.nixcraft.com)
> lan.master.nixcraft.com:23: ignoring out-of-zone data (wks1.nixcraft.com)
> lan.master.nixcraft.com:24: ignoring out-of-zone data (wks2.nixcraft.com)
> lan.master.nixcraft.com:25: ignoring out-of-zone data (wks3.nixcraft.com)
> lan.master.nixcraft.com:26: ignoring out-of-zone data (
> in-router.nixcraft.com)
> zone internal.nixcraft.com/IN: has 0 SOA records
> zone internal.nixcraft.com/IN: has no NS records
> zone internal.nixcraft.com/IN: not loaded due to errors.
>
>
> --
> *From:* Ondřej Surý 
> *Sent:* Thursday, December 5, 2019 6:42 PM
> *To:* Sten Carlsen 
> *Cc:* Harshith Mulky ;
> bind-users@lists.isc.org 
> *Subject:* Re: What is wrong in the view matching below
>
> There’s a space after com
>
> O.
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 5 Dec 2019, at 13:29, Sten Carlsen  wrote:
> >
> >>
> >> zone "internal.nixcraft.com " IN {
> >> type master;
> >> file "lan.master.nixcraft.com";
> >>   };
> >> };
> >
> > Looks like the file lan.master.nixcraft.com has no data.
> >
> >>
> >> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
> >> internal.nixcraft.com\032/IN/internal:
> has 0 SOA records
> >> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
> >> internal.nixcraft.com\032/IN/internal:
> has no NS records
> >> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
> >> internal.nixcraft.com\032/IN/internal:
> not loaded due to errors.
> >>
> >> Please help
> >>
> >> Thanks
>

named.conf says:
zone "internal.nixcraft.com" IN {
type master;
file "lan.master.nixcraft.com";

But the zone file has:
$ORIGIN nixcraft.com.

Is the zone "nixcraft.com" or "internal.nixcraft.com" ?  They need to match.

-- 
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

Re: What is wrong in the view matching below

[Harshith Mulky]

Thank you. I corrected this

acl internal {
   10.54.8.0/24;
   localhost;
};

view "external" {
  match-clients { any; };
  recursion no;
zone "nixcraft.com" IN {
type master;
file "internet.master.nixcraft.com";
  };
};
view "internal" {
match-clients { internal; };
allow-recursion { any; };
zone "." in {
type hint;
file "root.hint";
};

zone "localhost" in {
type master;
file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" 
IN {
type master;
file "127.0.0.zone";
};

zone "internal.nixcraft.com" IN {
type master;
file "lan.master.nixcraft.com";
  };
};


But still getting same error

/var/lib/named # named-checkzone internal.nixcraft.com lan.master.nixcraft.com
lan.master.nixcraft.com:3: ignoring out-of-zone data (nixcraft.com)
lan.master.nixcraft.com:10: ignoring out-of-zone data (nixcraft.com)
lan.master.nixcraft.com:11: ignoring out-of-zone data (nixcraft.com)
lan.master.nixcraft.com:13: ignoring out-of-zone data (nixcraft.com)
lan.master.nixcraft.com:14: ignoring out-of-zone data (nixcraft.com)
lan.master.nixcraft.com:16: ignoring out-of-zone data (nixcraft.com)
lan.master.nixcraft.com:17: ignoring out-of-zone data (ns1.nixcraft.com)
lan.master.nixcraft.com:18: ignoring out-of-zone data (ns2.nixcraft.com)
lan.master.nixcraft.com:19: ignoring out-of-zone data (mail1.nixcraft.com)
lan.master.nixcraft.com:20: ignoring out-of-zone data (mail2.nixcraft.com)
lan.master.nixcraft.com:21: ignoring out-of-zone data (out-router.nixcraft.com)
lan.master.nixcraft.com:23: ignoring out-of-zone data (wks1.nixcraft.com)
lan.master.nixcraft.com:24: ignoring out-of-zone data (wks2.nixcraft.com)
lan.master.nixcraft.com:25: ignoring out-of-zone data (wks3.nixcraft.com)
lan.master.nixcraft.com:26: ignoring out-of-zone data (in-router.nixcraft.com)
zone internal.nixcraft.com/IN: has 0 SOA records
zone internal.nixcraft.com/IN: has no NS records
zone internal.nixcraft.com/IN: not loaded due to errors.



From: Ondřej Surý 
Sent: Thursday, December 5, 2019 6:42 PM
To: Sten Carlsen 
Cc: Harshith Mulky ; bind-users@lists.isc.org 

Subject: Re: What is wrong in the view matching below

There’s a space after com

O.
--
Ondřej Surý
ond...@isc.org

> On 5 Dec 2019, at 13:29, Sten Carlsen  wrote:
>
>>
>> zone "internal.nixcraft.com " IN {
>> type master;
>> file "lan.master.nixcraft.com";
>>   };
>> };
>
> Looks like the file lan.master.nixcraft.com has no data.
>
>>
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
>> internal.nixcraft.com\032/IN/internal: has 0 SOA records
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
>> internal.nixcraft.com\032/IN/internal: has no NS records
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
>> internal.nixcraft.com\032/IN/internal: not loaded due to errors.
>>
>> Please help
>>
>> 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
>
> ___
> 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: What is wrong in the view matching below

[Ondřej Surý]

There’s a space after com

O.
--
Ondřej Surý
ond...@isc.org

> On 5 Dec 2019, at 13:29, Sten Carlsen  wrote:
> 
>> 
>> zone "internal.nixcraft.com " IN {
>> type master;
>> file "lan.master.nixcraft.com";
>>   };
>> };
> 
> Looks like the file lan.master.nixcraft.com has no data.
> 
>> 
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
>> internal.nixcraft.com\032/IN/internal: has 0 SOA records
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
>> internal.nixcraft.com\032/IN/internal: has no NS records
>> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
>> internal.nixcraft.com\032/IN/internal: not loaded due to errors.
>> 
>> Please help
>> 
>> 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
> 
> ___
> 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: What is wrong in the view matching below

[Sten Carlsen]

> 
> zone "internal.nixcraft.com  " IN {
> type master;
> file "lan.master.nixcraft.com ";
>   };
> };

Looks like the file lan.master.nixcraft.com has no data.

> 
> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone internal.nixcraft.com 
> \032/IN/internal: has 0 SOA records
> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone internal.nixcraft.com 
> \032/IN/internal: has no NS records
> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone internal.nixcraft.com 
> \032/IN/internal: not loaded due to errors.
> 
> Please help
> 
> 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 
> 
___
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

What is wrong in the view matching below

[Harshith Mulky]

I have setup view matching as below on my bind server running version 
"bind-9.9.5P1-2.2.2.x86_64"

my /etc/named.conf is as below

options {

directory "/var/lib/named";
#dnssec-enable yes;
managed-keys-directory "/var/lib/named/dyn/";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
listen-on-v6 { any; };
notify no;

disable-empty-zone 
"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
};

acl internal {
   192.168.24.0/24;
   localhost;
};

view "internal" {
match-clients { internal; };
allow-recursion { any; };
zone "." in {
type hint;
file "root.hint";
};

zone "localhost" in {
type master;
file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" 
IN {
    type master;
file "127.0.0.zone";
};

zone "internal.nixcraft.com " IN {
type master;
file "lan.master.nixcraft.com";
  };
};

view "external" {
  match-clients { any; };
  recursion no;
zone "nixcraft.com " IN {
type master;
file "internet.master.nixcraft.com";
  };
};


Zone file lan.master.nixcraft.com as below

$ORIGIN nixcraft.com.
$TTL 3h
@IN SOA ns1.nixcraft.com. vivek.nixcraft.com. (
   2008070332; Serial mmddnn
   3h; Refresh After 3 hours
   1h; Retry Retry after 1 hour
   1h; Expire after 1 week 1w
   1h) ; Minimum negative caching of 1 hour

@  IN NSns1.nixcraft.com.
@  IN NSns2.nixcraft.com.

@  3600 IN MX 10 mail1.nixcraft.com.
@  3600 IN MX 20 mail2.nixcraft.com.

@  3600IN A 208.43.79.236
ns13600IN A 208.43.138.52
ns23600IN A 75.126.168.152
mail1  3600IN A 208.43.79.236
mail2  3600IN A 67.228.49.229
out-router 3600IN A 208.43.79.100
; lan data
wks1   3600IN A 192.168.1.5
wks2   3600IN A 192.168.1.5
wks3   3600IN A 192.168.1.5
in-router  3600IN A 192.168.1.254
; add other lan specifc data below


These are the examples from:
https://www.cyberciti.biz/faq/linux-unix-bind9-named-configure-views/

When starting named:
I am getting error as below

Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
internal.nixcraft.com\032/IN/internal: has 0 SOA records
Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
internal.nixcraft.com\032/IN/internal: has no NS records
Dec 05 17:51:54 sataradnsVM1 named[4038]: zone 
internal.nixcraft.com\032/IN/internal: not loaded due to errors.

Please help

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: Bind with views: forward any public domain in one view

[Roberto Carna]

Thanks a lot !!!

El jue., 15 ago. 2019 a las 13:09, Matus UHLAR - fantomas (<
uh...@fantomas.sk>) escribió:

> On 15.08.19 12:18, Roberto Carna wrote:
> >Dear, I have a BIND 9 working with two views.
> >
> >One view forwards two public domains to our resolver.
> >
> >And I want the second view to forward any public domain to our resolver in
> >order to let navigate withouth restrictions.
>
> what restricions and where are they applied?
>
> >I need something like this:
> >
> >zone "ANY" {
> >type forward;
> >forward only;
> >forwarders {
> >8.8.8.8;
> >};
> >};
> >
> >How can I implement this second option ???  Can I replace ANY for the
> >correct wildcard ???
>
> "." should be enough, but note that BIND can do the same that google
> servers
> (8.8.8.8) can do, and you'll avoid one hop.
>
> simply don't forward but let BIND to resolve.
> --
> 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.
> The early bird may get the worm, but the second mouse gets the cheese.
> ___
> 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: Bind with views: forward any public domain in one view

[Matus UHLAR - fantomas]

On 15.08.19 12:18, Roberto Carna wrote:

Dear, I have a BIND 9 working with two views.

One view forwards two public domains to our resolver.

And I want the second view to forward any public domain to our resolver in
order to let navigate withouth restrictions.


what restricions and where are they applied?


I need something like this:

zone "ANY" {
   type forward;
   forward only;
   forwarders {
   8.8.8.8;
   };
};

How can I implement this second option ???  Can I replace ANY for the
correct wildcard ???


"." should be enough, but note that BIND can do the same that google servers
(8.8.8.8) can do, and you'll avoid one hop.

simply don't forward but let BIND to resolve.
--
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.
The early bird may get the worm, but the second mouse gets the cheese.
___
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

Bind with views: forward any public domain in one view

[Roberto Carna]

Dear, I have a BIND 9 working with two views.

One view forwards two public domains to our resolver.

And I want the second view to forward any public domain to our resolver in
order to let navigate withouth restrictions.

I need something like this:

zone "ANY" {
type forward;
forward only;
forwarders {
8.8.8.8;
};
};

How can I implement this second option ???  Can I replace ANY for the
correct wildcard ???

Thanks a lot !!!
___
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: Forward zone inside a view

[Tony Finch]

Grant Taylor via bind-users  wrote:
>
> I know it's not yet an option and won't yet work for Roberto C., but would
> BIND's forthcoming "mirror" zone type change any of this?

No.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
safeguard the balance of nature and the environment
___
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: Forward zone inside a view

[Kevin Darcy]

Controlling DNS resolution isn't the panacea for all security challenges,
but then neither is a firewall. Or IPS. Or DLP. Or
blacklisting/whitelisting. Or restrictive routing. Or NAT'ing. But some
combination of those can be part of an overall security strategy. Defense
in depth.


- Kevin

On Tue, Feb 12, 2019 at 6:34 PM Timothe Litt  wrote:

> All these replies are correct in the details (as usual), but miss the
> point.
>
> Blocking name resolution, while popular, does not meet the OP's
> requirement:
>
> "The point is I have several desktops that *must* have access **only** to
> internal domains.*"
>
> Let's say that your client's favorite illicit site is facebook.com.
>
> One dig (or host) command reveals that:
>
>   facebook.com has address 157.240.3.35
>  facebook.com has IPv6 address 2a03:2880:f101:83:face:b00c:0:25de
>
> Fits on scrap of paper.  Carry in to office.  Connect - with a Host header
> for http, SNI for TLS, and off you go.  Or just put it in hosts.txt/hosts.
>
> Or use a public nameserver.   Or...
>
> If you want to block access, you need a firewall.  If you merely want to
> inconvenience people or reduce the risk of clicking on ransomware
> hyperlinks, mess with their default nameserver.  RPZ is good for that.  If
> you have a private address space & need to resolve some names differently
> inside and out, views are good for that. (Or you can have a different
> nameserver; tastes vary.)  If you are resource limited and want to benefit
> from a public server's larger cache, while serving authoritatively some
> local names, forwarding can be a good choice.
>
> But "**must** have access **only**" implies that one expects that the
> solution should resist *more* than a cooperative or unmotivated client.  NO
> DNS-only based solution will do that.
>
> Governments and political pressure groups think that DNS corruption is an
> effective tool for limiting access.  People here know better.  It deters
> certain casual problem behavior.  It does not prevent anyone with a modicum
> of knowledge and determination from watching cat videos.  (Or downloading
> malware, or whatever other behavior a policy maker wishes to ban.)
>
> It is worth listening to the OP's problem statement and steering him away
> from illusory technology.  It's the responsible thing to do.
>
> That there are technical answers to the question asked doesn't mean that
> it's the right question.  If it's not (and in this case it does not appear
> to be), those answers are not helpful.  Even though they are correct in
> other contexts.
>
>
> 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-Feb-19 17:45, Kevin Darcy wrote:
>
>
> Define root zone.
>
> Delegate teamviewer.com from root zone.
>
> Define teamviewer.com as "type forward".
>
> "recursion no" is incompatible with *any* type of forwarding or iterative
> resolution. Should only be used if *everything* you resolve is from
> authoritative data, i.e. for a hosting-only BIND instance. Since you want
> to forward -- selectively -- you need "recursion yes". Nothing outside of
> that part of the namespace will be forwarded, since named considers
> everything else to be contained in the root zone.
>
>
>   - Kevin
>
> On Mon, Feb 11, 2019 at 9:06 AM Roberto Carna 
> wrote:
>
>> Matus, I've followed whatyou say:
>>
>> view "internet" {
>>match-clients { internet_clients; key "pnet"; };
>>
>> recursion yes;
>>
>> zone "teamviewer.com" {
>> type forward;
>> forward only;
>> forwarders {
>> 8.8.8.8;
>> };
>> };
>>
>> };
>>
>> but clients can resolve ANY public Internet domain, in addition to
>> teamviewer.comI think "recursion yes" apply to every public domain and
>> not just for "teamviewer.com", but I don't know why.
>>
>> Please can yoy give me more details, using forward or not, how can let
>> some clients resolve just teamviewer.com ??? I confirm that my BIND is
>> an authorittaive name server for internal domains.
>>
>> Thanks a lot again.
>>
>> El lun., 11 feb. 2019 a las 10:49, Matus UHLAR - fantomas (<
>> uh...@fantomas.sk>) escribió:
>>
>>> On 11.02.19 10:38, Roberto Carna wrote:
>>> >Dear Mathus, thanks al lot for your help.
>>> >
>>> >>> what is the point of running DNS server with only two hostnames
>>

Re: Forward zone inside a view

[Timothe Litt]

All these replies are correct in the details (as usual), but miss the point.

Blocking name resolution, while popular, does not meet the OP's requirement:

"The point is I have several desktops that *must* have access **only**
to internal domains.*"

Let's say that your client's favorite illicit site is facebook.com.

One dig (or host) command reveals that:

  facebook.com has address 157.240.3.35
 facebook.com has IPv6 address 2a03:2880:f101:83:face:b00c:0:25de

Fits on scrap of paper.  Carry in to office.  Connect - with a Host
header for http, SNI for TLS, and off you go.  Or just put it in
hosts.txt/hosts.

Or use a public nameserver.   Or...

If you want to block access, you need a firewall.  If you merely want to
inconvenience people or reduce the risk of clicking on ransomware
hyperlinks, mess with their default nameserver.  RPZ is good for that. 
If you have a private address space & need to resolve some names
differently inside and out, views are good for that. (Or you can have a
different nameserver; tastes vary.)  If you are resource limited and
want to benefit from a public server's larger cache, while serving
authoritatively some local names, forwarding can be a good choice.

But "**must** have access **only**" implies that one expects that the
solution should resist *more* than a cooperative or unmotivated client. 
NO DNS-only based solution will do that.

Governments and political pressure groups think that DNS corruption is
an effective tool for limiting access.  People here know better.  It
deters certain casual problem behavior.  It does not prevent anyone with
a modicum of knowledge and determination from watching cat videos.  (Or
downloading malware, or whatever other behavior a policy maker wishes to
ban.)

It is worth listening to the OP's problem statement and steering him
away from illusory technology.  It's the responsible thing to do.

That there are technical answers to the question asked doesn't mean that
it's the right question.  If it's not (and in this case it does not
appear to be), those answers are not helpful.  Even though they are
correct in other contexts.


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-Feb-19 17:45, Kevin Darcy wrote:

> Define root zone. 
>
> Delegate teamviewer.com <http://teamviewer.com> from root zone.
>
> Define teamviewer.com <http://teamviewer.com> as "type forward".
>
> "recursion no" is incompatible with *any* type of forwarding or
> iterative resolution. Should only be used if *everything* you resolve
> is from authoritative data, i.e. for a hosting-only BIND instance.
> Since you want to forward -- selectively -- you need "recursion yes".
> Nothing outside of that part of the namespace will be forwarded, since
> named considers everything else to be contained in the root zone.
>
>                                                                      
>           - Kevin
>
> On Mon, Feb 11, 2019 at 9:06 AM Roberto Carna
> mailto:robertocarn...@gmail.com>> wrote:
>
> Matus, I've followed whatyou say:
>
> view "internet" {
>    match-clients { internet_clients; key "pnet"; };
>
> recursion yes;
>
> zone "teamviewer.com <http://teamviewer.com>" {
>         type forward;
>         forward only;
>         forwarders {
>                 8.8.8.8;
>         };
> };
>
> };
>
> but clients can resolve ANY public Internet domain, in addition to
> teamviewer.comI think "recursion yes" apply to every public
> domain and not just for "teamviewer.com <http://teamviewer.com>",
> but I don't know why.
>
> Please can yoy give me more details, using forward or not, how can
> let some clients resolve just teamviewer.com
> <http://teamviewer.com> ??? I confirm that my BIND is an
> authorittaive name server for internal domains.
>
> Thanks a lot again.
>
> El lun., 11 feb. 2019 a las 10:49, Matus UHLAR - fantomas
> (mailto:uh...@fantomas.sk>>) escribió:
>
> On 11.02.19 10:38, Roberto Carna wrote:
> >Dear Mathus, thanks al lot for your help.
> >
> >>> what is the point of running DNS server with only two
> hostnames allowed
> >>> to resolve?
> >
> >The point is I have several desktops that must have access
> only to internal
> >domains. The unique exception is they have access to
> teamviewer.com <http://teamviewer.com>  in
> >order to download the Teamviewer client and a 

Re: Forward zone inside a view

[Grant Taylor via bind-users]

On 02/12/2019 03:45 PM, Kevin Darcy wrote:
"recursion no" is incompatible with *any* type of forwarding or 
iterative resolution. Should only be used if *everything* you resolve is 
from authoritative data, i.e. for a hosting-only BIND instance.


I know it's not yet an option and won't yet work for Roberto C., but 
would BIND's forthcoming "mirror" zone type change any of this?




--
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: Forward zone inside a view

[Grant Taylor via bind-users]

On 02/07/2019 07:02 PM, Paul Kosinski wrote:
I haven't analyzed the details and pitfalls, but could a Web proxy 
mechanism of some sort be of help? In particular, rather than having 
your users directly access "teamviewer.org" (or whatever), have them to 
access "teamviewer.local", which is resolved by your internal DNS to a 
specialized proxy server.


It sounds like you might be talking about using a reverse proxy of sorts 
to translate internal requests for teamviewer.local to external requests 
for teamviewer.com.


Then set up this proxy server to forward those requests to 
"teamviewer.org", *not* its IP address (since that can, of course, 
change). This is likely the hard part, but the proxy can at least assume 
that it never gets HTTP(S) requests in general.


The internal (reverse) proxy can accept HTTPS protected requests for a 
domain that it has the certificate for, i.e. teamviewer.local, or 
possibly teamviewer.corpdomain.tld.  (The latter would allow for TLS 
certificates from 3rd parties like Let's Encrypt.)


In other words, move the mapping one level up in the protocol stack, 
from the DNS layer to the HTTP(S) layer.


The other advantage that this has is that recursion could remain 
disabled on the internal DNS servers.  All that would need to be done is 
to make the internal DNS server authoritative for teamviewer.local (et 
al) domain.


And, if the proxy can support the equivalent of name-based hosting, then 
it could support multiple local domain redirects, if needed in the future.


I've done this a number of times with Apache.

P.S. PRIVOXY is probably able at least to do the redirect for a single 
domain -- and it's lightweight.


I think Squid can do it.  I expect that other sufficiently capable proxy 
or web server can do it too.




--
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: Forward zone inside a view

[Kevin Darcy]

Define root zone.

Delegate teamviewer.com from root zone.

Define teamviewer.com as "type forward".

"recursion no" is incompatible with *any* type of forwarding or iterative
resolution. Should only be used if *everything* you resolve is from
authoritative data, i.e. for a hosting-only BIND instance. Since you want
to forward -- selectively -- you need "recursion yes". Nothing outside of
that part of the namespace will be forwarded, since named considers
everything else to be contained in the root zone.


- Kevin

On Mon, Feb 11, 2019 at 9:06 AM Roberto Carna 
wrote:

> Matus, I've followed whatyou say:
>
> view "internet" {
>match-clients { internet_clients; key "pnet"; };
>
> recursion yes;
>
> zone "teamviewer.com" {
> type forward;
> forward only;
> forwarders {
> 8.8.8.8;
> };
> };
>
> };
>
> but clients can resolve ANY public Internet domain, in addition to
> teamviewer.comI think "recursion yes" apply to every public domain and
> not just for "teamviewer.com", but I don't know why.
>
> Please can yoy give me more details, using forward or not, how can let
> some clients resolve just teamviewer.com ??? I confirm that my BIND is an
> authorittaive name server for internal domains.
>
> Thanks a lot again.
>
> El lun., 11 feb. 2019 a las 10:49, Matus UHLAR - fantomas (<
> uh...@fantomas.sk>) escribió:
>
>> On 11.02.19 10:38, Roberto Carna wrote:
>> >Dear Mathus, thanks al lot for your help.
>> >
>> >>> what is the point of running DNS server with only two hostnames
>> allowed
>> >>> to resolve?
>> >
>> >The point is I have several desktops that must have access only to
>> internal
>> >domains. The unique exception is they have access to teamviewer.com  in
>> >order to download the Teamviewer client and a pair of operations in this
>> >public domain.
>>
>> if you disable recursion, any client using that server will only have
>> access
>> to the domains that are configured on that server internally.
>>
>> That also means they won't be allowed to contact any internal domains,
>> unless you configure those internal domains on that server.
>> Also no windows updates, nothing.
>>
>> >I think if I have setup "recursion = no", if I define a forward zone with
>> >"type forward" and the corresponding forwarder, this option enable the
>> >recursion just for this defined zone.
>>
>> No. Forward zone means recursion. "recursion no" is designed for
>> authoritative servers, not servers like there.
>>
>> >In general, my question is how to forward a public domain to a DNS
>> resolver
>> >like 8.8.8.8 ???
>>
>> configure it as "type forward" and forwarders to 8.8.8.8. However, BIND
>> can
>> do resolution well without forwarding. Also, this seems to be just the
>> opposite wht you describe above.
>>
>> >El sáb., 9 feb. 2019 a las 12:28, Matus UHLAR - fantomas (<
>> uh...@fantomas.sk>)
>> >escribió:
>> >
>> >> On 07.02.19 16:30, Roberto Carna wrote:
>> >> >Desktops I mentioned can only access to web apps from internal
>> domains,
>> >> but
>> >> >in some web apps there are links to download Teamviewer client
>> software
>> >> >from Internet. I can create a private zone "teamviewer.com" with all
>> the
>> >> >hostnames and IP's we will use, but if they change I will be in
>> trouble.
>> >> >
>> >> >So we need to forward the query to our resolvers in order to get a
>> valid
>> >> >response.
>> >> >
>> >> >So I think we can use the forward option from BIND, but it doesn't
>> work at
>> >> >all as I described:
>> >> >
>> >> >1. "recursion no" can only be set at the top (view) level, not
>> overridden
>> >> >   at the zone level.
>> >> >
>> >> >2. If I set "recursion no" at the view level, then a "type forward"
>> >> >   zone has no effect:
>> >> >
>> >> >  view "foo" {
>> >> >recursion no;
>> >> >...
>> >> >zone "teamviewer.com" {
>> >> >  type forward;
>> >> >  forward only;
>> >> >  forwarders {172.18.1.1; 172.18.1.2;};
>> >>

Re: Forward zone inside a view

[Dirk Gottschalk via bind-users]

Hello.

Am Donnerstag, den 07.02.2019, 10:32 -0300 schrieb Roberto Carna:
> Dear, I have Bind 9.10.3 as our private DNS service with two views,
> one of them let some clients to query linux.org domain from Internet
> forwarding the query to our Bind resolvers, but the query is refused
> by our private Bind.

What about setting up a (transparent) Proxy and forcing all Clients to
use it for Web-Traffic?

This wouzld solve the problem much easier.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
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: Forward zone inside a view

[Timothe Litt]

On 11-Feb-19 08:38, Roberto Carna wrote:

> The point is I have several desktops that must have access only to
> internal domains. The unique exception is they have access to
> teamviewer.com <http://teamviewer.com>  in order to download the
> Teamviewer client and a pair of operations in this public domain.
>
(Ab)using the DNS for this is almost certainly the wrong approach,
though this sort of question comes up

frequently.

Any sufficiently motivated user can list a blacklisted domain in
HOSTS.TXT, change his DNS server

to a public one, use an IP address (obtained at home, the local internet
cafe, or elsewhere), or

use other work-arounds.

So besides being painful to set up, it's likely ineffective.  You can
clamp down on some of these with file

system or other administrative controls - but not all.  It will be a
frustrating path.

If you want (or are required) to create a walled garden, the only
effective approach is likely to be

a firewall configuration.  You can set it up to only allow traffic from
particular IP address to the permitted

ones.  And control protocols.  You can either send "not reachable" ICMP
responses, or redirect connection

attempts to a port-appropriate warning/notification service.  (e.g. a
web page, e-mail robot, etc.)

You need a process to update the firewall in the unlikely event that the
IP address of a permitted

service changes.  And if your clients get their addresses from DHCP,
you'll want to set up distinct

address pools - and possibly VLANs.

DNS is the wrong hammer for this nail. 

Whether you should hammer the nail at all is a political, not a
technical issue.

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

On 11-Feb-19 08:38, Roberto Carna wrote:
> Dear Mathus, thanks al lot for your help.
>
> >> what is the point of running DNS server with only two hostnames allowed to
> >> resolve? 
>
> The point is I have several desktops that must have access only to
> internal domains. The unique exception is they have access to
> teamviewer.com <http://teamviewer.com>  in order to download the
> Teamviewer client and a pair of operations in this public domain.
>
> I think if I have setup "recursion = no", if I define a forward zone
> with "type forward" and the corresponding forwarder, this option
> enable the recursion just for this defined zone.
>
> In general, my question is how to forward a public domain to a DNS
> resolver like 8.8.8.8 ???
>
> Thanks again.
>
> El sáb., 9 feb. 2019 a las 12:28, Matus UHLAR - fantomas
> (mailto:uh...@fantomas.sk>>) escribió:
>
> On 07.02.19 16:30, Roberto Carna wrote:
> >Desktops I mentioned can only access to web apps from internal
> domains, but
> >in some web apps there are links to download Teamviewer client
> software
> >from Internet. I can create a private zone "teamviewer.com
> <http://teamviewer.com>" with all the
> >hostnames and IP's we will use, but if they change I will be in
> trouble.
> >
> >So we need to forward the query to our resolvers in order to get
>     a valid
> >response.
> >
> >So I think we can use the forward option from BIND, but it
> doesn't work at
> >all as I described:
> >
>     >1. "recursion no" can only be set at the top (view) level, not
> overridden
> >   at the zone level.
> >
> >2. If I set "recursion no" at the view level, then a "type forward"
> >   zone has no effect:
> >
> >  view "foo" {
> >    recursion no;
> >    ...
> >    zone "teamviewer.com <http://teamviewer.com>" {
> >      type forward;
> >      forward only;
> >      forwarders {172.18.1.1; 172.18.1.2;};
> >    };
> >
> >-- query for foo.teamviewer.com <http://foo.teamviewer.com> fails
> and tell it's not a recursive query
>
> the whole point of "recursion no" is not to answer recursive queries,
> so there should be no wonder it works that way.
>
>
> >3. If I define "recursion yes" at view level:
> >
> >  view "foo" {
> >    recursion yes;
> >    ...
> >    zone "teamviewer.com <http://teamviewer.com>" {
> >      type forward;
> >      forward only;
> >      forwarders {172.18.1.1; 172.18.1.2;};
> >    };
> >
> >-- query for foo.teamviewer.com <http://foo.teamviewer.com> is

Re: Forward zone inside a view

[Roberto Carna]

Matus, I've followed whatyou say:

view "internet" {
   match-clients { internet_clients; key "pnet"; };

recursion yes;

zone "teamviewer.com" {
type forward;
forward only;
forwarders {
8.8.8.8;
};
};

};

but clients can resolve ANY public Internet domain, in addition to
teamviewer.comI think "recursion yes" apply to every public domain and
not just for "teamviewer.com", but I don't know why.

Please can yoy give me more details, using forward or not, how can let some
clients resolve just teamviewer.com ??? I confirm that my BIND is an
authorittaive name server for internal domains.

Thanks a lot again.

El lun., 11 feb. 2019 a las 10:49, Matus UHLAR - fantomas (<
uh...@fantomas.sk>) escribió:

> On 11.02.19 10:38, Roberto Carna wrote:
> >Dear Mathus, thanks al lot for your help.
> >
> >>> what is the point of running DNS server with only two hostnames allowed
> >>> to resolve?
> >
> >The point is I have several desktops that must have access only to
> internal
> >domains. The unique exception is they have access to teamviewer.com  in
> >order to download the Teamviewer client and a pair of operations in this
> >public domain.
>
> if you disable recursion, any client using that server will only have
> access
> to the domains that are configured on that server internally.
>
> That also means they won't be allowed to contact any internal domains,
> unless you configure those internal domains on that server.
> Also no windows updates, nothing.
>
> >I think if I have setup "recursion = no", if I define a forward zone with
> >"type forward" and the corresponding forwarder, this option enable the
> >recursion just for this defined zone.
>
> No. Forward zone means recursion. "recursion no" is designed for
> authoritative servers, not servers like there.
>
> >In general, my question is how to forward a public domain to a DNS
> resolver
> >like 8.8.8.8 ???
>
> configure it as "type forward" and forwarders to 8.8.8.8. However, BIND can
> do resolution well without forwarding. Also, this seems to be just the
> opposite wht you describe above.
>
> >El sáb., 9 feb. 2019 a las 12:28, Matus UHLAR - fantomas (<
> uh...@fantomas.sk>)
> >escribió:
> >
> >> On 07.02.19 16:30, Roberto Carna wrote:
> >> >Desktops I mentioned can only access to web apps from internal domains,
> >> but
> >> >in some web apps there are links to download Teamviewer client software
> >> >from Internet. I can create a private zone "teamviewer.com" with all
> the
> >> >hostnames and IP's we will use, but if they change I will be in
> trouble.
> >> >
> >> >So we need to forward the query to our resolvers in order to get a
> valid
> >> >response.
> >> >
> >> >So I think we can use the forward option from BIND, but it doesn't
> work at
> >> >all as I described:
> >> >
> >> >1. "recursion no" can only be set at the top (view) level, not
> overridden
> >> >   at the zone level.
> >> >
> >> >2. If I set "recursion no" at the view level, then a "type forward"
> >> >   zone has no effect:
> >> >
> >> >  view "foo" {
> >> >recursion no;
> >> >...
> >> >zone "teamviewer.com" {
> >> >  type forward;
> >> >  forward only;
> >> >  forwarders {172.18.1.1; 172.18.1.2;};
> >> >};
> >> >
> >> >-- query for foo.teamviewer.com fails and tell it's not a recursive
> query
> >>
> >> the whole point of "recursion no" is not to answer recursive queries,
> >> so there should be no wonder it works that way.
> >>
> >>
> >> >3. If I define "recursion yes" at view level:
> >> >
> >> >  view "foo" {
> >> >recursion yes;
> >> >...
> >> >zone "teamviewer.com" {
> >> >  type forward;
> >> >  forward only;
> >> >  forwarders {172.18.1.1; 172.18.1.2;};
> >> >};
> >> >
> >> >-- query for foo.teamviewer.com is OK, but also I get response OK from
> >> >foo.ibm.com, foo.google.com, and any other public domain from Internet
> >> >(and this is not what I want, it's what I'm trying to prevent))
> >> >
> >> >So can y

Re: Forward zone inside a view

[Matus UHLAR - fantomas]

On 11.02.19 10:38, Roberto Carna wrote:

Dear Mathus, thanks al lot for your help.


what is the point of running DNS server with only two hostnames allowed
to resolve?


The point is I have several desktops that must have access only to internal
domains. The unique exception is they have access to teamviewer.com  in
order to download the Teamviewer client and a pair of operations in this
public domain.


if you disable recursion, any client using that server will only have access
to the domains that are configured on that server internally.

That also means they won't be allowed to contact any internal domains,
unless you configure those internal domains on that server.
Also no windows updates, nothing.


I think if I have setup "recursion = no", if I define a forward zone with
"type forward" and the corresponding forwarder, this option enable the
recursion just for this defined zone.


No. Forward zone means recursion. "recursion no" is designed for
authoritative servers, not servers like there.


In general, my question is how to forward a public domain to a DNS resolver
like 8.8.8.8 ???


configure it as "type forward" and forwarders to 8.8.8.8. However, BIND can
do resolution well without forwarding. Also, this seems to be just the
opposite wht you describe above.


El sáb., 9 feb. 2019 a las 12:28, Matus UHLAR - fantomas ()
escribió:


On 07.02.19 16:30, Roberto Carna wrote:
>Desktops I mentioned can only access to web apps from internal domains,
but
>in some web apps there are links to download Teamviewer client software
>from Internet. I can create a private zone "teamviewer.com" with all the
>hostnames and IP's we will use, but if they change I will be in trouble.
>
>So we need to forward the query to our resolvers in order to get a valid
>response.
>
>So I think we can use the forward option from BIND, but it doesn't work at
>all as I described:
>
>1. "recursion no" can only be set at the top (view) level, not overridden
>   at the zone level.
>
>2. If I set "recursion no" at the view level, then a "type forward"
>   zone has no effect:
>
>  view "foo" {
>recursion no;
>...
>zone "teamviewer.com" {
>  type forward;
>  forward only;
>  forwarders {172.18.1.1; 172.18.1.2;};
>};
>
>-- query for foo.teamviewer.com fails and tell it's not a recursive query

the whole point of "recursion no" is not to answer recursive queries,
so there should be no wonder it works that way.


>3. If I define "recursion yes" at view level:
>
>  view "foo" {
>recursion yes;
>...
>zone "teamviewer.com" {
>  type forward;
>  forward only;
>  forwarders {172.18.1.1; 172.18.1.2;};
>};
>
>-- query for foo.teamviewer.com is OK, but also I get response OK from
>foo.ibm.com, foo.google.com, and any other public domain from Internet
>(and this is not what I want, it's what I'm trying to prevent))
>
>So can you help me please???

you still have not answered my question:

>> what is the point of running DNS server with only two hostnames allowed
to
>> resolve?

However, you can define empty type master "." zone, and bind will return
NXDOMAIN for anything other.


>El jue., 7 feb. 2019 a las 15:40, Matus UHLAR - fantomas (<
uh...@fantomas.sk>)
>escribió:
>
>> On 07.02.19 14:58, Roberto Carna wrote:
>> >In our company we have several desktops from two different cities
>> accessing
>> >only to internal domains distributed in two views in a private BIND
with
>> >authoritative zones, where I've defined "recursion no;".
>> >
>> >But now we have to let them access to *.teamviewer.com hostnames, just
>> this
>> >public domain and not other.
>>
>> btw, when did linux.org change to teamviewer.com?
>>
>> >So I've implemented the forwarding of "teamviewer.com" zone to our
BIND
>> >resolvers servers (they forward DNS queries to 8.8.8.8). So I've
created a
>> >third view with this information in named.conf.local:
>> >
>> >acl internet { 10.0.0.0/24 };
>> >
>> >view "internet" {
>> >
>> >   match-clients { internet; key "custom"; };
>> >
>> > recursion yes;
>> >
>> > zone "teamviewer.com" {
>> >
>> >type forward;
>> >
>> >forward only;
>> >
>> >forwarders {
>> >
>> >172.18.1.1;
>> >
>> >172.18.1.2;
>> >
>> >};
>> >
>> >};
>>
>>
>> &g

Re: Forward zone inside a view

[Roberto Carna]

Dear Mathus, thanks al lot for your help.

>> what is the point of running DNS server with only two hostnames allowed
to
>> resolve?

The point is I have several desktops that must have access only to internal
domains. The unique exception is they have access to teamviewer.com  in
order to download the Teamviewer client and a pair of operations in this
public domain.

I think if I have setup "recursion = no", if I define a forward zone with
"type forward" and the corresponding forwarder, this option enable the
recursion just for this defined zone.

In general, my question is how to forward a public domain to a DNS resolver
like 8.8.8.8 ???

Thanks again.

El sáb., 9 feb. 2019 a las 12:28, Matus UHLAR - fantomas ()
escribió:

> On 07.02.19 16:30, Roberto Carna wrote:
> >Desktops I mentioned can only access to web apps from internal domains,
> but
> >in some web apps there are links to download Teamviewer client software
> >from Internet. I can create a private zone "teamviewer.com" with all the
> >hostnames and IP's we will use, but if they change I will be in trouble.
> >
> >So we need to forward the query to our resolvers in order to get a valid
> >response.
> >
> >So I think we can use the forward option from BIND, but it doesn't work at
> >all as I described:
> >
> >1. "recursion no" can only be set at the top (view) level, not overridden
> >   at the zone level.
> >
> >2. If I set "recursion no" at the view level, then a "type forward"
> >   zone has no effect:
> >
> >  view "foo" {
> >recursion no;
> >...
> >zone "teamviewer.com" {
> >  type forward;
> >  forward only;
> >  forwarders {172.18.1.1; 172.18.1.2;};
> >};
> >
> >-- query for foo.teamviewer.com fails and tell it's not a recursive query
>
> the whole point of "recursion no" is not to answer recursive queries,
> so there should be no wonder it works that way.
>
>
> >3. If I define "recursion yes" at view level:
> >
> >  view "foo" {
> >recursion yes;
> >...
> >zone "teamviewer.com" {
> >  type forward;
> >  forward only;
> >  forwarders {172.18.1.1; 172.18.1.2;};
> >};
> >
> >-- query for foo.teamviewer.com is OK, but also I get response OK from
> >foo.ibm.com, foo.google.com, and any other public domain from Internet
> >(and this is not what I want, it's what I'm trying to prevent))
> >
> >So can you help me please???
>
> you still have not answered my question:
>
> >> what is the point of running DNS server with only two hostnames allowed
> to
> >> resolve?
>
> However, you can define empty type master "." zone, and bind will return
> NXDOMAIN for anything other.
>
>
> >El jue., 7 feb. 2019 a las 15:40, Matus UHLAR - fantomas (<
> uh...@fantomas.sk>)
> >escribió:
> >
> >> On 07.02.19 14:58, Roberto Carna wrote:
> >> >In our company we have several desktops from two different cities
> >> accessing
> >> >only to internal domains distributed in two views in a private BIND
> with
> >> >authoritative zones, where I've defined "recursion no;".
> >> >
> >> >But now we have to let them access to *.teamviewer.com hostnames, just
> >> this
> >> >public domain and not other.
> >>
> >> btw, when did linux.org change to teamviewer.com?
> >>
> >> >So I've implemented the forwarding of "teamviewer.com" zone to our
> BIND
> >> >resolvers servers (they forward DNS queries to 8.8.8.8). So I've
> created a
> >> >third view with this information in named.conf.local:
> >> >
> >> >acl internet { 10.0.0.0/24 };
> >> >
> >> >view "internet" {
> >> >
> >> >   match-clients { internet; key "custom"; };
> >> >
> >> > recursion yes;
> >> >
> >> > zone "teamviewer.com" {
> >> >
> >> >type forward;
> >> >
> >> >forward only;
> >> >
> >> >forwarders {
> >> >
> >> >172.18.1.1;
> >> >
> >> >172.18.1.2;
> >> >
> >> >};
> >> >
> >> >};
> >>
> >>
> >> >I defined "recursion yes" but the BIND servers forwards all the public
&g

Re: Forward zone inside a view

[Matus UHLAR - fantomas]

On 07.02.19 16:30, Roberto Carna wrote:

Desktops I mentioned can only access to web apps from internal domains, but
in some web apps there are links to download Teamviewer client software
from Internet. I can create a private zone "teamviewer.com" with all the
hostnames and IP's we will use, but if they change I will be in trouble.

So we need to forward the query to our resolvers in order to get a valid
response.

So I think we can use the forward option from BIND, but it doesn't work at
all as I described:

1. "recursion no" can only be set at the top (view) level, not overridden
  at the zone level.

2. If I set "recursion no" at the view level, then a "type forward"
  zone has no effect:

 view "foo" {
   recursion no;
   ...
   zone "teamviewer.com" {
 type forward;
 forward only;
 forwarders {172.18.1.1; 172.18.1.2;};
   };

-- query for foo.teamviewer.com fails and tell it's not a recursive query


the whole point of "recursion no" is not to answer recursive queries,
so there should be no wonder it works that way.



3. If I define "recursion yes" at view level:

 view "foo" {
   recursion yes;
   ...
   zone "teamviewer.com" {
 type forward;
 forward only;
 forwarders {172.18.1.1; 172.18.1.2;};
   };

-- query for foo.teamviewer.com is OK, but also I get response OK from
foo.ibm.com, foo.google.com, and any other public domain from Internet
(and this is not what I want, it's what I'm trying to prevent))

So can you help me please???


you still have not answered my question:


what is the point of running DNS server with only two hostnames allowed to
resolve?


However, you can define empty type master "." zone, and bind will return
NXDOMAIN for anything other.



El jue., 7 feb. 2019 a las 15:40, Matus UHLAR - fantomas ()
escribió:


On 07.02.19 14:58, Roberto Carna wrote:
>In our company we have several desktops from two different cities
accessing
>only to internal domains distributed in two views in a private BIND with
>authoritative zones, where I've defined "recursion no;".
>
>But now we have to let them access to *.teamviewer.com hostnames, just
this
>public domain and not other.

btw, when did linux.org change to teamviewer.com?

>So I've implemented the forwarding of "teamviewer.com" zone to our BIND
>resolvers servers (they forward DNS queries to 8.8.8.8). So I've created a
>third view with this information in named.conf.local:
>
>acl internet { 10.0.0.0/24 };
>
>view "internet" {
>
>   match-clients { internet; key "custom"; };
>
> recursion yes;
>
> zone "teamviewer.com" {
>
>type forward;
>
>forward only;
>
>forwarders {
>
>172.18.1.1;
>
>172.18.1.2;
>
>};
>
>};


>I defined "recursion yes" but the BIND servers forwards all the public
>domains queries to our resolvers and not just for "teamviewer.com", so it
>doesn't work. And if I change for "recursion no", the query
>www.teamviewer.com is refused and at the client side appears an error
>telling that recursion is necessary.

of course, BIND will resolve other domains (recurse) only when you allow it
to recurse.

>So I let desktops resolve all the Internet domains or neither, and this is
>not what I want because I just want to let them resolve just
teamviewer.com.
>
>How can I do to forward only teamviewer.com zone queries to my
resolvers???



--
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.
Eagles may soar, but weasels don't get sucked into jet engines. 
___

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: Forward zone inside a view

[Paul Kosinski]

I haven't analyzed the details and pitfalls, but could a Web proxy
mechanism of some sort be of help? In particular, rather than having
your users directly access "teamviewer.org" (or whatever), have them to
access "teamviewer.local", which is resolved by your internal DNS to a
specialized proxy server.

Then set up this proxy server to forward those requests to
"teamviewer.org", *not* its IP address (since that can, of course,
change). This is likely the hard part, but the proxy can at least
assume that it never gets HTTP(S) requests in general. 

In other words, move the mapping one level up in the protocol stack,
from the DNS layer to the HTTP(S) layer.

And, if the proxy can support the equivalent of name-based hosting, then
it could support multiple local domain redirects, if needed in the
future. 

P.S. PRIVOXY is probably able at least to do the redirect for a single
domain -- and it's lightweight.




On Thu, 7 Feb 2019 15:00:47 -0500
Alan Clegg  wrote:

> On 2/7/19 2:30 PM, Roberto Carna wrote:
> > Dear, thanks for your contact. I've used teamviewer.com
> >  just for tests.
> > 
> > Desktops I mentioned can only access to web apps from internal
> > domains, but in some web apps there are links to download
> > Teamviewer client software from Internet. I can create a private
> > zone "teamviewer.com " with all the
> > hostnames and IP's we will use, but if they change I will be in
> > trouble.
> 
> Sounds to me like a use for a global block with RPZ and a passthrough
> for the domain that needs to be ... uh ... passed through.
> 
> And from my experience, this is never going to work because whatever
> the "only thing we want to resolve" is, it will rely on something
> else that you don't (currently) resolve.
> 
> Anyone that has ever tried to block their "smart TV" so that it only
> allows certain apps but not others will know exactly what I'm talking
> about.
> 
> AlanC

___
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: Forward zone inside a view

[Alan Clegg]

On 2/7/19 2:30 PM, Roberto Carna wrote:
> Dear, thanks for your contact. I've used teamviewer.com
>  just for tests.
> 
> Desktops I mentioned can only access to web apps from internal domains,
> but in some web apps there are links to download Teamviewer client
> software from Internet. I can create a private zone "teamviewer.com
> " with all the hostnames and IP's we will use,
> but if they change I will be in trouble.

Sounds to me like a use for a global block with RPZ and a passthrough
for the domain that needs to be ... uh ... passed through.

And from my experience, this is never going to work because whatever the
"only thing we want to resolve" is, it will rely on something else that
you don't (currently) resolve.

Anyone that has ever tried to block their "smart TV" so that it only
allows certain apps but not others will know exactly what I'm talking about.

AlanC
___
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: Forward zone inside a view

[Roberto Carna]

Dear, thanks for your contact. I've used teamviewer.com just for tests.

Desktops I mentioned can only access to web apps from internal domains, but
in some web apps there are links to download Teamviewer client software
from Internet. I can create a private zone "teamviewer.com" with all the
hostnames and IP's we will use, but if they change I will be in trouble.

So we need to forward the query to our resolvers in order to get a valid
response.

So I think we can use the forward option from BIND, but it doesn't work at
all as I described:

1. "recursion no" can only be set at the top (view) level, not overridden
   at the zone level.

2. If I set "recursion no" at the view level, then a "type forward"
   zone has no effect:

  view "foo" {
recursion no;
...
zone "teamviewer.com" {
  type forward;
  forward only;
  forwarders {172.18.1.1; 172.18.1.2;};
};

-- query for foo.teamviewer.com fails and tell it's not a recursive query

3. If I define "recursion yes" at view level:

  view "foo" {
recursion yes;
...
zone "teamviewer.com" {
  type forward;
  forward only;
  forwarders {172.18.1.1; 172.18.1.2;};
};

-- query for foo.teamviewer.com is OK, but also I get response OK from
foo.ibm.com, foo.google.com, and any other public domain from Internet
(and this is not what I want, it's what I'm trying to prevent))

So can you help me please???

Regards.


El jue., 7 feb. 2019 a las 15:40, Matus UHLAR - fantomas ()
escribió:

> On 07.02.19 14:58, Roberto Carna wrote:
> >In our company we have several desktops from two different cities
> accessing
> >only to internal domains distributed in two views in a private BIND with
> >authoritative zones, where I've defined "recursion no;".
> >
> >But now we have to let them access to *.teamviewer.com hostnames, just
> this
> >public domain and not other.
>
> btw, when did linux.org change to teamviewer.com?
>
> >So I've implemented the forwarding of "teamviewer.com" zone to our BIND
> >resolvers servers (they forward DNS queries to 8.8.8.8). So I've created a
> >third view with this information in named.conf.local:
> >
> >acl internet { 10.0.0.0/24 };
> >
> >view "internet" {
> >
> >   match-clients { internet; key "custom"; };
> >
> > recursion yes;
> >
> > zone "teamviewer.com" {
> >
> >type forward;
> >
> >forward only;
> >
> >forwarders {
> >
> >172.18.1.1;
> >
> >172.18.1.2;
> >
> >};
> >
> >};
>
>
> >I defined "recursion yes" but the BIND servers forwards all the public
> >domains queries to our resolvers and not just for "teamviewer.com", so it
> >doesn't work. And if I change for "recursion no", the query
> >www.teamviewer.com is refused and at the client side appears an error
> >telling that recursion is necessary.
>
> of course, BIND will resolve other domains (recurse) only when you allow it
> to recurse.
>
> >So I let desktops resolve all the Internet domains or neither, and this is
> >not what I want because I just want to let them resolve just
> teamviewer.com.
> >
> >How can I do to forward only teamviewer.com zone queries to my
> resolvers???
>
> what is the point of running DNS server with only two hostnames allowed to
> resolve?
>
> --
> 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.
> Despite the cost of living, have you noticed how popular it remains?
> ___
> 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: Forward zone inside a view

[Matus UHLAR - fantomas]

On 07.02.19 14:58, Roberto Carna wrote:

In our company we have several desktops from two different cities accessing
only to internal domains distributed in two views in a private BIND with
authoritative zones, where I've defined "recursion no;".

But now we have to let them access to *.teamviewer.com hostnames, just this
public domain and not other.


btw, when did linux.org change to teamviewer.com?


So I've implemented the forwarding of "teamviewer.com" zone to our BIND
resolvers servers (they forward DNS queries to 8.8.8.8). So I've created a
third view with this information in named.conf.local:

acl internet { 10.0.0.0/24 };

view "internet" {

  match-clients { internet; key "custom"; };

recursion yes;

zone "teamviewer.com" {

   type forward;

   forward only;

   forwarders {

   172.18.1.1;

   172.18.1.2;

   };

};




I defined "recursion yes" but the BIND servers forwards all the public
domains queries to our resolvers and not just for "teamviewer.com", so it
doesn't work. And if I change for "recursion no", the query
www.teamviewer.com is refused and at the client side appears an error
telling that recursion is necessary.


of course, BIND will resolve other domains (recurse) only when you allow it
to recurse.


So I let desktops resolve all the Internet domains or neither, and this is
not what I want because I just want to let them resolve just teamviewer.com.

How can I do to forward only teamviewer.com zone queries to my resolvers???


what is the point of running DNS server with only two hostnames allowed to
resolve?

--
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.
Despite the cost of living, have you noticed how popular it remains? 
___

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: Forward zone inside a view

[Roberto Carna]

Ok Tony, please let me explain to you.

In our company we have several desktops from two different cities accessing
only to internal domains distributed in two views in a private BIND with
authoritative zones, where I've defined "recursion no;".

But now we have to let them access to *.teamviewer.com hostnames, just this
public domain and not other.

So I've implemented the forwarding of "teamviewer.com" zone to our BIND
resolvers servers (they forward DNS queries to 8.8.8.8). So I've created a
third view with this information in named.conf.local:

acl internet { 10.0.0.0/24 };

view "internet" {

   match-clients { internet; key "custom"; };

 recursion yes;

 zone "teamviewer.com" {

type forward;

forward only;

forwarders {

172.18.1.1;

172.18.1.2;

};

};

I defined "recursion yes" but the BIND servers forwards all the public
domains queries to our resolvers and not just for "teamviewer.com", so it
doesn't work. And if I change for "recursion no", the query
www.teamviewer.com is refused and at the client side appears an error
telling that recursion is necessary.

So I let desktops resolve all the Internet domains or neither, and this is
not what I want because I just want to let them resolve just teamviewer.com.

How can I do to forward only teamviewer.com zone queries to my resolvers???

Sorry for my new message, special thanks Tony !!!

El jue., 7 feb. 2019 a las 13:41, Tony Finch () escribió:

> Roberto Carna  wrote:
> >
> > So how can I define "recursion yes" just for the zone "linux.org" ???
>
> You can turn recursion on and off for the entire server, or per view, but
> not per zone.
>
> It isn't clear to me what you want this server to do. If it is providing
> DNS service to end-user devices (if it is configured in /etc/resolv.conf
> or advertised by DHCP) then it needs to provide recursive service. If not,
> then I am even more confused about what you are trying to do!
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> St Davids Head to Great Orme Head, including St Georges Channel: Southwest
> 5
> or 6, increasing 7 to severe gale 9. Moderate or rough becoming very rough.
> Rain and drizzle, squally showers later. Moderate or good, occasionally
> poor.
>
___
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: Forward zone inside a view

[Tony Finch]

Roberto Carna  wrote:
>
> So how can I define "recursion yes" just for the zone "linux.org" ???

You can turn recursion on and off for the entire server, or per view, but
not per zone.

It isn't clear to me what you want this server to do. If it is providing
DNS service to end-user devices (if it is configured in /etc/resolv.conf
or advertised by DHCP) then it needs to provide recursive service. If not,
then I am even more confused about what you are trying to do!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Southwest 5
or 6, increasing 7 to severe gale 9. Moderate or rough becoming very rough.
Rain and drizzle, squally showers later. Moderate or good, occasionally poor.
___
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: Forward zone inside a view

[Roberto Carna]

When I query www.teamviewer from a desktop, I fail and get this error in
dig:

 WARNING: recursion requested but not available

In BIND I have in named.conf.local:

zone "linux. org" {
type forward;
forwarders {
172.18.1.1;
172.18.1.2;
};

and "recursion no;" is defined in named.conf.options.

How can enable the recursion for linux.org queries in order to forward them
to my resolvers???

Thanks a lot

El jue., 7 feb. 2019 a las 11:40, Roberto Carna ()
escribió:

> Tony, as you said forwarding requires recursion but when I define:
>
> zone "linux. org" {
> recursion yes;
> type forward;
> forward only;
> forwarders {
> 172.18.1.1;
> 172.18.1.2;
> };
>
> and after that I restart bind9 service, it fails:
>
> unknown option 'recursion'
>
> So how can I define "recursion yes" just for the zone "linux.org" ???
>
> Sorry for my newquestion, I'd appreciate your help.
>
> Regards!!!
>
>
> El jue., 7 feb. 2019 a las 11:26, Tony Finch () escribió:
>
>> Roberto Carna  wrote:
>>
>> > Dear Tony, I forward the "linux.org" queries from our private Bind to
>> our
>> > Bind resolvers (they have authoritative public zones and also they are
>> > resolvers that forward the queries to 8.8.8.8).
>> >
>> > So why you say they are authoritative only servers?
>>
>> Oh, I misread your explanation, I thought the "recursion no" in your
>> configuration was on the target server. But it is on the server with the
>> "type forward" zone, and since forwarding requires recursion, it will not
>> work.
>>
>> Tony.
>> --
>> f.anthony.n.finchhttp://dotat.at/
>> Shannon: Southwest 7 to severe gale 9, veering west gale 8 to storm 10
>> later.
>> Very rough, becoming high or very high. Rain or squally showers. Poor.
>>
>
___
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: Forward zone inside a view

[Roberto Carna]

Tony, as you said forwarding requires recursion but when I define:

zone "linux. org" {
recursion yes;
type forward;
forward only;
forwarders {
172.18.1.1;
172.18.1.2;
};

and after that I restart bind9 service, it fails:

unknown option 'recursion'

So how can I define "recursion yes" just for the zone "linux.org" ???

Sorry for my newquestion, I'd appreciate your help.

Regards!!!


El jue., 7 feb. 2019 a las 11:26, Tony Finch () escribió:

> Roberto Carna  wrote:
>
> > Dear Tony, I forward the "linux.org" queries from our private Bind to
> our
> > Bind resolvers (they have authoritative public zones and also they are
> > resolvers that forward the queries to 8.8.8.8).
> >
> > So why you say they are authoritative only servers?
>
> Oh, I misread your explanation, I thought the "recursion no" in your
> configuration was on the target server. But it is on the server with the
> "type forward" zone, and since forwarding requires recursion, it will not
> work.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Shannon: Southwest 7 to severe gale 9, veering west gale 8 to storm 10
> later.
> Very rough, becoming high or very high. Rain or squally showers. Poor.
>
___
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: Forward zone inside a view

[Tony Finch]

Roberto Carna  wrote:

> Dear Tony, I forward the "linux.org" queries from our private Bind to our
> Bind resolvers (they have authoritative public zones and also they are
> resolvers that forward the queries to 8.8.8.8).
>
> So why you say they are authoritative only servers?

Oh, I misread your explanation, I thought the "recursion no" in your
configuration was on the target server. But it is on the server with the
"type forward" zone, and since forwarding requires recursion, it will not
work.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon: Southwest 7 to severe gale 9, veering west gale 8 to storm 10 later.
Very rough, becoming high or very high. Rain or squally showers. Poor.
___
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: Forward zone inside a view

[Roberto Carna]

Dear Tony, I forward the "linux.org" queries from our private Bind to our
Bind resolvers (they have authoritative public zones and also they are
resolvers that forward the queries to 8.8.8.8).

So why you say they are authoritative only servers?

A I said, can I still use the forward option for "linux.org" ???

Thanks a lot again!!!

El jue., 7 feb. 2019 a las 11:05, Tony Finch () escribió:

> Roberto Carna  wrote:
>
> > Dear, I have Bind 9.10.3 as our private DNS service with two views, one
> of
> > them let some clients to query linux.org domain from Internet forwarding
> > the query to our Bind resolvers, but the query is refused by our private
> > Bind.
>
> You can't forward to an authoritative-only server. Use a static-stub zone
> configuration instead.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Tyne: West, backing south, 5 to 7. Slight or moderate, occasionally rough
> later. Showers. Good occasionally moderate.
>
___
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: Forward zone inside a view

[Tony Finch]

Roberto Carna  wrote:

> Dear, I have Bind 9.10.3 as our private DNS service with two views, one of
> them let some clients to query linux.org domain from Internet forwarding
> the query to our Bind resolvers, but the query is refused by our private
> Bind.

You can't forward to an authoritative-only server. Use a static-stub zone
configuration instead.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Tyne: West, backing south, 5 to 7. Slight or moderate, occasionally rough
later. Showers. Good occasionally moderate.
___
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

Forward zone inside a view

[Roberto Carna]

Dear, I have Bind 9.10.3 as our private DNS service with two views, one of
them let some clients to query linux.org domain from Internet forwarding
the query to our Bind resolvers, but the query is refused by our private
Bind.

The private Bind has these main parameters in named.conf.options:

options {
directory "/var/cache/bind";
allow-transfer {"none";};

   dnssec-validation auto;
dnssec-enable yes;
auth-nxdomain no;
allow-query { any; };
recursion no;
version "none";
};

And this is te relevant part of named.conf.local:

acl internet { 10.0.0.0/24; };

view "INTERNET" {
   match-clients { internet; key "custom";};

zone "linux. <http://teamviewer.com>org" {
type forward;
forward only;
forwarders {
172.18.1.1;
172.18.1.2;
};
};

};

Please can you help me in forward the query for linux.org hostnames from
the private BIND with the views to our resolvers?

Thanks a lot!!!
___
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: Re: Re: checkhints: view “internal”: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints

[Warren Kumari]

On Sun, Sep 10, 2017 at 8:15 PM, Mark Andrews  wrote:
>
> In message , Timothe Litt 
> writes:
>> The most sensible thing to do is ignore the message, and keep named
>> reasonably up-to-date.
>
> Well something in the resolution path is changing the answer to
> return the old  address which is why I suggested that there may
> be a forwarder involved.  One should get a answer like this from
> all of the root server addresses.  The exact ordering of the records
> may differ.  If one doesn't then something on the path is modifying
> the response.

... and here's a (really ugly) bit of bash to allow you to check all of them:
for letter in `echo "abcdefghijklm" | grep -o .` ; do echo "Letter:
${letter}"; dig ns . @${letter}.root-servers.net | grep
b.root-servers.net | grep ; done

W

>
> ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ns . +norec 
> @a.root-servers.net
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29723
> ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;.  IN  NS
>
> ;; ANSWER SECTION:
> .   518400  IN  NS  a.root-servers.net.
> .   518400  IN  NS  b.root-servers.net.
> .   518400  IN  NS  c.root-servers.net.
> .   518400  IN  NS  d.root-servers.net.
> .   518400  IN  NS  e.root-servers.net.
> .   518400  IN  NS  f.root-servers.net.
> .   518400  IN  NS  g.root-servers.net.
> .   518400  IN  NS  h.root-servers.net.
> .   518400  IN  NS  i.root-servers.net.
> .   518400  IN  NS  j.root-servers.net.
> .   518400  IN  NS  k.root-servers.net.
> .   518400  IN  NS  l.root-servers.net.
> .   518400  IN  NS  m.root-servers.net.
>
> ;; ADDITIONAL SECTION:
> a.root-servers.net. 518400  IN  A   198.41.0.4
> b.root-servers.net. 518400  IN  A   192.228.79.201
> c.root-servers.net. 518400  IN  A   192.33.4.12
> d.root-servers.net. 518400  IN  A   199.7.91.13
> e.root-servers.net. 518400  IN  A   192.203.230.10
> f.root-servers.net. 518400  IN  A   192.5.5.241
> g.root-servers.net. 518400  IN  A   192.112.36.4
> h.root-servers.net. 518400  IN  A   198.97.190.53
> i.root-servers.net. 518400  IN  A   192.36.148.17
> j.root-servers.net. 518400  IN  A   192.58.128.30
> k.root-servers.net. 518400  IN  A   193.0.14.129
> l.root-servers.net. 518400  IN  A   199.7.83.42
> m.root-servers.net. 518400  IN  A   202.12.27.33
> a.root-servers.net. 518400  IN  2001:503:ba3e::2:30
> b.root-servers.net. 518400  IN  2001:500:200::b
> c.root-servers.net. 518400  IN  2001:500:2::c
> d.root-servers.net. 518400  IN  2001:500:2d::d
> e.root-servers.net. 518400  IN  2001:500:a8::e
> f.root-servers.net. 518400  IN  2001:500:2f::f
> g.root-servers.net. 518400  IN  2001:500:12::d0d
> h.root-servers.net. 518400  IN  2001:500:1::53
> i.root-servers.net. 518400  IN  2001:7fe::53
> j.root-servers.net. 518400  IN  2001:503:c27::2:30
> k.root-servers.net. 518400  IN  2001:7fd::1
> l.root-servers.net. 518400  IN  2001:500:9f::42
> m.root-servers.net. 518400  IN  2001:dc3::35
>
> ;; Query time: 179 msec
> ;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
> ;; WHEN: Mon Sep 11 10:09:10 AEST 2017
> ;; MSG SIZE  rcvd: 811
>
> --
> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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: Re: Re: checkhints: view “internal”: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints

[Mark Andrews]

In message , Timothe Litt writes:
> The most sensible thing to do is ignore the message, and keep named
> reasonably up-to-date.

Well something in the resolution path is changing the answer to
return the old  address which is why I suggested that there may
be a forwarder involved.  One should get a answer like this from
all of the root server addresses.  The exact ordering of the records
may differ.  If one doesn't then something on the path is modifying
the response.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ns . +norec 
@a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29723
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;.  IN  NS

;; ANSWER SECTION:
.   518400  IN  NS  a.root-servers.net.
.   518400  IN  NS  b.root-servers.net.
.   518400  IN  NS  c.root-servers.net.
.   518400  IN  NS  d.root-servers.net.
.   518400  IN  NS  e.root-servers.net.
.   518400  IN  NS  f.root-servers.net.
.   518400  IN  NS  g.root-servers.net.
.   518400  IN  NS  h.root-servers.net.
.   518400  IN  NS  i.root-servers.net.
.   518400  IN  NS  j.root-servers.net.
.   518400  IN  NS  k.root-servers.net.
.   518400  IN  NS  l.root-servers.net.
.   518400  IN  NS  m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net. 518400  IN  A   198.41.0.4
b.root-servers.net. 518400  IN  A   192.228.79.201
c.root-servers.net. 518400  IN  A   192.33.4.12
d.root-servers.net. 518400  IN  A   199.7.91.13
e.root-servers.net. 518400  IN  A   192.203.230.10
f.root-servers.net. 518400  IN  A   192.5.5.241
g.root-servers.net. 518400  IN  A   192.112.36.4
h.root-servers.net. 518400  IN  A   198.97.190.53
i.root-servers.net. 518400  IN  A   192.36.148.17
j.root-servers.net. 518400  IN  A   192.58.128.30
k.root-servers.net. 518400  IN  A   193.0.14.129
l.root-servers.net. 518400  IN  A   199.7.83.42
m.root-servers.net. 518400  IN  A   202.12.27.33
a.root-servers.net. 518400  IN  2001:503:ba3e::2:30
b.root-servers.net. 518400  IN  2001:500:200::b
c.root-servers.net. 518400  IN  2001:500:2::c
d.root-servers.net. 518400  IN  2001:500:2d::d
e.root-servers.net. 518400  IN  2001:500:a8::e
f.root-servers.net. 518400  IN  2001:500:2f::f
g.root-servers.net. 518400  IN  2001:500:12::d0d
h.root-servers.net. 518400  IN  2001:500:1::53
i.root-servers.net. 518400  IN  2001:7fe::53
j.root-servers.net. 518400  IN  2001:503:c27::2:30
k.root-servers.net. 518400  IN  2001:7fd::1
l.root-servers.net. 518400  IN  2001:500:9f::42
m.root-servers.net. 518400  IN  2001:dc3::35

;; Query time: 179 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Mon Sep 11 10:09:10 AEST 2017
;; MSG SIZE  rcvd: 811

-- 
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