Re: MDLZ user activation

[Nick Tait via bind-users]

Hi list.

I received the email below, which on the face of it looks pretty bogus 
(especially since this supposed 'list' email is personalised with my 
name). But the message headers show that this email was relayed to my MX 
server from the same MTA that relays legitimate emails from the 
bind-users list:


Received: from lists.isc.org (lists.isc.org [149.20.2.23])
    by mx.tait.net.nz (Postfix) with ESMTPS id E42DBA08D5
    for; Fri,  7 Jun 2024 04:20:02 +1200 (NZST)

So either the email below is valid, but if so I have no idea what it is 
for (and hence haven't clicked the link), or the email below is bogus 
and they have exploited the list MTA to distribute spam?


Can anyone shed any light on this? Happy to share all the mail headers 
if that helps?


Thanks,

Nick.


On 07/06/2024 04:19, gustavojavi...@gmail.com wrote:


Hi Nick Tait via bind-users,

A new MDLZ account has been created for you.

Click the url below to activate your account and select a password!



If the above URL does not work try copying and pasting it into your 
browser. If you continue to have problems, please feel free to contact us.


Regards,
MDLZ


-- 
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: Problem with a certain domain

[Nick Tait via bind-users]

On 4/06/2024 12:44 am, Thomas Barth via bind-users wrote:
unfortunately, today I had to restart bind9 for the third time in an 
attempt to send a newsletter to get rid the communication error, 
although with a query response of 1800 msecs. Is it possible to 
configure bind9 so that a public DNS service (e.g. 9.9.9.9) is used 
for the particular domain and bind9 for everything else? Because dig 
@9.9.9.9 s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es always 
works with a good response. 


Hi Thomas.

Yes a zone with type=forward will allow you to forward requests for a 
single zone to a specific recursive resolver. See: 
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-type%20forward


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

Re: CIDR notation for RPZ rpz-ip ?

[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

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

[Nick Tait via bind-users]

On 17/04/2024 11:41, John Thurston wrote:


I'm seeing strange behavior with a BIND 9.18.24 resolver and 
dnssec-failed.org.


With no dnssec-validation line (or with "dnssec-validation auto") in 
the .conf, querying for www.dnssec-failed.org returns SERVFAIL, as 
expected . . until it doesn't. After several seconds of answering 
SERVFAIL, I start getting NOERROR responses, and IP addresses in the 
ANSWER. It isn't a predictable number of seconds; sometimes 9, 
sometimes 20.


Is this supposed to be happening?

When I examine the process with delv and my eyeballs, I can't see why 
it is succeeding with dig and my validating resolver.


Maybe I'm not looking for the right things with my eyeballs? I'm 
stumped, and looking for advice for nest-steps in understanding what's 
going on.



The following one-liner:

# rndc flush && while true; do dig -4 www.dnssec-failed.org. A 
@localhost; sleep 1; done



Hi John.

FYI I tried running your command myself and didn't see the same problem.

The first thing you'd want to rule out is the possibility that you have 
more than one resolver running? E.g.


sudo netstat -anp | awk '{ if ($4 ~ /:53$/) print; }' | sort -u

The last column in the output from the command above should show a 
number followed by a slash then a process name, which should be the same 
on every line (e.g. "1804/named"). If it isn't, then see if you can stop 
the other service(s) and then rerun your test?


If you have just a single process listening on port 53, then I'd suggest 
using "tail -f" to watch your BIND logs (or syslog?) while you are 
running your test, to see what is going on from the recursive resolver's 
point of view? Hopefully you'll see something interesting when the 
problem happens?


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

Re: opendnssec -> inline-signing

[Nick Tait via bind-users]

On 08/03/2024 12:54, Randy Bush wrote:

but WHY NOT?  same key sets with opendnssec and inline-signing, we
think.


The most obvious possibility is that this is referring to a different 
directory to where you put the keys that you wanted to use:


|key-directory "/usr/home/dns/dkeys"|

I couldn't help noticing that when you ran dnssec-dsfromkey you 
referenced this directory: /usr/home/dns/Fixed


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

Re: fixed rrset ordering - is this still a thing?

[Nick Tait via bind-users]

On 02/03/2024 11:36, Greg Choules wrote:
Please don't encourage using "search" in resolv.conf or the Windows 
equivalent. Search domains make queries take longer, impose 
unnecessary load on resolvers and make diagnosis of issues harder 
because, when users say "it doesn't work" you have no idea what it was 
that didn't work.


This is not necessarily the case. If you are running your own recursive 
resolvers that hold mirrors of the root zone, and if you only have a few 
search domains, the impact will be negligible. Then it is a question of 
ergonomics.


I tried using separate subdomains for different interfaces on devices 
once and ran into exactly that problem. There's also the overhead of 
maintaining more zones than you really need.


Using sub-domains doesn't mean you have to create separate zones. All 
the example names I gave could be included in the "example.com" zone.


--
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: fixed rrset ordering - is this still a thing?

[Nick Tait via bind-users]

On 02/03/2024 03:42, Mike Mitchell via bind-users wrote:

Our networking team is in the habit of entering the IP address of every
network interface on a router under one name.  The very first address
entry is their out-of-band management interface.  "rrset-order fixed" is
  used on their domain for address records, so they can ssh to the router
  by name reliably and not have to worry about interfaces that are down
or that filter SSH.
I wonder if an alternative (cleaner?) solution to your use case could be 
to use different sub-domains for the different networks (network 
interfaces)? For example:


   firewall1.example.com = Internet IP address
   firewall1./dmz/.example.com = IP address on DMZ network
   firewall1./management/.example.com = IP address on out-of-band
   management network

If you did this you could make use of DNS search domains to allow 
different parts of the network to resolve the unqualified name 
"firewall1" differently. E.g. If you "ssh firewall1" from a management 
host it could expand that to firewall1./management/.example.com?


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

Re: Problem upgrading to 9.18 - important feature being removed

[Nick Tait via bind-users]

On 27/02/2024 13:22, Michael Sinatra wrote:

On 2/26/24 13:41, Al Whaley wrote:
Originally (under the above command) RR records for DNSSEC were 
maintained by bind, but the ZSK and KSK keys were maintained by me.  
This command is being discarded.  I understand that bind "sort of" 
supports this feature in 9.18 by allowing the DNSSEC policy statement 
to declare unlimited lifetime, but after careful reading of the 
documentation and reading a number of complaints, it turns out that 
bind may under various circumstances decide that it is appropriate 
not to use existing keys and decide that it knows best, and then it 
makes new ones.  This potential instability of course would be 
disastrous, and completely unnecessary.


I have never experienced this, in either BIND 9.16 or BIND 9.18 
(including the latter with KASP set to not rotate any keys).  Can you 
elaborate as to where in the documentation and/or what complaints you 
have seen where correctly configured KASPs in 9.18.24+ decide to roll 
keys?  I'd certainly like to know if that's the case, for reasons 
described below. 


The only example that I can recall (from this list) where this type of 
thing happened was where someone specified a different algorithm when 
transitioning to dnssec-policy. The advice for this type of situation is 
to transition to dnssec-policy with the same algorithm first, and make 
sure everything in your state files is "omnipresent", and only then 
update the dnssec-policy to use a different algorithm.


My (somewhat uneducated) advice would also be to avoid 
implementing dnssec-policy if you were in the middle of a key roll-over. 
Not because I think it would necessarily create a problem, but more to 
reduce risk and make it easier to verify that nothing untoward has happened.


In other words, if you aren't in the middle of a roll-over, and your 
current keys don't have any expiration set, then you can reconfigure 
your zone to use a dnssec-policy that specifies the same algorithm as 
what you previously had, and BIND should be happy to carry on using the 
existing keys -- indefinitely if you've specified an unlimited lifetime. 
The only difference you should notice is that after 
implementing dnssec-policy there are additional *.state files in your 
keys directory.


The only other thing I'd add is that if (after transitioning 
to dnssec-policy) you do initiate a manual roll-over, keep an eye on 
your state files to verify that the new key becomes "omnipresent". This 
can take much longer than you might expect! For ZSK roll-overs don't be 
surprised if it takes 9-10 days. Also FYI for KSK (and CSK) roll-overs, 
you may need to run rndc commands to tell BIND when DS records are 
added/removed -- but that is possibly what you already do with auto-dnssec?


Of course in life there are no absolute guarantees, so you should back 
up your configuration and make a plan to mitigate the impacts in the 
event that everything turns pear-shaped?


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

NOTIFY and TSIG

[Nick Tait via bind-users]

Hi list.

I've been trying to understand whether it is necessary for the NOTIFY 
request (i.e. sent from primary to secondary server) to use TSIG, in the 
case where the secondary server specifies a key in its zone's 
"primaries" option?


For example, assume the following set-up:

The primary server (192.0.2.1) specifies the following configuration:

   key "secret-key.example.com" { ... };
   zone "example.com" {
type primary;
file "/etc/bind/db.example.com";
notify yes;
allow-transfer { key "secret-key.example.com"; };
   };

And the secondary server (192.0.2.2) specifies:

   key "secret-key.example.com" { ... };
   zone "example.com" {
type secondary;
file "db.example.com";
*primaries { 192.0.2.1 key "secret-key.example.com"; };*
notify no;
   };

And if the zone file db.example.com (on the primary server) contained:

   $TTL 3600
   @ IN SOA server1 root.server1 1 86400 7200 2419200 1800
   @ IN NS server1
   @ IN NS server2
   server1  IN A 192.0.2.1
   server2  IN A 192.0.2.2

In this case when the zone is changed on the primary server, it will 
send an /unsigned/ NOTIFY to the secondary server. The question I was 
trying to answer was: /With the configuration above, will the secondary 
server accept the unsigned notification?/


I was hoping to find an RFC that answered this question, but didn't have 
any luck Googling. However the BIND documentation for "allow-notify" 
(https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify) 
contains the following text:


   *allow-notify*
   ...
   Defines an address_match_list that is allowed to send NOTIFY
   messages for the zone, in addition to addresses defined in the
   primaries option for the zone.
   ...
   If not specified, the default is to process NOTIFY messages only
   from the configured primaries for the zone. allow-notify can be used
   to expand the list of permitted hosts, not to reduce it.

My interpretation of the above was that if a key is specified in the 
"primaries" option, then the secondary would require the NOTIFY to be 
signed by the same key? However when I tested this theory, I found the 
secondary did accept (and process) the unsigned NOTIFY.


While I understand (and agree) that this behaviour makes the most sense, 
given my confusion based on the documentation, I wonder if the 
documentation could be made clearer? E.g. Add the sentence: "In the case 
where the primaries option specifies a TSIG key, it is not necessary for 
the received NOTIFY to be signed by the same key."


Thanks,

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

Re: migration from auto-dnssec to dnssec-policy deletes keys immediately

[Nick Tait via bind-users]

> On 28 Dec 2023, at 1:05 PM, Adrian Zaugg  
> wrote:
> 
> 2023-12-27 23:51:24: zone myzone.ch/IN (signed): reconfiguring zone keys
> 2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/14076 
> (KSK)
> 2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/3654 
> (ZSK)
> 2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/2336 (KSK) created for 
> policy mypolicy
> 2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/35413 (ZSK) created for 
> policy mypolicy

Your DNSSEC policy “mypolicy” specifies a different algorithm (ED25519) to what 
was previously in effect (ECDSAP256SHA256), which is why Bind generated new 
keys. If you want Bind to keep the old keys when transitioning to dnssec-policy 
you should initially specify the same algorithm in your policy.

My understanding is that after you’ve transitioned to using dnssec-policy you 
should be able to change the algorithm and Bind should do a graceful roll-over? 
Just make sure everything is “omnipresent” in your state files (in the keys 
directory) first.

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

Re: Zone file got updated via named process unexpected

[Nick Tait via bind-users]

On 17/12/2023 5:30 pm, liudong...@ynu.edu.cn wrote:
I found this zone file got updated in about 15 minutes when I made 
changes or restarted named, and this behavior seems match the docs 
bind9.readthedocs.io/en/latest/chapter6.html#dynamic-update, but I can 
confirm I DO NOT configure allow-update or update-policy. I even add 
"allow-update {none;}; // no DDNS by default" in the zone block of the 
problematic view. Is there any chances this configuration comes from 
other config file or named build options?


Are you using DNSSEC with this zone? Your config extract doesn't show 
it, but what you described sounds like BIND might be resigning the zone 
file and writing the new signed zone over top of the original file? If 
so, the solution is to use inline-signing: 
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-inline-signing


Note that there have been many improvements in BIND's support for DNSSEC 
over the last few years, so if this is a server that you've inherited, 
it is probably worth reviewing the DNSSEC configuration options to see 
if it can be improved?


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

Re: dnssec-delegation seems to be broken from .gov to bls.gov

[Nick Tait via bind-users]

On 7/12/2023 9:05 am, Nick Tait via bind-users wrote:
I could be wrong, but based on the output above it looks like the 
current TTL is 0, which means that doing this should provide immediate 
relief.


Sorry it looks like the DNS server on the Wi-Fi network I'm connected to 
has done something weird with the TTL.


This is what I get when querying one of the "gov." authoritative servers 
directly:


   $ dig -t ds bls.gov @a.ns.gov +norecurse

   ; <<>> DiG 9.18.18-0ubuntu2-Ubuntu <<>> -t ds bls.gov @a.ns.gov +norecurse
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32241
   ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags:; udp: 1232
   ;; QUESTION SECTION:
   ;bls.gov.   IN  DS

   ;; ANSWER SECTION:
   bls.gov.3600IN  DS  50951 8 2 
E6B0A294066904F20A2B8EBA3FA9920F9A1822802977F59D706B30A1 77F7DC0C

   ;; Query time: 16 msec
   ;; SERVER: 2001:503:ff40::1#53(a.ns.gov) (UDP)
   ;; WHEN: Thu Dec 07 09:19:24 NZDT 2023
   ;; MSG SIZE  rcvd: 84

This means when you remove the DS record, it will take 1 hour to fully 
take effect (assuming no delay replicating between authoritative servers).


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

Re: dnssec-delegation seems to be broken from .gov to bls.gov

[Nick Tait via bind-users]

On 7/12/2023 1:53 am, Bhangui, Sandeep - BLS CTR via bind-users wrote:


Hi

It seems the DNSSEC delegation is broken from “.gov” to bls.gov domain 
and due to which the records for bls.gov are considered as bogus and 
we are having issues at our site.


It looks like we were in the process of KSK rollover and that may have 
caused the issue as things were fine till yesterday.


As we troubleshoot this issue was wondering whether from our master 
DNS server can we use some option in named.conf so that dnssec 
verification is NOT done for any bls.gov DNS lookups from outside to 
get a quick fix to this problem.


Currently DNS lookups from outside are flaky and I believe the reason 
behind that being that the DNSSEC delegation is broken.


From the output at dnsviz.net analyzing for bls.gov it seems that KSK 
rollover for bls.gov is the issue.


Basically, trying to see if I can get a quick interim fix till we 
resolve the issue correctly.


Please advise.

Thanks

Sandeep


Hi Sandeep.

Probably the simplest workaround for broken chain of trust would be to 
remove your zone's DS records from the parent zone.


   $ dig -t ds bls.gov

   ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> -t ds bls.gov
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27975
   ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
   ;; WARNING: recursion requested but not available

   ;; QUESTION SECTION:
   ;bls.gov.   IN  DS

   ;; ANSWER SECTION:
   bls.gov.    0   IN  DS  50951 8 2 
E6B0A294066904F20A2B8EBA3FA9920F9A1822802977F59D706B30A1 77F7DC0C

   ;; Query time: 0 msec
   ;; SERVER: 172.20.192.1#53(172.20.192.1) (UDP)
   ;; WHEN: Thu Dec 07 09:01:33 NZDT 2023
   ;; MSG SIZE  rcvd: 80

I could be wrong, but based on the output above it looks like the 
current TTL is 0, which means that doing this should provide immediate 
relief.


Add a new DS record once you've fixed your KSK issues.

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

mirror zone and hint zone?

[Nick Tait via bind-users]

Hi list.

I've just implemented a mirror zone for ".", and I noticed that it works 
even though I haven't removed the hint zone (also for ".").


What is the recommendation here? Is it OK to have both mirror and hint 
zones? Or should I remove the hint zone from my configuration, to avoid 
potential issues in future versions of BIND?


Thanks,

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

Re: Stub zones, but secndary?

[Nick Tait via bind-users]

On 20/11/2023 1:00 pm, Peter wrote:

It's tricky. One problem is these are slave zones, they are
authoritative and do not work well with DNSSEC.


I'm curious... What issues did you have with these zones and DNSSEC? I 
would have expected that the signed zones should just work?


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

Re: KASP Key Rollover: ZSK Disappears Immediately

[Nick Tait via bind-users]

On 03/10/2023 09:59, Eddie Rowe wrote:

I appreciate the feedback.  I did make sure the ZSK is omnipresent and the
issue still happens so it might be that my attempt to take the default 
policy
and bring it down to 1 day to hurry along testing.  I will see if I 
can find
any test policies in the list archives and failing that use the 
default one

with a greater amount of patience.

Hi Eddie.

Not sure if you're still interested in this topic, but a couple of weeks 
ago I did a manual ZSK roll-over, to see if I observed results similar 
to what you described in your original email...


Before starting the rollover /everything/ was showing omnipresent.

After initiating the rollover things mostly happened in the expected 
timeframes, but there was one thing that surprised me: The old ZSK 
removal date was set 9-and-a-bit days(!) after the roll-over was 
initiated, and the old ZSK and new ZSK state files showed "ZRRSIGState: 
unretentive" and "ZRRSIGState: rumoured" (respectively) right up until 
the old ZSK removal date, before eventually transitioning to the 
expected end states of "ZRRSIGState: hidden" and "ZRRSIGState: 
omnipresent" (respectively). This was in spite of the fact that all 
RRSIG records were replaced with the new ZSK more than a week prior. I 
can only assume that the 9 days somehow relates to how long BIND wanted 
to allow itself to generate RRSIGs for all the records in a really, 
really large zone file?


Anyway, I remembered seeing "ZRRSIGState: rumoured" in your ZSK state 
file before you initiated your ZSK roll-over, and so I suspect that all 
your issues stem from the fact that not everything was omnipresent 
before you initiated the roll-over?


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

Re: Question about URL being logged by resolver

[Nick Tait via bind-users]

Hi J.

I'm not sure what the cause of the URLs is, but I can confirm I'm seeing 
the same URLs in my own logs. The queries originate from multiple 
devices on my internal network - all Apple devices I think.


My advice: I wouldn't waste too much effort trying to solve this one, as 
it is almost certainly something that you will have no control over. 
E.g. It could be something bogus on a web page that these devices have 
all accessed?


Nick.


On 4/11/23 11:30, J Doe wrote:

Hello,

On a Bind 9.18.19 server configured as a recursive resolver, I 
sometimes see URL's being noted in the log files.


One such example is:

02-Nov-2023 23:32:19.435 lame-servers: info: success resolving 
'https://app-measurement.com/sdk-exp/A' after disabling qname 
minimization due to 'ncache nxdomain'


This seems unusual to me because Bind usually notes the domain name it 
is attempting to resolve, not an URL.  In this particular case, I 
would expect to see a notation about "app-measurement.com" and not 
"http://etc;.


What is the significance of logging the URL and why does this happen 
in only some cases ?


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: How should I configure internal and external DNS servers

[Nick Tait via bind-users]

Hi Nick.

Your current set-up sounds like a fairly common configuration. And 
depending on your requirements there are a number of options that you 
might consider.


But let's start with requirements: I've made some assumptions - please 
advise if I've got any of this wrong?:


 * You have two distinct sets of authoritative servers, which don't
   overlap in any way currently. E.g. Servers A (primary/master), B & C
   (secondaries/slaves) are authoritative for internal zone
   ("Bind-internal"); Servers C (primary), D & E (secondaries) are
   authoritative for external zone ("Bind-external").
 * The records in Bind-external are a subset of those in Bind-internal.
   In other words, for every resource record (not including SOA & NS
   records) in Bind-external, there is an identical record in
   Bind-internal.
 * Do you have another set of servers that act as recursive resolvers
   in your network currently, or do A, B and/or C fulfil that role
   currently? (I'm going to assume that A, B & C are used as recursive
   resolvers on your internal network for now. It probably doesn't make
   a huge difference either way but it is just an extra factor that
   needs to be taken into account.)
 * You are not using DNSSEC to sign your zones.
 * Your zone structure is more-or-less flat currently. i.e. You don't
   have any delegations to sub-zones.
 * Your primary reason for having separate authoritative servers is for
   privacy, rather than simply being a workaround for IPv4 Network
   Address Translation.

There are a few options worth considering, and I should point out that 
some of these won't fit your requirements, in which case you can 
immediately rule them out. But I believe it is important that the 
decision to rule them out is a conscious one, so you are fully aware of 
the scope/limitations of the solution you end up choosing.


*Option A: Keep using separate sets of authoritative servers*

What you have currently is not a bad configuration. Sure, there is 
additional overhead of having to maintain two separate versions of the 
zone, but it is easy to understand and troubleshoot. If your zones are 
small and are updated infrequently, then this is probably the best 
solution. However the fact you are looking for a better solution 
suggests this isn't the case...


*Option B: Merge the authoritative zones and use IPv6 exclusively for 
internal hosts

*

I only included this because the idea had been put forward already. But 
even if the logistics of assigning public IPv6 addresses to your 
internal hosts was palatable to you, you'd also want to think about 
whether you are comfortable making that information (i.e. the IPv6 
addresses used for internal servers) publicly available? I think most 
organisations wouldn't want to do that?


*Option C: Merge servers but use views to serve separate (existing) zone 
files*


If your goal was consolidation of servers while keeping the existing 
internal and external zones separate, then this might be worth looking 
at. But you haven't mentioned consolidation as a requirement so I'm 
going to skip over this one. Also it doesn't solve the problem of having 
multiple zones to maintain.


*Option D: Simple delegation*

Depending on whether there is opportunity to do some zone refactoring, 
you might consider something like this...


 * In Bind-external, create a new zone: internal.example.com
 * Use permissions (e.g. allow-query) to limit access to
   internal.example.com to only internal clients
 * For each zone record in Bind-internal that doesn't exist in
   Bind-external, create a CNAME record in Bind-external that points to
   the same name in internal.example.com zone.
 * You can then get rid of Bind-internal zone. (The servers could still
   be used as recursive resolvers though.)

Then, if x.example.com was a name that was previously defined only in 
Bind-internal:


 * Internally if you attempt to resolve x.example.com, the result will
   be a CNAME that points to x.internal.example.com, which resolves to
   the 10.x.x.x IP address.
 * Externally if you attempt to resolve x.example.com, the result will
   be a CNAME that points to x.internal.example.com, which will result
   in some sort of access denied error.

One possible concern with this idea is that even though an external 
client can't retrieve the IP address of an internal server, the CNAME + 
access denied error tells them that the name does still exist.


*Option E: Split views and delegation *

If you liked the general idea of option D, but didn't like the bit where 
externally attempting to resolve internal host names resulted in an 
access denied error, then you could look at doing something with views. 
However this pretty much has the same problem that you started with, 
where you end up maintaining two versions of the example.com zone, so 
I'm not going to bother going deeper into this one.


*Option F: Response Policy Zones*

I saved this one until last because I think this is the most 

Re: KASP Key Rollover: ZSK Disappears Immediately

[Nick Tait via bind-users]

Sorry I just realised that all that waffle about DS records is only 
relevant for KSKs (and CSKs), not ZSKs. So please disregard that. :-P



But I think the "rumoured" vs. "omnipresent" thing is still relevant and 
is the most likely explanation for why the old ZSK doesn't stick around. 
I can only assume that the reason you have rumoured state is because you 
are trying to roll your ZSK to soon after the previous ZSK rollover? 
Have you checked the various timing settings in the KASP definition?



Nick.



On 30/09/23 11:32, Nick Tait via bind-users wrote:

On 29/09/23 12:05, Eddie Rowe wrote:
When I perform a ZSK key rollover the existing ZSK disappears 
*immediately* so not sure what I am missing when using the KASP to 
manage key rollover.  The state for the keys looks good and for this 
test I have TTL set to 1 hour..  But why does dig not show me both 
DNSKEY records for the ZSK after I initiate the rollover when there 
should be overlap as described in Automatic DNSSEC Zone Signing Key 
rollover explained (isc.org) <https://kb.isc.org/docs/aa-00822>?


Bind 9.16.23 which seems to be the newest release provided by my 
distribution.  I reviewed the ARM for notes for newer releases in the 
9.16 branch and did not see mention of any rollover bugs or for dig.


 1.  Here is the key info from dig for ZSK key 15465 at 17:17.

# dig @localhost myexample.com DNSKEY +multi

; <<>> DiG 9.16.23-RH <<>> @localhost myexample.com DNSKEY +multi
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41895
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0,
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7c2a0e61926d2d3a01006515fb68eef12b631ca40c20 (good)
;; QUESTION SECTION:
;myexample.com.         IN DNSKEY

;; ANSWER SECTION:
myexample.com.  3600 IN DNSKEY 257 3 13 (
      20agIXl9sQCo00yiHHviYWZG8TvVmDoVxPJwO3mlcwxB
      le7UNrzNQaeukC6teT4XrqYflqDxcM6d9L/mtREIKA==
      ) ; KSK; alg = ECDSAP256SHA256 ; key id = 31296
myexample.com.  3600 IN DNSKEY 256 3 13 (
      AlKXH5aebvboC4laAovc6wfg6uGK1uTbTqYYnhKadSq6
      78nSI3DyM+1t91jqQ81tlBy+e3hJyKtlX/OiOhuZcA==
                                ) ; ZSK; alg = ECDSAP256SHA256 ;
key id = 15465

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 17:17:12 CDT 2023
;; MSG SIZE  rcvd: 230

 3.  Here is the info from the key as far as state goes.

# more Kmyexample.com.+013+15465.key
; This is a zone-signing key, keyid 15465, for myexample.com.
; Created: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Publish: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Activate: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Inactive: 20231127221438 (Mon Nov 27 16:14:38 2023)
; Delete: 20231207231938 (Thu Dec  7 17:19:38 2023)
myexample.com. 3600 IN DNSKEY 256 3 13
AlKXH5aebvboC4laAovc6wfg6uGK1uTbTqYYnhKadSq678nSI3DyM+1t
91jqQ81tlBy+e3hJyKtlX/OiOhuZcA==

# more Kmyexample.com.+013+15465.state
; This is the state of key 15465, for myexample.com.
Algorithm: 13
Length: 256
Lifetime: 5184000
KSK: no
ZSK: yes
Generated: 20230928221438 (Thu Sep 28 17:14:38 2023)
Published: 20230928221438 (Thu Sep 28 17:14:38 2023)
Active: 20230928221438 (Thu Sep 28 17:14:38 2023)
Retired: 20231127221438 (Mon Nov 27 16:14:38 2023)
Removed: 20231207231938 (Thu Dec  7 17:19:38 2023)
DNSKEYChange: 20230928221438 (Thu Sep 28 17:14:38 2023)
ZRRSIGChange: 20230928221438 (Thu Sep 28 17:14:38 2023)
DNSKEYState: rumoured
ZRRSIGState: rumoured
GoalState: omnipresent

I suspect that the crucial detail above is "DNSKEYState: rumoured". 
This suggests that the last ZSK rollover hasn't been fully completed.



Before starting a rollover it is a good idea to make sure the ZSK that 
you are retiring is in an "omnipresent" state.



The usual reason that the key isn't in omnipresent state is because 
BIND is still waiting for the corresponding DS record to be published 
and available in the parent zone. BIND 9.16 only knows if the DS 
record is published if you've set up parental-agents, or if you've 
explicitly told it using rndc. (BTW BIND 9.19 introduces new default 
behaviour which means you don't need to set parental-agents in order 
for it to figure this out.)



Have a look here: 
https://bind9.readthedocs.io/en/latest/chapter5.html#key-rollover



Specifically:

/If setting up a parental agent is undesirable, it is also
possible to tell BIND that the DS is published in the parent with:
/|rndc dnssec -checkds -key 12345 published dnssec.example.|

<https://bind9.readthedocs.io/en/latest/manpages.html#cmdoption-rndc-arg-dnssec>/.
and the DS for the predecessor key has been removed wi

Re: KASP Key Rollover: ZSK Disappears Immediately

[Nick Tait via bind-users]

On 29/09/23 12:05, Eddie Rowe wrote:
When I perform a ZSK key rollover the existing ZSK disappears 
*immediately* so not sure what I am missing when using the KASP to 
manage key rollover.  The state for the keys looks good and for this 
test I have TTL set to 1 hour..  But why does dig not show me both 
DNSKEY records for the ZSK after I initiate the rollover when there 
should be overlap as described in Automatic DNSSEC Zone Signing Key 
rollover explained (isc.org) ?


Bind 9.16.23 which seems to be the newest release provided by my 
distribution.  I reviewed the ARM for notes for newer releases in the 
9.16 branch and did not see mention of any rollover bugs or for dig.


 1.  Here is the key info from dig for ZSK key 15465 at 17:17.

# dig @localhost myexample.com DNSKEY +multi

; <<>> DiG 9.16.23-RH <<>> @localhost myexample.com DNSKEY +multi
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41895
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0,
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7c2a0e61926d2d3a01006515fb68eef12b631ca40c20 (good)
;; QUESTION SECTION:
;myexample.com.         IN DNSKEY

;; ANSWER SECTION:
myexample.com.          3600 IN DNSKEY 257 3 13 (
    20agIXl9sQCo00yiHHviYWZG8TvVmDoVxPJwO3mlcwxB
    le7UNrzNQaeukC6teT4XrqYflqDxcM6d9L/mtREIKA==
    ) ; KSK; alg = ECDSAP256SHA256 ; key id = 31296
myexample.com.          3600 IN DNSKEY 256 3 13 (
    AlKXH5aebvboC4laAovc6wfg6uGK1uTbTqYYnhKadSq6
    78nSI3DyM+1t91jqQ81tlBy+e3hJyKtlX/OiOhuZcA==
                                ) ; ZSK; alg = ECDSAP256SHA256 ;
key id = 15465

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 17:17:12 CDT 2023
;; MSG SIZE  rcvd: 230

 3.  Here is the info from the key as far as state goes.

# more Kmyexample.com.+013+15465.key
; This is a zone-signing key, keyid 15465, for myexample.com.
; Created: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Publish: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Activate: 20230928221438 (Thu Sep 28 17:14:38 2023)
; Inactive: 20231127221438 (Mon Nov 27 16:14:38 2023)
; Delete: 20231207231938 (Thu Dec  7 17:19:38 2023)
myexample.com. 3600 IN DNSKEY 256 3 13
AlKXH5aebvboC4laAovc6wfg6uGK1uTbTqYYnhKadSq678nSI3DyM+1t
91jqQ81tlBy+e3hJyKtlX/OiOhuZcA==

# more Kmyexample.com.+013+15465.state
; This is the state of key 15465, for myexample.com.
Algorithm: 13
Length: 256
Lifetime: 5184000
KSK: no
ZSK: yes
Generated: 20230928221438 (Thu Sep 28 17:14:38 2023)
Published: 20230928221438 (Thu Sep 28 17:14:38 2023)
Active: 20230928221438 (Thu Sep 28 17:14:38 2023)
Retired: 20231127221438 (Mon Nov 27 16:14:38 2023)
Removed: 20231207231938 (Thu Dec  7 17:19:38 2023)
DNSKEYChange: 20230928221438 (Thu Sep 28 17:14:38 2023)
ZRRSIGChange: 20230928221438 (Thu Sep 28 17:14:38 2023)
DNSKEYState: rumoured
ZRRSIGState: rumoured
GoalState: omnipresent

I suspect that the crucial detail above is "DNSKEYState: rumoured". This 
suggests that the last ZSK rollover hasn't been fully completed.



Before starting a rollover it is a good idea to make sure the ZSK that 
you are retiring is in an "omnipresent" state.



The usual reason that the key isn't in omnipresent state is because BIND 
is still waiting for the corresponding DS record to be published and 
available in the parent zone. BIND 9.16 only knows if the DS record is 
published if you've set up parental-agents, or if you've explicitly told 
it using rndc. (BTW BIND 9.19 introduces new default behaviour which 
means you don't need to set parental-agents in order for it to figure 
this out.)



Have a look here: 
https://bind9.readthedocs.io/en/latest/chapter5.html#key-rollover



Specifically:

   /If setting up a parental agent is undesirable, it is also possible
   to tell BIND that the DS is published in the parent with: /|rndc
   dnssec -checkds -key 12345 published dnssec.example.|
   
/.
   and the DS for the predecessor key has been removed with: /|rndc
   dnssec -checkds -key 54321 withdrawn dnssec.example.|
   
/.
   where 12345 and 54321 are the key tags of the successor and
   predecessor key, respectively./

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

Re: KSAP - How to manually rollover keys documentation?

[Nick Tait via bind-users]

On 28/09/23 10:02, Eddie Rowe wrote:
I am using the nifty feature of the KASP in 9.16.23, but I cannot seem 
to locate documentation on how to manually rollover keys in case this 
is needed in the future. The documentation is excellent as far as 
discussing the steps involved for the manual or semi-automatic but I 
am not seeing the steps and tools you would use to rollover manually 
when using the KASP feature.  Am I overlooking another document or KB 
article on this topic?


Hi Eddie.

I wonder if the information you're looking for is here: 
https://bind9.readthedocs.io/en/latest/chapter5.html#key-rollover


Specifically the following sentence:

   /To roll a key sooner than scheduled, or to roll a key that has an
   unlimited lifetime, use: /|rndc dnssec -rollover -key 12345
   dnssec.example.|
   
/./

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

Re: Should I set parental-agents to localhost?

[Nick Tait via bind-users]

Hi Björn.

Not sure if my (late) reply is any use to you, but yes my understanding 
is that you could use localhost as the parental agent in the cases where 
(a) the local machine also hosts the parent zone, or (b) it is a 
recursive resolver. In the latter case the DNSSEC responses would be 
validated (assuming of course that the local resolver does DNSSEC 
validation).


As I understand there are two schools of thought for configuring 
parental-agents:


1. You could explicitly specify all of the parent zone name servers. In
   that case all the servers are queried and the KSK rollover proceeds
   once all servers are publishing the new DS record.
2. You could specify a validating recursive resolver. In that case only
   one authoritative name server will be queried (you won't know which)
   and the recursive resolver validates the response, and the KSK
   rollover proceeds if that server is publishing the new DS record.

I suppose the theoretical risk with #1 is that because the responses 
from the authoritative servers aren't validated, it would be possible 
for a MITM to trick BIND into thinking that the new DS records had been 
published before they actually had, which could lead to a situation 
where you complete the KSK roll-over early and invalidate your zone?


Also please note that BIND 9.19 introduces a new option:

/*checkds*/

   *Grammar: *|checkds ( explicit |  );|

   *Blocks: *zone (primary, secondary)

   *Tags: *dnssec

   Controls whether |DS| queries are sent to parental agents.

   If set to |yes|, DS queries are sent when a KSK rollover is in
   progress. The queries are sent to the servers listed in the parent
   zone’s NS records. This is the default if there are no
   |parental-agents|
   

   configured for the zone.

   If set to |explicit|, DS queries are sent only to servers explicitly
   listed using |parental-agents|
   
.
   This is the default if there are parental agents configured.

   If set to |no|, no DS queries are sent. Users should manually run
   |rndc dnssec -checkds|
   

   with the appropriate parameters to signal that specific DS records
   are published and/or withdrawn.

Nick.


On 11/09/23 23:52, Björn Persson wrote:

Hello, I'm trying to configure automatic KSK (or CSK) rollover. I'm
confused about how to poll securely for DS records.

Section 5.1.2.1 of the BIND 9 Administrator Reference Manual says:

| [parental-agents] needs to be a trusted server, because BIND does not
| validate the response.

and section 8.2.26.1 says:

| The DS response is not validated so it is recommended to set up a
| trust relationship with the parental agent. For example, use TSIG to
| authenticate the parental agent, or point to a validating resolver.

I don't think the registry wants to exchange TSIG keys with every
domain holder. A validating resolver seems much more achievable. My
master server is also the validating resolver of its host. Can I set
parental-agents to localhost to make BIND ask itself to validate the DS
response? Or would it still do the lookup in the same non-validating
way? Or would it enter infinite recursion? Must the validating resolver
be a different name server from the master server that performs the key
rollover?

Björn Persson
-- 
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 Transfers Being Refused

[Nick Tait via bind-users]

Hi Dulux-Oz.It looks like the router between the primary and secondary DNS 
servers is performing NAT on the packets it is forwarding between those 
subnets?It would make your life much simpler if you can turn that off? I.e only 
NAT packets going out to the Internet/your ISP?Nick.
 Original message From: Ondřej Surý  Date: 
31/07/23  8:10 PM  (GMT+12:00) To: matt...@peregrineit.net Cc: 
bind-users@lists.isc.org Subject: Re: Zone Transfers Being Refused Well, for 
starters your primaries list 192.168.2.10, but your logs show connection from 
192.168.1.1…--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 31. 7. 2023, at 9:51, duluxoz  wrote:> > 
Hi Ondřej,> > Sorry, force of habit (re: "example.com").> > External Secondary 
DNS Server (ns1.mjb-co.com):> > ~~~> > acl "bogusnets" {> 
!"internal_hosts";> 0.0.0.0/8;> 10.0.0.0/8;> 172.16.0.0/12;> 
192.0.2.0/24;> 192.168.0.0/16;> 224.0.0.0/3;> };> acl "internal_hosts" 
{> 192.168.1.0/24;> 192.168.2.0/24;> 192.168.3.0/24;> };> acl 
"secondary_external_servers" {> 192.168.1.10/32;> };> acl 
"secondary_internal_servers" {> 192.168.2.11/32;> 192.168.2.12/32;> };> 
acl "ddns_servers" {> "localhost";> 192.168.2.10/32;> 
192.168.2.11/32;> };> acl "rndc_servers" {> "localhost";> 
192.168.2.10/32;> };> acl "stats_hosts" {> 192.168.2.0/24;> };> controls {> 
    inet 0.0.0.0 port 953 allow {> "rndc_servers";> } keys {>   
  "rndc-key";> };> };> logging {> channel "auth_servers_log" {> 
file "/var/log/named/auth_servers.log" versions 3 size 20971520 suffix 
timestamp;> severity info;> print-time yes;> 
print-severity yes;> print-category yes;> };> channel 
"client_security_log" {> file "/var/log/named/client_security.log" 
versions 3 size 20971520 suffix timestamp;> severity info;> 
print-time yes;> print-severity yes;> print-category yes;> 
};> channel "default_log" {> file "/var/log/named/default.log" 
versions 3 size 20971520 suffix timestamp;> severity info;> 
print-time yes;> print-severity yes;> print-category yes;> 
};> channel "default_debug_log" {> file 
"/var/log/named/default_debug.log" versions 3 size 20971520 suffix timestamp;>  
   severity dynamic;> print-time yes;> print-severity yes;> 
    print-category yes;> };> channel "ddns_log" {> file 
"/var/log/named/ddns.log" versions 3 size 20971520 suffix timestamp;> 
severity info;> print-time yes;> print-severity yes;> 
print-category yes;> };> channel "dnssec_log" {> file 
"/var/log/named/dnssec.log" versions 3 size 20971520 suffix timestamp;> 
severity info;> print-time yes;> print-severity yes;> 
print-category yes;> };> channel "dnstap_log" {> file 
"/var/log/named/dnstap.log" versions 3 size 20971520 suffix timestamp;> 
severity info;> print-time yes;> print-severity yes;> 
print-category yes;> };> channel "queries_log" {> file 
"/var/log/named/queries.log" versions 3 size 20971520 suffix timestamp;>
 severity info;> print-time yes;> print-severity yes;> 
print-category yes;> };> channel "query_errors_log" {> file 
"/var/log/named/query_errors.log" versions 3 size 20971520 suffix timestamp;>   
  severity dynamic;> print-time yes;> print-severity yes;>  
   print-category yes;> };> channel "rate_limiting_log" {> 
file "/var/named/log/rate_limiting.log" versions 3 size 20971520 suffix 
timestamp;> severity info;> print-time yes;> 
print-severity yes;> print-category yes;> };> channel "rpz_log" 
{> file "/var/named/log/rpz.log" versions 3 size 20971520 suffix 
timestamp;> severity info;> print-time yes;> 
print-severity yes;> print-category yes;> };> channel 
"zone_transfers_log" {> file "/var/log/named/zone_transfers.log" 
versions 3 size 20971520 suffix timestamp;> severity info;> 
print-time yes;> print-severity yes;> print-category yes;> 
};> category "client" {> "client_security_log";> 
"default_debug";> };> category "dnssec" {> "dnssec_log";>   
  "default_debug";> };> category "default" {> 
"default_syslog";> "default_debug";> "default_log";> };>
 category "delegation-only" {> "auth_servers_log";> 
"default_debug";> };> category "edns-disabled" {> 
"auth_servers_log";> "default_debug";> };> category 

RE: How to update zone with dnssec-policy

[Nick Tait via bind-users]

Hi Matthias.It looks like nobody solved your /original/ problem? If you are 
still looking for an answer it might help if you posted some logs? The people 
on this list are good at interpreting any errors you're seeing. :-)Nick.
 Original message From: Matthias Fechner  
Date: 2/07/23  11:29 PM  (GMT+12:00) To: bind-users@lists.isc.org Subject: How 
to update zone with dnssec-policy Dear all,I have the following problem that 
changes in a zone file do not get active, no matter if I reload the zone using 
rndc or restarting bind 9.16.42 on FreeBSD.If I update a zone I edit the zone 
file, adapt the serial in the SOA and normally do a rndc reload fechner.net.The 
nameserver is more or less setup like it is described 
here:https://wiki.idefix.fechner.net/freebsd/bind/The zonefile for domain 
fechner.net are in directory: /usr/local/etc/namedb/master/fechner.netIt is not 
a dynamic zone file or better I cannot freeze it:  rndc freeze fechner.netrndc: 
'freeze' failed: not dynamicBut if I delete the 
files:fechner.net.jbkfechner.net.signed.jnland restart bind, zone changes are 
correctly loaded and I can see an increased serial in:dig -t soa 
fechner.net.Would be nice if someone can explain me, how I need to edit a zone 
file, that has a dnssec-policy attached that modification get active, without 
the need to delete the `*.[jbk|jnl] files.Thanks a lot.GrußMatthias-- 
"Programming today is a race between software engineers striving tobuild bigger 
and better idiot-proof programs, and the universe trying toproduce bigger and 
better idiots. So far, the universe is winning." --Rich Cook-- Visit 
https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this 
listISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.bind-users 
mailing 
listbind-us...@lists.isc.orghttps://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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

[Nick Tait via bind-users]

On 2/06/23 15:02, Jesus Cea wrote:
What I get from your reply is that BIND is not expected to do anything 
about this. It is a bit disappointed but I agree that BIND is doing 
the right thing. Too bad big players don't care. But I need to "solve" 
this, so dropping BIND (nooo!) or patching software is on my table now. 


Don't know if it will work, but something to try could be to create a 
forwarding zone for each of the zones that is having this problem, and 
forward the queries to (e.g.) Google? In theory that would cause BIND to 
ask Google for the answer instead of working it out for itself?


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

Re: Problem with subdomain delegation - NS RR ignored?

[Nick Tait via bind-users]

Hi TG.

I just wanted to check:

1. Your "hub" zone contains the NS delegation for "fish.hub." to
   "ns1.fish.hub." with glue record "4.4.4.4". Is 4.4.4.4 the correct
   IP address of the server you are delegating to?
2. You haven't included the sub zone configuration (i.e. from 4.4.4.4)
   below. What do the zone stanza in the config file, and the zone file
   itself look like?
3. What answer do you get if you try: *dig @4.4.4.4 **fish.hub soa
   +norecurse*

Nick.

On 10/05/23 16:07, bindu...@thegeezer.net wrote:

Howdy

I'm struggling with subdomain creation, for some reason the delegation 
glue records are being ignored - and i was wondering if someone could 
help me identify what I've done wrong please.  I know i need to setup 
another server for the subdomain, but I've been trying to get this 
going at work and getting the same issue, so thought to try on my test 
bed.  Can't even get the NS record returned for the subdomain


Given the domain ".hub"  I can verify the domain level NS
# host -t NS hub localhost
> hub name server localhost.

I can create an A record  for "salmon.hub."  and this resolves as 
expected:

# host -t a salmon.hub localhost
> salmon.hub has address 8.8.8.8

I want to delegate to a different domain server the subdomain 
"fish.hub" and have created glue records as below in the config 
snippet, but get NXDOMAIN for both the A record and the NS record

# host -t a ns1.fish.hub localhost
> Host ns1.fish.hub not found: 3(NXDOMAIN)

# host -t NS fish.hub localhost
> Host fish.hub not found: 3(NXDOMAIN)

Any suggestions gratefully received.  Pertinent parts of named.conf 
and zone file are shown below, if you need more info please don't 
hesitate to ask


thanks in advance!

TG

/etc/bind/named.conf
acl "trusted" {
    10.0.0.0/8;
    192.168.0.0/16;
    127.0.0.0/8;
    ::1/128;
};
allow-recursion {
    trusted;
   };
forwarders {
    208.67.220.220;
    208.67.222.222;
    };
zone "hub" IN {
   type master;
   file "pri/hub.zone";
   notify no;
    };

/etc/bind/pri/hub.zone
$TTL 1W
@   IN  SOA hub. root.hub.  (
  2008122601 ; Serial
  28800  ; Refresh
  14400  ; Retry
  604800 ; Expire - 1 week
  86400 )    ; Minimum
@   IN  NS  localhost.
@   IN  A   127.0.0.1

@   IN      ::1

salmon.hub. IN  A   8.8.8.8
fish.hub.   IN  NS  ns1.fish.hub.
ns1.fish.hub.   IN  A   4.4.4.4


-- 
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: help with notify

[Nick Tait via bind-users]

On 18/04/2023 2:16 am, Matt Zagrabelny via bind-users wrote:

On Mon, Apr 17, 2023 at 9:04 AM Marco  wrote:

Am 17.04.2023 um 08:59:29 Uhr schrieb Matt Zagrabelny via bind-users:

> I'm running a little older Debian bind:
>
> bind9               1:9.9.5.dfsg-9

The upgrade your OS, stretch already has 9.10 and that is very old.


Agreed! It is on the list of things to do, but I can't upgrade right now.

Any other suggestions would be appreciated.


If NOTIFY isn't working in your current BIND version, you could consider 
reducing the REFRESH parameter in the SOA record, so that the 
secondaries poll the primary more frequently?


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

Re: Best practice MultiView

[Nick Tait via bind-users]

On 18/04/2023 2:43 am, Greg Choules via bind-users wrote:
Why do you need it? Do you have some secondaries that are not listed 
as NS in zones?


The goal was to have the primary use a particular TSIG key when it sends 
out the NOTIFY messages to the secondaries, which is achieved by turning 
off the default notifies ("notify explicit"), and specifying the keys in 
an "also-notify" block.


Regarding views. Why would you have the same zone in an internal and 
external view? A few years ago, having to maintain multiple zones of 
the same name but different contents caused me problems daily. I would 
recommend having internal zones be proper delegations from external 
zones. e.g.:

external "example.com "
internal "internal.example.com "


I agree that having your internal infrastructure in a sub-zone is a good 
idea. But even if you do this there are valid reasons for having a 
split-view of the parent zone. One reason is so that you can include 
proper NS delegation records in the parent zone (e.g. in the internal 
view only). (I don't remember all the details, but I seem to recall that 
without these, if the parent zone is DNSSEC-signed and doesn't use the 
OPT-OUT feature, then a DNSSEC-validating resolver (e.g. running "delv" 
tool) would complain when querying names in the internal zone.)


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

Re: Best practice MultiView

[Nick Tait via bind-users]

On 18/04/2023 1:40 am, Jiaming Zhang wrote:
However, I got a question on the syntax of |also-notify|​, what I can 
see from bind9's user manual, the target of |also-notify|​ can be 
| |  [ port  ] |  
[ port  ]|​, does this means that I can use domain names of 
the server instead of IP? Both name server has IPv4 (single or 
multiple) and IPv6 glued with the domain name, and I was wondering if 
by setting domain name instead of IP, bind will intelligently find if 
it would need to communicate with which IP (like it currently do with 
|notify yes|​). I asked because if by any chance for whatever reason 
sending notify was failed to a certain IP, it may look up any other 
available IP that is defined with the related domain name (at least 
from my observation).


As Greg said, it needs to be IP addresses, not host names. The 
documentation defines "" as follows:


    A named list of one or more ip_addresses with optional tls_id, server_key, 
and/or port. A remote-servers list may include other remote-servers lists. See 
primaries block.

I was also confused what you exactly referred to with '"primaries" (or 
"masters" in old terminology) statement that includes the correct key 
name', I assume you mean I need to point which is the master and the 
keys to communicate with this specific master on the slave server. For 
the reference, I attached the related config on slave below.


```
zone "example.com" IN {
type slave;
masters { ; };
file "/path/to/file";
allow-query { any; };
notify yes; # will become "explicit"
};
```


What I was trying to say was the primaries/masters block above needs to 
include the key name. Also you may not even need your secondaries 
(slaves) to send notifies - unless you have a hierarchical structure 
where your secondaries need to notify downstream secondaries? e.g. In 
the simplest case you might have your secondaries using:


   zone "example.com" IN {
   type slave;
   masters { 192.0.2.2 key "internal.example.com"; };
   file "/path/to/file";
   allow-query { any; };
   notify no;
   };

NB: In all my examples "192.0.2.2" is the primary (master) and 
"192.0.2.1" is the secondary (slave).


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

Re: Best practice MultiView

[Nick Tait via bind-users]

Hi Jiaming.

You'll also need "match-clients" in the first view (at least), so that 
the correct view handles the zone transfer request. As well as 
specifying 'the right key' in match-clients, you'll probably also want 
to specify 'not the wrong key', otherwise you won't be able to query the 
view from any clients (e.g. on your internal network) that don't present 
any key in their request...


I've taken your example, and changed the key names to 
"internal.example.com" and "external.example.com" (for clarity), and 
added the match-clients to it as follows:


   view "internal" {
  match-clients { key "internal.example.com"; !key
   "external.example.com"; internal-networks; };
  zone "example.com" IN {
    # some other config, master zone
    allow-transfer { key "internal.example.com"; };
    notify yes;
  };
  # some more zone
   };
   view "external" {
  match-clients { key "external.example.com"; !key
   "internal.example.com"; any; };
  zone "example.com" IN {
    # some other config, master zone
    allow-transfer { key "external.example.com"; };
    notify yes;
  };
   };

Note that I've included "internal-networks" in the internal view. This 
is simply to illustrate that you might also want the view to answer DNS 
requests from clients within your network.


There is one further improvement on the above, which is what Mark 
referred to below, which is where each view can include the respective 
key in NOTIFY messages. To do that, change "notify yes" to "notify 
explicit" and then use "also-notify" to specify the secondary servers 
along with the key to use. Applying this to the above you get something 
like:


   view "internal" {
  match-clients { key "internal.example.com"; !key
   "external.example.com"; internal-networks; };
  zone "example.com" IN {
    # some other config, master zone
    allow-transfer { key "internal.example.com"; };
    notify explicit;
    also-notify { 192.0.2.1 key "internal.example.com"; };
  };
  # some more zone
   };
   view "external" {
  match-clients { key "external.example.com"; !key
   "internal.example.com"; any; };
  zone "example.com" IN {
    # some other config, master zone
    allow-transfer { key "external.example.com"; };
    notify explicit;
    also-notify { 192.0.2.1 key "external.example.com"; };
  };
   };

The secondary server would need a similar match-clients set-up so that 
it associated the notify with the correct view (based on key). And as 
I'm sure you know it would also need a "primaries" (or "masters" in old 
terminology) statement that includes the correct key name.


Nick.


On 17/04/23 22:12, Mark Andrews wrote:

You use keys as well when sending notify to select which view processes the 
notify


On 17 Apr 2023, at 18:44, Jiaming Zhang  wrote:

Dear community,

I was wondering if notifying and updating zones in different view (say "internal" and 
"external") between bind servers via different key is a good practice. I got a sample 
zone/config like below:
```
view "internal" {   zone "example.com" IN {
 # some other config, master zone
 allow-transfer { key key1; };
 notify yes;
   };
   # some more zone
}
view "external" {
   zone "example.com" IN {
 # some other config, master zone
 allow-transfer { key key2; };
 notify yes;
   };
}
```
where both zones have the same name server (e.g. `ns1.example.com` and `ns2.example.com`). What I'm trying to archive 
is that and update on zones in "internal" view does not contaminate zones in "external" view, or 
vice versa. I was wondering if using different key to limit update is a good practice, since I'm expecting 
"external" view on slave server will also receive notify upon update on "internal" zone at master, 
but just unable to query update due to incorrect key.

Kind Regards,
Jiaming Zhang

Yixi Meta
Tel: +31 (6) 12 98 08 07
Email:j.zh...@yiximeta.com
Website: yiximeta.com

De informatie in dit bericht is uitsluitend bestemd voor de geadresseerde. Aan 
dit bericht en de bijlagen kunnen geen rechten worden ontleend. Heeft u deze 
e-mail onbedoeld ontvangen? Dan verzoeken wij u het te vernietigen en de 
afzender te informeren. Openbaar maken, kopiëren en verspreiden van deze e-mail 
of informatie uit deze e-mail is alleen toegestaan met voorafgaande 
schriftelijke toestemming van de afzender. Het Yixi Meta staat geregistreerd 
bij de Kamer van Koophandel in het handelsregister onder nummer 85744115.

The content of this message is intended solely for the addressee. No rights can 
be derived from this message or its attachments. If you are not the intended 
recipient, we kindly request you to delete the message and inform the sender. 
It is strictly prohibited to disclose, copy or distribute this email or the 
information inside it, without a written consent from the sender. Yixi Meta is 
registered with the Dutch Chamber of Commerce trade register 

Re: Piggybacking on a zone’s dnssec-policy using auto-dnssec: How can one do this after Bind 9.19?

[Nick Tait via bind-users]

On 17/04/23 09:08, Andrej Podzimek via bind-users wrote:
The easiest (?) way to make DNSSEC work in all views has been to keep 
a dnssec-policy for zones in *one* of the views (to generate and 
maintain keys) and then passively refer to the keys from the zones’ 
counterparts in other views using auto-dnssec. \o/


Hi Andrej.

I think you might be over-complicating this? I use multiple views that 
define the same DNSSEC-signed zone, and I refer to the same 
dnssec-policy (i.e. the 'real' policy that does the rollovers) in each 
one. Admittedly I've only recently enabled automated ZSK roll-overs, but 
my understanding (based on others asking questions about this) is that 
recent versions of BIND are clever enough to recognise that the same 
keys apply to both versions of the zone, so it doesn't trip over itself 
when rolling keys.


See: https://www.mail-archive.com/bind-users@lists.isc.org/msg28526.html

Just make sure you aren't using an ancient version of BIND! :-)

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

Re: RPZ zone response delay time ?

[Nick Tait via bind-users]

On 8/04/2023 4:27 am, Jason Vas Dias wrote:

   I have converted the excellent hosts file at
 https://someonewhocares.org/hosts/
   to a Response Policy Zone (RPZ) file served by my
   local named that ends:

*.google-analytics.com A 0.0.0.0
*.clarity.ms A 0.0.0.0
*.adtelligent.com A 0.0.0.0

   (there are over 15,000 entries in it).


Hi Jason.

I'm doing something similar myself, although it looks like you've gone 
one step further with the inclusion of wildcards (i.e. "*") in the RPZ?


The other notable difference in my case is that my RPZ results in 
NXDOMAIN (i.e. same as suggested by Evan Hunt) rather than returning a 
bogus IP address.


FWIW I haven't experienced any issues with youtube, so I wonder whether 
one of these differences could be the cause of your CPU usage issue?


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

Re: BIND operating in Parental Agent role (according to RFC 7344)?

[Nick Tait via bind-users]

On 12/04/2023 7:51 pm, Petr Špaček wrote:
There is a philosophical question whether this is something a DNS 
server should do.


You make a very good point.


There are external tools which can automate zone scan, e.g.
https://github.com/CZ-NIC/fred-cdnskey-scanner


It hadn't occurred to me to look for a third-party solution. :-P

I suppose that it should be possible to glue it to standard DNS UPDATE 
mechanism and thus make it work with any standard DNS server. 


I must admit I was hoping for a solution that didn't require me to 
convert my main zone into a dynamic zone - i.e. something that would 
work within the inline-signing framework. But perhaps I was being overly 
optimistic?


I've decided I'll stick with manual KSK roll-overs for now... :-)

Thanks again.

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

Re: Delegation NS-records when zones share an authority server

[Nick Tait via bind-users]

On 13/04/2023 5:58 am, Havard Eidnes via bind-users wrote:

I suspect you don't need the NS records in challenge.state.ak.us and
if you remove them then the records in challenge.state.ak.us are
simply part of the state.ak.us zone since they're served off of the
same server.

Unfortunately "not quite".

While a publishing name server will respond with data from the most
specific zone available to it when queried (e.g. for the NS records
for challenge.state.ak.us), this "overriding" or "leakage" does not
happen when you do a zone transfer of the parent zone (state.ak.us).

So ... if you have a publishing name server which is a name server for
state.ak.us and not for challenge.state.ak.us, it will *not* have the
delegation NS RRset for challenge.state.ak.us, and if a recursor
happens to query this particular publishing name server as part of the
process of resolving a name in challenge.state.ak.us, it will get an
apparently-spurious NXDOMAIN response.


I think the suggestion was for the other way around - i.e. NS in parent 
zone only?


But that is also not a good idea. I'll defer to RFC 1034 section 4.2.1 
for the details:


   Though logically part of the authoritative data, the RRs that describe
   the top node of the zone are especially important to the zone's
   management.  These RRs are of two types: name server RRs that list, one
   per RR, all of the servers for the zone, and a single SOA RR that
   describes zone management parameters.

   The RRs that describe cuts around the bottom of the zone are NS RRs that
   name the servers for the subzones.  Since the cuts are between nodes,
   these RRs are NOT part of the authoritative data of the zone, and should
   be exactly the same as the corresponding RRs in the top node of the
   subzone.  Since name servers are always associated with zone boundaries,
   NS RRs are only found at nodes which are the top node of some zone.  In
   the data that makes up a zone, NS RRs are found at the top node of the
   zone (and are authoritative) and at cuts around the bottom of the zone
   (where they are not authoritative), but never in between.

The terminology is a bit confusing, but it boils down to this: The NS 
records for the zone must be included in the zone itself, and also in 
the parent zone.


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

BIND operating in Parental Agent role (according to RFC 7344)?

[Nick Tait via bind-users]

Hi list.

I'm currently running a few DNSSEC zones in BIND using dnssec-policy 
option, albeit with an unlimited lifetime on the KSK, so that I can 
control KSK roll-overs (which is necessary because my Registrar doesn't 
support RFC 7344)...


Anyway I know that BIND supports RFC 7344 via parental-agents option 
when BIND is operating in the 'Child' role; but my question is whether 
BIND currently supports (or if there are any plans for BIND to support) 
RFC 7344 with BIND operating in the 'Parental Agent' (and 'Parent') 
capacity.


In other words, can BIND be configured to poll a child zone for 
CDS/CDNSKEY records, and automatically add corresponding DS records into 
a zone that it controls?


If this isn't on the radar already, I'll be happy to submit an 
enhancement request?


Thanks,

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

Re: KASP: sharing policy and keys between views

[Nick Tait via bind-users]

Hi Carsten.I've been running split views with a DNSSEC zone using dnssec-policy 
for at least a couple of years.I'm using a CSK (i.e. combined KSK+ZSK) and 
haven't yet worked out the best way to automate key rollover wrt DS in parent 
zone, so my key rollovers are manual currently. Consequently I've only done a 
key rollover a couple of time in that period.But this setup has been working 
fine for me the whole time.Nick.
 Original message From: Matthijs Mekking  
Date: 18/03/23  3:43 AM  (GMT+12:00) To: bind-users@lists.isc.org Subject: Re: 
KASP: sharing policy and keys between views Hi Carsten,We did have some bugs in 
the past when it comes to sharing keys with dnssec-policy among different 
views. But the last one is from a year ago (fixed in 9.16.19).So while I don't 
have experience myself with a similar setup, we did have some bug reports that 
used dnssec-policy and views that have been resolved and it has been quiet when 
it comes to "dnssec-policy with views" related bug reports.Now that doesn't 
mean there are none, but hopefully adds a bit of confidence.Best regards,   
MatthijsOn 3/17/23 11:46, Carsten Strotmann via bind-users wrote:> Hi,> > 
(please do not start a discussion on the usefulness of views. I'm not> in favor 
of views, but sometimes I have to work with them).> > I have a client that runs 
a split horizon (internal / external view> of the same domain namespace) setup 
with BIND 9 on Linux.> > Both the internal and external views of the domain are 
DNSSEC> signed.> > In the past, the setup was using "auto-dnssec maintain;" on 
a common,> shared key directory with manually created keys. Both zones in both> 
views fetched the keys and did the signing. This setup was stable and> working 
fine.> > Because "auto-dnssec maintain;" is deprecated, we're evaluating to> 
change the setup to use a shared DNSSEC KASP definition, pointing to> the same 
key directory (using shared keys and a shared state file).> > The test setup 
runs without issues for one month now and has> successfully done 3 ZSK 
rollovers in the time (KSK rollovers are> manual). So it *seems* like a working 
configuration. We have not seen> errors or race-conditions (but we might have 
been lucky).> > Does anyone here has experience with a similar setup, or 
deeper> insight into the code and can tell me if this is a possible solution> 
to operate a DNSSEC signed split horizon setup?> > Greetings> > Carsten 
Strotmann> > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this listISC funds the development of this software with paid 
support subscriptions. Contact us at https://www.isc.org/contact/ for more 
information.bind-users mailing 
listbind-us...@lists.isc.orghttps://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: [KASP] Key rollover

[Nick Tait via bind-users]

On 14/02/23 05:39, adrien sipasseuth wrote:
"You configure parental agents and named will check which DS’s are 
published.  Named won’t complete the

roll until it knows the new DS is published."
=> what is parental agent ? i don't find this term in Bind 
documentation. From what I understand, you have to specify to Bind 
that the new DS is published with the command: rndc dnssec -checkds 
-key  published 
Have a look at 
https://downloads.isc.org/isc/bind9/9.18.11/doc/arm/html/reference.html 
and search for "|parental-agents|"? (The basic idea is that BIND will 
automatically poll to see if the new DS has been published, rather than 
relying on you to run the rndc command.)


"If it was me, I'd set the KSK to not roll-over automatically, and
instead create a recurring reminder for yourself to initiate the KSK
roll-over manually? That way you'd never get caught out with a KSK
roll-over happening when you weren't prepared for it? "
=> I don't know if I can get a policy for ZSK and a manual method for 
KSK. From what I understand if I want to use a policy I have to remove 
"auto-dnssec maintain;" which is necessary for the manual method right?


You can configure your dnssec-policy to automatically roll the ZSK only, 
and then you can manually roll the KSK. Just set the policy to give the 
KSK an unlimited lifetime, e.g.:


dnssec-policy 90dayzsk {
    keys {
    ksk lifetime unlimited algorithm ecdsa256;
    zsk lifetime P90D algorithm ecdsa256;
    };
};

You can trigger the (KSK) roll-over with: rndc dnssec -rollover -key xxx

BIND will then schedule the creation of the new key, etc, and all you 
need to do is change the DS key (in the parent zone) at the appropriate 
time, then (if not using parental-agents) tell BIND that you've done it, 
and it will take care of retiring the old key.




In the meantime, I wonder if I can't stay on the manual method even 
with a bind 9.18? I read that the auto-dnssec directive might 
disappear in favor of dnssec-policy. Does that mean that it might not 
be possible to do it manually anymore? source here => 
https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy
See previous answer. IMHO transitioning to using dnssec-policy is 
definitely worth it! :-)-- 
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: [KASP] Key rollover

[Nick Tait via bind-users]

On 9/02/23 05:17, adrien sipasseuth wrote:
so it works BUT I need to know more than 48h in advance that the 
rollover is starting to submit the new KSK to my registar.


How can I set this up if it's not with "public-safety"?
If it was me, I'd set the KSK to not roll-over automatically, and 
instead create a recurring reminder for yourself to initiate the KSK 
roll-over manually? That way you'd never get caught out with a KSK 
roll-over happening when you weren't prepared for it?

--
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: Resolve some hosts thats are dnssec signed differently

[Nick Tait via bind-users]

Hi Matthias.

Using a Response Policy Zone on your internal DNS resolver, to change 
the answers to DNS queries for your domain from 195.30.95.36 to 
192.168.0.1, sounds like the solution that most closely matches what 
you've described. Just be aware though, if you have any internal clients 
that rely explicitly on DNSSEC (such as a mail server that needs to 
apply DANE) then, by default, those queries (that contain DO=1) won't be 
rewritten. (See response-policy option, and in particular the 
break-dnssec sub-option for more information.)


Another advantage that RPZ has over split-views, is that you don't need 
to maintain a separate duplicate zone file.


OTOH if the DNSSEC thing is an issue, you may want to look at other 
alternatives, including:


 * The split-view thing I mentioned below.
 * IP-layer network trickery, such as mangle rules (or similar) so that
   the internal machines continue to use the public address, but the
   packets don't actually get routed out to the Internet.

Nick.


On 7/02/23 19:45, Matthias Fechner wrote:

Hi Darren, Hi Nick,

at first thanks a lot for your answer.
I see that I have not explained my use-case detailed enough.
I have bind running for domain fechner.net, but not at home and this 
server I think is here completely out of discussion.
If I must not touch it, I do not want to touch it as it would see the 
traffic from my local computer from home like any other computer in 
the internet and I do not want to open it in any way and it should not 
know the setup of my local network at home.


At home I have a bind running. It serves some local zones I use here 
internally and is forwarding all requests to the DNS server my 
provider is providing.
It is not connected in any way to my bind servers running for domain 
fechner.net.


The public IP address (idefix.fechner.net) is due to this routing, NAT 
and openvpn not visible on any of my interfaces on my home server.


So if I would like to access idefix.fechner.net it makes a DNS lookup 
which returns the A record for idefix.fechner.net and it sees it does 
not belong to my interface so it uses the default gateway to go to my 
internet provider. It reaches my server in the internet, is routed 
into the openvpn tunnel and goes through my local firewall through a 
policy based NAT to a local IP (192.168.200.x). So you see that is not 
very efficient.


My idea was to hook into the DNS and make sure to not return the IPv4 
address 195.30.95.36, but 192.168.0.1 (as all my devices at home are 
using my local bind here for lookup).


I hope that explain it better what I would like to solve.

Matthias

Am 07.02.2023 um 07:48 schrieb Nick Tait via bind-users:


Hi Matthias.

It isn't clear whether the issue you're trying to solve is (a) 
avoiding DNS resolution going out then in to get to your 
authoritative servers, or (b) with resolved addresses of your servers 
being the public address which means that data packets sent to/from 
those servers are going out then in to get to them?


It looks like Darren has assumed (a)? If that is correct then it is 
worth noting that using forwarders like this will require your 
authoritative servers to answer recursive queries. If that is 
undesirable, you might want to look at using "mirror" zones on your 
recursive resolvers? I haven't personally used zones of this type, 
but according to the documentation, this has following advantage over 
using "secondary" zones to achieve the same thing: /Answers coming 
from a mirror zone look almost exactly like answers from a zone of 
type //|secondary|//, with the notable exceptions that the AA bit 
(“authoritative answer”) is not set, and the AD bit (“authenticated 
data”) is./


However I suspect your issue is actually (b), in which case I'd 
suggest using views to serve two versions of your zone file - one 
with public IP addresses that is served to external clients, and one 
with private IP addresses that is served to internal clients only, 
along the lines of the following:


# View containing zone with public IP addresses.
view "public" {
     match-clients { ... };

     zone "fechner.net" {
     type primary;
     file "../master/fechner.net/*public-*fechner.net";
     dnssec-policy "one-year-zsk";
     inline-signing yes;
     };
};

# View containing zone with private IP addresses.
view "private" {
     match-clients { ... };

     zone "fechner.net" {
     type primary;
     file "../master/fechner.net/*private-*fechner.net";
     dnssec-policy "one-year-zsk";
     inline-signing yes;
     };
};

The two copies of the zone are signed using the same keys.

For the sake of simplicity I've glossed over the details of 
replicating the two different copies of the zone to your secondary 
DNS servers, but the general idea is to have the secondaries use 
different TSIG signatures for transferring each copy, 

Re: Resolve some hosts thats are dnssec signed differently

[Nick Tait via bind-users]

Hi Matthias.

It isn't clear whether the issue you're trying to solve is (a) avoiding 
DNS resolution going out then in to get to your authoritative servers, 
or (b) with resolved addresses of your servers being the public address 
which means that data packets sent to/from those servers are going out 
then in to get to them?


It looks like Darren has assumed (a)? If that is correct then it is 
worth noting that using forwarders like this will require your 
authoritative servers to answer recursive queries. If that is 
undesirable, you might want to look at using "mirror" zones on your 
recursive resolvers? I haven't personally used zones of this type, but 
according to the documentation, this has following advantage over using 
"secondary" zones to achieve the same thing: /Answers coming from a 
mirror zone look almost exactly like answers from a zone of type 
//|secondary|//, with the notable exceptions that the AA bit 
(“authoritative answer”) is not set, and the AD bit (“authenticated 
data”) is./


However I suspect your issue is actually (b), in which case I'd suggest 
using views to serve two versions of your zone file - one with public IP 
addresses that is served to external clients, and one with private IP 
addresses that is served to internal clients only, along the lines of 
the following:


# View containing zone with public IP addresses.
view "public" {
    match-clients { ... };

    zone "fechner.net" {
    type primary;
    file "../master/fechner.net/*public-*fechner.net";
    dnssec-policy "one-year-zsk";
    inline-signing yes;
    };
};

# View containing zone with private IP addresses.
view "private" {
    match-clients { ... };

    zone "fechner.net" {
    type primary;
    file "../master/fechner.net/*private-*fechner.net";
    dnssec-policy "one-year-zsk";
    inline-signing yes;
    };
};

The two copies of the zone are signed using the same keys.

For the sake of simplicity I've glossed over the details of replicating 
the two different copies of the zone to your secondary DNS servers, but 
the general idea is to have the secondaries use different TSIG 
signatures for transferring each copy, and have the "match-clients" use 
the TSIG key to figure out which view they are talking to. Let me know 
if you need more info about how to set this up?


Nick.


On 6/02/23 01:08, Darren Ankney wrote:

Matthias,

This is what I did to force my resolver bind instance to lookup my
internal domain directly on my authoritative bind instance without
asking any other servers (would have failed anyway as it is a fake
domain "mylocal"):

// on resolver (or caching name server)
zone "mylocal" {
   type forward;
   forwarders {
 192.168.40.142; // authoritative server 1
 192.168.40.182; // authoritative server 2
   };
   forward only; // don't ask any other server
};

Not sure if that will break dnssec for you. There are probably other
way(s) to accomplish this, especially for a real domain on real IP
address(s). But maybe its somewhere to start.

-Darren

On Sun, Feb 5, 2023 at 1:21 AM Matthias Fechner  wrote:

Dear all,

I have a question regarding a setup I use at home.
It is for domain idefix.fechner.net.

I have at home a small server running with some services at it. As I do
not have a public IP, I tunnel traffic using pf on FreeBSD and openvpn
to route a public IP to my server at home.
This works nice but if I now access idefix.fechner.net it will always go
outside to the internet and then back through the tunnel to my local
server which is a real performance problem, as the internet connection
here is really slow.

The complete domain is dnssec signed using the following configuration:
zone "fechner.net" {
  type master;
  file "../master/fechner.net/fechner.net";
  dnssec-policy "one-year-zsk";
  inline-signing yes;
};

Now I want to make sure if I access idefix.fechner.net that it does not
use the tunnel but access it directly using the local address.

So the idea was to configure my named running at home to resolve some
host names differently.

What is here recommended best practice doing it?

Just added a new domain fechner.net and overwrite some A records? I
think that will break dnssec or?

Thanks for any pointer into the right direction.

Gruß
Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

--
Visithttps://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 athttps://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 

Re: Providing AD flag for authoritative domains

[Nick Tait via bind-users]

On 23/12/2022 2:30 am, Jesus Cea wrote:
Is there any way to configure bind to verify DNSSEC integrity and 
signal the AD flag for authoritative domains?. Views (it would lose 
the AA flag, then)?


What would be the best practice for dnssec verification? To use a 
fully validating local resolver? Any other choice? I am currently 
using a local "bind" as a resolver and it works fine for DNSSEC 
verification, except for my authoritative domains. 


Yes you can use views to effectively separate the concerns of the 
recursive resolver function from the authoritative server, without 
having to deploy extra servers. For example:


view "resolver" {
    # Match criteria
    match-clients { ... };
    match-recursive-only yes;

    zone "example.com" {
    type static-stub;
    server-addresses { ::1; };
    };

    include "/etc/bind/named.conf.default-zones";
};

view "authority" {
    # View settings
    empty-zones-enable no;
    recursion no;
    allow-recursion { none; };
    rate-limit {
    responses-per-second 5;
    window 5;
    };

    zone "example.com" {
        ...
    };
};

The idea here is that a recursive query (received from an 'internal' 
address covered by the match-clients criteria) will be handled by the 
/resolver/ view, which will use the static-stub zone to query (via 
loopback address) the /authority/ view, which is authoritative for the 
example.com zone. Provided the answer from the /authority/ view is 
DNSSEC signed and the /resolver/ view can successfully validate the 
signature, then the answer returned by the /resolver/ view to the 
original client performing the recursive query includes the AD flag (but 
not the AA flag).


It could actually work without the static-stub zone, but I prefer to 
keep this to stop the /resolver/ view from sending the queries to a 
different (authoritative) server.


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

Re: parental-agents clause - IP address only ?

[Nick Tait via bind-users]

On 5/12/22 15:34, vom513 wrote:

Hello all,

So I set up parental-agents lists for my zones, and actually got to see it work 
(awesome !).  bind detected the parent DS records and acted accordingly.

However, I currently have these lists configured using the IP (v4 only at the 
moment) addresses of the parent NS’es.  I tried inputting hostnames, and I got 
errors (i.e. syntax) every time.

I would prefer to put these in as hostnames.  While at a certain level in the 
tree these don’t change very often, they can and do.  I’d rather not have to 
keep track of these in this manner.

So my question - am I just mangling the syntax - or does this clause really 
only support IPs ?  I was thinking if so - perhaps the reason is some chicken 
vs. egg / security reason ?  I.e. not trusting the name (which would have to be 
itself resolved) ?

Thanks in advance for clue++
Although I haven't personally set up parental-agents (yet), I noticed an 
interesting remark in section 8.2.26.1 of the documentation 
(https://bind9.readthedocs.io/en/v9_18_8/reference.html#automated-ksk-rollovers) 
- NB: italics added for emphasis:



Note

The DS response is not validated so it is recommended to set up a
trust relationship with the parental agent. For example, use TSIG
to authenticate the parental agent, /or point to a validating
resolver/.

So you might consider pointing your parental-agents at (an IP address 
of) your local resolver(s), instead of the parent NSs?


However the obvious drawback of this approach would seem to be that the 
resolver will only check one of the parent NSs for the DS record, 
whereas if you explicitly specify all the NSs in parental-agents, then 
they all get checked?


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

Re: dig +norecurse behaviour changed with 9.16.33

[Nick Tait via bind-users]

Hi Veronique.

I'm not an expert, but to me the 9.16 behaviour is what I would expect 
to happen, based on:


 * When you issue the non-recursive query for "spectrum.cern.ch", it is
   answered from the "cern.ch" zone, which only knows the CNAME
   (returned in the ANSWER section) and the NS records for the zone
   that the CNAME points to (presumably returned in the ADDITIONAL
   section?).
 * A [hypothetical] subsequent non-recursive query for
   "spectrum-lb.cern.ch" would be answered from the
   "spectrum-lb.cern.ch" zone which contains the A records (which
   should be returned in the ANSWER section of that query).

(A recursive resolver would be expected to make both of the queries 
above to give a complete answer to the query for "spectrum.cern.ch".)


But aside from the observation that the responses from 9.11 and 9.16 
aren't the same, what is the actual problem you are trying to solve? 
i.e. Why does it matter if the A record is or isn't returned in a 
/non-recursive/ query for "spectrum.cern.ch"?


Nick.


On 28/10/22 01:28, Veronique Lefebure wrote:

Well,

So here a bit more details.
Sorry, I cannot take an example with a DNS server accessible to you 
(*)  because they have all been upgraded to 9.16.


The .cern.ch contains:

spectrum-lb IN NS ip-dns-1.cern.ch.
spectrum-lb IN NS ip-dns-2.cern.ch.
spectrum IN CNAME spectrum-lb.cern.ch.

and

spectrum-lb.cern.ch contains:

$ORIGIN .
$TTL 60 ; 1 minute
spectrum-lb.cern.ch IN SOA ip-dns-1.cern.ch. internal-dns.cern.ch. (
273 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
360 ; expire (5 weeks 6 days 16 hours)
60 ; minimum (1 minute)
)
NS ip-dns-1.cern.ch.
NS ip-dns-2.cern.ch.
A xxx.xxx.xx.140



named configuration file is identical between 9.11 and 9.16 except for 
the following options that we have added for 9.16:


#BIND916 options
qname-minimization disabled;
stale-answer-enable no;
stale-refresh-time 0; #default is 30
max-stale-ttl 1w;
dnssec-policy none;
synth-from-dnssec no;
min-cache-ttl 0;
min-ncache-ttl 0;
minimal-responses no;





(*) On an external DNS server you can try with the following similar 
case:


Running DiG 9.11.21 on a linux client
ext-dns-1 (192.65.187.5) runs BIND9.16:
dig @ext-dns-1 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
dig @ext-dns-1 foundservices.cern.ch *+norecurse* | grep flags | grep 
ANSWER

;; flags: qr aa ra; QUERY: 1, ANSWER: *1*, AUTHORITY: 0, ADDITIONAL: 1
Full output:
dig @192.65.187.5 foundservices.cern.ch +norecurse
; <<>> DiG 9.11.21 <<>> @192.65.187.5 foundservices.cern.ch +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9899
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8786b980a1a80a790100635a7898a512a21aa6138faf (good)
;; QUESTION SECTION:
;foundservices.cern.ch. IN A
;; ANSWER SECTION:
foundservices.cern.ch. 900 IN CNAME db-lb-1234.cern.ch.
;; Query time: 2 msec
;; SERVER: 192.65.187.5#53(192.65.187.5)
;; WHEN: Thu Oct 27 14:24:56 CEST 2022
;; MSG SIZE rcvd: 103
ip-dns-0 runs BIND9.11:
dig @ip-dns-0 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4
dig @ip-dns-0 foundservices.cern.ch *+norecurse* | grep flags | grep 
ANSWER

;; flags: qr aa; QUERY: 1, ANSWER:*2*, AUTHORITY: 2, ADDITIONAL: 4


Does that help ?

Greg, can I send you a pcap file in a private email ?


Thanks,
Veronique
On 27/10/2022 10:09 Greg Choules 
 wrote:



Hi Veronique.
No, we cannot easily reproduce this behaviour because we have no 
knowledge of the configs of either of those servers, the details of 
the zones you have configured, the contents of those zones or of the 
system on which you are running the dig command.


As I said, we need to see everything please:
- Full digs, not +short
- you have specified @ip-dns0 and @ip-dns1 - the full configs of both 
of those servers please, including zone definitions and contents for 
where "spectrum.cern.ch " lives as it is 
not a name that can be resolved from the public Internet
- a binary pcap file, using the -w option of tcpdump, capturing all 
port 53 traffic (UDP and TCP) between this machine and both DNS servers.


By the way, when using the @ option of dig please use 
explicit IP addresses, not names. If you use a name, then dig first 
has to resolve that name and the place it will go to do that is 
resolv.conf. So it is now dependent on your system DNS setup to get 
an IP address to send the dig to.
Also, you have specified @ not @. This 
suggests to me that in resolv.conf you have a 'search' list. 
Personally I don't like search lists because they potentially 
increase the workload of the DNS system generally, lengthen query 
times and mean that you can't be sure exactly where an answer came from.


Thanks, Greg


On Thu, 

Secondary zone is only using the first listed primary

[Nick Tait via bind-users]

Hi list.

I have a BIND server that is acting as a secondary to replicate a zone 
from SpamHaus/Deteque, which is then used internally as a Response 
Policy Zone. This had been working fine for several years, but recently 
I noticed that BIND was reporting that the zone had expired. When I 
looked closer I realised that I'd only specified the 2 x IPv6 addresses 
for the SpamHaus servers, and for some reason neither of those were 
responding to DNS queries, so I added in the IPv4 addresses. My 
configuration basically looked like this:


   primaries deteque-primary {
    2600:1f18:215e:b701:8624:5523:94aa:f163;
    2a05:d014:1bf:db01:c11:ab37:1f20:3358;
    34.194.195.25;
    35.156.219.71;
   };
   ...
   view "xxx" {
    zone "drop.ip.dtq" {
    type secondary;
    file "db.drop.ip.dtq";
    primaries { deteque-primary; };
    notify explicit;
    also-notify { nick-secondary-deteque; };
    allow-transfer { nick-nameservers-private; };
    allow-query { nick-nameservers-private; loopback-networks; 
};
    };
   };

My expectation was that BIND would try the first IPv6 address 
(2600:1f18:215e:b701:8624:5523:94aa:f163), then when that timed out due 
to no response, it would try the second one 
(2a05:d014:1bf:db01:c11:ab37:1f20:3358), then after that timed out it 
would try the first IPv4 address (34.194.195.25) which should succeed.


However after restarting BIND I was finding that the zone still wasn't 
being transferred. And Wireshark revealed that SOA query packets were 
being sent every 15 seconds to the first address only 
(2600:1f18:215e:b701:8624:5523:94aa:f163), which wasn't replying (as 
expected), and no packets were being sent to any of the other IP 
addresses listed in the 'primaries' statement. (I left the packet 
capture running for >15 minutes without seeing any packets being sent to 
the other 3 addresses.)


So my question is: For a secondary zone, are there any circumstances 
where BIND would try the servers listed after the first entry in the 
primaries stanza? And if so, should the lack of response from the first 
primary be one of those circumstances?


In other words, is the behaviour I'm seeing a bug, or does BIND always 
only use the first entry in a primaries stanza of a secondary zone?


FYI BIND version is: 9.18.1

Thanks,

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

Re: Sparklight and DNSSEC

[Nick Tait via bind-users]

On 27/09/2022 3:58 am, Benny Pedersen wrote:
imho dnssec-validation auto;  have a bug as it validates domains 
without DS set


hope bind developpers can confirm or deny it 


Hi Benny.

Until DS records are published in the parent zone, the (signed) zone is 
considered 'insecure', and validation doesn't occur. i.e. The behaviour 
you described above is how it is supposed to work.


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

RE: Dnssec issues

[Nick Tait via bind-users]

Hi Salma.While I haven't experienced your problem before, I do recall having 
'issues' with DNSSEC when my router was acting as a caching DNS resolver.My 
suggestion is to check if you have an appliance 'helping' with DNS (e.g. 
between these servers and the Internet?) and if so try turning that function 
off to see if the problem goes away?Nick.
 Original message From: salma smaoui  
Date: 22/09/22  11:18 PM  (GMT+12:00) To: bind-users@lists.isc.org Subject: 
Dnssec issues 

Hello All,




We are facing some resolution problems on a CENTOS resolver that deploys bind 
9.11.36-S1 with DNSSEC being activated.



The logs in 'default.logs' shows the current errors :

X-Sep-2022 10:34:29.348 dnssec: info:   validating shalltry.com/SOA: bad cache 
hit (shalltry.com/DS)
X-Sep-2022 10:34:29.363 dnssec: info: validating osupdate2020.shalltry.com/A: 
bad cache hit (shalltry.com/DS)
X-Sep-2022 10:34:29.411 dnssec: info:   validating static.cnews.fr/NSEC: no 
valid signature found
X-Sep-2022 10:34:29.445 dnssec: info: validating 
ocsp.comodoca.com.cdn.cloudflare.net/A: bad cache hit (cloudflare.net/DNSKEY)
X-Sep-2022 10:34:29.447 dnssec: info: validating 
cdn.jsdelivr.net.cdn.cloudflare.net/A: bad cache hit (cloudflare.net/DNSKEY)
X-Sep-2022 10:34:29.558 dnssec: info: validating oshola.shalltry.com/A: bad 
cache hit (shalltry.com/DS)
X-Sep-2022 10:34:29.567 dnssec: info: validating ds.shalltry.com/A: bad cache 
hit (shalltry.com/DS)
X-Sep-2022 10:34:29.570 dnssec: info: validating cdn.shalltry.com/A: bad cache 
hit (shalltry.com/DS)

Each night we noticed the occurence of a resolution problem (mini crisis) where 
requestes receive 'ServFail' for random domains, the maximum
 recursive clients is also reached along with the appearance of the error in 
the logs being highly increased. Even known domain names like apple.com and 
google.com receive 'ServFail' when requested.  Once flushing the cache, the 
situation gets back to normal
 and bind starts functionning correctly.
In fact, by activating dnssec.log, we noticed these errors : 'no walidating 
signature found'.
When deactivating DNSSEC, we noticed that there are no more crisis for now.
Any possible explanation? Have anyone faced this problem before?


Best regards.






-- 
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: Issue with dns resolution for www.ssa.gov

[Nick Tait via bind-users]

On 2/09/22 08:09, Bhangui, Sandeep - BLS CTR via bind-users wrote:

# nslookup _www.ssa.gov_ 
;; Got SERVFAIL reply from 127.0.0.1, trying next server
Server: 198.6.1.1
Address:    198.6.1.1#53
Non-authoritative answer:


Hi Sandeep.

This looks like when you use nslookup it is using 127.0.0.1 as your DNS 
server, but when you use dig it isn't. Do you have systemd on that 
machine? If so, I suspect your requests using nslookup are going to the 
systemd-resolved stub resolver?


FYI I know that there were issues with the stub resolver and DNSSEC 
lookups, but I don't recall exactly what the issues were and so I'm not 
sure if those limitations have been resolved by now?


If this is your situation, then you may want to consider disabling the 
stub resolver? Have a look at "man resolved.conf" and in particular the 
option you want to set is "DNSStubListener=no". The preferred way to do 
this is to create a .conf file with this in 
/etc/systemd/resolved.conf.d/ directory, e.g.:


   $ cat /etc/systemd/resolved.conf.d/00-nick.conf
   [Resolve]
   FallbackDNS=192.168.20.195 192.168.20.196 192.168.20.197
   DNSSEC=yes
   DNSStubListener=no

After editing the configuration run "sudo systemctl restart 
systemd-resolved".


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

Re: Primary zone not fully maintained by BIND

[Nick Tait via bind-users]

On 26/05/22 20:34, Matthijs Mekking wrote:
What version are you using? We had a bug with dnssec-policy and views 
(#2463), but that has been fixed.


Since 9.16.18 you should not be able to set the same key-directory for 
the same zone in different views. 


Hi Matthijs.

You got me worried just then because for several years I have been using 
a split DNS set-up, with the same zone defined in two different views 
which share a common keys directory. And then about a month ago I 
upgraded from 9.16.something to 9.18.1.


But I've managed to find the release note that I think you're referring 
to. From 
https://downloads.isc.org/isc/bind9/9.16.29/doc/arm/html/notes.html#id24 :


   Zones which are configured in multiple views, with different values
   set for |dnssec-policy| and with identical values set for
   |key-directory|, are now detected and treated as a configuration
   error. *[GL #2463]*
   

So based on this it would seem that it is OK for two views to define the 
same DNSSEC zone and share the same keys directory, *as long as they are 
using the same dnssec-policy*?


Please advise if I've got that wrong?

Thanks,

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

Re: why did it take 26 hours for DSState to change to omnipresent?

[Nick Tait via bind-users]

On 16/05/22 21:34, Matthijs Mekking wrote:

Hi Nik,

On 16-05-2022 07:49, Nick Tait via bind-users wrote:

Hi there.

Ever since I updated my BIND configuration to use the new 
dnssec-policy feature (a year or so ago) my KSK/CSK rollovers have 
been a complete shambles. My problems stem from the inference (based 
documentation and examples) that running "rndc dnssec -checkds 
published" tells BIND that the DS record is now published in the 
parent zone? Based on that predicate, it would be my expectation that 
after running this command above, the DSState should immediately 
transition from "rumoured" to "omnipresent".


This assumption is incorrect. Once the DS is in the parent, validators 
do not immediately know about the new DS record. That why it is rumoured.


Being omnipresent means that every resolver will use the new DS record 
for validation purposes, whether they have it in the cache, or 
retrieve it from the parent zone. More importantly this means that any 
previous versions of the DS RRset are not known anywhere.


In past rollovers, the DSState hasn't transitioned from "rumoured". 
And then I've thought "oh it must be a bug" and so I've set about 
trying to force the DSState to change to "omnipresent". And suffice 
to say that the shambles followed on from there...


So anyway, since I'd recently upgraded to BIND 9.18.1 (as part of 
Ubuntu 22.04 upgrade), and thinking maybe these 'bugs' might now be 
fixed, I thought I'd have another look at it, but this time I'll pay 
more attention to what is going on, and try to be less impatient...


Before I did anything the key state file looked like this:

Algorithm: 15
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20211024221429 (Mon Oct 25 11:14:29 2021)
Published: 20211024221429 (Mon Oct 25 11:14:29 2021)
Active: 20211024221429 (Mon Oct 25 11:14:29 2021)
PublishCDS: 20211025231929 (Tue Oct 26 12:19:29 2021)
DNSKEYChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
ZRRSIGChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
KRRSIGChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
DSChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent

As you can see the DSState was "rumoured" before I started. So the 
first thing I did was run "rndc dnssec -checkds published", and this 
added the following line to the state file:


DSPublish: 20220515001647 (Sun May 15 12:16:47 2022)

However the DSState value remained "rumoured". So then I thought, 
I'll wait a TTL or two (TTL for DS and DNSKEY are both 1 hour -- 
although I wouldn't expect BIND to know the DS TTL). But still 
nothing changed. So then I decided I'd leave it alone until the next 
day. When I checked after ~20 hours elapsed time, still nothing had 
changed.


I checked again just now, and finally the DSState has changed to 
"omnipresent". Here are the lines in the state file that have changed:


DSChange: 20220516021647 (Mon May 16 14:16:47 2022)
DSState: omnipresent

So my big question is this: Is it expected that the DSState won't 
change until 26 hours after the "rndc dnssec -checkds published" 
command is run? And if so why does it take so long?


That depends on your dnssec-policy. BIND will/should move the DSState 
to omnipresent after an x amount of time, where:


    x =  parent-ds-ttl + parent-propagation-delay + retire-safety


By default these values are

    parent-ds-ttl: 24h
    parent-propagation-delay: 1h
    retire-safety: 1h

So the 26 hours add up.

Now these may be very conservative values, but for the default policy 
we rather wait a little longer than too short.


Best regards,

Matthijs


Thanks so much for the explanation. Makes perfect sense now. :-)

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

Re: per record responses based on originating IP

[Nick Tait via bind-users]

On 16/05/22 20:05, Angus Clarke wrote:
As mentioned in a separate reply to Grant, the goal is to have 
(amongst other things) local recursors "find" the locally deployed 
authoritative servers through NS records. What hasn't been mentioned 
is that I am also looking to simplify configuration management by 
means of a single set of data which can be deployed to all 
authoritative servers - I don't think the RPZ solution proposed by 
Nick achieves that.


That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can.


Hi Angus.

Thanks for clarifying. Based on what you've said, what I proposed 
probably has slightly more merit than I concluded, although admittedly 
it doesn't quite tick all the boxes...


Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are 
represented as prefixlength.B4.B3.B2.B1.rpz-client-ip. In my examples I 
was specifying a single host which is why the RPZ-CLIENT-IP records all 
started with 32.


Secondly, RPZs are more commonly used on recursive resolvers rather than 
the authoritative nameservers for the zone, although in your case if you 
are wanting to change the answer that an authoritative nameserver gives 
to the NS question from the recursive resolver, then it probably makes 
the most sense to put the RPZ on the authoritative nameserver. In this 
case you'd also need to specify "recursive-only no". (FYI Default 
behaviour is to apply RPZ rewriting to queries with RD=1 and DO=0.)


However this still doesn't meet your requirement for "a single set of 
data", unless you are only talking about zone data, and in that case you 
could replicate all the RPZ zone files to all authoritative nameservers, 
and then configure each server to specify only one of these in its 
"response-policy" configuration?


But the anycast suggestion sounds like it has the most merit? Or at 
least it sounds the coolest to me. :-)


Nick.

P.S. I don't think this will be useful to you, but FWIW... if your goal 
is simply to have the recursive resolvers use a specific subset of 
nameservers for specific zones, then there is yet another option: 
static-stub zones. Static-stub zones allow you to effectively override 
the authoritative nameserver that will be used for a particular zone. So 
you could configure the static-stub zone on the recursive resolver, and 
that would point to the local authoritative nameserver(s). However the 
main drawback with static-stub zones is that you need to create a 
static-stub zone (on the local resolver) for every authoritative zone 
that you are doing this with, so it probably isn't practical if you have 
many zones or are adding or removing zones frequently?
-- 
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

why did it take 26 hours for DSState to change to omnipresent?

[Nick Tait via bind-users]

Hi there.

Ever since I updated my BIND configuration to use the new dnssec-policy 
feature (a year or so ago) my KSK/CSK rollovers have been a complete 
shambles. My problems stem from the inference (based documentation and 
examples) that running "rndc dnssec -checkds published" tells BIND that 
the DS record is now published in the parent zone? Based on that 
predicate, it would be my expectation that after running this command 
above, the DSState should immediately transition from "rumoured" to 
"omnipresent".


In past rollovers, the DSState hasn't transitioned from "rumoured". And 
then I've thought "oh it must be a bug" and so I've set about trying to 
force the DSState to change to "omnipresent". And suffice to say that 
the shambles followed on from there...


So anyway, since I'd recently upgraded to BIND 9.18.1 (as part of Ubuntu 
22.04 upgrade), and thinking maybe these 'bugs' might now be fixed, I 
thought I'd have another look at it, but this time I'll pay more 
attention to what is going on, and try to be less impatient...


Before I did anything the key state file looked like this:

Algorithm: 15
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20211024221429 (Mon Oct 25 11:14:29 2021)
Published: 20211024221429 (Mon Oct 25 11:14:29 2021)
Active: 20211024221429 (Mon Oct 25 11:14:29 2021)
PublishCDS: 20211025231929 (Tue Oct 26 12:19:29 2021)
DNSKEYChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
ZRRSIGChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
KRRSIGChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
DSChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent

As you can see the DSState was "rumoured" before I started. So the first 
thing I did was run "rndc dnssec -checkds published", and this added the 
following line to the state file:


DSPublish: 20220515001647 (Sun May 15 12:16:47 2022)

However the DSState value remained "rumoured". So then I thought, I'll 
wait a TTL or two (TTL for DS and DNSKEY are both 1 hour -- although I 
wouldn't expect BIND to know the DS TTL). But still nothing changed. So 
then I decided I'd leave it alone until the next day. When I checked 
after ~20 hours elapsed time, still nothing had changed.


I checked again just now, and finally the DSState has changed to 
"omnipresent". Here are the lines in the state file that have changed:


DSChange: 20220516021647 (Mon May 16 14:16:47 2022)
DSState: omnipresent

So my big question is this: Is it expected that the DSState won't change 
until 26 hours after the "rndc dnssec -checkds published" command is 
run? And if so why does it take so long?


Thanks,

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

Re: per record responses based on originating IP

[Nick Tait via bind-users]

On 13/05/22 09:02, Grant Taylor via bind-users wrote:

On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:

This sounds like exactly the sort of use case for Response Policy Zones:


How are you going to have RPZ return different addresses for different 
clients?  Are you suggesting use different RPZs with different 
contents for different clients?


Yes, although now that I think through the details it turns out to be 
much messier than I first thought, because there doesn't seem to be a 
way to specify "not" in the RPZ...


Also I should point out that I'm assuming that a PASSTHRU result in one 
RPZ will still result in subsequent RPZs being processed. I haven't 
actually tested this, so its possible I'm misunderstanding the 
documentation?


Anyway in the interests of following this all the way though, let's 
assume you had 3 clients and you wanted them to each receive a different 
answer to the query "www.example.com":


Suppose their IP addresses are:

   A = 192.0.2.10
   B = 192.0.2.20
   C = 192.0.2.30

Then, if I'm not mistaken, you could create 3 RPZ zones:

Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients B & C
   32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.1

Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients A & C
   32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.2

Zone file for "c.rpz.mylocaldomain.com" contains (in addition to SOA, etc):

   ; Don't overwrite the answer for queries received from clients A & B
   32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
   32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.

   ; Change the answer to the question www.example.com
   www.example.com IN A 10.0.0.3

And then configure BIND to use all three RPZs:

   response-policy {
    zone "a.rpz.mylocaldomain.com";
    zone "b.rpz.mylocaldomain.com";
    zone "c.rpz.mylocaldomain.com";
   };

Scalability is obviously a challenge with this particular solution! :-(

So on reflection, there are probably better solutions to the problem 
that you are trying to solve. Although I don't personally have 
experience with it, wonder if "dnsmasq" might do what you need?


Thanks,

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

Re: per record responses based on originating IP

[Nick Tait via bind-users]

On 13/05/2022 12:30 am, Angus Clarke wrote:
Does bind have some simple way to respond differently based on source 
address but on a per record basis? Or perhaps include a baseline zone 
in a view and separately include differences for that view - something 
like this perhaps?


Hi Angus.

This sounds like exactly the sort of use case for Response Policy Zones: 
https://bind9.readthedocs.io/en/v9_18_2/reference.html#response-policy-zone-rpz-rewriting


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

Re: Bind9 Server conflicts with docker0 interface

[Nick Tait via bind-users]

On 7/05/2022 1:38 am, Maurà cio Penteado via bind-users wrote:
I added the A-record "ns1  IN  A  172.17.0.1" to my zone-file as 
suggested and it seems that the order fixed the issue.

Now my Bind9 clients are getting ip 192.168.0.10 favorably.


Hi Mauricio.

I don't think anyone suggested that you add that address to your zone file?

My suggestion was to simply update the SOA serial number.

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

Re: Bind9 Server conflicts with docker0 interface

[Nick Tait via bind-users]

On 6/05/2022 7:51 am, Grant Taylor via bind-users wrote:

On my Bind9 server, I have the following zone-files:

forward.example.lan.db:
ns1     IN      A           192.168.0.10
ns1     IN          fe80::f21f:afff:fe5d:be90


I don't see the 2nd, Docker (?), address; 172.17.0.1, in the zone.  So 
if your client is still receiving that address in addition to the 
192.168.0.10 address, then something else is happening outside of BIND. 


Mauricio, was 172.17.0.1 in the zone file at any time in the past? 
Because if so, I'm betting that the problem is simply that after you 
removed it, you neglected to increment the SOA serial number? (In case 
you weren't aware the serial number needs to be increased every time you 
change the zone file.)


Can you please try updating the "1 ; Serial" line to "*2* ; Serial" as 
shown below:


$TTL    604800
@       IN      SOA     ns1.example.lan. hostmaster.example.lan. (
*2*         ; Serial
                        604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                        604800 )       ; Negative Cache TTL

Once you've done that, run "sudo rndc reload" on your the primary DNS 
server for the zone (or alternatively restart BIND), and see if that 
makes a difference?


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

Re: Bind and systemd-resolved

[Nick Tait via bind-users]

On 2/05/2022 8:13 pm, Reindl Harald wrote:

you want 127.0.0.1 act as your resolver no matter what


Well, not always... If your local BIND service isn't a recursive 
resolver


irrelevant in context of this topic and worth exactly the same as 
saying "if you don't use bind at all" and honestly i don't get why you 
responed to that thread nearly a week later at all


below again the thread start and it's irrelevant what can be in some 
completly different context when the problem here is systemd-resolved 


Here's a tip for you: Often different people have the same or similar 
problems, and so when answering a question on a mailing list from one 
person it is useful to not only address their specific situation, but 
also provide alternatives that may be applicable to the same problem in 
slightly different contexts. :-)


FWIW I personally avoid statements like "no matter what" because it 
makes an assumption that everyone has the same goal.


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

Re: Bind and systemd-resolved

[Nick Tait via bind-users]

On 1/05/2022 9:13 pm, Reindl Harald wrote:

Am 01.05.22 um 06:38 schrieb Nick Tait via bind-users:
I'm not 100% sure, but I wonder if disabling systemd-resolved may 
create issues if, for example, you are using netplan with 
systemd-networkd as the renderer? E.g. Will it still be possible to 
pick up DNS servers from IPv6 router advertisements?
pick up some nameservers from wherever is exactly what you *don't 
want* in case you have named running on your machine as resolver


you want 127.0.0.1 act as your resolver no matter what


Well, not always... If your local BIND service isn't a recursive 
resolver (e.g. because it is acting in a role of authoritative name 
server only), then you'd want to use a resolver on the network, which 
may be statically configured (e.g. in netplan configuration) or 
dynamically assigned (e.g. obtained from DHCP or IPv6 router 
advertisements).


I was merely offering an alternative/lower impact solution to solve the 
OP's question about how to get dig to not use 127.0.0.53 by default. It 
may not be the solution chosen by the OP (given their expressed distaste 
for systemd) but others following this thread may find it useful?


Thanks,

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

Confused by parental-source documentation

[Nick Tait via bind-users]

Hi list.

I've been reading the latest BIND9 documentation on the new DNSSEC 
features, and section 4.2.28.1 got me horribly confused:


   /The following options apply to DS queries sent to
   //|parental-agents|//:/

   /|parental-source|/

   /|parental-source|//determines which local source address, and
   optionally UDP port, is used to send parental DS queries. This
   address must appear in the secondary server’s
   //|parental-agents|//zone clause. This statement sets the
   //|parental-source|//for all zones, but can be overridden on a
   per-zone or per-view basis by including a
   //|parental-source|//statement within the //|zone|//or
   //|view|//block in the configuration file./

No matter how many times I read the sentence in blue font, I couldn't 
make sense of it...


I finally realised that the parental-source paragraph is almost 
identical to the documentation for notify-source:


   /|notify-source|/

   /|notify-source|//determines which local source address, and
   optionally UDP port, is used to send NOTIFY messages. This
   address must appear in the secondary server’s
   //|primaries|//zone clause or in an //|allow-notify|//clause.
   This statement sets the //|notify-source|//for all zones, but
   can be overridden on a per-zone or per-view basis by including a
   //|notify-source|//statement within the //|zone|//or
   //|view|//block in the configuration file./

And so I can only assume that the problematic sentence in 
parental-source (i.e. "/This address must appear in the secondary 
server’s //|parental-agents|//zone clause./") is a copy-paste error? If 
that is the case can the sentence please be removed from the documentation?


Or if I'm mistaken can anybody please give an example to explain what 
this is trying to say?


Thanks,

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

Re: Bind and systemd-resolved

[Nick Tait via bind-users]

Hi list.

I'm not 100% sure, but I wonder if disabling systemd-resolved may create 
issues if, for example, you are using netplan with systemd-networkd as 
the renderer? E.g. Will it still be possible to pick up DNS servers from 
IPv6 router advertisements?


A lower impact (and IMHO more future-proof) alternative to disabling 
systemd-resolved completely, is to simply turn off the stub resolver? 
That can be achieved by creating a file under 
/etc/systemd/resolved.conf.d (e.g. 00-local.conf) containing:


   [Resolve]
   DNSStubListener=no

BTW There are some other useful settings that can be configured here. 
Check out "man resolved.conf" for details. FWIW The configuration that I 
use contains:


   [Resolve]
   FallbackDNS=//
   DNSSEC=yes
   DNSStubListener=no

NB: After making changes to the configuration run "systemctl restart 
systemd-resolved". Use "resolvectl status" to see current settings.


Thanks,

Nick.


On 23/04/22 03:50, Ondřej Surý wrote:

I think you also might want to mask the service:

https://fedoramagazine.org/systemd-masking-units/

--
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 22. 4. 2022, at 17:20, Randy Bush  wrote:

   sudo systemctl disable systemd-resolved.service
   sudo service systemd-resolved stop
--
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