Changing DNS servers (name only) for a DNSSEC enabled domain

2023-02-13 Thread Danilo Godec via bind-users 

Hello,


in the near future I will have to change NS records for one of my 
domains, as DNS servers currently use an old domain (not mine), that 
will be phased out. DNS servers will actually remain the same, only the 
domain name will change.


So, basically:

 * mydomain currently uses dns1.olddomain, dns2.olddomain,
   dns3.olddomain, ...
 * dns*.olddomain are the same servers as dns*.newdomain
 * mydomain has to change DNS server to dns1.newdomain, dns2.newdomain,
   dns3.newdomain, ...



Since DNSSEC is enabled on mydomain, I've been reading some instructions 
about doing this with DNSSEC and they say:


1. Disable DNSSEC at Registrar
2. Wait 24 hours
3. Disable DNSSEC at Name Server (remove DS-records)
4. Switch name servers
5. Wait 24 hours
6. Re-enable DNSSEC


Is this really necessary in this case, changing only DNS server names? I 
would like to avoid changing DS records at the registrar level as they 
don't provide a 'self-service' interface for managing them, so I have to 
go though their support and that's usually tedious.


If that is necessary, why?


   Thanks, Danilo

PS: If it matters, this is (still) a manually DNSSEC'd domain.-- 
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: Master file permission denied

2023-06-28 Thread Danilo Godec via bind-users 

  
  
Hello,


I think 


  chmod ug+x /etc/bind/zonas/

should solve the issue by giving the
  owner (bind) and the group (bind) permissions to enter the
  directory.




  Danilo








On 28.6.2023 20:44, Daniel Armando
  Rodriguez via bind-users wrote:


  
  Before I start describing the problem, I should mention that
this incident started when I tried to enable DNSSEC. I
understand that it is unrelated, but previously everything was
working correctly.
  
  
  I'm using Debian 11 and Bind 9.18 from backports
   
  This is current config
   
  # named-checkconf -px
options {
    directory "/var/cache/bind/";
    listen-on  {
        127.0.0.1/32;
        170.210.45.130/32;
    };
    listen-on-v6  {
        2800:110:44:6260::130/128;
    };
    querylog yes;
    transfers-in 20;
    transfers-per-ns 20;
    version "Info not currently available";
    allow-recursion {
        "localhost";
        ::1/128;
        170.210.0.0/16;
        2800:110:44:6260::/64;
    };
    auth-nxdomain no;
    recursion yes;
    allow-query {
        "any";
    };
    allow-transfer  {
        "none";
    };
    key-directory "/var/cache/bind/keys";
    masterfile-format text;
};
statistics-channels {
    inet 127.0.0.1 port 8053 allow {
        127.0.0.1/32;
    };
};
zone "10.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "16.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "17.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "18.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "19.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "20.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "21.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "22.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "23.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "24.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "25.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "26.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "27.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "28.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "29.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "30.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "31.172.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.empty";
};
zone "unau.edu.ar" {
    type primary;
    file "/etc/bind/zonas/db.unau.edu.ar";
    allow-query {
        "any";
    };
    allow-transfer  {
        170.210.45.131/32;
    };
    allow-update {
        "none";
    };
    also-notify {
        170.210.45.131;
    };
    serial-update-method increment;
};
zone "133.45.210.170.in-addr.arpa" {
    type primary;
    file
  "/etc/bind/zonas/133.45.210.170.in-addr.arpa";
    allow-transfer  {
        170.210.45.131/32;
    };
    also-notify {
        170.210.45.131;
    };
};
zone
"3.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.2.6.4.4.0.0.0.1.1.0.0.0.8.2.ip6.arpa"
  {
    type primary;
    file
"/etc/bind/zonas/3.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.2.6.4.4.0.0.0.1.1.0.0.0.8.2.ip6.arpa";
    allow-transfer  {
        170.210.45.131/32;
    };
    also-notify {
        170.210.45.131;
    };
};
zone "." {
    type hint;
    file "/usr/share/dns/root.hints";
};

Problem resolving

2021-09-16 Thread Danilo Godec via bind-users 
Hello,


I recently stumbled upon a problem trying to update my root hints file
from *ftp.rs.internic.net*. For some reason, one of my DNS servers
running on Alpine Linux, can't resolve this name properly and always fails:

# ping ftp.rs.internic.net
ping: ftp.rs.internic.net: Try again

nslookup starts off fine, it prints the A record, but then it fails to:

# nslookup ftp.rs.internic.net
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
ftp.rs.internic.net canonical name = ftp.rs.verisigndns.com.
Name:   ftp.rs.verisigndns.com
Address: 69.58.179.79
** server can't find ftp.rs.verisigndns.com: SERVFAIL


It seems the problem is with  records, as apparently musl libc tries
to resolve both A and  record and fails if either of them are not
available. Unfortunately, I couldn't find a way to configure the musl
resolver not to try  records.

Digging a bit deeper I found out that these queries cause BIND to log
errors:

named[12737]: DNS format error from 185.100.2.22#53 resolving 
ftp.rs.verisigndns.com/ for 127.0.0.1#39521: Name rs.verisigndns.com (SOA) 
not subdomain of zone ftp.rs.verisigndns.com -- invalid response
named[12737]: DNS format error from 72.13.39.22#53 resolving 
ftp.rs.verisigndns.com/ for 127.0.0.1#39521: Name rs.verisigndns.com (SOA) 
not subdomain of zone ftp.rs.verisigndns.com -- invalid response
named[12737]: DNS format error from 69.36.158.22#53 resolving 
ftp.rs.verisigndns.com/ for 127.0.0.1#39521: Name rs.verisigndns.com (SOA) 
not subdomain of zone ftp.rs.verisigndns.com -- invalid response
named[12737]: DNS format error from 199.16.87.22#53 resolving 
ftp.rs.verisigndns.com/ for 127.0.0.1#39521: Name rs.verisigndns.com (SOA) 
not subdomain of zone ftp.rs.verisigndns.com -- invalid response


