Re: Domain no longer fully secure after move

2022-12-16 Thread Sandro 

On 14-12-2022 19:13, Sandro wrote:

I recently (last weekend) moved the domain to a new registrar. The keys
are now managed by the registrar directly. At least I don't see an
option providing my own or additional keys in their web interface.

Moreover, I'm no longer running my own DNS server. 🙁
Previously, I could set my own BIND server as a primary server for my
domain and have the registrar use AXFR to update the secondaries.

The DNSViz analysis for the current situation:
https://dnsviz.net/d/penguinpee.nl/Y5oJSw/dnssec/

And from before the move:
https://dnsviz.net/d/penguinpee.nl/Yq3P8w/dnssec/

Verisign has one single complaint: No DS records found for penguinpee.nl
in the nl zone.


Answering my own mail, by way of slapping my palm on my forehead.

The missing DS record in the .nl domain is all that's wrong. That breaks 
the chain of validation, therefore showing all penguinpee.nl entries as 
insecure.


I got confused earlier, since the RRs in penguinpee.nl are actually 
signed. But it's the validation that breaks due to the missing DS 
record. End of year fatigue...


-- Sandro
--
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: Behavior of port tag in options clause is ambiguous

2022-12-16 Thread Vikas Sharma 
Thanks Ondrej and Clark for quick reply,
i have gone through the documentation and really its very well written,

bind version used : 9.18.3
notification message = Zone Change Notification

referring to part of the option clause from the original mail .

 port 15010;
 listen-on port 15010 { 127.0.0.1; };
 also-notify {
 10.1.2.4 port 53;
 10.1.2.5 port 53;
 };

here i have  listen-on port 15010 { 127.0.0.1; }  this means primary DNS is
listening on port 15010,
in also notify section i have secondary DNS server IP and port 53
also-notify {

 10.1.2.4 port 53;   #=> notify should
go on port 53 to secondary DNS
 10.1.2.5 port 53;
 };

so based on also-notify configuration primary DNS should send all
notifications to Secondary DNS on dest port 53.

now after adding port 15010; notifications are now going to secondary DNS
on port 15010 also whereas notification on port 53 are also taking place.
so this behaviour is expected?
Port 15010 is neither completely overriding port 53 in also-notify nor port
15010 is ignored while sending notification to secondary DNS.

and if all notification messages to dest port 15010 are dropped on
secondary DNS, is there any impact?

as per Clark's explanation "port number the server uses to receive and
*send* DNS protocol traffic".
then bind should use dest port 15010 for all notification to secondary DNS
but notification is going to port 53 as well.

So when port 15010 will be used and when port 53 will be used while sending
notification to secondary DNS?


*BR,*

*Vikas Sharma*


On Fri, Dec 16, 2022 at 12:11 PM Ondƙej SurĂœ  wrote:

> Hi,
>
> there’s really nice documentation for BIND 9, and it’s even online and
> have a section on the “port”:
> https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-port
>
> Also don’t limit the outgoing ports to a single number - that’s a bad
> security practice, you should be using the full range if possible.
>
> Ondrej
> --
> Ondƙej SurĂœ — ISC (He/Him)
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> On 16. 12. 2022, at 7:26, Vikas Sharma  wrote:
>
> ï»ż
> Hi Team,
>
> we have following configuration in my named.conf
> where i named process on primary DNS is listening on port 15010.
> whereas secondary DNS is running on port 53.
> All Notification to secondary DNS is forwarded on destination port 53 from
> primary DNS.
>
> Now when i add tag port 15010 in options clause on primary DNS, then i see
> some notification message being forwarded to secondary DNS to dest port
> 15010. these messages are in addition to notification to secondary DNS with
> dest port 53.
> changing port value form 15010 to 20598 sends notification to secondary
> DSN on dest port 20598 in addition to notification to secondary on port 53.
>
> i have a firewall on secondary DNS which is rejecting all packets on port
> 15010/20598.
> i see that all my data is populated on secondary DNS without any problem
> due to notifications to secondary DNS on port 53.
>
> query is why named is sending notification to secondary DNS on port
> 15010/20598 when regular notification is also going to secondary DNS on
> port 53.
>
>
> acl theAllServers {
>  thePrimary;
>  theSecondary;
>  localhost;
> };
>
> options {
>  directory "/var/opt/named";
>  pid-file "/var/opt/run/named.pid";
>  allow-transfer { theAllServers; };
>  allow-query { any; };
>  zone-statistics no;
>  notify yes;
>  max-cache-size 14297m;
>  max-journal-size 1048576;
>  port 15010;   #=> used 20598
> as well instead of 15010;
>  listen-on port 15010 { 127.0.0.1; };
>  also-notify {
>  10.1.2.4 port 53;
>  10.1.2.5 port 53;
>  };
> };
>
> Best Regards,
> Vikas Sharma
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: Domain no longer fully secure after move

