Question regarding newsyslog.conf and Bind logs

2022-08-24 Thread J Doe 

Hello,

I was wondering if anyone could provide feedback on whether the 
following: newsyslog.conf file is correct to allow for daily log 
rotation for my Bind 9.16.30 logs ?


My currently logging settings in: named.conf are:

...
logging {
channel chn_file_queries {
buffered no;
file "/var/queries.log"
versions 2 size 1g suffix increment;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
...
};
...

newsyslog.conf examples tend to make use of: pkill but I note in the 
Bind ARM and man page that signals are deprecated in favor of: rndc.


I am *thinking* the following should work for newsyslog.conf

/var/named/var/queries.log6407 *$D0  Z 
"/usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true"


So settings:

Log path: My Bind is running in chroot
File mode:0640
Log count:7 (1 per day)
Size limit:   none
Frequency:$D0 (daily)
Flags:z to compress
Binary:   rndc (instead of pkill)

Is this correct ?

Thank you,

- J
--
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: address/prefix length mismatch

2022-08-24 Thread Elias Pereira 
As I initially thought that bind worked with the normal notation of a
subnet, I did the configuration as I initially posted.

Now with your explanations I see that it is as Greg commented. This is just
pattern matching.

Thank you all!!!

On Wed, Aug 24, 2022 at 1:23 PM Ondřej Surý  wrote:

> The original problem was that BIND 9.16 now requires use of CIDR blocks
> rather than using IP addresses in CIDR notation. Using arbitrary IP address
> to specify CIDR block doesn’t make much sense and is prone to errors - when
> you see 10.10.1.0/23 it’s quite hard to tell what was the original
> intention and whether it’s a typo in the network or in the bits - did the
> origin author meant 10.10.0.0-10.10.1.255 or 10.20.1.0-10.10.1.255 or
> something completely else (like 10.10.1.0-10.10.2.255 based on wrong
> assumption?)
>
> --
> 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 24. 8. 2022, at 17:34, Sten Carlsen  wrote:
>
> 
>
> On 24 Aug 2022, at 16.52, Greg Choules <
> gregchoules+bindus...@googlemail.com> wrote:
>
> Hi Sten.
> That is absolutely what you do *not* want to do.
>
> Writing it out in binary might help. /23 means the following:
>   1110 
>
> '1' bits mean, test an incoming address against the corresponding bit from
> the address in the mask.
> '0' bits mean, don't test an incoming address against the
> corresponding bit from the address in the mask.
>
> The ACL 10.60.0.0/23 will match *any* address from 10.60.0.0 to
> 10.60.1.255 *inclusive*.
>
> There is no concept of network address and broadcast address here. It is
> just pattern matching.
>
>
> Yes, I was (incorrectly) thinking in terms of a /24 network and assumed
> that removing the ..0 and ..255 addresses was the issue. The proposal would
> do that by first rejecting (! - means reject) the offending addresses (all
> have to be listed separately) before doing the above pattern matching.
>
>
> Cheers, Greg
>
> On Wed, 24 Aug 2022 at 15:40, Sten Carlsen  wrote:
>
>> I think you want something like this:
>>
>> (!10.60.0.0; !10.60.0.255; 10.60.0.0/24)
>>
>> First deny the two addresses you want not to be part of the *ACL* and
>> then accept the whole network.
>>
>> First match is used, so 10.60.0.0 would match !10.60.0.0 and be rejected
>> before the next  are tested.
>>
>> Thanks
>>
>> Sten
>>
>> On 24 Aug 2022, at 16.05, Ondřej Surý  wrote:
>>
>>
>> On 24. 8. 2022, at 15:58, Elias Pereira  wrote:
>>
>> hello Ondrej,
>>
>> Not completely wrong, because 255 is the broadcast.
>>
>>
>> No, it's not. This is ACL specification, not a interface/network
>> configuration.
>>
>> For a better understanding, then it would be Available range 10.60.0.1 to
>> 10.60.1.254.
>>
>>
>> No, I've already provided you with a correct answer what 10.60.0.0/23
>> means in terms of range, why do you insist on this?
>>
>> Correctly specified range (without address/host bits) does takes the
>>> whole range.
>>
>>
>> Like this 10.60/23; ?
>>
>>
>> I think others have already answered that, I would be just repeating
>> their answers.
>>
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org
>>
>> My working hours and your working hours may be different. Please do not
>> feel obligated to reply outside your normal working hours.
>>
>>
>> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý  wrote:
>>
>>>
>>>
>>> On 24. 8. 2022, at 15:26, Elias Pereira  wrote:
>>>
>>> 
>>> Hello Greg,
>>>
>>> Why doesn't bind work with networks/subnets in the conventional way?
>>>
>>>
>>> It does.
>>>
>>> If the private subnet is 10.60.0.0/23, then it means that the address
>>> range is 10.60.0.1 to 10.60.1.254.
>>>
>>>
>>> That’s wrong. 10.60.0.0/23 means 10.60.0.0 to 10.60.1.255 range.
>>>
>>> How do I configure this ACL in named.conf.local so that it takes the
>>> whole range?
>>>
>>>
>>> Correctly specified range (without address/host bits) does takes the
>>> whole range.
>>>
>>> Ondrej
>>> --
>>> 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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev  wrote:
>>>
 On 24/08/2022 14:16, Elias Pereira wrote:

 Hi Elias,

 > Oh, sorry... :D
 >
 > here it is
 >
 > # cat named.conf.local
 > # ACL das redes internas
 > # Ultima modificação: 24/08/2022
 >
 > acl "internal" {
 > 10.60.0.1/23;

 This is the issue. The address part of the prefix should be the lowest
 address in that prefix. If you change this to 10.60.0.0/23, it will be
 fine. The same goes for all the other prefixes in your list. Change the
 1's to 0's.

 > 10.10.1.1/24;
 > 10.10.2.1/25;
 > 10.10.3.1/25;
 > 10.10.4.1/25;
 > 10.10.5.1/25;
 > 10.51.0.1/23;
 > 10.10.6.1/25;
 > 10.10.7.1/26;
 > 172.20.0.1/26;

Re: address/prefix length mismatch

2022-08-24 Thread Ondřej Surý 
The original problem was that BIND 9.16 now requires use of CIDR blocks rather 
than using IP addresses in CIDR notation. Using arbitrary IP address to specify 
CIDR block doesn’t make much sense and is prone to errors - when you see 
10.10.1.0/23 it’s quite hard to tell what was the original intention and 
whether it’s a typo in the network or in the bits - did the origin author meant 
10.10.0.0-10.10.1.255 or 10.20.1.0-10.10.1.255 or something completely else 
(like 10.10.1.0-10.10.2.255 based on wrong assumption?)

--
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 24. 8. 2022, at 17:34, Sten Carlsen  wrote:
> 
> 
> 
>>> On 24 Aug 2022, at 16.52, Greg Choules 
>>>  wrote:
>>> 
>>> Hi Sten.
>>> That is absolutely what you do *not* want to do.
>>> 
>>> Writing it out in binary might help. /23 means the following:
>>>   1110 
>>> 
>>> '1' bits mean, test an incoming address against the corresponding bit from 
>>> the address in the mask.
>>> '0' bits mean, don't test an incoming address against the corresponding bit 
>>> from the address in the mask.
>>> 
>>> The ACL 10.60.0.0/23 will match *any* address from 10.60.0.0 to 10.60.1.255 
>>> *inclusive*.
>>> 
>>> There is no concept of network address and broadcast address here. It is 
>>> just pattern matching.
>> 
>> Yes, I was (incorrectly) thinking in terms of a /24 network and assumed that 
>> removing the ..0 and ..255 addresses was the issue. The proposal would do 
>> that by first rejecting (! - means reject) the offending addresses (all have 
>> to be listed separately) before doing the above pattern matching.
>> 
>> 
>> Cheers, Greg
>> 
>>> On Wed, 24 Aug 2022 at 15:40, Sten Carlsen  wrote:
>>> I think you want something like this:
>>> 
>>> (!10.60.0.0; !10.60.0.255; 10.60.0.0/24)
>>> 
>>> First deny the two addresses you want not to be part of the ACL and then 
>>> accept the whole network.
>>> 
>>> First match is used, so 10.60.0.0 would match !10.60.0.0 and be rejected 
>>> before the next  are tested.
>>> 
>>> Thanks
>>> 
>>> Sten
>>> 
> On 24 Aug 2022, at 16.05, Ondřej Surý  wrote:
> 
> 
>> On 24. 8. 2022, at 15:58, Elias Pereira  wrote:
>> 
>> hello Ondrej,
>> 
>> Not completely wrong, because 255 is the broadcast.
> 
> No, it's not. This is ACL specification, not a interface/network 
> configuration.
> 
> For a better understanding, then it would be Available range 10.60.0.1 to 
> 10.60.1.254.
 
 No, I've already provided you with a correct answer what 10.60.0.0/23 
 means in terms of range, why do you insist on this?
 
>> Correctly specified range (without address/host bits) does takes the 
>> whole range.
> 
> Like this 10.60/23; ?
 
 I think others have already answered that, I would be just repeating their 
 answers.
 
 Ondrej
 --
 Ondřej Surý (He/Him)
 ond...@isc.org
 
 My working hours and your working hours may be different. Please do not 
 feel obligated to reply outside your normal working hours.
 
 
>> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý  wrote:
>> 
>> 
 On 24. 8. 2022, at 15:26, Elias Pereira  wrote:
 
>>> 
>>> Hello Greg,
>>> 
>>> Why doesn't bind work with networks/subnets in the conventional way?
>> 
>> It does.
>> 
>>> If the private subnet is 10.60.0.0/23, then it means that the address 
>>> range is 10.60.0.1 to 10.60.1.254.
>> 
>> That’s wrong. 10.60.0.0/23 means 10.60.0.0 to 10.60.1.255 range.
>> 
>>> How do I configure this ACL in named.conf.local so that it takes the 
>>> whole range?
>> 
>> Correctly specified range (without address/host bits) does takes the 
>> whole range.
>> 
>> Ondrej 
>> --
>> 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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev  wrote:
 On 24/08/2022 14:16, Elias Pereira wrote:
 
 Hi Elias,
 
 > Oh, sorry... :D
 > 
 > here it is
 > 
 > # cat named.conf.local
 > # ACL das redes internas
 > # Ultima modificação: 24/08/2022
 > 
 > acl "internal" {
 > 10.60.0.1/23;
 
 This is the issue. The address part of the prefix should be the lowest 
 address in that prefix. If you change this to 10.60.0.0/23, it will be 
 fine. The same goes for all the other prefixes in your list. Change 
 the 
 1's to 0's.
 
 > 10.10.1.1/24;
 > 10.10.2.1/25;
 > 10.10.3.1/25;
 > 10.10.4.1/25;
 > 10.10.5.1/25;
 > 10.51.0.1/23;

Re: Thread handling

2022-08-24 Thread hamid 
> Such use case (authoritative data) is fine, I was merely speaking about 
> caching server before.Understood. Interesting. Was my understanding of DynDB 
> correct? It reads from a backend DB into memory, to eliminate the latency?In 
> my proposed "workaround" (a hidden primary server with DLZ and multiple 
> secondary caching nodes) we gain speed but lose the dynamic element. Meaning 
> if a record is updated in the DB, the change will be reflected on the caching 
> servers after ttl.With DynDB, a reload would be necessary after any update if 
> I understand correctly. Trying to understand how would a hidden primary with 
> DLZ, paired with multiple secondaries with dynamic zones leveraging nsupdate 
> work. Do secondaries poll the primary? Or is primary sending updates to 
> secondaries when a record is updated? I believe it's the former, just trying 
> to clarify.RegardsHamid Maadani
 Original message From: Ondřej Surý  Date: 
8/24/22  02:32  (GMT-08:00) To: hamid  Cc: ML BIND Users 
 Subject: Re: Thread handling On 24. 8. 2022, at 
11:01, hamid  wrote:> Perhaps, describing the use case first 
(why do you want to use MongoDB at all) might have the benefit of not wasting 
time on your end.Forgot to answer this, my use case would be the same as 
someone who uses a SQL DB backend I imagine: to be able to configure multiple 
BIND endpoints, using the same backend DB instead of configuration files, so 
there is no need to worry about change propagation and use of configuration 
management tools like chef, ansible etc.I just prefer to use no-sql backends 
like MongoDB, or Amazon's DocumentDB.If there is any specific downside to using 
no-sql databases, or any reason it would not make sense, I would appreciate it 
if you can explain it a bit. I am aware of the latency it would introduce, but 
was under the impression that DynDB is introduced to address that.Such use case 
(authoritative data) is fine, I was merely speaking about caching server 
before.You have to calculate the benefit-cost ratio yourself compared to other 
provisioning systems - f.e. hidden primary with multiple secondaries updated 
with nsupdate works reasonably well in smaller 
deployments.Cheers,Ondrej--Ondřej Surý (He/Him)ondrej@isc.orgMy working hours 
and your working hours may be different. Please do not feel obligated to reply 
outside your normal working hours.RegardsHamid Maadani Original message 
From: Hamid Maadani  Date: 8/24/22 01:08 (GMT-08:00) 
To: Ondřej Surý , Evan Hunt  Cc: 
bind-us...@lists.isc.orgSubject: Re: Thread handling > BIND does have dyndb 
support, since 9.11.> As far as I know, though, the only two dyndb modules in 
existence are> the bind-dyndb-ldap modiule that was written by Red Hat as part 
of> FreeIPA, and a toy module used for testing. If you were interested in> 
writing your MongoDB module for dyndb instead of DLZ, I'd be quite> excited 
about that, I've long hoped the API would get more use.Interesting. I looked in 
the contrib directory and only found the DLZ modules there. Can you please 
point me in the direction of the source code for that toy module?I would 
definitely work on a mongo-dyndb implementation as well, when the time 
permits.> I am fairly confident that any advantage from shared cache will be 
lost because the extra latency caused by communication with the MongoDB (or any 
other no-sql systems).> Perhaps, describing the use case first (why do you want 
to use MongoDB at all) might have the benefit of not wasting time on your 
end.This is a bit confusing to me. As I understand it, a normal bind zone is 
loaded into memory, and requests are served from that memory-cache, hence super 
fast.DLZ modules however, make a call to the backend database per query. Which 
would introduce latency (in my tests, 50ms when using an Atlas cluster in the 
same geographical region). However, why would this be specific to no-sql 
databases?! Doesn't this also apply to any sql based DB?Now, an advantage of 
DLZ, is any change you make to the backend DB takes place immediately without 
the need to reload the server. Not a huge advantage in my personal opinion, but 
I do see the use case for it.Looking for a way to load queried records from a 
backend database into memory to speed up the responses, I found posts about the 
DynDB API. If Evan can kindly point me in the right direction there, I will be 
developing both DLZ and DynDB modules for MongoDB, as I do see use cases for 
each one.The caching question that I asked, was more around having a workaround 
without DynDB, because I was under the impression that DynDB API is not 
available at the moment. My understanding of a BIND caching server (and 
admittedly , I am by no means an advanced user when it comes to BIND), is that 
it would query records from another server, and cache them for the life (TTL) 
of that record, and serve it. This cache, exists in memory, correct?So in 
theory, if I was to use a DLZ to keep my records

Re: address/prefix length mismatch

2022-08-24 Thread Sten Carlsen 


> On 24 Aug 2022, at 16.52, Greg Choules  
> wrote:
> 
> Hi Sten.
> That is absolutely what you do *not* want to do.
> 
> Writing it out in binary might help. /23 means the following:
>   1110 
> 
> '1' bits mean, test an incoming address against the corresponding bit from 
> the address in the mask.
> '0' bits mean, don't test an incoming address against the corresponding bit 
> from the address in the mask.
> 
> The ACL 10.60.0.0/23  will match *any* address from 
> 10.60.0.0 to 10.60.1.255 *inclusive*.
> 
> There is no concept of network address and broadcast address here. It is just 
> pattern matching.

Yes, I was (incorrectly) thinking in terms of a /24 network and assumed that 
removing the ..0 and ..255 addresses was the issue. The proposal would do that 
by first rejecting (! - means reject) the offending addresses (all have to be 
listed separately) before doing the above pattern matching.

> 
> Cheers, Greg
> 
> On Wed, 24 Aug 2022 at 15:40, Sten Carlsen  > wrote:
> I think you want something like this:
> 
> (!10.60.0.0; !10.60.0.255; 10.60.0.0/24 )
> 
> First deny the two addresses you want not to be part of the ACL and then 
> accept the whole network.
> 
> First match is used, so 10.60.0.0 would match !10.60.0.0 and be rejected 
> before the next  are tested.
> 
> Thanks
> 
> Sten
> 
>> On 24 Aug 2022, at 16.05, Ondřej Surý > > wrote:
>> 
>> 
>>> On 24. 8. 2022, at 15:58, Elias Pereira >> > wrote:
>>> 
>>> hello Ondrej,
>>> 
>>> Not completely wrong, because 255 is the broadcast.
>> 
>> No, it's not. This is ACL specification, not a interface/network 
>> configuration.
>> 
>>> For a better understanding, then it would be Available range 10.60.0.1 to 
>>> 10.60.1.254.
>> 
>> No, I've already provided you with a correct answer what 10.60.0.0/23 
>>  means in terms of range, why do you insist on this?
>> 
>>> Correctly specified range (without address/host bits) does takes the whole 
>>> range.
>>> 
>>> Like this 10.60/23; ?
>> 
>> I think others have already answered that, I would be just repeating their 
>> answers.
>> 
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org 
>> 
>> My working hours and your working hours may be different. Please do not feel 
>> obligated to reply outside your normal working hours.
>> 
>> 
>>> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý >> > wrote:
>>> 
>>> 
 On 24. 8. 2022, at 15:26, Elias Pereira >>> > wrote:
 
 
 Hello Greg,
 
 Why doesn't bind work with networks/subnets in the conventional way?
>>> 
>>> It does.
>>> 
 If the private subnet is 10.60.0.0/23 , then it means 
 that the address range is 10.60.0.1 to 10.60.1.254.
>>> 
>>> That’s wrong. 10.60.0.0/23  means 10.60.0.0 to 
>>> 10.60.1.255 range.
>>> 
 How do I configure this ACL in named.conf.local so that it takes the whole 
 range?
>>> 
>>> Correctly specified range (without address/host bits) does takes the whole 
>>> range.
>>> 
>>> Ondrej 
>>> --
>>> 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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev >>> > wrote:
 On 24/08/2022 14:16, Elias Pereira wrote:
 
 Hi Elias,
 
 > Oh, sorry... :D
 > 
 > here it is
 > 
 > # cat named.conf.local
 > # ACL das redes internas
 > # Ultima modificação: 24/08/2022
 > 
 > acl "internal" {
 > 10.60.0.1/23 ;
 
 This is the issue. The address part of the prefix should be the lowest 
 address in that prefix. If you change this to 10.60.0.0/23 
 , it will be 
 fine. The same goes for all the other prefixes in your list. Change the 
 1's to 0's.
 
 > 10.10.1.1/24 ;
 > 10.10.2.1/25 ;
 > 10.10.3.1/25 ;
 > 10.10.4.1/25 ;
 > 10.10.5.1/25 ;
 > 10.51.0.1/23 ;
 > 10.10.6.1/25 ;
 > 10.10.7.1/26 ;
 > 172.20.0.1/26 ;
 > 10.50.0.1/23 ;
 > 10.40.0.1/22 ;
 > 10.56.0.1/22 ;
 > };
 
 
 -- 
 Elias Pereira
 -- 
 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/

Re: address/prefix length mismatch

2022-08-24 Thread Greg Choules via bind-users 
Hi Sten.
That is absolutely what you do *not* want to do.

Writing it out in binary might help. /23 means the following:
  1110 

'1' bits mean, test an incoming address against the corresponding bit from
the address in the mask.
'0' bits mean, don't test an incoming address against the corresponding bit
from the address in the mask.

The ACL 10.60.0.0/23 will match *any* address from 10.60.0.0 to 10.60.1.255
*inclusive*.

There is no concept of network address and broadcast address here. It is
just pattern matching.

Cheers, Greg

On Wed, 24 Aug 2022 at 15:40, Sten Carlsen  wrote:

> I think you want something like this:
>
> (!10.60.0.0; !10.60.0.255; 10.60.0.0/24)
>
> First deny the two addresses you want not to be part of the *ACL* and
> then accept the whole network.
>
> First match is used, so 10.60.0.0 would match !10.60.0.0 and be rejected
> before the next  are tested.
>
> Thanks
>
> Sten
>
> On 24 Aug 2022, at 16.05, Ondřej Surý  wrote:
>
>
> On 24. 8. 2022, at 15:58, Elias Pereira  wrote:
>
> hello Ondrej,
>
> Not completely wrong, because 255 is the broadcast.
>
>
> No, it's not. This is ACL specification, not a interface/network
> configuration.
>
> For a better understanding, then it would be Available range 10.60.0.1 to
> 10.60.1.254.
>
>
> No, I've already provided you with a correct answer what 10.60.0.0/23
> means in terms of range, why do you insist on this?
>
> Correctly specified range (without address/host bits) does takes the whole
>> range.
>
>
> Like this 10.60/23; ?
>
>
> I think others have already answered that, I would be just repeating their
> answers.
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
>
> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý  wrote:
>
>>
>>
>> On 24. 8. 2022, at 15:26, Elias Pereira  wrote:
>>
>> 
>> Hello Greg,
>>
>> Why doesn't bind work with networks/subnets in the conventional way?
>>
>>
>> It does.
>>
>> If the private subnet is 10.60.0.0/23, then it means that the address
>> range is 10.60.0.1 to 10.60.1.254.
>>
>>
>> That’s wrong. 10.60.0.0/23 means 10.60.0.0 to 10.60.1.255 range.
>>
>> How do I configure this ACL in named.conf.local so that it takes the
>> whole range?
>>
>>
>> Correctly specified range (without address/host bits) does takes the
>> whole range.
>>
>> Ondrej
>> --
>> 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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev  wrote:
>>
>>> On 24/08/2022 14:16, Elias Pereira wrote:
>>>
>>> Hi Elias,
>>>
>>> > Oh, sorry... :D
>>> >
>>> > here it is
>>> >
>>> > # cat named.conf.local
>>> > # ACL das redes internas
>>> > # Ultima modificação: 24/08/2022
>>> >
>>> > acl "internal" {
>>> > 10.60.0.1/23;
>>>
>>> This is the issue. The address part of the prefix should be the lowest
>>> address in that prefix. If you change this to 10.60.0.0/23, it will be
>>> fine. The same goes for all the other prefixes in your list. Change the
>>> 1's to 0's.
>>>
>>> > 10.10.1.1/24;
>>> > 10.10.2.1/25;
>>> > 10.10.3.1/25;
>>> > 10.10.4.1/25;
>>> > 10.10.5.1/25;
>>> > 10.51.0.1/23;
>>> > 10.10.6.1/25;
>>> > 10.10.7.1/26;
>>> > 172.20.0.1/26;
>>> > 10.50.0.1/23;
>>> > 10.40.0.1/22;
>>> > 10.56.0.1/22;
>>> > };
>>>
>>
>>
>> --
>> Elias Pereira
>> --
>> 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
>>
>>
>
> --
> Elias Pereira
>
>
> --
> 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
>
-- 
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: address/prefix length mismatch

2022-08-24 Thread Sten Carlsen 
I think you want something like this:

(!10.60.0.0; !10.60.0.255; 10.60.0.0/24)

First deny the two addresses you want not to be part of the ACL and then accept 
the whole network.

First match is used, so 10.60.0.0 would match !10.60.0.0 and be rejected before 
the next  are tested.

Thanks

Sten

> On 24 Aug 2022, at 16.05, Ondřej Surý  wrote:
> 
> 
>> On 24. 8. 2022, at 15:58, Elias Pereira > > wrote:
>> 
>> hello Ondrej,
>> 
>> Not completely wrong, because 255 is the broadcast.
> 
> No, it's not. This is ACL specification, not a interface/network 
> configuration.
> 
>> For a better understanding, then it would be Available range 10.60.0.1 to 
>> 10.60.1.254.
> 
> No, I've already provided you with a correct answer what 10.60.0.0/23 means 
> in terms of range, why do you insist on this?
> 
>> Correctly specified range (without address/host bits) does takes the whole 
>> range.
>> 
>> Like this 10.60/23; ?
> 
> I think others have already answered that, I would be just repeating their 
> answers.
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org 
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
> 
>> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý > > wrote:
>> 
>> 
>>> On 24. 8. 2022, at 15:26, Elias Pereira >> > wrote:
>>> 
>>> 
>>> Hello Greg,
>>> 
>>> Why doesn't bind work with networks/subnets in the conventional way?
>> 
>> It does.
>> 
>>> If the private subnet is 10.60.0.0/23 , then it means 
>>> that the address range is 10.60.0.1 to 10.60.1.254.
>> 
>> That’s wrong. 10.60.0.0/23  means 10.60.0.0 to 
>> 10.60.1.255 range.
>> 
>>> How do I configure this ACL in named.conf.local so that it takes the whole 
>>> range?
>> 
>> Correctly specified range (without address/host bits) does takes the whole 
>> range.
>> 
>> Ondrej 
>> --
>> 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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev >> > wrote:
>>> On 24/08/2022 14:16, Elias Pereira wrote:
>>> 
>>> Hi Elias,
>>> 
>>> > Oh, sorry... :D
>>> > 
>>> > here it is
>>> > 
>>> > # cat named.conf.local
>>> > # ACL das redes internas
>>> > # Ultima modificação: 24/08/2022
>>> > 
>>> > acl "internal" {
>>> > 10.60.0.1/23 ;
>>> 
>>> This is the issue. The address part of the prefix should be the lowest 
>>> address in that prefix. If you change this to 10.60.0.0/23 
>>> , it will be 
>>> fine. The same goes for all the other prefixes in your list. Change the 
>>> 1's to 0's.
>>> 
>>> > 10.10.1.1/24 ;
>>> > 10.10.2.1/25 ;
>>> > 10.10.3.1/25 ;
>>> > 10.10.4.1/25 ;
>>> > 10.10.5.1/25 ;
>>> > 10.51.0.1/23 ;
>>> > 10.10.6.1/25 ;
>>> > 10.10.7.1/26 ;
>>> > 172.20.0.1/26 ;
>>> > 10.50.0.1/23 ;
>>> > 10.40.0.1/22 ;
>>> > 10.56.0.1/22 ;
>>> > };
>>> 
>>> 
>>> -- 
>>> Elias Pereira
>>> -- 
>>> 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 
>>> 
>> 
>> 
>> -- 
>> Elias Pereira
> 
> -- 
> 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: address/prefix length mismatch

2022-08-24 Thread Elias Pereira 
>
> No, it's not. This is ACL specification, not a interface/network
> configuration.

Ok.


> No, I've already provided you with a correct answer what 10.60.0.0/23 means
> in terms of range, why do you insist on this?

ok.

> I think others have already answered that, I would be just repeating their
> answers.

Ok.

Thanks!!!

On Wed, Aug 24, 2022 at 11:05 AM Ondřej Surý  wrote:

>
> On 24. 8. 2022, at 15:58, Elias Pereira  wrote:
>
> hello Ondrej,
>
> Not completely wrong, because 255 is the broadcast.
>
>
> No, it's not. This is ACL specification, not a interface/network
> configuration.
>
> For a better understanding, then it would be Available range 10.60.0.1 to
> 10.60.1.254.
>
>
> No, I've already provided you with a correct answer what 10.60.0.0/23
> means in terms of range, why do you insist on this?
>
> Correctly specified range (without address/host bits) does takes the whole
>> range.
>
>
> Like this 10.60/23; ?
>
>
> I think others have already answered that, I would be just repeating their
> answers.
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
>
> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý  wrote:
>
>>
>>
>> On 24. 8. 2022, at 15:26, Elias Pereira  wrote:
>>
>> 
>> Hello Greg,
>>
>> Why doesn't bind work with networks/subnets in the conventional way?
>>
>>
>> It does.
>>
>> If the private subnet is 10.60.0.0/23, then it means that the address
>> range is 10.60.0.1 to 10.60.1.254.
>>
>>
>> That’s wrong. 10.60.0.0/23 means 10.60.0.0 to 10.60.1.255 range.
>>
>> How do I configure this ACL in named.conf.local so that it takes the
>> whole range?
>>
>>
>> Correctly specified range (without address/host bits) does takes the
>> whole range.
>>
>> Ondrej
>> --
>> 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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev  wrote:
>>
>>> On 24/08/2022 14:16, Elias Pereira wrote:
>>>
>>> Hi Elias,
>>>
>>> > Oh, sorry... :D
>>> >
>>> > here it is
>>> >
>>> > # cat named.conf.local
>>> > # ACL das redes internas
>>> > # Ultima modificação: 24/08/2022
>>> >
>>> > acl "internal" {
>>> > 10.60.0.1/23;
>>>
>>> This is the issue. The address part of the prefix should be the lowest
>>> address in that prefix. If you change this to 10.60.0.0/23, it will be
>>> fine. The same goes for all the other prefixes in your list. Change the
>>> 1's to 0's.
>>>
>>> > 10.10.1.1/24;
>>> > 10.10.2.1/25;
>>> > 10.10.3.1/25;
>>> > 10.10.4.1/25;
>>> > 10.10.5.1/25;
>>> > 10.51.0.1/23;
>>> > 10.10.6.1/25;
>>> > 10.10.7.1/26;
>>> > 172.20.0.1/26;
>>> > 10.50.0.1/23;
>>> > 10.40.0.1/22;
>>> > 10.56.0.1/22;
>>> > };
>>>
>>
>>
>> --
>> Elias Pereira
>> --
>> 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
>>
>>
>
> --
> Elias Pereira
>
>
>

-- 
Elias Pereira
-- 
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: address/prefix length mismatch

2022-08-24 Thread Ondřej Surý 

> On 24. 8. 2022, at 15:58, Elias Pereira  wrote:
> 
> hello Ondrej,
> 
> Not completely wrong, because 255 is the broadcast.

No, it's not. This is ACL specification, not a interface/network configuration.

> For a better understanding, then it would be Available range 10.60.0.1 to 
> 10.60.1.254.

No, I've already provided you with a correct answer what 10.60.0.0/23 means in 
terms of range, why do you insist on this?

> Correctly specified range (without address/host bits) does takes the whole 
> range.
> 
> Like this 10.60/23; ?

I think others have already answered that, I would be just repeating their 
answers.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

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


> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý  > wrote:
> 
> 
>> On 24. 8. 2022, at 15:26, Elias Pereira > > wrote:
>> 
>> 
>> Hello Greg,
>> 
>> Why doesn't bind work with networks/subnets in the conventional way?
> 
> It does.
> 
>> If the private subnet is 10.60.0.0/23 , then it means 
>> that the address range is 10.60.0.1 to 10.60.1.254.
> 
> That’s wrong. 10.60.0.0/23  means 10.60.0.0 to 
> 10.60.1.255 range.
> 
>> How do I configure this ACL in named.conf.local so that it takes the whole 
>> range?
> 
> Correctly specified range (without address/host bits) does takes the whole 
> range.
> 
> Ondrej 
> --
> 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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev > > wrote:
>> On 24/08/2022 14:16, Elias Pereira wrote:
>> 
>> Hi Elias,
>> 
>> > Oh, sorry... :D
>> > 
>> > here it is
>> > 
>> > # cat named.conf.local
>> > # ACL das redes internas
>> > # Ultima modificação: 24/08/2022
>> > 
>> > acl "internal" {
>> > 10.60.0.1/23 ;
>> 
>> This is the issue. The address part of the prefix should be the lowest 
>> address in that prefix. If you change this to 10.60.0.0/23 
>> , it will be 
>> fine. The same goes for all the other prefixes in your list. Change the 
>> 1's to 0's.
>> 
>> > 10.10.1.1/24 ;
>> > 10.10.2.1/25 ;
>> > 10.10.3.1/25 ;
>> > 10.10.4.1/25 ;
>> > 10.10.5.1/25 ;
>> > 10.51.0.1/23 ;
>> > 10.10.6.1/25 ;
>> > 10.10.7.1/26 ;
>> > 172.20.0.1/26 ;
>> > 10.50.0.1/23 ;
>> > 10.40.0.1/22 ;
>> > 10.56.0.1/22 ;
>> > };
>> 
>> 
>> -- 
>> Elias Pereira
>> -- 
>> 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 
>> 
> 
> 
> -- 
> Elias Pereira

-- 
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: address/prefix length mismatch

2022-08-24 Thread Elias Pereira 
hello Ondrej,

Not completely wrong, because 255 is the broadcast.

For a better understanding, then it would be Available range 10.60.0.1 to
10.60.1.254.

Correctly specified range (without address/host bits) does takes the whole
> range.


Like this 10.60/23; ?

On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý  wrote:

>
>
> On 24. 8. 2022, at 15:26, Elias Pereira  wrote:
>
> 
> Hello Greg,
>
> Why doesn't bind work with networks/subnets in the conventional way?
>
>
> It does.
>
> If the private subnet is 10.60.0.0/23, then it means that the address
> range is 10.60.0.1 to 10.60.1.254.
>
>
> That’s wrong. 10.60.0.0/23 means 10.60.0.0 to 10.60.1.255 range.
>
> How do I configure this ACL in named.conf.local so that it takes the whole
> range?
>
>
> Correctly specified range (without address/host bits) does takes the whole
> range.
>
> Ondrej
> --
> 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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev  wrote:
>
>> On 24/08/2022 14:16, Elias Pereira wrote:
>>
>> Hi Elias,
>>
>> > Oh, sorry... :D
>> >
>> > here it is
>> >
>> > # cat named.conf.local
>> > # ACL das redes internas
>> > # Ultima modificação: 24/08/2022
>> >
>> > acl "internal" {
>> > 10.60.0.1/23;
>>
>> This is the issue. The address part of the prefix should be the lowest
>> address in that prefix. If you change this to 10.60.0.0/23, it will be
>> fine. The same goes for all the other prefixes in your list. Change the
>> 1's to 0's.
>>
>> > 10.10.1.1/24;
>> > 10.10.2.1/25;
>> > 10.10.3.1/25;
>> > 10.10.4.1/25;
>> > 10.10.5.1/25;
>> > 10.51.0.1/23;
>> > 10.10.6.1/25;
>> > 10.10.7.1/26;
>> > 172.20.0.1/26;
>> > 10.50.0.1/23;
>> > 10.40.0.1/22;
>> > 10.56.0.1/22;
>> > };
>>
>
>
> --
> Elias Pereira
> --
> 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
>
>

-- 
Elias Pereira
-- 
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: address/prefix length mismatch

2022-08-24 Thread Ondřej Surý 


> On 24. 8. 2022, at 15:26, Elias Pereira  wrote:
> 
> 
> Hello Greg,
> 
> Why doesn't bind work with networks/subnets in the conventional way?

It does.

> If the private subnet is 10.60.0.0/23, then it means that the address range 
> is 10.60.0.1 to 10.60.1.254.

That’s wrong. 10.60.0.0/23 means 10.60.0.0 to 10.60.1.255 range.

> How do I configure this ACL in named.conf.local so that it takes the whole 
> range?

Correctly specified range (without address/host bits) does takes the whole 
range.

Ondrej 
--
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 Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev  wrote:
>> On 24/08/2022 14:16, Elias Pereira wrote:
>> 
>> Hi Elias,
>> 
>> > Oh, sorry... :D
>> > 
>> > here it is
>> > 
>> > # cat named.conf.local
>> > # ACL das redes internas
>> > # Ultima modificação: 24/08/2022
>> > 
>> > acl "internal" {
>> > 10.60.0.1/23;
>> 
>> This is the issue. The address part of the prefix should be the lowest 
>> address in that prefix. If you change this to 10.60.0.0/23, it will be 
>> fine. The same goes for all the other prefixes in your list. Change the 
>> 1's to 0's.
>> 
>> > 10.10.1.1/24;
>> > 10.10.2.1/25;
>> > 10.10.3.1/25;
>> > 10.10.4.1/25;
>> > 10.10.5.1/25;
>> > 10.51.0.1/23;
>> > 10.10.6.1/25;
>> > 10.10.7.1/26;
>> > 172.20.0.1/26;
>> > 10.50.0.1/23;
>> > 10.40.0.1/22;
>> > 10.56.0.1/22;
>> > };
> 
> 
> -- 
> Elias Pereira
> -- 
> 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: address/prefix length mismatch

2022-08-24 Thread Elias Pereira 
Hello Greg,

Why doesn't bind work with networks/subnets in the conventional way?

If the private subnet is 10.60.0.0/23, then it means that the address range
is 10.60.0.1 to 10.60.1.254.

How do I configure this ACL in named.conf.local so that it takes the whole
range?

On Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev  wrote:

> On 24/08/2022 14:16, Elias Pereira wrote:
>
> Hi Elias,
>
> > Oh, sorry... :D
> >
> > here it is
> >
> > # cat named.conf.local
> > # ACL das redes internas
> > # Ultima modificação: 24/08/2022
> >
> > acl "internal" {
> > 10.60.0.1/23;
>
> This is the issue. The address part of the prefix should be the lowest
> address in that prefix. If you change this to 10.60.0.0/23, it will be
> fine. The same goes for all the other prefixes in your list. Change the
> 1's to 0's.
>
> > 10.10.1.1/24;
> > 10.10.2.1/25;
> > 10.10.3.1/25;
> > 10.10.4.1/25;
> > 10.10.5.1/25;
> > 10.51.0.1/23;
> > 10.10.6.1/25;
> > 10.10.7.1/26;
> > 172.20.0.1/26;
> > 10.50.0.1/23;
> > 10.40.0.1/22;
> > 10.56.0.1/22;
> > };
>


-- 
Elias Pereira
-- 
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: address/prefix length mismatch

2022-08-24 Thread Anand Buddhdev 

On 24/08/2022 14:16, Elias Pereira wrote:

Hi Elias,


Oh, sorry... :D

here it is

# cat named.conf.local
# ACL das redes internas
# Ultima modificação: 24/08/2022

acl "internal" {
10.60.0.1/23;


This is the issue. The address part of the prefix should be the lowest 
address in that prefix. If you change this to 10.60.0.0/23, it will be 
fine. The same goes for all the other prefixes in your list. Change the 
1's to 0's.



10.10.1.1/24;
10.10.2.1/25;
10.10.3.1/25;
10.10.4.1/25;
10.10.5.1/25;
10.51.0.1/23;
10.10.6.1/25;
10.10.7.1/26;
172.20.0.1/26;
10.50.0.1/23;
10.40.0.1/22;
10.56.0.1/22;
};

--
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: address/prefix length mismatch

2022-08-24 Thread Greg Choules via bind-users 
Hi Elias.
I can't say why this might have worked with 9.11 (if it did - I'd be
surprised). But you should not/cannot define ACLs like this:
10.60.0.1/23;
/23 means consider only the first 23 bits of the available 32 bits of an
IPv4 address and ignore the rest (in this context. Please don't someone
else shoot me down for other uses of netmasks).

Since the human-readable version of an IPv4 address (in bits) is 8.8.8.8
(no, not THAT 8.8.8.8) a /23 mask means care about the first three octets
(24 bits), except the last bit of the third octet (back to 23 bits), and
don't care about the fourth octet at all.

So in this case the third octet *must* be an even number (zero is even in
this context) and the fourth octet should be zero. Like this:
10.60.0.0/23;

10.60.2.0/23; would also be acceptable.
10.60.17.0/23; would not be acceptable because the third octet is odd, so
its low order bit is 1.

I hope that helps.
Greg



On Wed, 24 Aug 2022 at 13:17, Elias Pereira  wrote:

> Oh, sorry... :D
>
> here it is
>
> # cat named.conf.local
> # ACL das redes internas
> # Ultima modificação: 24/08/2022
>
> acl "internal" {
> 10.60.0.1/23;
> 10.10.1.1/24;
> 10.10.2.1/25;
> 10.10.3.1/25;
> 10.10.4.1/25;
> 10.10.5.1/25;
> 10.51.0.1/23;
> 10.10.6.1/25;
> 10.10.7.1/26;
> 172.20.0.1/26;
> 10.50.0.1/23;
> 10.40.0.1/22;
> 10.56.0.1/22;
> };
>
> On Wed, Aug 24, 2022 at 9:14 AM Anand Buddhdev  wrote:
>
>> On 24/08/2022 14:08, Elias Pereira wrote:
>>
>> Hi Elias,
>>
>> > I upgraded my AD, debian 10 to 11 and bind upgraded to version 9.16.27.
>> >
>> > Now I get the address/prefix length mismatch error in name.conf.local.
>> >
>> > In my first AD that I have not upgraded yet, it is working correctly
>> with
>> > the same settings in version 9.11.x.
>> >
>> > What is the problem with version 9.16.x?
>>
>> We don't know what your named.conf.local looks like, so it's impossible
>> to help you. Please help yourself by asking a better question, in which
>> you show your configuration. Then someone can probably spot the error
>> and provide a helpful answer.
>>
>> Regards,
>> Anand
>>
>
>
> --
> Elias Pereira
> --
> 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: address/prefix length mismatch

2022-08-24 Thread Elias Pereira 
I changed all the networks from x.x.x.1/x to x.x.x.0/x and it seems to me
that it now works.

On Wed, Aug 24, 2022 at 9:16 AM Elias Pereira  wrote:

> Oh, sorry... :D
>
> here it is
>
> # cat named.conf.local
> # ACL das redes internas
> # Ultima modificação: 24/08/2022
>
> acl "internal" {
> 10.60.0.1/23;
> 10.10.1.1/24;
> 10.10.2.1/25;
> 10.10.3.1/25;
> 10.10.4.1/25;
> 10.10.5.1/25;
> 10.51.0.1/23;
> 10.10.6.1/25;
> 10.10.7.1/26;
> 172.20.0.1/26;
> 10.50.0.1/23;
> 10.40.0.1/22;
> 10.56.0.1/22;
> };
>
> On Wed, Aug 24, 2022 at 9:14 AM Anand Buddhdev  wrote:
>
>> On 24/08/2022 14:08, Elias Pereira wrote:
>>
>> Hi Elias,
>>
>> > I upgraded my AD, debian 10 to 11 and bind upgraded to version 9.16.27.
>> >
>> > Now I get the address/prefix length mismatch error in name.conf.local.
>> >
>> > In my first AD that I have not upgraded yet, it is working correctly
>> with
>> > the same settings in version 9.11.x.
>> >
>> > What is the problem with version 9.16.x?
>>
>> We don't know what your named.conf.local looks like, so it's impossible
>> to help you. Please help yourself by asking a better question, in which
>> you show your configuration. Then someone can probably spot the error
>> and provide a helpful answer.
>>
>> Regards,
>> Anand
>>
>
>
> --
> Elias Pereira
>


-- 
Elias Pereira
-- 
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: address/prefix length mismatch

2022-08-24 Thread Elias Pereira 
Oh, sorry... :D

here it is

# cat named.conf.local
# ACL das redes internas
# Ultima modificação: 24/08/2022

acl "internal" {
10.60.0.1/23;
10.10.1.1/24;
10.10.2.1/25;
10.10.3.1/25;
10.10.4.1/25;
10.10.5.1/25;
10.51.0.1/23;
10.10.6.1/25;
10.10.7.1/26;
172.20.0.1/26;
10.50.0.1/23;
10.40.0.1/22;
10.56.0.1/22;
};

On Wed, Aug 24, 2022 at 9:14 AM Anand Buddhdev  wrote:

> On 24/08/2022 14:08, Elias Pereira wrote:
>
> Hi Elias,
>
> > I upgraded my AD, debian 10 to 11 and bind upgraded to version 9.16.27.
> >
> > Now I get the address/prefix length mismatch error in name.conf.local.
> >
> > In my first AD that I have not upgraded yet, it is working correctly with
> > the same settings in version 9.11.x.
> >
> > What is the problem with version 9.16.x?
>
> We don't know what your named.conf.local looks like, so it's impossible
> to help you. Please help yourself by asking a better question, in which
> you show your configuration. Then someone can probably spot the error
> and provide a helpful answer.
>
> Regards,
> Anand
>


-- 
Elias Pereira
-- 
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: address/prefix length mismatch

2022-08-24 Thread Anand Buddhdev 

On 24/08/2022 14:08, Elias Pereira wrote:

Hi Elias,


I upgraded my AD, debian 10 to 11 and bind upgraded to version 9.16.27.

Now I get the address/prefix length mismatch error in name.conf.local.

In my first AD that I have not upgraded yet, it is working correctly with
the same settings in version 9.11.x.

What is the problem with version 9.16.x?


We don't know what your named.conf.local looks like, so it's impossible 
to help you. Please help yourself by asking a better question, in which 
you show your configuration. Then someone can probably spot the error 
and provide a helpful answer.


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

address/prefix length mismatch

2022-08-24 Thread Elias Pereira 
Hello,

I upgraded my AD, debian 10 to 11 and bind upgraded to version 9.16.27.

Now I get the address/prefix length mismatch error in name.conf.local.

In my first AD that I have not upgraded yet, it is working correctly with
the same settings in version 9.11.x.

What is the problem with version 9.16.x?

-- 
Elias Pereira
-- 
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: Thread handling

2022-08-24 Thread Ondřej Surý 
> On 24. 8. 2022, at 11:01, hamid  wrote:
> 
> > Perhaps, describing the use case first (why do you want to use MongoDB at 
> > all) might have the benefit of not wasting time on your end.
> 
> Forgot to answer this, my use case would be the same as someone who uses a 
> SQL DB backend I imagine: to be able to configure multiple BIND endpoints, 
> using the same backend DB instead of configuration files, so there is no need 
> to worry about change propagation and use of configuration management tools 
> like chef, ansible etc.
> I just prefer to use no-sql backends like MongoDB, or Amazon's DocumentDB.
> 
> If there is any specific downside to using no-sql databases, or any reason it 
> would not make sense, I would appreciate it if you can explain it a bit. I am 
> aware of the latency it would introduce, but was under the impression that 
> DynDB is introduced to address that.

Such use case (authoritative data) is fine, I was merely speaking about caching 
server before.

You have to calculate the benefit-cost ratio yourself compared to other 
provisioning systems - f.e. hidden primary with multiple secondaries updated 
with nsupdate works reasonably well in smaller deployments.

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

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


> Regards
> Hamid Maadani
> 
> 
>  Original message 
> From: Hamid Maadani mailto:ha...@dexo.tech>> 
> Date: 8/24/22 01:08 (GMT-08:00) 
> To: Ondřej Surý mailto:ond...@isc.org>>, Evan Hunt 
> mailto:e...@isc.org>> 
> Cc: bind-users@lists.isc.org 
> Subject: Re: Thread handling 
> 
> > BIND does have dyndb support, since 9.11.
> > As far as I know, though, the only two dyndb modules in existence are
> > the bind-dyndb-ldap modiule that was written by Red Hat as part of
> > FreeIPA, and a toy module used for testing. If you were interested in
> > writing your MongoDB module for dyndb instead of DLZ, I'd be quite
> > excited about that, I've long hoped the API would get more use.
> 
> Interesting. I looked in the contrib directory and only found the DLZ modules 
> there. Can you please point me in the direction of the source code for that 
> toy module?
> I would definitely work on a mongo-dyndb implementation as well, when the 
> time permits.
> > I am fairly confident that any advantage from shared cache will be lost 
> > because the extra latency caused by communication with the MongoDB (or any 
> > other no-sql systems).
> > Perhaps, describing the use case first (why do you want to use MongoDB at 
> > all) might have the benefit of not wasting time on your end.
> 
> This is a bit confusing to me. As I understand it, a normal bind zone is 
> loaded into memory, and requests are served from that memory-cache, hence 
> super fast.
> DLZ modules however, make a call to the backend database per query. Which 
> would introduce latency (in my tests, 50ms when using an Atlas cluster in the 
> same geographical region). However, why would this be specific to no-sql 
> databases?! Doesn't this also apply to any sql based DB?
> 
> Now, an advantage of DLZ, is any change you make to the backend DB takes 
> place immediately without the need to reload the server. Not a huge advantage 
> in my personal opinion, but I do see the use case for it.
> Looking for a way to load queried records from a backend database into memory 
> to speed up the responses, I found posts about the DynDB API. If Evan can 
> kindly point me in the right direction there, I will be developing both DLZ 
> and DynDB modules for MongoDB, as I do see use cases for each one.
> 
> The caching question that I asked, was more around having a workaround 
> without DynDB, because I was under the impression that DynDB API is not 
> available at the moment. My understanding of a BIND caching server (and 
> admittedly , I am by no means an advanced user when it comes to BIND), is 
> that it would query records from another server, and cache them for the life 
> (TTL) of that record, and serve it. This cache, exists in memory, correct?
> So in theory, if I was to use a DLZ to keep my records in a backend DB, I can 
> technically create a BIND server with the DLZ enabled (let's say a docker 
> image), and then put a caching server in front of it, which is "customer 
> facing".
> That way, all queries will come to the caching server, and will be served 
> super fast because they are cached in memory, but the actual records live in 
> a backend DB somewhere.
> Long story short, I was trying to see if the same can be achieved with one 
> single instance instead of two, which sounds like it can not be done.
> 
> Regards
> Hamid Maadani
> 
> August 24, 2022 12:40 AM, "Ondřej Surý"  >
>  wrote:
>> On 24. 8. 2022, at 8:48, Evan Hunt mailto:e...@isc.org>> 
>> wrote:
>>> In

Re: Thread handling

2022-08-24 Thread hamid 
> Perhaps, describing the use case first (why do you want to use MongoDB at 
> all) might have the benefit of not wasting time on your end.Forgot to answer 
> this, my use case would be the same as someone who uses a SQL DB backend I 
> imagine: to be able to configure multiple BIND endpoints, using the same 
> backend DB instead of configuration files, so there is no need to worry about 
> change propagation and use of configuration management tools like chef, 
> ansible etc.I just prefer to use no-sql backends like MongoDB, or Amazon's 
> DocumentDB.If there is any specific downside to using no-sql databases, or 
> any reason it would not make sense, I would appreciate it if you can explain 
> it a bit. I am aware of the latency it would introduce, but was under the 
> impression that DynDB is introduced to address that.RegardsHamid Maadani
 Original message From: Hamid Maadani  Date: 
8/24/22  01:08  (GMT-08:00) To: Ondřej Surý , Evan Hunt 
 Cc: bind-users@lists.isc.org Subject: Re: Thread handling > BIND 
does have dyndb support, since 9.11.> As far as I know, though, the only two 
dyndb modules in existence are> the bind-dyndb-ldap modiule that was written by 
Red Hat as part of> FreeIPA, and a toy module used for testing. If you were 
interested in> writing your MongoDB module for dyndb instead of DLZ, I'd be 
quite> excited about that, I've long hoped the API would get more 
use.Interesting. I looked in the contrib directory and only found the DLZ 
modules there. Can you please point me in the direction of the source code for 
that toy module?I would definitely work on a mongo-dyndb implementation as 
well, when the time permits. > I am fairly confident that any advantage from 
shared cache will be lost because the extra latency caused by communication 
with the MongoDB (or any other no-sql systems).> Perhaps, describing the use 
case first (why do you want to use MongoDB at all) might have the benefit of 
not wasting time on your end.This is a bit confusing to me. As I understand it, 
a normal bind zone is loaded into memory, and requests are served from that 
memory-cache, hence super fast.DLZ modules however, make a call to the backend 
database per query. Which would introduce latency (in my tests, 50ms when using 
an Atlas cluster in the same geographical region). However, why would this be 
specific to no-sql databases?! Doesn't this also apply to any sql based DB?Now, 
an advantage of DLZ, is any change you make to the backend DB takes place 
immediately without the need to reload the server. Not a huge advantage in my 
personal opinion, but I do see the use case for it.Looking for a way to load 
queried records from a backend database into memory to speed up the responses, 
I found posts about the DynDB API. If Evan can kindly point me in the right 
direction there, I will be developing both DLZ and DynDB modules for MongoDB, 
as I do see use cases for each one.The caching question that I asked, was more 
around having a workaround without DynDB, because I was under the impression 
that DynDB API is not available at the moment. My understanding of a BIND 
caching server (and admittedly , I am by no means an advanced user when it 
comes to BIND), is that it would query records from another server, and cache 
them for the life (TTL) of that record, and serve it. This cache, exists in 
memory, correct?So in theory, if I was to use a DLZ to keep my records in a 
backend DB, I can technically create a BIND server with the DLZ enabled (let's 
say a docker image), and then put a caching server in front of it, which is 
"customer facing".That way, all queries will come to the caching server, and 
will be served super fast because they are cached in memory, but the actual 
records live in a backend DB somewhere.Long story short, I was trying to see if 
the same can be achieved with one single instance instead of two, which sounds 
like it can not be done.RegardsHamid MaadaniAugust 24, 2022 12:40 AM, "Ondřej 
Surý"  wrote:   On 24. 8. 2022, at 8:48, Evan Hunt 
 wrote: In the absence of that, is caching from DLZ a possible 
configurationon a single BIND server?Not DLZ, no. And I'm not sure dyndb can be 
used for the cache database,either; do you know something about it that I 
don't?It would definitely be easier to *make* dyndb work for the cache;it has 
all the necessary API calls, and DLZ doesn't. But I don'tknow a way to 
configure it to take the place of the cache currently.If you do, please educate 
me. I am fairly confident that any advantage from shared cache will be lost 
because the extra latency caused by communication with the MongoDB (or any 
other no-sql systems).Perhaps, describing the use case first (why do you want 
to use MongoDB at all) might have the benefit of not wasting time on your 
end.Ondrej--Ondřej Surý (He/Him)ondrej@isc.orgMy working hours and your working 
hours may be different. Please do not feel obligated to reply outside your 
normal working hours.
--

Re: Thread handling

2022-08-24 Thread Hamid Maadani 
> BIND does have dyndb support, since 9.11.
> As far as I know, though, the only two dyndb modules in existence are
> the bind-dyndb-ldap modiule that was written by Red Hat as part of
> FreeIPA, and a toy module used for testing. If you were interested in
> writing your MongoDB module for dyndb instead of DLZ, I'd be quite
> excited about that, I've long hoped the API would get more use.

Interesting. I looked in the contrib directory and only found the DLZ modules 
there. Can you please point me in the direction of the source code for that toy 
module?
I would definitely work on a mongo-dyndb implementation as well, when the time 
permits.
> I am fairly confident that any advantage from shared cache will be lost 
> because the extra latency caused by communication with the MongoDB (or any 
> other no-sql systems).
> Perhaps, describing the use case first (why do you want to use MongoDB at 
> all) might have the benefit of not wasting time on your end.
This is a bit confusing to me. As I understand it, a normal bind zone is loaded 
into memory, and requests are served from that memory-cache, hence super fast.
DLZ modules however, make a call to the backend database per query. Which would 
introduce latency (in my tests, 50ms when using an Atlas cluster in the same 
geographical region). However, why would this be specific to no-sql databases?! 
Doesn't this also apply to any sql based DB?

Now, an advantage of DLZ, is any change you make to the backend DB takes place 
immediately without the need to reload the server. Not a huge advantage in my 
personal opinion, but I do see the use case for it.
Looking for a way to load queried records from a backend database into memory 
to speed up the responses, I found posts about the DynDB API. If Evan can 
kindly point me in the right direction there, I will be developing both DLZ and 
DynDB modules for MongoDB, as I do see use cases for each one.

The caching question that I asked, was more around having a workaround without 
DynDB, because I was under the impression that DynDB API is not available at 
the moment. My understanding of a BIND caching server (and admittedly , I am by 
no means an advanced user when it comes to BIND), is that it would query 
records from another server, and cache them for the life (TTL) of that record, 
and serve it. This cache, exists in memory, correct?
So in theory, if I was to use a DLZ to keep my records in a backend DB, I can 
technically create a BIND server with the DLZ enabled (let's say a docker 
image), and then put a caching server in front of it, which is "customer 
facing".
That way, all queries will come to the caching server, and will be served super 
fast because they are cached in memory, but the actual records live in a 
backend DB somewhere.
Long story short, I was trying to see if the same can be achieved with one 
single instance instead of two, which sounds like it can not be done.

Regards
Hamid Maadani

August 24, 2022 12:40 AM, "Ondřej Surý" mailto:ond...@isc.org?to=%22Ond%C5%99ej%20Sur%C3%BD%22%20)> 
wrote:
On 24. 8. 2022, at 8:48, Evan Hunt mailto:e...@isc.org)> wrote: 