However, if I point the system resolver (or nslookup) to some other DNS
(my ISP's DNS, for examle), neither ping or nslookup fail.


Is there anything I can do on my BIND to make musl libc happy and not
fail in such a case?


 Thanks,

    Danilo


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CNAME query

2021-09-23 Thread Danilo Godec via bind-users 

Don't know if that helps, but if I query my local Bind DNS for a CNAME,
that doesn't exists, dig gives me the SOA record:


> dig cname nonexisting.example.com @mydns

; <<>> DiG 9.16.6 <<>> cname nonexisting.example.com @mydns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22683
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nonexisting.example.com. IN  CNAME

;; AUTHORITY SECTION:
example.com.  600 IN  SOA mydns.example.com. 
hostmaster.mydns.example.com. 2020042504 86400 3600 604800 604800

;; Query time: 0 msec
;; SERVER: mydns#53(mydns)
;; WHEN: thu sep 23 13:50:00 CEST 2021
;; MSG SIZE  rcvd: 100




Obviously I replaced my real domain with 'example.com'...



  Regards,

   Danilo






On 23. 09. 21 13:36, Sonal Pahuja wrote:
> Can some one please help me on this
> 
> *From:* Sonal Pahuja
> *Sent:* Thursday, September 23, 2021 10:26:48 AM
> *To:* bind-users@lists.isc.org 
> *Subject:* CNAME query
>  
>
> Hi All,
>
>  
>
> We are sending a CNAME query but currently we don’t have any CNAME
> record, just have NS info.
>
> What should be the Bind9 response for this CNAME query? Will it return
> NS Record in Authority/Answer section?
>
>  
>
> Regards,
>
> Sonal
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


-- 
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.go...@example.com  | T: +386
(0)2 421 61 31 | F: +386 (0)2 420 06 90
Agenda OpenSystems  | Največji slovenski
odprtokodni integrator
Red Hat v Sloveniji  | Red Hat Premier Business
Partner
ElasticBox  | Poslovne rešitve v oblaku
Agenda d.o.o. 
Izjava o omejitvi odgovornosti / Legal disclaimer statement


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Millions of './ANY/IN' queries denied

2021-12-15 Thread Danilo Godec via bind-users 
Hello,


I'm noticing some unusual activity where 48 external IPs generated over
2M queries that have all been denied (just today):

15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.123 security: info: client @0x7f9618019e20
45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
15-Dec-2021 00:01:42.127 security: info: client @0x7f96180b3fe0
45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied


I'm guessing this is some sort of an reflection attack attempt, but I
don't quite understand if these are the perpetrators or victims?

Would I be doing a bad thing by using fail2ban to block these IPs?


    Regards,

 Danilo


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNS cache poisoning - am I safe if I limit recursion to trusted local networks?

2021-12-29 Thread Danilo Godec via bind-users 

Hello,


I have an authoritative DNS server for a domain, but I was also going to 
use the same server as a recursive DNS for my internal network, limiting 
recursion by the IP. Apparently, this is a bad idea that can lead to 
cache poisoning...


After watching a Computerphile Youtube video 
(https://www.youtube.com/watch?v=7MT1F0O3_Yw) on that topic I have a 
rough understanding of how cache poisoning works, but it doesn't explain 
why limiting recursion to 'trusted' IP networks doesn't help.



Is it because with UDP IP's can be 'easily' spoofed and if someone 
guessed my internal network IPs and spoofed the IP, my DNS server would 
happily accept their requests? Or is it even wider than that?



    Danilo


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?

2021-12-30 Thread Danilo Godec via bind-users 

On 29. 12. 21 19:24, tale wrote:

On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users
 wrote:

I have an authoritative DNS server for a domain, but I was also going to
use the same server as a recursive DNS for my internal network, limiting
recursion by the IP. Apparently, this is a bad idea that can lead to
cache poisoning...

In short, no, this configuration with a BIND 9 server does not
increase your risk of cache poisoning any more than running your local
server in pure recursive mode.  I'm curious to hear more from the
source that has given you this impression.  I suspect there were some
additional qualifications that don't align with what you've described.

The source is a security audit report, claiming that using a single 
server for both authoritative (for public use) and recursive (limited to 
internal clients by means of 'allow-recursion' directive) roles 
increases the risk of DoS attacks and DNS cache poisoning... They 
mentioned CVE-2021-20322 that supposedly makes cache poisoning feasible 
(again) - that made them increase the concern level to a 'medium'.



While I understand how and why DoS and cache poisoning are bad, I don't 
understand how separating these two roles would help mitigate the risk.



Thanks for helping me understand,

  Danilo


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dnssec rookie question

2022-01-10 Thread Danilo Godec via bind-users 

Hello,


today I implemented DNSSEC for a domain - by that I mean that the DS 
records have been published / added to TLD DNS today, while the zone has 
been signed a couple of days ago.



So a couple of hours later I went to https://dnsviz.net to see if 
everything seems OK and it reports one error and a couple of warnings. 
The error is:



RRSIG sid.si/NSEC3PARAM alg 13, id 48018: The TTL of the RRset (3600) exceeds 
the value of the Original TTL field of the RRSIG RR covering it (0).


But if I use /dig/ for, I get this:

;; ANSWER SECTION:
sid.si. 3600IN  NSEC3PARAM 1 0 10 -
sid.si. 3600IN  RRSIG   NSEC3PARAM 13 2 0 
20220205091303 20220106091303 48018 sid.si. 
WVstsjBLSQNS+PaKbR3LAAALG7tlV+cuzLYUKgWDXKrFnxe+dxx5Tmsa 
pYIrabwi/sANBgEBMHtW1Z3NS7hRow==


Both records show TTL 3600 - which should be OK, I think? Where does 
dnsviz.net get that TTL 0?





The warnings are:

sid.si/DS (alg 13, id 12603): DNSSEC specification prohibits signing with DS 
records that use digest algorithm 1 (SHA-1).

sid.si/DS (alg 13, id 12603): DNSSEC specification prohibits signing with DS 
records that use digest algorithm 1 (SHA-1).

sid.si/DS (alg 13, id 12603): DS records with digest type 1 (SHA-1) are ignored 
when DS records with digest type 2 (SHA-256) exist in the same RRset.

sid.si/DS (alg 13, id 12603): DS records with digest type 1 (SHA-1) are ignored 
when DS records with digest type 2 (SHA-256) exist in the same RRset.


This is probably due to the fact that Bind version included in CentOS 8 
/dnssec-signzone/ creates two 'digests' in the /dsset/ file (sha-1 and 
sha-256 - which is what I've sent to the domain registrar to include), 
while newer Bind versions only create one...



Is including SHA-1 bad in some way? Should I change that?



  Thanks,

 Danilo
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Changing the DNSSEC algorithm

2022-04-05 Thread Danilo Godec via bind-users 

Hello,


I implemented DNSSEC for my personal domain a good while ago with an 
older Bind and back then, I used RSASHA1-NSEC3-SHA1 algorithm, which by 
now is not recommended... So I'm going to change the algorithm, probably 
to ECDSAP256SHA256, which should also be NSEC3 capable.


Since my domain is small and rarely changes, I'm not using any fancy 
updating features - I manage it manually, by editing the non-signed 
version of the zone file and then signing it to create a signed version.



Here I'd like to verify that I understand the steps required to change 
DNSEC key / algorithm without disruption:



1. create new keys for my zone

 * dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain
 * dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain


2. include new keys in my zone while keeping old keys too:

    $INCLUDE Kmydomain.+008+14884.key <- old key
    $INCLUDE Kmydomain.+008+27618.key <- old key
    $INCLUDE Kmydomain.+013+10503.key <- new key
    $INCLUDE Kmydomain.+013+39532.key <- new key


3. sign the zone file

    /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | 
sha1sum | cut -b 1-16) -e +3024000 -o mydomain -t mydomain.hosts



4. ask the registrar to add new DS record to TLD (I have to do this by 
mail, there is no 'self-service' UI)


5. wait at least one TTL (making sure to use the longest TTL in my zone)

6. ask the registrar to remove old DS record(s) (I don't quite remember 
why, but I had two)


7. wait another TTL period

8. remove old keys from zone

9. re-sign the zone


Will that be OK?


   Best regards,

 Danilo

-- 
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: Changing the DNSSEC algorithm

2022-04-06 Thread Danilo Godec via bind-users 

On 6.4.2022 8:52, Daniel Stirnimann wrote:

Hello Danilo,

A simple schema to change DNSSEC algorithms is as follows:

1. Add new KSK/ZSK and double sign DNSKEY and all zone RRs
with both the new and old algorithm
2. Replace DS at parent
3. Remove old DNSKEY and all RRSIGs from the old algorithm

Before step 2 wait the max zone TTL to expire.
Before step 3 wait the DS TTL to expire.


Here I'd like to verify that I understand the steps required to change
DNSEC key / algorithm without disruption:


1. create new keys for my zone

   * dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain
   * dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain


2. include new keys in my zone while keeping old keys too:

     $INCLUDE Kmydomain.+008+14884.key <- old key
     $INCLUDE Kmydomain.+008+27618.key <- old key
     $INCLUDE Kmydomain.+013+10503.key <- new key
     $INCLUDE Kmydomain.+013+39532.key <- new key


Looks good to me.



3. sign the zone file

     /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum
| cut -b 1-16) -e +3024000 -o mydomain -t mydomain.hosts


Not related to the algorithm rollover but you may want to reconsider the
use of NSEC3 using opt-out, the use of NSEC3 salt or the use of NSEC3
all together. Please have a look at:

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance

This is currently an IETF dnsop working group document.



4. ask the registrar to add new DS record to TLD (I have to do this by
mail, there is no 'self-service' UI)


As you use a Double-Signature [1] KSK roll, you can replace the DS
record in a single step. While your procedure does not break anything it
does not need to be more complicated then necessary. You description is
a mix of the Double-Singature / Double-DS KSK rollover.

I would suggest you go directly to step 5 instead and in step 6 you
*replace* the DS record.



5. wait at least one TTL (making sure to use the longest TTL in my zone)

6. ask the registrar to remove old DS record(s) (I don't quite remember
why, but I had two)


As mentioned above, in step 6 you can *replace* the DS record.



7. wait another TTL period


You need to wait at least for the DS TTL to expire.



8. remove old keys from zone

9. re-sign the zone


Looks good to me.


Daniel


[1] https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.2



Thank you, it seems I was close enough (it would've worked).


I read the draft-ietf-dnsop-nsec3-guidance and while it's a bit above my 
level of understanding, I think the gist is that one should not use 
'advanced' NSEC3 features like iterations and salt - achieved by setting 
NSEC3PARAM to 1 0 0 - .



    Regards,
  Danilo


--
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: Changing the DNSSEC algorithm

2022-04-06 Thread Danilo Godec via bind-users 

  
  

  I read several articles regarding algorithm rollover,
including:
  * https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
  *
https://downloads.isc.org/isc/bind9/9.16.6/doc/arm/html/advanced.html#dnssec-dynamic-zones-and-automatic-signing
  
  Unfortunately I can't find all of them in my browser history...
  
  
  
  For re-signing I have a Bash script running once a month
through cron.
  
  
  
  With only a few zones to manage I think I'll stick with the
simple way of editing them by hand.
  
  
   Thanks for your thoughts,
  

    Danilo




On 6.4.2022 13:18, Petr Menšík wrote:


  
  Hi Danilo,
  I think the way you have describe should work. But can I ask
what source this recipe has? I have seen recently similar
signing in one of our test. I guess this should be from public
recipe. Would you share its origin, please?
  
  I would recommend having DNS server do the job of maintaining
signatures. If you do it this way manually, you have to resign
your zone each time your signatures expire. Do you have set some
kind of reminder to remind you?
  I would try DNSSEC guide [1] with bind 9.16 or more recent. It
provides a policy inside named. It depends on what version do
you have. Even 9.11 can maintain signatures [2] and resign them,
but the process is more complicated. You would have to just
regenerate keys, otherwise it will maintain your signatures. But
yes, it won't be able to edit zone file by hand this way.
  Read dnssec-settime manual page and way to set times, when each
key should be activated or deactivated. It should be more safe
if done the right way. You can use dnssec-signzone -S to use
smart signing and then omit step 2. Just provide correct
directory to keys. But I admit it might be simpler to do it
manually if you would upgrade just single zone, which has no
high impact in case of error.
  Btw. it seems really clumsy to read 1000 characters from proper
entropy source and then use just 16 hexcoded chars from it.
/dev/urandom might be better source and 16 bytes should be
enough.
  Regards,
Petr
  
  1. https://bind9.readthedocs.io/en/v9_16_27/dnssec-guide.html
  2.
https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones
  
  On 4/5/22 09:07, Danilo Godec via
    bind-users wrote:
  
  
Hello,


I implemented DNSSEC for my personal domain a good while ago
  with an older Bind and back then, I used RSASHA1-NSEC3-SHA1
  algorithm, which by now is not recommended... So I'm going to
  change the algorithm, probably to ECDSAP256SHA256, which
  should also be NSEC3 capable.
Since my domain is small and rarely changes, I'm not using
  any fancy updating features - I manage it manually, by editing
  the non-signed version of the zone file and then signing it to
  create a signed version.


Here I'd like to verify that I understand the steps required
  to change DNSEC key / algorithm without disruption:


1. create new keys for my zone

  dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain
  dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain



2. include new keys in my zone while keeping old keys too:

    $INCLUDE Kmydomain.+008+14884.key <- old key
      $INCLUDE Kmydomain.+008+27618.key <- old key
      $INCLUDE Kmydomain.+013+10503.key <- new key
      $INCLUDE Kmydomain.+013+39532.key <- new key


3. sign the zone file
    /usr/sbin/dnssec-signzone -A -3 $(head -c 1000
  /dev/random | sha1sum | cut -b 1-16) -e +3024000 -o mydomain
  -t mydomain.hosts


4. ask the registrar to add new DS record to TLD (I have to
  do this by mail, there is no 'self-service' UI)
5. wait at least one TTL (making sure to use the longest TTL
  in my zone)
6. ask the registrar to remove old DS record(s) (I don't
  quite remember why, but I had two)
7. wait another TTL period
8. remove old keys from zone
9. re-sign the zone



Will that be OK?


   Best regards,
 Danilo




  
  -- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...

CDNSKEY / CDS for key is now published - but why?

2024-10-02 Thread Danilo Godec via bind-users 

Hi all,

yesterday I filled my day fiddling with DNSSEC for a couple of my test 
domains - both have been signed 'manually' before, but I haven't 
published the DS record.



So yesterday I setup both for dnssec-policy, while also changing the 
signing algorithm and keys (basically started from scratch):


dnssec-policy "nsec3_no_rotate" {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime unlimited algorithm 13;
};
nsec3param iterations 0 optout false;
};

...

    zone "sociopat.si" {
    type master;
    file "master/Danci/sociopat.si.hosts";
    key-directory "master/Danci/keys";
    dnssec-policy "nsec3_no_rotate";
    inline-signing yes;
    };

    zone "psihopat.si" {
    type master;
    file "master/Danci/psihopat.si.hosts";
    key-directory "master/Danci/keys";
    dnssec-policy "nsec3_no_rotate";
    inline-signing yes;
    };
...


I published DS records through my registrar and after a couple of hours 
all seemed fine - both Verisign dnssec-analyzer and DNSViz show no 
errors or warnings for them.



However, today bind logged this:

named[17379]: general: info: CDNSKEY for key sociopat.si/ECDSAP256SHA256/61220 
is now published
named[17379]: general: info: CDS for key sociopat.si/ECDSAP256SHA256/61220 is 
now published


I'm pretty sure this is not bad or wrong, but I would like to sort-of 
understand, why Bind decided it needs to publish CDS / CDNSKEY for this 
one and not the other one, given that DS records are published in ccTLDs:


# dig ds sociopat.si
;; QUESTION SECTION:
;sociopat.si.   IN  DS

;; ANSWER SECTION:
sociopat.si.5826IN  DS  61220 13 2 
D8C1553B3D6BCF7A704A3D821069F57B6946DCA1D198D303E3B4C730 616F92AD


# dig ds psihopat.si

;; QUESTION SECTION:
;psihopat.si.   IN  DS

;; ANSWER SECTION:
psihopat.si.7200IN  DS  7162 13 2 
3C5A5625F848DBCF99A0B85017AFE04FD1F681037B61BE970D57AE9F 90F21CD8


Also, as far as I know, .si DNS servers don't support CDS / CDNSKEY, so 
publishing them might be futile.



  Regards,

   Danilo

-- 
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: CDNSKEY / CDS for key is now published - but why?

2024-10-02 Thread Danilo Godec via bind-users 

Hi Greg,

thanks for the answer.

I knew that CDS and CDNSKEY are just in my own zone and (as far as I 
understand), serve to inform the parent DNS about (upcoming?) changes in 
DS / DNSKEY records. I'm not quite sure about establishing the initial 
trust with the parent, but as our ccTLD parent DNS doesn't support CDS / 
CDNSKEY it's not a big deal anyway.



What I don't understand is why Bind published CDS / CDNSKEY just for one 
of two very similar domains? Initially I thought that Bind checks the DS 
on the parent and only publishes CDS / CDNSKEY if DS doesn't exist or is 
in some way different.




   Regards,

    Danilo



On 2. 10. 24 12:19, Greg Choules wrote:

Hi Danilo.
The CDS and CDNSKEY are published in your own zone, not anywhere else. 
You can confirm this by doing a dig for them directly, or AXFR if you 
permit transfers on your server.


They are intended for use with registrars that *do* support automatic 
DS creation using one of them. If yours doesn't and you already 
published your DS in the parent, then no big deal. The CDS and CDNSKEY 
will just sit in your zone and you don't have to do anything with them.


Does that help?
Cheers, Greg

On Wed, 2 Oct 2024 at 10:58, Danilo Godec via bind-users 
 wrote:


Hi all,

yesterday I filled my day fiddling with DNSSEC for a couple of my
test domains - both have been signed 'manually' before, but I
haven't published the DS record.


So yesterday I setup both for dnssec-policy, while also changing
the signing algorithm and keys (basically started from scratch):

dnssec-policy "nsec3_no_rotate" {
 keys {
 ksk key-directory lifetime unlimited algorithm 13;
 zsk key-directory lifetime unlimited algorithm 13;
 };
 nsec3param iterations 0 optout false;
};

...

     zone "sociopat.si  <http://sociopat.si>" {
     type master;
     file "master/Danci/sociopat.si.hosts";
     key-directory "master/Danci/keys";
     dnssec-policy "nsec3_no_rotate";
     inline-signing yes;
     };

     zone "psihopat.si  <http://psihopat.si>" {
     type master;
     file "master/Danci/psihopat.si.hosts";
     key-directory "master/Danci/keys";
     dnssec-policy "nsec3_no_rotate";
     inline-signing yes;
     };
...


I published DS records through my registrar and after a couple of
hours all seemed fine - both Verisign dnssec-analyzer and DNSViz
show no errors or warnings for them.


However, today bind logged this:

named[17379]: general: info: CDNSKEY for keysociopat.si/ECDSAP256SHA256/61220  
<http://sociopat.si/ECDSAP256SHA256/61220>  is now published
named[17379]: general: info: CDS for keysociopat.si/ECDSAP256SHA256/61220  
<http://sociopat.si/ECDSAP256SHA256/61220>  is now published


I'm pretty sure this is not bad or wrong, but I would like to
sort-of understand, why Bind decided it needs to publish CDS /
CDNSKEY for this one and not the other one, given that DS records
are published in ccTLDs:

# dig dssociopat.si  <http://sociopat.si>
;; QUESTION SECTION:
;sociopat.si  <http://sociopat.si>.   IN  DS

;; ANSWER SECTION:
sociopat.si  <http://sociopat.si>.5826IN  DS  61220 
13 2 D8C1553B3D6BCF7A704A3D821069F57B6946DCA1D198D303E3B4C730 616F92AD


# dig dspsihopat.si  <http://psihopat.si>

;; QUESTION SECTION:
;psihopat.si  <http://psihopat.si>.   IN  DS

;; ANSWER SECTION:
psihopat.si  <http://psihopat.si>.7200IN  DS  7162 
13 2 3C5A5625F848DBCF99A0B85017AFE04FD1F681037B61BE970D57AE9F 90F21CD8


Also, as far as I know, .si DNS servers don't support CDS /
CDNSKEY, so publishing them might be futile.


  Regards,

   Danilo


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




Lep pozdrav / Best regards,
--
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.go...@agenda.si | T: +386 (0)2 421 61 31
Agenda OpenSystems <https://www.agenda.si/> | Največji slovenski 
odprtokodni integrator
Red Hat v Sloveniji <http://www.redhat.si/> | Red Hat Premier Business 
Partne

DS digest type(s)

2024-10-16 Thread Danilo Godec via bind-users 

Hi,


I've been doing some more reading into DNSSEC and if I understand 
correctly, it is allowed to have multiple DS records for one KSK - with 
different digest types. Apparently, SHA-1 is deprecated and shouldn't be 
used anymore, while SHA-256 is mandatory and has to exist.


That leaves SHA-384, which is optional and I can generate manually with 
'dnssec-dsfromkey'. Since I have to ask my registrar to add DS records 
to parent zones (.eu in this case), I can just send them both records, 
right?



Is it also possible to have dnssec-policy to generate both digest types 
as CDS records?



    Regards,

    Danilo


--
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: DS digest type(s)

2024-10-16 Thread Danilo Godec via bind-users 


I've been looking at RFC8624 and there is no mention of SHA-512 - just this:

   ++-+---+---+
   | Number | Mnemonics   | DNSSEC Delegation | DNSSEC Validation |
   ++-+---+---+
   | 0  | NULL (CDS only) | MUST NOT [*]  | MUST NOT [*]  |
   | 1  | SHA-1   | MUST NOT  | MUST  |
   | 2  | SHA-256 | MUST  | MUST  |
   | 3  | GOST R 34.11-94 | MUST NOT  | MAY   |
   | 4  | SHA-384 | MAY   | RECOMMENDED   |
   ++-+---+---+


Are there any newer RFCs or guidelines regarding DNSSEC algorithms?


   Danilo




On 16. 10. 24 14:15, Robert Wagner wrote:
Our preference would be to at least allow SHA-384 and SHA-512 per the 
CNSA 2.0 requirements: CSA_CNSA_2.0_ALGORITHMS_.PDF (defense.gov) 
<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF> 




My understanding is this will be the base requirement for all US 
Government cryptography.



RW


*From:* bind-users  on behalf of 
Danilo Godec via bind-users 

*Sent:* Wednesday, October 16, 2024 8:00 AM
*To:* bind-users@lists.isc.org 
*Subject:* DS digest type(s)
This email originated from outside of TESLA

Do not click links or open attachments unless you recognize the sender 
and know the content is safe.


Hi,


I've been doing some more reading into DNSSEC and if I understand
correctly, it is allowed to have multiple DS records for one KSK - with
different digest types. Apparently, SHA-1 is deprecated and shouldn't be
used anymore, while SHA-256 is mandatory and has to exist.

That leaves SHA-384, which is optional and I can generate manually with
'dnssec-dsfromkey'. Since I have to ask my registrar to add DS records
to parent zones (.eu in this case), I can just send them both records,
right?


Is it also possible to have dnssec-policy to generate both digest types
as CDS records?


 Regards,

 Danilo


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




Lep pozdrav / Best regards,
--
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.go...@agenda.si | T: +386 (0)2 421 61 31
Agenda OpenSystems <https://www.agenda.si/> | Največji slovenski 
odprtokodni integrator
Red Hat v Sloveniji <http://www.redhat.si/> | Red Hat Premier Business 
Partner

ElasticBox <http://elasticbox.eu/> | Poslovne rešitve v oblaku
Agenda d.o.o. <https://www.agenda.si/>
Izjava o omejitvi odgovornosti / Legal disclaimer statement 
<https://www.agenda.si/index.php?id=228>
-- 
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: DS digest type(s)

2024-10-17 Thread Danilo Godec via bind-users 

Thanks,


now that I know what to look for, I found the docs for it.


Maybe worth mentioning that /cds-digest-types/ is not available in 
9.18.x, as it has been introduced in 9.19.11.




   Danilo



On 16. 10. 24 23:24, Mark Andrews wrote:



On 16 Oct 2024, at 23:00, Danilo Godec via bind-users 
wrote:

Hi,


I've been doing some more reading into DNSSEC and if I understand correctly, it 
is allowed to have multiple DS records for one KSK - with different digest 
types. Apparently, SHA-1 is deprecated and shouldn't be used anymore, while 
SHA-256 is mandatory and has to exist.

That leaves SHA-384, which is optional and I can generate manually with 
'dnssec-dsfromkey'. Since I have to ask my registrar to add DS records to 
parent zones (.eu in this case), I can just send them both records, right?


Is it also possible to have dnssec-policy to generate both digest types as CDS 
records?

cds-digest-types { "sha-256"; "sha-384"; };


 Regards,

 Danilo


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




Lep pozdrav / Best regards,
--
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.go...@agenda.si | T: +386 (0)2 421 61 31
Agenda OpenSystems <https://www.agenda.si/> | Največji slovenski 
odprtokodni integrator
Red Hat v Sloveniji <http://www.redhat.si/> | Red Hat Premier Business 
Partner

ElasticBox <http://elasticbox.eu/> | Poslovne rešitve v oblaku
Agenda d.o.o. <https://www.agenda.si/>
Izjava o omejitvi odgovornosti / Legal disclaimer statement 
<https://www.agenda.si/index.php?id=228>
-- 
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: CDNSKEY / CDS for key is now published - but why?

2024-10-02 Thread Danilo Godec via bind-users 

Hi Matthijs,


thanks,  that explains a bunch.

I checked both domain with '/rndc dnssec -status/' and they do show 
different states:


# rndc dnssec -status psihopat.si
dnssec-policy: nsec3_no_rotate
current time:  Wed Oct  2 14:25:31 2024

key: 37651 (ECDSAP256SHA256), ZSK
  published:  yes - since Tue Oct  1 20:23:24 2024
  zone signing:   yes - since Tue Oct  1 20:23:24 2024

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
*- zone rrsig: rumoured*

key: 7162 (ECDSAP256SHA256), KSK
  published:  yes - since Tue Oct  1 20:23:24 2024
  key signing:yes - since Tue Oct  1 20:23:24 2024

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
*- ds: hidden*
  - key rrsig:  omnipresent


# rndc dnssec -status sociopat.si
dnssec-policy: nsec3_no_rotate
current time:  Wed Oct  2 14:25:34 2024

key: 17354 (ECDSAP256SHA256), ZSK
  published:  yes - since Tue Oct  1 10:09:53 2024
  zone signing:   yes - since Tue Oct  1 10:09:53 2024

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - zone rrsig: omnipresent

key: 61220 (ECDSAP256SHA256), KSK
  published:  yes - since Tue Oct  1 10:09:53 2024
  key signing:yes - since Tue Oct  1 10:09:53 2024

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
*- ds: rumoured*
  - key rrsig:  omnipresent


So I ran /rndc dnssec -checkds published**/for both zones:

# rndc dnssec -checkds published sociopat.si
Marked DS as published since 02-Oct-2024 14:33:33.000

# rndc dnssec -checkds published legenda.si
Marked DS as published since 02-Oct-2024 14:33:47.000

That changed KSK DS state from *hidden* to *rumoured* for psihopat.si, 
but made no change to sociopat.si.



Should the change be immediate or is it also TTL dependent?



   Regards,

   Danilo




On 2. 10. 24 13:10, Matthijs Mekking wrote:

Hi Danilo,

When you enable DNSSEC for the first time, first the DNSKEY and the 
signatures need to be introduced in the zone, and propagated to the 
world. The propagation depends on the TTL values, and these are 
derived from the dnssec-policy configuration. By default it takes more 
than a day because of max-zone-ttl is set to 86400.


Only then it is fully safe to publish the DS, so at that point BIND 
will publish the CDS/CDNSKEY records.


Note that this long delay is only when you enable DNSSEC, key 
rollovers only need to take the DNSKEY TTL into account (plus some 
safety and propagation values).


So you submitted the DS too soon. Luckily the delay on the first sign 
is pretty conservative and your zones appear to be fine after 
publishing the DS. But in an automated way (CDS polling), the DS would 
have been submitted later than you did.


Three more comments:


1.
> I thought that Bind checks the DS on the parent and only publishes 
CDS > / CDNSKEY if DS doesn't exist or is in some way different.


No. The CDS/CDNSKEY RRset is published and won't be removed from the 
zone.


The RFC says that when the Parent DS is in sync with the CDS/CDNSKEY 
RRset, the Child DNS Operator MAY delete the CDS/CDNSKEY RRset.


We chose not to do so, because it can be handy to see what the DS 
records in the parent should be given what CDS/CDNSKEY RRset is 
published in the child zone.



2.
Depending on your configuration, BIND will check if the DS is actually 
in the parent zone. If it does not, you have to check it manually and 
tell BIND with the 'rndc dnssec -checkds' command. Otherwise, the DS 
may stay in the "Rumoured" state indefinitely, and this can influence 
future key rollovers.



3.
You can use the options 'cds-digest-types' and 'cdnskey' to set what 
RRsets need to be published.



Hope this helps, best regards,

Matthijs


On 10/2/24 12:42, Danilo Godec via bind-users wrote:

Hi Greg,

thanks for the answer.

I knew that CDS and CDNSKEY are just in my own zone and (as far as I 
understand), serve to inform the parent DNS about (upcoming?) changes 
in DS / DNSKEY records. I'm not quite sure about establishing the 
initial trust with the parent, but as our ccTLD parent DNS doesn't 
support CDS / CDNSKEY it's not a big deal anyway.



What I don't understand is why Bind published CDS / CDNSKEY just for 
one of two very similar domains? Initially I thought that Bind checks 
the DS on the parent and only publishes CDS / CDNSKEY if DS doesn't 
exist or is in some way different.




    Regards,

 Danilo



On 2. 10. 24 12:19, Greg Choules wrote:

Hi Danilo.
The CDS and CDNSKEY are published in your own zone, not anywhere 
else. You can confirm this by doing a dig for them directly, or AXFR 
if you permit transfers on your server.


They are intended for use with registrars that *do* support 
automatic DS creation using one of them. If yours doesn't and you 
already published your DS in the pa

Re: CDNSKEY / CDS for key is now published - but why?

2024-10-03 Thread Danilo Godec via bind-users 

Thanks,

so patience is really the name of the game here. )


