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

2023-04-11 Thread 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: Does DNSSEC increased packet size reach end computers?

2023-04-11 Thread Mark Andrews
There are some applications that will do DNSSEC.  You should assume that any 
application may ask for DNSSEC records and that is normal.  DNSSEC was designed 
from the very beginning to be validated in the application and only works fully 
when that is done.  The recursive server still needs to validate the responses 
to prevent the cache being poisoned by spoofed responses.  The clients will 
switch between UDP and TCP to get the responses they need.

The AD bit is only to be trusted if there is channel security and you trust the 
recursive server.

Mark

> On 12 Apr 2023, at 05:11, Bob Harold  wrote:
> 
> I was in the process of setting up a test server with DNSSEC signed domains, 
> and asking users to point at the test server to see if the larger packets 
> affected their application, when I realized I might be wrong.
> DNS Resolvers will get bigger responses from DNS Authoritative servers 
> because of DNSSEC signatures.  But clients, running stub resolvers, will 
> likely set the +AD flag and expect the DNS Resolver to validate, but the 
> client will get a response that does not include any DNSSEC records.  Is that 
> correct?
> 
> So I only need to worry about increased packet sizes between DNS Resolvers 
> and DNS Authoritative servers?
> 
> (Granted, the actual answer size to the client could be large enough to cause 
> fall-back to TCP, but that is not because of DNSSEC.)
> 
> -- 
> Bob Harold
> -- 
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

-- 
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: Does DNSSEC increased packet size reach end computers?

2023-04-11 Thread Josh Kuo
You are correct. Normal stub resolvers on desktop clients or mobile devices
only see the AD flag (or SERVFAIL when validation fails). They will only
get all the additional DNSSEC record types if they used the +dnssec option
in dig (which sets the DO bit in the outbound query).

On Tue, Apr 11, 2023 at 3:12 PM Bob Harold  wrote:

> I was in the process of setting up a test server with DNSSEC signed
> domains, and asking users to point at the test server to see if the larger
> packets affected their application, when I realized I might be wrong.
> DNS Resolvers will get bigger responses from DNS Authoritative servers
> because of DNSSEC signatures.  But clients, running stub resolvers, will
> likely set the +AD flag and expect the DNS Resolver to validate, but the
> client will get a response that does not include any DNSSEC records.  Is
> that correct?
>
> So I only need to worry about increased packet sizes between DNS Resolvers
> and DNS Authoritative servers?
>
> (Granted, the actual answer size to the client could be large enough to
> cause fall-back to TCP, but that is not because of DNSSEC.)
>
> --
> Bob Harold
> --
> 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


Does DNSSEC increased packet size reach end computers?

2023-04-11 Thread Bob Harold
I was in the process of setting up a test server with DNSSEC signed
domains, and asking users to point at the test server to see if the larger
packets affected their application, when I realized I might be wrong.
DNS Resolvers will get bigger responses from DNS Authoritative servers
because of DNSSEC signatures.  But clients, running stub resolvers, will
likely set the +AD flag and expect the DNS Resolver to validate, but the
client will get a response that does not include any DNSSEC records.  Is
that correct?

So I only need to worry about increased packet sizes between DNS Resolvers
and DNS Authoritative servers?

(Granted, the actual answer size to the client could be large enough to
cause fall-back to TCP, but that is not because of DNSSEC.)

-- 
Bob Harold
-- 
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: Fully automated DNSSEC with BIND 9.16

2023-04-11 Thread David Carvalho via bind-users
Thank you so much!
Regards

David 


-Original Message-
From: bind-users  On Behalf Of Matthijs 
Mekking
Sent: 11 April 2023 13:03
To: bind-users@lists.isc.org
Subject: Re: Fully automated DNSSEC with BIND 9.16

On 4/11/23 13:14, David Carvalho wrote:
> Hello and thank you so much for your help. Regarding question 1, My 
> version is 9.16-9.1623-0.9.el8...so I got the bug. No update available 
> from Oracle Linux yet, so I'll create a folder and maintain a copy of 
> those files there.
> 
> In which situation should I be required to resend my key to the top 
> domain? I'll have to read more about ZSK, KSK and CSK rollovers. All 
> of this is new to me so far.

I think it would be useful to read this knowledge base article if all is new to 
you:

 https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy

Basically in the following two scenarios you need to publish the public key to 
the parent domain:

1. Enabling DNSSEC
2. KSK rollover