In the absence of that, is caching from DLZ a possible configuration
on a single BIND server?
Not DLZ, no. And I'm not sure dyndb can be used for the cache database,
either; do you know something about it that I don't?

It would definitely be easier to *make* dyndb work for the cache;
it has all the necessary API calls, and DLZ doesn't. But I don't
know a way to configure it to take the place of the cache currently.
If you do, please educate me. 
I am fairly confident that any advantage from shared cache will be lost because 
the extra latency caused by communication with the MongoDB (or any other no-sql 
systems).

Perhaps, describing the use case first (why do you want to use MongoDB at all) 
might have the benefit of not wasting time on your end.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org (mailto:ond...@isc.org)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.
-- 
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: Thread handling

2022-08-24 Thread Ondřej Surý 

> On 24. 8. 2022, at 8:48, Evan Hunt  wrote:
> 
>> In the absence of that, is caching from DLZ a possible configuration
>> on a single BIND server?
> 
> Not DLZ, no. And I'm not sure dyndb can be used for the cache database,
> either; do you know something about it that I don't?
> 
> It would definitely be easier to *make* dyndb work for the cache;
> it has all the necessary API calls, and DLZ doesn't. But I don't
> know a way to configure it to take the place of the cache currently.
> If you do, please educate me.

I am fairly confident that any advantage from shared cache will be lost because 
the extra latency caused by communication with the MongoDB (or any other no-sql 
systems).