One more question, if I may - I noticed that the serial number in signed 
zone gets 'out-of-sync' compared to my source text zone file. I guess 
that happens when Bind publishes CDS / CDNSKEY records etc.


Is the serial number in my source text zone file still relevant? If it 
is, I suppose increasing it by one is no longer good enough - I probably 
need to check the actual SOA and then use that as 'base' and increase 
that by 1, right?



   Regards,

    Danilo




On 2. 10. 24 15:13, Matthijs Mekking wrote:

Hi,

The change from rumoured to omnipresent is TTL dependent. To be 
precise: it is the sum of the configured parent-ds-ttl, 
parent-propagation-delay, and retire-safety.


- Matthijs

On 10/2/24 14:55, Danilo Godec via bind-users wrote:

Hi Matthijs,


thanks,  that explains a bunch.

I checked both domain with '/rndc dnssec -status/' and they do show 
different states:


# rndc dnssec -status psihopat.si
dnssec-policy: nsec3_no_rotate
current time:  Wed Oct  2 14:25:31 2024

key: 37651 (ECDSAP256SHA256), ZSK
   published:  yes - since Tue Oct  1 20:23:24 2024
   zone signing:   yes - since Tue Oct  1 20:23:24 2024

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
*- zone rrsig: rumoured*

key: 7162 (ECDSAP256SHA256), KSK
   published:  yes - since Tue Oct  1 20:23:24 2024
   key signing:    yes - since Tue Oct  1 20:23:24 2024

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
*- ds: hidden*
   - key rrsig:  omnipresent