With the default policy, KSK rollover is not scheduled, so only after you 
manually roll the key you need to publish (and withdraw) the DS records from 
the parent.

When exactly? You can check with 'rndc dnssec -status '. If the DS state 
is rumoured it is safe to submit the DS to the parent.

Best regards,

Matthijs



> 
> Thanks! David Carvalho
> 
> 
> 
> -Original Message- From: bind-users 
>  On Behalf Of Matthijs Mekking
> Sent: 11 April 2023 11:16 To: bind-users@lists.isc.org Subject: Re:
> Fully automated DNSSEC with BIND 9.16
> 
> Hello David,
> 
> On 4/11/23 12:02, David Carvalho via bind-users wrote:
>> Hello, hope everyone is fine.
>> 
>> So it seems that going to Bind version 9.16 was the right call as it 
>> simplifies DNSSEC a lot.
>> 
>> Nevertheless, I would like to clarify some things because our 
>> organization has a parent domain and I host my own e-mail servers.
>> I know they had problems while implementing DNSSEC on the top domain, 
>> and some configurations had to be made to let subdomain e-mail 
>> servers to still work after DNSSEC.
>> 
>> Following RedHat tutorial, all I had to do was add “*dnssec-policy
>> default;”* into one of my zones for testing purposes. I’m not testing 
>> Reverse zones yet.
>> 
>> After this, 3 files “Kmy.domain***” were created:
>> 
>> “.key”
>> 
>> “.private”
>> 
>> “.state”.
>> 
>> Three  files regarding my zone were also created:
>> 
>> My.domain.signed
>> 
>> And the following 2, which I’m not sure what their purpose is
>> 
>> *My.domain*.*jbk* and*my.domain.signed.jnl*
> 
> The .jnl files are journal files and are created when a zone uses 
> dynamic update to store changes that are made to zone files.
> 
> The .jbk files are truly temporary files and should be removed again 
> when writing the contents of the zone to file.
> 
>> There are also “managed-keys.bind” and “managed-keys.bind.jnl”
> 
> These are trust anchor files, and store the state of those keys.
> These will be updated on a restart.
> 
>> 
>> My questions:
>> 
>> 1. Everytime I restart the service, it seems all these files are 
>> recreated.  Does this mean that every time I make a change in the 
>> host zone, I need resend the public key to my top domain?
> 
> No, the key files (.key, .private, .state) should also not be 
> recreated upon restart (a bug that would recreate key files every 
> keymgr run was fixed in 9.16.30).
> 
> 
>> 2. Do Parental Agents help with this?
> 
> Not in this case, because there is no need to send the public key to 
> the parent domain. Parental agents only help to automatically detect 
> if the corresponding DS has been published.
> 
> Without parental agents configured you need to use 'rndc dnssec 
> -checkds' to tell BIND that a certain DS has been published/withdrawn 
> in order to continue key rollover.
> 
> 
>> 3. Which format should I use when providing the key to the top level 
>> domain?
>> 
>> * dnssec-dsfromkey
>> /var/named/K/example.com.+013+61141/.key*
>> 
>> or
>> 
>> * grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/
> 
> I assume you are submitting the public key to your registrar and it 
> depends on what format your registrar accepts.
> 
> 
> Best regards,
> 
> Matthijs
> 
--
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: Fully automated DNSSEC with BIND 9.16

2023-04-11 Thread Matthijs Mekking

On 4/11/23 13:14, David Carvalho wrote:

Hello and thank you so much for your help. Regarding question 1, My
version is 9.16-9.1623-0.9.el8...so I got the bug. No update
available from Oracle Linux yet, so I'll create a folder and maintain
a copy of those files there.

In which situation should I be required to resend my key to the top
domain? I'll have to read more about ZSK, KSK and CSK rollovers. All
of this is new to me so far.


I think it would be useful to read this knowledge base article if all is 
new to you:


https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy

Basically in the following two scenarios you need to publish the public 
key to the parent domain:


1. Enabling DNSSEC
2. KSK rollover

With the default policy, KSK rollover is not scheduled, so only after 
you manually roll the key you need to publish (and withdraw) the DS 
records from the parent.


When exactly? You can check with 'rndc dnssec -status '. If the DS 
state is rumoured it is safe to submit the DS to the parent.


Best regards,

Matthijs





Thanks! David Carvalho



-Original Message- From: bind-users
 On Behalf Of Matthijs Mekking 
Sent: 11 April 2023 11:16 To: bind-users@lists.isc.org Subject: Re:

Fully automated DNSSEC with BIND 9.16