Perhaps, describing the use case first (why do you want to use MongoDB at all) 
might have the benefit of not wasting time on your end.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

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

-- 
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: Thread handling

2022-08-24 Thread Evan Hunt 


> Regarding the child process(es), does named create one child process,
> or can it be multiple processes? I assume each process loads the
> shared objects for itself, so only one call to dns_dlzcreate per
> process?

I'm pretty sure it's called only once on startup, after daemonizing,
and again whenever you reconfigure the server.  (I haven't checked,
but I think that's the case.)

> Question about the cache mentioned here. Can cache be configured to
> pull from a DLZ?

No.

> As far as I know, the DynDB API is not merged to BIND's codebase yet.

BIND does have dyndb support, since 9.11.

As far as I know, though, the only two dyndb modules in existence are
the bind-dyndb-ldap modiule that was written by Red Hat as part of
FreeIPA, and a toy module used for testing.  If you were interested in
writing your MongoDB module for dyndb instead of DLZ, I'd be quite
excited about that, I've long hoped the API would get more use.

> In the absence of that, is caching from DLZ a possible configuration
> on a single BIND server?

Not DLZ, no. And I'm not sure dyndb can be used for the cache database,
either; do you know something about it that I don't?

It would definitely be easier to *make* dyndb work for the cache;
it has all the necessary API calls, and DLZ doesn't. But I don't
know a way to configure it to take the place of the cache currently.
If you do, please educate me.

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