2022-12-16 Thread Ondƙej SurĂœ 
> On 16. 12. 2022, at 9:25, Sandro  wrote:
> 
> The missing DS record in the .nl domain is all that's wrong. That breaks the 
> chain of validation, therefore showing all penguinpee.nl 
>  entries as insecure.

Hi,

some registrars or registries strip the DS record when you move between 
registrars.
I don't know if this is the case with .nl, but I just know that it might happen.

Cheers,
--
Ondƙej SurĂœ (He/Him)
ond...@isc.org

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


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

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


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

Re: Domain no longer fully secure after move

2022-12-16 Thread Sandro 

On 16-12-2022 10:26, Ondƙej SurĂœ wrote:

some registrars or registries strip the DS record when you move between 
registrars.
I don't know if this is the case with .nl, but I just know that it might happen.


It sure was stripped. Before I provided the details for the DS entry 
myself, since I also signed the zone myself.


I would have expected the new registrar to take care of the DS record, 
since they are now the party signing the zone.


-- Sandro
--
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] setup KASP in master / slave architecture

2022-12-16 Thread adrien sipasseuth 
Hi,

I deleted my zone file .db on my slaves and I forced a transfer from
the master.

Now it seems to work, I do have the RRSIG associated with my RRset A when I
do a dig from my slave.

When I test my dig from my internal network I actually don't have the ad
flag. But from the google resolver (https://dns.google/) I have the flag.

To summarize:
- on my master : declaration of my policy and I use it in my zone
configuration
- on the slaves : configuration of my zone, standard without mentioning
dnssec-policy

What I observe:
- on the master: files .db, .db.jbk,
.db.signed,.db.signed.jnl and my keys
- on the slaves: files .db

I don't understand why there is no .db.signed file on my slave
knowing that a dig from a slave does return RRSIG.

zone  "**" {
type slave;
masters {  ** ; };
file "/ **/ ** / ** .db";
};

Should I specify the .db or the .db.signed ? On the master
or/and ths slaves ?

Regards,

Adrien

Le jeu. 15 déc. 2022 à 19:10, Darren Ankney  a
Ă©crit :

> I have a simple “mylocal” zone setup with a primary and secondary server.
>
> my primary has this .jnl file:
>
> mylocal.jnl
>
>
> My secondary has this similar .jnl file:
>
>
> mylocal.saved.jnl
>
>
> which I believe was distributed via zone transfer.  You find no such
> similar files on your secondary?
>
>
> If you
>
>
> dig @ .. A +dnssec +multiline
>
>
> where  is the IP of your recursive server and
> .. is something in the domain you are trying to
> verify the DNSSEC is working.
>
>
> Does your flags line look something like this?
>
>
> ;; flags: qr rd ra ad;
>
>
> Per the manual:
>
>
> The important detail in this output is the presence of the ad flag in the
> header. This signifies that BIND has retrieved all related DNSSEC
> information related to the target of the query (ftp.isc.org) and that the
> answer received has passed the validation process described in How Are
> Answers Verified?. We can have confidence in the authenticity and integrity
> of the answer, that ftp.isc.org really points to the IP address
> 149.20.1.49, and that it was not a spoofed answer from a clever attacker.
>
>
>
>
> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#using-dig-to-verify
>
> My “flags” line does not show the “ad” flag as this is just a set of
> private servers on a local lan. I can’t submit the DNSSEC details upstream
> as described here:
>
>
> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#uploading-information-to-the-parent-zone
>
>
> On Dec 15, 2022, at 12:05 PM, adrien sipasseuth <
> sipasseuth.adr...@gmail.com> wrote:
>
> Hi,
>
> Ok, I got confused, no need for the keys on the slavs actually.
>
> On the other hand, my slaves should generate the .signed, .signed.jnl and
> .jbk files of my zones, no? currently it is not my case, should I copy them
> from the master?
>
> moreover, when I test a "dig A" I don't have the associated RRSIG when I
> do my "dig A" on a slave while on the master I do.
>
> Regards,
> Adrien
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: [KASP] setup KASP in master / slave architecture

2022-12-16 Thread Niall O'Reilly 
On 16 Dec 2022, at 15:59, adrien sipasseuth wrote:

> - on the slaves: files .db
>
> I don't understand why there is no .db.signed file on my slave
> knowing that a dig from a slave does return RRSIG.

The secondary (slave) only needs one file to hold whatever zone
data the primary provides when transferring the zone.

It doesn't actually matter what you call this file, but something
based on the name of the zone will likely make it easier to
understand months later.

The primary uses additional files to contain the keys and to
hold both DNSSEC and NSUPDATE state. These files aren't needed
on the secondaries.

On a secondary, I actually prefer to use a suffix distinct from
any used on the primary (eg. ".bk"), so that I don't have to worry
about filename collisions in case, in an emergency, I might need
to import the primary files from backup and reconfigure what is
normally a secondary as a primary instead.

I hope this helps.

Niall
-- 
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] setup KASP in master / slave architecture