Hello David,

On 4/11/23 12:02, David Carvalho via bind-users wrote:

Hello, hope everyone is fine.

So it seems that going to Bind version 9.16 was the right call as
it simplifies DNSSEC a lot.

Nevertheless, I would like to clarify some things because our 
organization has a parent domain and I host my own e-mail servers.

I know they had problems while implementing DNSSEC on the top
domain, and some configurations had to be made to let subdomain
e-mail servers to still work after DNSSEC.

Following RedHat tutorial, all I had to do was add “*dnssec-policy 
default;”* into one of my zones for testing purposes. I’m not

testing Reverse zones yet.

After this, 3 files “Kmy.domain***” were created:

“.key”

“.private”

“.state”.

Three  files regarding my zone were also created:

My.domain.signed

And the following 2, which I’m not sure what their purpose is

*My.domain*.*jbk* and*my.domain.signed.jnl*


The .jnl files are journal files and are created when a zone uses
dynamic update to store changes that are made to zone files.

The .jbk files are truly temporary files and should be removed again
when writing the contents of the zone to file.


There are also “managed-keys.bind” and “managed-keys.bind.jnl”


These are trust anchor files, and store the state of those keys.
These will be updated on a restart.



My questions:

1. Everytime I restart the service, it seems all these files are 
recreated.  Does this mean that every time I make a change in the 
host zone, I need resend the public key to my top domain?


No, the key files (.key, .private, .state) should also not be
recreated upon restart (a bug that would recreate key files every
keymgr run was fixed in 9.16.30).



2. Do Parental Agents help with this?


Not in this case, because there is no need to send the public key to
the parent domain. Parental agents only help to automatically detect
if the corresponding DS has been published.

Without parental agents configured you need to use 'rndc dnssec
-checkds' to tell BIND that a certain DS has been published/withdrawn
in order to continue key rollover.



3. Which format should I use when providing the key to the top
level domain?

* dnssec-dsfromkey
/var/named/K/example.com.+013+61141/.key*

or

* grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/


I assume you are submitting the public key to your registrar and it
depends on what format your registrar accepts.


Best regards,

Matthijs


--
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: Fully automated DNSSEC with BIND 9.16

2023-04-11 Thread David Carvalho via bind-users
Hello and thank you so much for your help.
Regarding question 1, My version is 9.16-9.1623-0.9.el8...so I got the bug. No 
update available from Oracle Linux yet, so I'll create a folder and maintain a 
copy of those files there.

In which situation should I be required to resend my key to the top domain?
I'll have to read more about ZSK, KSK and CSK rollovers. All of this is new to 
me so far.

Thanks!
David Carvalho



-Original Message-
From: bind-users  On Behalf Of Matthijs 
Mekking
Sent: 11 April 2023 11:16
To: bind-users@lists.isc.org
Subject: Re: Fully automated DNSSEC with BIND 9.16

Hello David,

On 4/11/23 12:02, David Carvalho via bind-users wrote:
> Hello, hope everyone is fine.
> 
> So it seems that going to Bind version 9.16 was the right call as it 
> simplifies DNSSEC a lot.
> 
> Nevertheless, I would like to clarify some things because our 
> organization has a parent domain and I host my own e-mail servers. I 
> know they had problems while implementing DNSSEC on the top domain, 
> and some configurations had to be made to let subdomain e-mail servers 
> to still work after DNSSEC.
> 
> Following RedHat tutorial, all I had to do was add “*dnssec-policy
> default;”* into one of my zones for testing purposes. I’m not testing 
> Reverse zones yet.
> 
> After this, 3 files “Kmy.domain***” were created:
> 
> “.key”
> 
> “.private”
> 
> “.state”.
> 
> Three  files regarding my zone were also created:
> 
> My.domain.signed
> 
> And the following 2, which I’m not sure what their purpose is
> 
> *My.domain*.*jbk* and*my.domain.signed.jnl*

The .jnl files are journal files and are created when a zone uses dynamic 
update to store changes that are made to zone files.

The .jbk files are truly temporary files and should be removed again when 
writing the contents of the zone to file.

> There are also “managed-keys.bind” and “managed-keys.bind.jnl”

These are trust anchor files, and store the state of those keys. These will be 
updated on a restart.

> 
> My questions:
> 
>  1. Everytime I restart the service, it seems all these files are
> recreated.  Does this mean that every time I make a change in the
> host zone, I need resend the public key to my top domain?