# rndc dnssec -status sociopat.si
dnssec-policy: nsec3_no_rotate
current time:  Wed Oct  2 14:25:34 2024

key: 17354 (ECDSAP256SHA256), ZSK
   published:  yes - since Tue Oct  1 10:09:53 2024
   zone signing:   yes - since Tue Oct  1 10:09:53 2024

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
   - zone rrsig: omnipresent

key: 61220 (ECDSAP256SHA256), KSK
   published:  yes - since Tue Oct  1 10:09:53 2024
   key signing:    yes - since Tue Oct  1 10:09:53 2024

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
*- ds: rumoured*
   - key rrsig:  omnipresent


So I ran /rndc dnssec -checkds published**/for both zones:

# rndc dnssec -checkds published sociopat.si
Marked DS as published since 02-Oct-2024 14:33:33.000

# rndc dnssec -checkds published legenda.si
Marked DS as published since 02-Oct-2024 14:33:47.000

That changed KSK DS state from *hidden* to *rumoured* for 
psihopat.si, but made no change to sociopat.si.



Should the change be immediate or is it also TTL dependent?



    Regards,

    Danilo


--
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: Zones list mask or wildcard

2024-12-04 Thread Danilo Godec via bind-users 
If nothing else works, you can always 'include' a file that contains 
configuration stanzas of those zones and then use a script to add new 
zone stanzas to the file.


