BIND operating in Parental Agent role (according to RFC 7344)?
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?
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?
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?
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
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
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
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
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
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
