Re: CIDR notation for RPZ rpz-ip ?

2024-05-17 Thread Nick Tait via bind-users

On 18/05/2024 09:11, J Doe wrote:

Hello,

When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used
or must they be either: /8, /16, /24, /32 for IPv4 ?

For example, if I want to block records with an A address of
192.168.10.1, I know I can write:

    32.1.10.168.192.rpz-ip    IN    CNAME .

... and records like A, MX, etc. that have an A value of: 192.168.10.1
will receive a NXDOMAIN response.

But am I able to block any CIDR ?  For instance, if I wanted to block
records like A, MX, etc. that have A values in: 192.168.10.1/22 can I
use the following:

    22.1.10.168.192.rpz-ip    IN    CNAME .


Thanks,

- J


Hi J.

Yes you can specify a CIDR network length that isn't on an 8-bit boundary.

In your example the /22 network address for 192.168.10.1 is actually 
192.168.8.0, so you'd specify:


22.0.8.168.192.rpz-ip IN CNAME .

Nick.


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


CIDR notation for RPZ rpz-ip ?

2024-05-17 Thread J Doe

Hello,

When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used
or must they be either: /8, /16, /24, /32 for IPv4 ?

For example, if I want to block records with an A address of
192.168.10.1, I know I can write:

32.1.10.168.192.rpz-ipINCNAME .

... and records like A, MX, etc. that have an A value of: 192.168.10.1
will receive a NXDOMAIN response.

But am I able to block any CIDR ?  For instance, if I wanted to block
records like A, MX, etc. that have A values in: 192.168.10.1/22 can I
use the following:

22.1.10.168.192.rpz-ipINCNAME .


Thanks,

- 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: queries for "_.domain"

2024-05-17 Thread Mark Andrews
Correct. Later versions use NS queries as that allows named to cache the 
non-existence of the NS RRset.  Using _.domain doesn’t allow that to happen.

NS queries do however expose broken delegations.  Make sure you have working NS 
records at the zone apex and at the delegation point. This is especially 
important when the server serves multiple levels in the zone hierarchy as 
intermediate delegations are often not seen without QNAME minimisation but are 
with QNAME minimisation. 

We have had bug reports due to all delegating NS records referring to 
non-existing servers.

We have had bug reports due to garbage records at the zone apex.

Mark

-- 
Mark Andrews

> On 17 May 2024, at 23:31, Stephane Bortzmeyer  wrote:
> 
> On Fri, May 17, 2024 at 03:25:01PM +0200,
> Matus UHLAR - fantomas  wrote 
> a message of 43 lines which said:
> 
>> I have noticed that BIND sends strange (for me) queries.
>> 
>>5   0.198221 192.168.0.1 → 193.108.88.128 DNS 105 Standard query 0x15a4 A 
>> _.net.akadns.net OPT
> 
> QNAME minimisation (RFC 9156), probably?
> -- 
> 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: queries for "_.domain"

2024-05-17 Thread Stephane Bortzmeyer
On Fri, May 17, 2024 at 03:25:01PM +0200,
 Matus UHLAR - fantomas  wrote 
 a message of 43 lines which said:

> I have noticed that BIND sends strange (for me) queries.
> 
> 5   0.198221 192.168.0.1 → 193.108.88.128 DNS 105 Standard query 0x15a4 A 
> _.net.akadns.net OPT

QNAME minimisation (RFC 9156), probably?
-- 
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


queries for "_.domain"

2024-05-17 Thread Matus UHLAR - fantomas

Hello,

I have noticed that BIND sends strange (for me) queries.

5   0.198221 192.168.0.1 → 193.108.88.128 DNS 105 Standard query 0x15a4 A 
_.net.akadns.net OPT
8   0.204738 193.108.88.128 → 192.168.0.1 DNS 159 Standard query response 
0x15a4 No such name A _.net.akadns.net SOA internal.akadns.net OPT
9   0.205400 192.168.0.1 → 193.108.88.128 DNS 112 Standard query 0x3413 A 
_.office.net.akadns.net OPT
   10   0.211944 193.108.88.128 → 192.168.0.1 DNS 166 Standard query response 
0x3413 No such name A _.office.net.akadns.net SOA internal.akadns.net OPT
   11   0.212646 192.168.0.1 → 193.108.88.128 DNS 128 Standard query 0x70df A 
_.omexexternallfb.office.net.akadns.net OPT
   12   0.218782 193.108.88.128 → 192.168.0.1 DNS 182 Standard query response 
0x70df No such name A _.omexexternallfb.office.net.akadns.net SOA 
internal.akadns.net OPT

Is this a known feature I have missed?

--
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.
--
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] testing KASP

2024-05-17 Thread Matthijs Mekking

Hi,

On 5/16/24 14:02, adrien sipasseuth wrote:

Hello,

I try to set up a testing environment in order to create some scripts 
for automated the roll over KSK.


# question 1 #
this is my policy :

dnssec-policy "test" {
     keys {
     ksk lifetime P3D algorithm ecdsa256 2048;
     zsk lifetime P1D algorithm ecdsa256 2048;
     };

     // Key timings
     purge-keys P4D;

     // Signature timings
     signatures-refresh  PT50M;
     signatures-validity PT1H;
     signatures-validity-dnskey PT1H;

     // Zone parameters
     max-zone-ttl PT1H;
     parent-ds-ttl PT1H;

};

I would like automaticly update new DS to my registar, to do it this my 
logic :


For each file en .state
     If is KSK with "DSState: rumoured" or "DSState: hidden"
         If not in my registar (dig ds  +dnssec +multiline)
             Publish on my Registar(api register)
             Notify Bind(bind rndc dnssec -checkds -key  published 
)


Only if KSK has DSState: rumoured. If the DSState is hidden it means 
that it is not expected to be in the parent (for example because the 
DNSKEY has not yet been fully propagated).




Do y need to withdraw the old key too immediatly ? anything else to do ?


Do you mean withdraw the old DS?

I would use similar logic but then use "unretentive" instead of 
"rumoured". Following the example above:


For each file en .state
  If is KSK with "DSState: unretentive"
  If in my registar (dig ds  +dnssec +multiline)
  Withdraw on my Registar(api register)
  Notify Bind(bind rndc dnssec -checkds -key  withdrawn



# question 2 #
If i want to unsigned a zone, i change my policy to "insecure" which is 
default but file like .signed still exist, Bind doesn't remove it ?


Correct. If all DNSSEC records have been removed, it is safe to remove 
the "dnssec-policy" configuration from your named.conf and then remove 
the .signed file.


Unsigning your zone also takes time.



# question 3 #

In state file, when the remove date issue, can i just remove the key, 
anything else to do ?


When all states are "hidden" it is safe to remove the key.

Best regards,

Matthijs



Regards,
Adrien SIPASSEUTH




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