# Include config file with thousands of domains
include "/etc/named.d/1000s_domains.conf";



The script could either recreate the whole file every time or it could 
be a bit clever and check if there are new zone files and only add those 
and remove those that have been removed.



This is probably 30-45 minutes worth of Bash scripting for the first 
working prototype and then a couple of hours refining - adding error 
checking, logging, notifications, etc.



  D.





On 27. 11. 24 12:19, Dimitry Bansikov wrote:
As I wrote earlier, I have 1000 different zones for domains. And to 
add a new zone or delete an old one, I have to change a file with a 
large list of lines "zone domain IN {...};".


I need to simplify adding and removing a domain so that it is enough 
to just add the zone file itself whitout editing the big list. Is this 
possible? There are simpler options?






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

Problem resolving a domainkey TXT record

2024-12-13 Thread Danilo Godec via bind-users 

Hello,


I recently noticed that emails from somewhat trustworthy organization 
don't have a valid DKIM signature - or rather, my email client can't 
verify them, because there is a timeout resolving the domainkey record.



Testing this with 'dig' confirms the problem:


dig txt eulisa._domainkey.eulisa.europa.eu

;; communications error to 172.16.0.35#53: timed out

; <<>> DiG 9.18.28 <<>> txt eulisa._domainkey.eulisa.europa.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55417
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d6eea8bdf879508b0100675c30a8e779768fc9685289 (good)
;; QUESTION SECTION:
;eulisa._domainkey.eulisa.europa.eu. IN TXT