No, the key files (.key, .private, .state) should also not be recreated upon 
restart (a bug that would recreate key files every keymgr run was fixed in 
9.16.30).


>  2. Do Parental Agents help with this?

Not in this case, because there is no need to send the public key to the parent 
domain. Parental agents only help to automatically detect if the corresponding 
DS has been published.

Without parental agents configured you need to use 'rndc dnssec -checkds' to 
tell BIND that a certain DS has been published/withdrawn in order to continue 
key rollover.


>  3. Which format should I use when providing the key to the top level
> domain? 
> 
> * dnssec-dsfromkey /var/named/K/example.com.+013+61141/.key*
> 
> or
> 
> * grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/

I assume you are submitting the public key to your registrar and it depends on 
what format your registrar accepts.


Best regards,

Matthijs

-- 
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: Fully automated DNSSEC with BIND 9.16

2023-04-11 Thread Matthijs Mekking

Hello David,

On 4/11/23 12:02, David Carvalho via bind-users wrote:

Hello, hope everyone is fine.

So it seems that going to Bind version 9.16 was the right call as it 
simplifies DNSSEC a lot.


Nevertheless, I would like to clarify some things because our 
organization has a parent domain and I host my own e-mail servers. I 
know they had problems while implementing DNSSEC on the top domain, and 
some configurations had to be made to let subdomain e-mail servers to 
still work after DNSSEC.


Following RedHat tutorial, all I had to do was add “*dnssec-policy 
default;”* into one of my zones for testing purposes. I’m not testing 
Reverse zones yet.


After this, 3 files “Kmy.domain***” were created:

“.key”

“.private”

“.state”.

Three  files regarding my zone were also created:

My.domain.signed

And the following 2, which I’m not sure what their purpose is

*My.domain*.*jbk* and*my.domain.signed.jnl*


The .jnl files are journal files and are created when a zone uses 
dynamic update to store changes that are made to zone files.


The .jbk files are truly temporary files and should be removed again 
when writing the contents of the zone to file.



There are also “managed-keys.bind” and “managed-keys.bind.jnl”


These are trust anchor files, and store the state of those keys. These 
will be updated on a restart.




My questions:

 1. Everytime I restart the service, it seems all these files are
recreated.  Does this mean that every time I make a change in the
host zone, I need resend the public key to my top domain?


No, the key files (.key, .private, .state) should also not be recreated 
upon restart (a bug that would recreate key files every keymgr run was 
fixed in 9.16.30).




 2. Do Parental Agents help with this?


Not in this case, because there is no need to send the public key to the 
parent domain. Parental agents only help to automatically detect if the 
corresponding DS has been published.


Without parental agents configured you need to use 'rndc dnssec 
-checkds' to tell BIND that a certain DS has been published/withdrawn in 
order to continue key rollover.




 3. Which format should I use when providing the key to the top level
domain? 


* dnssec-dsfromkey /var/named/K/example.com.+013+61141/.key*

or

* grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/


I assume you are submitting the public key to your registrar and it 
depends on what format your registrar accepts.



Best regards,

Matthijs

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


Fully automated DNSSEC with BIND 9.16

2023-04-11 Thread David Carvalho via bind-users
Hello, hope everyone is fine.

So it seems that going to Bind version 9.16 was the right call as it
simplifies DNSSEC a lot.

Nevertheless, I would like to clarify some things because our organization
has a parent domain and I host my own e-mail servers. I know they had
problems while implementing DNSSEC on the top domain, and some
configurations had to be made to let subdomain e-mail servers to still work
after DNSSEC.

 

Following RedHat tutorial, all I had to do was add "dnssec-policy default;"
into one of my zones for testing purposes. I'm not testing Reverse zones
yet.

After this, 3 files "Kmy.domain***" were created:

".key"

".private"

".state".

 

Three  files regarding my zone were also created:

My.domain.signed

And the following 2, which I'm not sure what their purpose is

My.domain.jbk and my.domain.signed.jnl

 

There are also "managed-keys.bind" and "managed-keys.bind.jnl"

 

My questions:

1.  Everytime I restart the service, it seems all these files are
recreated.  Does this mean that every time I make a change in the host zone,
I need resend the public key to my top domain?
2.  Do Parental Agents help with this?
3.  Which format should I use when providing the key to the top level
domain? 

 dnssec-dsfromkey /var/named/Kexample.com.+013+61141.key

or

 grep DNSKEY /var/named/Kexample.com.+013+61141.key

 

 

Kind regards

David Carvalho

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