2022-12-16 Thread Darren Ankney 
This is all I have in my zone on secondary:

zone "mylocal" {
  type secondary;
  file "/etc/bind/mylocal.saved";
  primaries {  
192.168.40.142;
  };
};

My primary is a little more complicated:

zone "mylocal" {
  type primary;
  file "/etc/bind/mylocal";
  notify yes;
  allow-update {
key kea_bind_DDNS_SEC;
  };
  allow-transfer {
key "192.168.40.142-192.168.40.182-zone-transfer";
  };
  dnssec-policy default;
};

I just removed the zone and .jnl files from secondary and restarted. The actual 
zone: mylocal.saved showed up immediately.  About an hour later 
mylocal.saved.jnl appeared.

> On Dec 16, 2022, at 10:59 AM, adrien sipasseuth  
> wrote:
> 
> Hi,
> 
> I deleted my zone file .db on my slaves and I forced a transfer from 
> the master.
> 
> Now it seems to work, I do have the RRSIG associated with my RRset A when I 
> do a dig from my slave.
> 
> When I test my dig from my internal network I actually don't have the ad 
> flag. But from the google resolver (https://dns.google/) I have the flag.
> 
> To summarize:
> - on my master : declaration of my policy and I use it in my zone 
> configuration
> - on the slaves : configuration of my zone, standard without mentioning 
> dnssec-policy
> 
> What I observe:
> - on the master: files .db, .db.jbk, 
> .db.signed,.db.signed.jnl and my keys
> - on the slaves: files .db
> 
> I don't understand why there is no .db.signed file on my slave knowing 
> that a dig from a slave does return RRSIG. 
> 
> zone  "**" {
> type slave;
> masters {  ** ; };
> file "/ **/ ** / ** .db";
> }; 
> 
> Should I specify the .db or the .db.signed ? On the master or/and 
> ths slaves ?
> 
> Regards,
> 
> Adrien
> 
> Le jeu. 15 déc. 2022 à 19:10, Darren Ankney  > a écrit :
>> I have a simple “mylocal” zone setup with a primary and secondary server.
>> 
>> my primary has this .jnl file:
>> 
>> mylocal.jnl
>> 
>> My secondary has this similar .jnl file:
>> 
>> mylocal.saved.jnl
>> 
>> which I believe was distributed via zone transfer.  You find no such similar 
>> files on your secondary?
>> 
>> If you 
>> 
>> dig @ .. A +dnssec +multiline
>> 
>> where  is the IP of your recursive server and 
>> .. is something in the domain you are trying to verify 
>> the DNSSEC is working.
>> 
>> Does your flags line look something like this? 
>> 
>> ;; flags: qr rd ra ad;
>> 
>> Per the manual:
>> 
>> The important detail in this output is the presence of the ad flag in the 
>> header. This signifies that BIND has retrieved all related DNSSEC 
>> information related to the target of the query (ftp.isc.org 
>> ) and that the answer received has passed the 
>> validation process described in How Are Answers Verified?. We can have 
>> confidence in the authenticity and integrity of the answer, that ftp.isc.org 
>>  really points to the IP address 149.20.1.49, and that 
>> it was not a spoofed answer from a clever attacker.
>> 
>> 
>> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#using-dig-to-verify
>> 
>> My “flags” line does not show the “ad” flag as this is just a set of private 
>> servers on a local lan. I can’t submit the DNSSEC details upstream as 
>> described here:
>> 
>> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#uploading-information-to-the-parent-zone
>> 
>>> On Dec 15, 2022, at 12:05 PM, adrien sipasseuth 
>>> mailto:sipasseuth.adr...@gmail.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Ok, I got confused, no need for the keys on the slavs actually.
>>> 
>>> On the other hand, my slaves should generate the .signed, .signed.jnl and 
>>> .jbk files of my zones, no? currently it is not my case, should I copy them 
>>> from the master?
>>> 
>>> moreover, when I test a "dig A" I don't have the associated RRSIG when I do 
>>> my "dig A" on a slave while on the master I do.
>>> 
>>> Regards,
>>> Adrien
>>> 
>> 
>> -- 
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
>> this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> bind-users mailing list
>> bind-users@lists.isc.org 
>> https://lists.isc.org/mailman/listinfo/bind-users
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

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


bind-users mailing list
bind-use

Re: [KASP] setup KASP in master / slave architecture

2022-12-16 Thread Crist Clark 
The statement that a BIND secondary only uses one file is incorrect. A
secondary will write IXFR data to a journal file, a jnl file.

But as has been stated earlier in the thread, a secondary is not involved
in anyway in signing a zone. One way to possibly make more sense of this is
to consider how DNSSEC is designed so caching server also can provide all
of the records needed to validate. It definitely has no special knowledge
of the keys, singing policies, no zone files, etc.


On Fri, Dec 16, 2022 at 12:51 PM Darren Ankney 
wrote:

> This is all I have in my zone on secondary:
>
> zone "mylocal" {
>
>   type secondary;
>
>   file "/etc/bind/mylocal.saved";
>
>   primaries {
>
> 192.168.40.142;
>
>   };
>
> };
>
> My primary is a little more complicated:
>
> zone "mylocal" {
>
>   type primary;
>
>   file "/etc/bind/mylocal";
>
>   notify yes;
>
>   allow-update {
>
> key kea_bind_DDNS_SEC;
>
>   };
>
>   allow-transfer {
>
> key "192.168.40.142-192.168.40.182-zone-transfer";
>
>   };
>
>   dnssec-policy default;
>
> };
>
> I just removed the zone and .jnl files from secondary and restarted. The
> actual zone: mylocal.saved showed up immediately.  About an hour
> later mylocal.saved.jnl appeared.
>
> On Dec 16, 2022, at 10:59 AM, adrien sipasseuth <
> sipasseuth.adr...@gmail.com> wrote:
>
> Hi,
>
> I deleted my zone file .db on my slaves and I forced a transfer from
> the master.
>
> Now it seems to work, I do have the RRSIG associated with my RRset A when
> I do a dig from my slave.
>
> When I test my dig from my internal network I actually don't have the ad
> flag. But from the google resolver (https://dns.google/) I have the flag.
>
> To summarize:
> - on my master : declaration of my policy and I use it in my zone
> configuration
> - on the slaves : configuration of my zone, standard without mentioning
> dnssec-policy
>
> What I observe:
> - on the master: files .db, .db.jbk,
> .db.signed,.db.signed.jnl and my keys
> - on the slaves: files .db
>
> I don't understand why there is no .db.signed file on my slave
> knowing that a dig from a slave does return RRSIG.
>
> zone  "**" {
> type slave;
> masters {  ** ; };
> file "/ **/ ** / ** .db";
> };
>
> Should I specify the .db or the .db.signed ? On the master
> or/and ths slaves ?
>
> Regards,
>
> Adrien
>
> Le jeu. 15 déc. 2022 à 19:10, Darren Ankney  a
> Ă©crit :
>
>> I have a simple “mylocal” zone setup with a primary and secondary server.
>>
>> my primary has this .jnl file:
>>
>> mylocal.jnl
>>
>> My secondary has this similar .jnl file:
>>
>> mylocal.saved.jnl
>>
>> which I believe was distributed via zone transfer.  You find no such
>> similar files on your secondary?
>>
>> If you
>>
>> dig @ .. A +dnssec +multiline
>>
>> where  is the IP of your recursive server and
>> .. is something in the domain you are trying to
>> verify the DNSSEC is working.
>>
>> Does your flags line look something like this?
>>
>> ;; flags: qr rd ra ad;
>>
>> Per the manual:
>>
>> The important detail in this output is the presence of the ad flag in the
>> header. This signifies that BIND has retrieved all related DNSSEC
>> information related to the target of the query (ftp.isc.org) and that
>> the answer received has passed the validation process described in How Are
>> Answers Verified?. We can have confidence in the authenticity and integrity
>> of the answer, that ftp.isc.org really points to the IP address
>> 149.20.1.49, and that it was not a spoofed answer from a clever attacker.
>>
>>
>>
>> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#using-dig-to-verify
>>
>> My “flags” line does not show the “ad” flag as this is just a set of
>> private servers on a local lan. I can’t submit the DNSSEC details upstream
>> as described here:
>>
>>
>> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#uploading-information-to-the-parent-zone
>>
>>
>> On Dec 15, 2022, at 12:05 PM, adrien sipasseuth <
>> sipasseuth.adr...@gmail.com> wrote:
>>
>> Hi,
>>
>> Ok, I got confused, no need for the keys on the slavs actually.
>>
>> On the other hand, my slaves should generate the .signed, .signed.jnl and
>> .jbk files of my zones, no? currently it is not my case, should I copy them
>> from the master?
>>
>> moreover, when I test a "dig A" I don't have the associated RRSIG when I
>> do my "dig A" on a slave while on the master I do.
>>
>> Regards,
>> Adrien
>>
>>
>> --
>> 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
>