;; Query time: 4992 msec
;; SERVER: 172.16.0.35#53(172.16.0.35) (UDP)
;; WHEN: Fri Dec 13 14:03:36 CET 2024
;; MSG SIZE  rcvd: 91


However, resolving other TXT records for the domain works normally:


dig txt eulisa.europa.eu


; <<>> DiG 9.18.28 <<>> txt eulisa.europa.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35151
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 1c40aaf791d3d85d0100675c30c1a34364fc3a09684c (good)
;; QUESTION SECTION:
;eulisa.europa.eu.  IN  TXT

;; ANSWER SECTION:
eulisa.europa.eu.   300 IN  TXT "MS=ms83963822"
eulisa.europa.eu.   300 IN  TXT "v=spf1 mx ip4:195.80.109.244 
ip4:195.80.109.246 ip4:185.78.44.242 ip4:185.78.44.243 ip4:185.7.39.180 ip4:213.32.127.167 
ip4:213.32.127.168" " ip4:51.254.189.37 ip4:194.126.110.37 ip4:212.234.189.164 
a:smtp-out.fingerprint.fr include:_spf.tech.ec.europa.eu include:spf.protection.outlook.com 
-all"
eulisa.europa.eu.   300 IN  TXT 
"atlassian-domain-verification=IAbzEpJrPKAGpbastIH07G8kB/zM1meGcRNejgMYZsby1d0k7VwnPjDu6eGVLbqT"
eulisa.europa.eu.   300 IN  TXT "MS=ms12401514"
eulisa.europa.eu.   300 IN  TXT 
"apple-domain-verification=z8I34fLchFm3RjgN"

