Re: CIDR notation for RPZ rpz-ip ?
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 ?
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"
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"
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"
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
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