;; Query time: 204 msec
;; SERVER: 172.16.0.35#53(172.16.0.35) (UDP)
;; WHEN: Fri Dec 13 14:04:01 CET 2024
;; MSG SIZE  rcvd: 593


I tried resolving the domainkey with Google and other DNSs and it seems 
to work.


As far as I could find so far, the problem manifests itself only on my 
location, where I have three named servers - two are version 9.18.28 
while one is 9.16.37. I also have a 4th one on a different location and 
it's even older (9.11.4), but this one does resolve the domain key:



dig txt eulisa._domainkey.eulisa.europa.eu @dns4.elasticbox.eu


; <<>> DiG 9.18.28 <<>> txt eulisa._domainkey.eulisa.europa.eu 
@dns4.elasticbox.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9239
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2b312991c2683e34f941a13f675c47654032168d65401367 (good)
;; QUESTION SECTION:
;eulisa._domainkey.eulisa.europa.eu. IN TXT

;; ANSWER SECTION:
eulisa._domainkey.eulisa.europa.eu. 3462 IN TXT "v=DKIM1;  
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1XVPzcIhCuMinLW2oceuhuqpGRxpX3koW2cV7ZGUzCnO+G0Xw6611ZMLT+Sk6313k0zVbwsL8Fnrbt+guvdqzx3Zh23chNZ24+ExN8Fhlb7XK0F7PqEH7pdJ1GAuraBJQmNviPiV64epsYu5gbiP8Aol16AcTCw1UvAG8xD4gQL2bXg52i5ucq2pRhEd9jbz1nc6gLA"
 
"tcTwlSWVjlw6gu0+FzQ3DvhoCeMR8u6uOZx1GyWMX0YZRXEm9s8a2A1+mlD9l7+ypQWsyl1RiOI/RV5druI3mEuxPn1/pzyO7bbroZXcFOjz4B5Z9iRqtXoEZRhYIS8zScCKy+k8T8gGyWwIDAQAB;"

;; AUTHORITY SECTION:
eulisa.europa.eu.   3462IN  NS  nssxb.eulisa.europa.eu.
eulisa.europa.eu.   3462IN  NS  nstll.eulisa.europa.eu.

;; ADDITIONAL SECTION:
nstll.eulisa.europa.eu. 3462IN  A   194.126.110.49
nssxb.eulisa.europa.eu. 3462IN  A   212.234.189.180

;; Query time: 40 msec
;; SERVER: 54.229.229.105#53(dns4.elasticbox.eu) (UDP)
;; WHEN: Fri Dec 13 15:40:38 CET 2024
;; MSG SIZE  rcvd: 582


That implies that this might be a network problem, but since all servers 
have a public IP and no NAT, I really cant's imagine why or how.


What diagnostic steps can I do get a better idea of what's going on with 
these queries as far as named is concerned?



  Thanks,

    Danilo



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

OPENSSL_FORCE_FIPS_MODE variable causes OpenSSL errors when running named commands

2025-01-20 Thread Danilo Godec via bind-users 

Hello,


I'm running bind 9.18.28 on OpenSuSE Leap 15.6. I also run 'certbot' 
with some home-brewed scripts for DNS validation.


Something happened between January 6th and yesterday that caused 
'certbot' renewals to fail with OpenSSL errors:


tls.c:90:tls_initialize(): fatal error: 
RUNTIME_CHECK(OPENSSL_init_ssl(OPENSSL_INIT_ENGINE_ALL_BUILTIN | 
OPENSSL_INIT_LOAD_CONFIG, NULL) == 1) failed
Aborted (core dumped)


Digging deeper I found out that 'certbot' defines several environment 
variables when it runs external scripts ('hooks') and among those is also:


export OPENSSL_FORCE_FIPS_MODE="0"


And when this variable is defined (regardless of it's value), named 
related commands, such as rndc, named-checkzone and named-checkconf fail 
with that error.


# named-checkconf
tls.c:90:tls_initialize(): fatal error: 
RUNTIME_CHECK(OPENSSL_init_ssl(OPENSSL_INIT_ENGINE_ALL_BUILTIN | 
OPENSSL_INIT_LOAD_CONFIG, NULL) == 1) failed
Aborted (core dumped)

# named-checkzone
tls.c:90:tls_initialize(): fatal error: 
RUNTIME_CHECK(OPENSSL_init_ssl(OPENSSL_INIT_ENGINE_ALL_BUILTIN | 
OPENSSL_INIT_LOAD_CONFIG, NULL) == 1) failed
Aborted (core dumped)

# rndc
tls.c:90:tls_initialize(): fatal error: 
RUNTIME_CHECK(OPENSSL_init_ssl(OPENSSL_INIT_ENGINE_ALL_BUILTIN | 
OPENSSL_INIT_LOAD_CONFIG, NULL) == 1) failed
Aborted (core dumped)

So my workaround is to 'unset' this variable in my script.


I guess the issue was caused by one of the OpenSuSE package updates 
(glibc, maybe?) and has probably nothing to do with Bind itself, but I 
thought someone else might run into it.



   Danilo

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

Can Bind report errors through EDE responses?

2025-02-20 Thread Danilo Godec via bind-users 

Hello,


I was testing / debugging some sub-zone delegation for a friend's domain 
(something about email marketing service that want's their clients to 
delegate a subzone to their NSs) and couldn't quite see the issue - 
apart from my local resolver reporting 'SERVFAIL':


; <<>> DiG 9.18.33 <<>> ns send.dom24.si
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status:*SERVFAIL*, id: 62197
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 58d59532ac7efb7b010067b6d70ac2a22d96114e96b0 (good)
;; QUESTION SECTION:
;send.dom24.si. IN  NS


I eventually figured out that the target NS servers that should host the 
delegated sub-zone, refuse the query - probably they're not yet configured:


; <<>> DiG 9.18.33 <<>> ns send.dom24.si*@ns1.klaviyo.com.*
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status:*REFUSED,* id: 21094
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;send.dom24.si. IN  NS



But then I tried using Google's 8.8.8.8 and Cloudflare's 1.1.1.1 and 
they provide more info that I can see directly in dig's output:


; <<>> DiG 9.18.33 <<>> ns send.dom24.si @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33277
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
*; EDE: 23 (Network Error): ([205.251.196.237] rcode=REFUSED for 
send.dom24.si/ns) ; EDE: 23 (Network Error): ([205.251.192.111] 
rcode=REFUSED for send.dom24.si/ns) ; EDE: 23 (Network Error): 
([205.251.195.79] rcode=REFUSED for send.dom24.si/ns) ; EDE: 23 (Network 
Error): ([205.251.198.128] rcode=REFUSED for send.dom24.si/ns) ; EDE: 22 
(No Reachable Authority): (At delegation send.dom24.si for send.dom24.si/ns)*

;; QUESTION SECTION:
;send.dom24.si. IN  NS


; <<>> DiG 9.18.33 <<>> ns send.dom24.si @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18432
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
*; EDE: 22 (No Reachable Authority): (at delegation send.dom24.si.) ; 
EDE: 23 (Network Error): (205.251.198.128:53 rcode=REFUSED for 
send.dom24.si NS)*

;; QUESTION SECTION:
;send.dom24.si. IN  NS


I thought that's neat and started digging (pun intended) in docs if Bind 
could be configured to provide something like that (ideally just for my 
'inside' view), but I couldn't find anything.



Is there a way to have Bind report such info through dig?


   Danilo

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

Using CNAME for _domainkey (DKIM)

2025-02-24 Thread Danilo Godec via bind-users 

Hello,


apparently one shouldn't use CNAMEs for 'delegating' _domainkey records 
to another DNS server, but I see that some email service vendors use 
that - they have their customers add a CNAME pointing to their TXT 
record (one recent example that I was dealing with is atlassian.net 
(https://accessplanit.atlassian.net/wiki/spaces/HG/pages/417005970/SPF+DKIM+SMTP+Prevent+your+system+emails+being+caught+by+spam+filters) 
- probably so that they can rollover their DKIM keys without their 
customers needing to do anything.



I know that CNAME records can clash with other essential (MX, A, ...)  
records, but since a _domainkey subzone is quite specific and unlikely 
to be used for anything else, this should still work, right?


Or should I consider this an absolute 'no-no' and have my 'customers' 
add the complete TXT record?



    Regards,

    Danilo


--
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: My Introduction and current issues -

2025-05-09 Thread Danilo Godec via bind-users 


  
  
On 10.05.2025 05:29, bi...@clearviz.biz
  wrote:

  >Also check /etc/resolv.conf and see what address(es) is/are
listed as nameservers.
  The resolv.conf file
contains:
    nameserver
127.0.0.53
    search
mydomain.net   (where mydomain is my actual domain name and
not the FQDN of the machine (i.e.
"machine01.mydomain.net")).   
  This was entered by
default as BIND was installed.   I am wondering if the
"namesever" should be the machine name on which the server
is running and not 127.0.0.53 And I gather the 53 on the end
has to do with the port on which it's listening. I'm not
sure if it's correct that the 4th octet is substituted like
that. 
  

/etc/resolv.conf is not changed or set by BIND, as far as I know
  it's got nothing to do with BIND at all.

IIRC Ubuntu is using 'systemd-resolved' (a local resolver with
  cache) and 127.0.0.53 is the address it listens on, so you might
  need to check that with 'resolvectl dns'.

Then check what is listening on port 53 (netstat -anp | egrep
  ":53.*LISTEN") on the server. 

And also check what DNS servers your DHCP sets.


   Danilo



  

  

-- 
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: 3Rd Follow Up - Re: My Introduction and current issues

2025-05-18 Thread Danilo Godec via bind-users 


  
  
On 18.05.2025 19:53, bi...@clearviz.biz
  wrote:

  I include it because all of the packets
seem to have the same problem (the router attempts a ping to my
main server (ending in octet ".10"), which it claims the host is
unreachable.  Not sure why that is happening.

I think you're misunderstanding the ICMP  'Destination
unreachable' packet - it's not that your router attempts to
  'ping' the server, it's the router informing the server that it's
  intended destination is unreachable.

Since that ICMP packet is always preceded by a DNS query directed
  to either 1.1.1.1 or 8.8.8.8, it might imply that either your
  router or something further along (i.e. your ISP) is not allowing
  the DNS query packets to pass.



Since Bind v9.18 has been in use for quite a while and is still
  widely used today (without such major issues), I very much doubt
  your issues are caused by Bind.



    Danilo



  

  

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