Re: DNSSEC regulatory requirements?
On Wed, Apr 05, 2023 at 11:04:10AM +0200, Klaus Malorny wrote: > On 04.04.23 15:11, Josh Kuo wrote: > > Hi all, > > > > [...] > > > > The only one I know of is the very dated US OMB memo from 2008. I see > > several European domains have better DNSSEC deployment rates (such as > > .de). Are there any regulations or friendly recommendations from some > > kind of governing body at work here? > > > > Thank you. > > > > -Josh > > > > Hi Josh, > > at least not in Germany/.de. There may be rules for governmental domain > names, but not for the general public/commercial domains. Other European > ccTLD registry have/had promotions for DNSSEC, so this might be the reason > for higher deployment rates. > > Greetings, > Klaus I think at least one Scandinavian country had a tax incentive to encourage DNSSEC adoption, but no regulatory requirement. cheers, raf -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How do subdomains get discovered by adversaries?
On Thu, Dec 22, 2022 at 07:16:55AM +, Michael De Roover wrote: > So PTR records don't seem to be very useful in getting this information > either. As such, I am still stranded. Unless you scan for all (IPv4) PTR records into a database ready for searches. Here's a link to a page that lists several tools for finding subdomains. At least one of them maintains a large database of domain names. But there are probably various ways. There seems to be a lot of different tools for this. You could check out each tool and see what they say they do. https://geekflare.com/find-subdomains/ > Thanks again for your attention, > Michael cheers, raf -- 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?
On Fri, Dec 31, 2021 at 10:45:12AM +1100, raf wrote: > On Thu, Dec 30, 2021 at 09:07:54AM +0100, Danilo Godec via bind-users > wrote: > > > 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 > > This site might explain it: https://www.saddns.net/ > > If it doesn't, perhaps you could ask the vendor of the > system that produced the security audit report to explain > their rationale. The only theory I can think of is that > separating the functions makes it more likely that the > resolving server would reside on a non-publically accessible > network, but it should still be possible to inject ICMP > packets directed at it by an attacker that can observe > its outgoing query packets. But that's an on-path attacker, > not an off-path attacker, so it would count as an improvement. > But even if the above isn't nonsense, it's not the separation > of functions that improves the situation, it's the location > of the resolving server. So it's probably a dumb theory. > > But the main thing is that the Linux kernel has been patched, > so it shouldn't be a problem after your next security update. > > Until then, you could block outgoing ICMP if doing so doesn't > cause more problems than it solves. > > cheers, > raf I've just watched the two videos referred to on that site, and I think what I said above refers mostly to the original SADDNS (CVE-2020-25705), not the new variant (CVE-2021-20322). But I think the second video might answer your question: https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F3460120.3486219=CCS21-fp236ab.mp4 It does make a distinction between "public-facing" and "private-facing" port scans, but they seem to just be terms used for referring to the difference between un-"connect()"ed and "connect()"ed UDP sockets, and how the kernel handles them. It's complicated. The attacks are different in each case, and the attack for the "private-facing" (i.e. "connect()"-ed sockets) is much more complicated, but still possible. So it didn't help me understand how separating functions in the name server would matter. I think asking your security vulnerability scanner vendor for an explanation is probably a good idea. cheers, raf ___ 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?
On Thu, Dec 30, 2021 at 09:07:54AM +0100, Danilo Godec via bind-users wrote: > 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 This site might explain it: https://www.saddns.net/ If it doesn't, perhaps you could ask the vendor of the system that produced the security audit report to explain their rationale. The only theory I can think of is that separating the functions makes it more likely that the resolving server would reside on a non-publically accessible network, but it should still be possible to inject ICMP packets directed at it by an attacker that can observe its outgoing query packets. But that's an on-path attacker, not an off-path attacker, so it would count as an improvement. But even if the above isn't nonsense, it's not the separation of functions that improves the situation, it's the location of the resolving server. So it's probably a dumb theory. But the main thing is that the Linux kernel has been patched, so it shouldn't be a problem after your next security update. Until then, you could block outgoing ICMP if doing so doesn't cause more problems than it solves. cheers, raf ___ 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: ***UNCHECKED*** Re: DNSSEC implementation on IPv6 PTR Zones
On Thu, Nov 18, 2021 at 09:47:03AM -0700, Grant Taylor via bind-users wrote: > On 11/18/21 3:14 AM, Mark Elkins wrote: > > With IPv6 - you might want to use NSEC3 - as there can be huge holes in > > the reverse zone. Make the bad guy work at guessing what is in the zone. > > Be mindful of current efforts for minimizing NSEC3 rounds / iterations which > purportedly have a diminishing RoI for higher counts. > -- > Grant. . . . > unix || die According to "Guidance for NSEC3 parameter settings" https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-nsec3-guidance-00 the recommendation is: nsec3param iterations 0 optout no salt-length 0; cheers, raf ___ 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: Query on issue#2389 BIND 9.16.10
On Mon, Oct 18, 2021 at 01:02:07PM +0200, Reindl Harald wrote: > Am 18.10.21 um 12:57 schrieb Rajnish Kamboj via bind-users: > > Upgrading to latest release will fix the issue > > lesson to learn: report issues after you made sure you are using the latest > version which probably would fix it > > > Can you also help us with scenarios as to why this issue is occurring? > > May be this will help us in quick workaround (if possible) till the time we > > plan for latest BIND. > > what exactly do you need to plan? > just update! > > shoudn't take more than 5 minutes with packages > > 9.16.10 to 9.16.21 is a bugfix update, case closed Packaging is not always that simple. For example, on Debian stable, the current version is 9.16.15. However, the Debian team will backport security patches from 9.5.16-21 if necessary. cheers, raf ___ 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: SMIMEA syntax question
On Fri, Sep 03, 2021 at 08:58:49PM +1000, Mark Andrews wrote: > yes Thanks. > > On 3 Sep 2021, at 20:41, raf via bind-users > > wrote: > > > > Hi, > > > > Sorry, but I'm having trouble finding zonefile syntax > > documentation. > > > > Is the following correct syntax for an SMIMEA record? > > > > ef809616390533e15df60e10478b6e5c7040a2152f762f173ef6c014._smimecert.raf.org > > IN SMIMEA ( > > 3 0 0 > > 308204c8308202b0020101300d06092a864886f70d01010b05003012 > > [...skip many hex lines...] > > be412474f2c5f04d193124990ef9b15490883604e4aa9adb > > ) > > > > Thanks. > > > > cheers, > > raf ___ 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
SMIMEA syntax question
Hi, Sorry, but I'm having trouble finding zonefile syntax documentation. Is the following correct syntax for an SMIMEA record? ef809616390533e15df60e10478b6e5c7040a2152f762f173ef6c014._smimecert.raf.org IN SMIMEA ( 3 0 0 308204c8308202b0020101300d06092a864886f70d01010b05003012 [...skip many hex lines...] be412474f2c5f04d193124990ef9b15490883604e4aa9adb ) Thanks. cheers, raf ___ 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: KSK signing zone records
On Thu, Sep 02, 2021 at 11:15:32AM +1000, Mark Andrews wrote: > The primary reason that it is per algorithm is that validators and > signers are not required to support the same sets of algorithms and > if you want validation to work for everyone the zone has to be fully > signed for each algorithm that you state that it is signed for, i.e. > published in the DS RRset held in the parent zone. CDS and CDNSKEY > also publish this but are not used as part of the validation process. > > If publish that you are signed for ALG-A and ALG-B and the validator > only supports ALG-B, then if you don’t sign all the zone with ALG-B > there will be answers that can’t be validated. The same applies if > the validator only supports ALG-A and you don’t fully sign the zone > with ALG-A. > > Downgrade attacks are where you support both algorithms but someone > strips out the signatures from one of the algorithms because they > have succeeded in breaking the other algorithm. DNSSEC does not > require that validators detect this condition, though some validators > can be configured to force checks for every published algorithm that > you support. If a validator wants to protect itself from downgrade > attacks it needs to limit itself to only checking RRSIGs for algorithms > listed in the DS RRset and ensure that all algorithms listed there are > present in the response and that the signatures are good. > > Mark Thanks again! cheers, raf ___ 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: KSK signing zone records
On Wed, Sep 01, 2021 at 03:04:56PM +0100, Tony Finch wrote: > raf via bind-users wrote: > > On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton > > wrote: > > > > > What algorithm(s) are you using for ZSK and KSK? If they’re not the > > > same algorithm, then both will be used to sign the entire zone. > > > > Just out of curiosity, why is that? > > Isn't having the KSK sign the ZSK enough? > > As well as what Mark said, the reason signing is per-algorithm is to do > with downgrade protection: if there's a situation where validators support > different algorithms (e.g. some have deprecated a bad algorithm but some > have not yet deployed its replacement) then a signer can support all the > validators by signing with both algorithms, without causing problems for > the newer validators that want to distrust the old algorithm. A validator > can decide whether a zone is secure or not based purely on the algorithms > listed in its DS RRset. > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Northwest Bailey: Southwesterly 3 to 5. Slight. Showers. Good. Thanks. cheers, raf ___ 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: KSK signing zone records
On Tue, Aug 31, 2021 at 02:13:35PM +1000, Mark Andrews wrote: > The rules for what get signed by what are per algorithm. Additionally the > SEP bit is hint to the signer as to what is desired. Named has controls to > say whether to pay attention to the SEP bit or not. Additionally it will > override those controls to pay attention to the SEP but if it believes that > the zone won’t be correctly signed if it paid attention to the SEP bit. > > People have created zones where one algorithm has keys with and without the > SEP > bit for one algorithm but for a second algorithm there are only keys with > (without) > the SEP bit. If the signer has been told to honour the SEP bit then for the > first > algorithm it will be honoured and for the second algorithm the instruction > will > be overridden. > > See dnssec-dnskey-kskonly, update-check-ksk and the keys sub-clause of > dnssec-policy. Thanks. cheers, raf ___ 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: KSK signing zone records
On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton wrote: > What algorithm(s) are you using for ZSK and KSK? If they’re not the > same algorithm, then both will be used to sign the entire zone. > > Regards, > Chris Buxton Just out of curiosity, why is that? Isn't having the KSK sign the ZSK enough? What difference does the nature of the thing being signed make? cheers, raf ___ 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: tsig question (and documentation bug)
On Fri, Aug 20, 2021 at 09:46:46PM +1000, raf via bind-users
wrote:
> On Fri, Aug 20, 2021 at 09:33:01PM +1000, raf via bind-users
> wrote:
>
> > Hi,
> >
> > I want to use TSIG for zone transfers,
> > only allowing zone transfers to
> > particular IP addresses if they
> > possess the TSIG shared secret.
> >
> > The documentation at:
> >
> > https://bind9.readthedocs.io/en/latest/advanced.html
> >
> > has this section:
> >
> > 5.5.4. TSIG-Based Access Control
> >
> > which gives this relevant but non-obvious example:
> >
> > allow-update { !{ !localnets; any; }; key host1-host2. ;};
> >
> > which somehow means localnets *and* possesses the shared secret.
> >
> > I've found old tutorials online that recommend:
> >
> > allow-update { key "KEYNAME"; };
> >
> > Because (they say) including the IP address (no mention
> > of nested negative boolean logic) allows the transfer
> > if *either* the address matches *or* the key is known.
> >
> > To do what I want, do I need to have this:
> >
> > allow-transfer { !{ !IPADDR; any; }; key KEYNAME; };
> >
> > where IPADDR is the address(es) of the secondary
> > (or the name of an acl containing the address(es)
> > of the secondary)?
> >
> > And if so, do I really want to? I'd like to, but
> > that syntax is a bit gross. Maybe I'm being silly.
> > Maybe I should just rely on the possession of the key.
> > Thoughts?
>
> Does this mean what I want?
>
> allow-transfer { !{ !IPADDR; !key KEYNAME; }; };
>
> meaning: not (not ipaddr or not possesses shared secret)
> meaning: ipaddr and possess shared secret
That was wishful thinking. :-)
I've found a good explanation of the short-circuiting
behaviour of negation.
So I think this is what I need to restrict zone transfers
to a set of IP addresses that possess the TSIG key:
acl secondaries { IPADDR1; IPADDR2; }; # Secondary servers
acl transfer { IPADDR3; }; # Separate transfer-only server
acl peers { secondaries; transfer; }; # The above combined
acl strangers { !peers; any; }; # Everywhere else
key tsigkey { algorithm hmac-sha512; secret "XXX"; };
zone ZONE
{
...
allow-transfer { !strangers; key tsigkey; };
also-notify { IPADDR3 key tsigkey; }; # IPADDR3 from acl transfer
};
I'm expecting that this will work, even with the nested
acls, because named-checkconf doesn't complain.
However, I'd also like to replace the explicit IPADDR3
in the also-notify statement with a name to represent
the IPADDR3 in the acl "transfer", but named-checkconf
doesn't like anything I try. But, according to my
(perhaps incorrect) understanding of the documentation,
I should be able to do this.
Even though I knew it didn't make sense, I first tried
the acl name "transfer" but the parser thought that it
was a primaries list name ("unable to find primaries
list 'transfer'"), and it saw the key's name as an
unexpected token (more on that below).
Even though I didn't understand why you would notify
primaries (not important), I tried defining a primaries
list named "transfer", but the key's name was still
rejected as an "unexpected token".
Then I looked at the documentation. In reference.html
section 4.2.16.7. Zone Transfers, it says also-notify
defines a list of IP addresses, with an optional port
each, and an optional TSIG key each. It then says "In
place of explicit addresses, one or more named
primaries lists can be used". It doesn't explicitly say
whether or not a TSIG key can be used with each
primaries list. Perhaps it is trying to imply that it
can't, but it was ambiguous.
I thought the grammar would make it explicit:
zone [ ] {
...
also-notify [ port ] [ dscp ] {
(
|
[ port ] |
[ port ]
)
[ key ] [ tls ];
...
};
...
}
I couldn't find a definition of . At
first, I had assumed it meant an FQDN, but it doesn't.
I realised that it must refer to the name of a defined
primaries list.
Suggestion: Perhaps the grammar should make it clear
that the is a primaries list name.
But more importantly, the grammar seems to say
(if does mean a primaries list),
that a TSIG key can follow a primaries list.
But either named-checkconf doesn't agree with the
documented grammar, or I did something wrong. I had:
primaries transfer { IPADDR3; };
key tsigkey { algorithm hmac-sha512; secret "XXX"; };
zone ZONE { ...; also-notify { transfer key tsigkey; }; };
Does that agree with the documented grammar?
Or did I do it wrong?
If it is true that a TSIG key can't follow a primaries list
name, I would expect the parser to complain about the &quo
Re: tsig question
On Fri, Aug 20, 2021 at 09:33:01PM +1000, raf via bind-users
wrote:
> Hi,
>
> I want to use TSIG for zone transfers,
> only allowing zone transfers to
> particular IP addresses if they
> possess the TSIG shared secret.
>
> The documentation at:
>
> https://bind9.readthedocs.io/en/latest/advanced.html
>
> has this section:
>
> 5.5.4. TSIG-Based Access Control
>
> which gives this relevant but non-obvious example:
>
> allow-update { !{ !localnets; any; }; key host1-host2. ;};
>
> which somehow means localnets *and* possesses the shared secret.
>
> I've found old tutorials online that recommend:
>
> allow-update { key "KEYNAME"; };
>
> Because (they say) including the IP address (no mention
> of nested negative boolean logic) allows the transfer
> if *either* the address matches *or* the key is known.
>
> To do what I want, do I need to have this:
>
> allow-transfer { !{ !IPADDR; any; }; key KEYNAME; };
>
> where IPADDR is the address(es) of the secondary
> (or the name of an acl containing the address(es)
> of the secondary)?
>
> And if so, do I really want to? I'd like to, but
> that syntax is a bit gross. Maybe I'm being silly.
> Maybe I should just rely on the possession of the key.
> Thoughts?
Does this mean what I want?
allow-transfer { !{ !IPADDR; !key KEYNAME; }; };
meaning: not (not ipaddr or not possesses shared secret)
meaning: ipaddr and possess shared secret
cheers,
raf
___
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
tsig question
Hi,
I want to use TSIG for zone transfers,
only allowing zone transfers to
particular IP addresses if they
possess the TSIG shared secret.
The documentation at:
https://bind9.readthedocs.io/en/latest/advanced.html
has this section:
5.5.4. TSIG-Based Access Control
which gives this relevant but non-obvious example:
allow-update { !{ !localnets; any; }; key host1-host2. ;};
which somehow means localnets *and* possesses the shared secret.
I've found old tutorials online that recommend:
allow-update { key "KEYNAME"; };
Because (they say) including the IP address (no mention
of nested negative boolean logic) allows the transfer
if *either* the address matches *or* the key is known.
To do what I want, do I need to have this:
allow-transfer { !{ !IPADDR; any; }; key KEYNAME; };
where IPADDR is the address(es) of the secondary
(or the name of an acl containing the address(es)
of the secondary)?
And if so, do I really want to? I'd like to, but
that syntax is a bit gross. Maybe I'm being silly.
Maybe I should just rely on the possession of the key.
Thoughts?
cheers,
raf
___
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: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
On Mon, Aug 16, 2021 at 10:32:35AM +0200, Matthijs Mekking wrote: > Hi, > > On 16-08-2021 04:28, raf via bind-users wrote: > > On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf wrote: > ... > > > > So it's looking good and I'm happy now. But how long > > after the zone has been signed can I expect to see > > CDS/CDNSKEY RRs appear? Why aren't they created at > > the same time as the DNSKEY RRs? I assume there's > > a good reason but I can't think what it is. > > First the RRsets with signatures need to be in the zone long enough that any > cached unsigned RRsets in resolver's caches have expired. > > If you call 'rndc dnssec -status ' you might see that the "zone > rrsigs" are still in the "rumoured" state. Once they are omnipresent, the DS > may be submitted and that is the time when the corresponding CDS/CDNSKEY > records will be published. Thanks! That makes much sense. I was thinking that it would be OK to publish the DS sooner when the zone is signed for the first time. But I get it. I'll trust bind's sense of timing and be patient. :-) cheers, raf ___ 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: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf wrote:
> But the real problem is that bind crashed, and dumped
> core, and couldn't start at all. There were a hectic
> few minutes there. :-) I deleted the coredump and the
> key files, and the .jnl files, restored backup
> zonefiles, updated the serials to be greater than that
> of the new DNSSEC signed zones, and then bind was able
> to start again.
>
> Does anyone have any idea why bind-6.19.15 would have
> crashed repeatedly?
I've had a sleep, looked in the logs, and found this:
general: notice: all zones loaded
general: notice: running
general: critical: rbtdb.c:6780: REQUIRE(((rbtnode->nsec ==
DNS_RBT_NSEC_NSEC3 && (rdataset->type ==
((dns_rdatatype_t)dns_rdatatype_nsec3) || rdataset->covers ==
((dns_rdatatype_t)dns_rdatatype_nsec3)))
|| (rbtnode->nsec != DNS_RBT_NSEC_NSEC3 && rdataset->type !=
((dns_rdatatype_t)dns_rdatatype_nsec3) &&
rdataset->covers != ((dns_rdatatype_t)dns_rdatatype_nsec3 failed, back
trace
general: critical: #0 0x558ce49ffeed in ??
general: critical: #1 0x7fd079be6d9a in ??
general: critical: #2 0x7fd079d7f73c in ??
general: critical: #3 0x7fd079e45680 in ??
general: critical: #4 0x7fd079c1b720 in ??
general: critical: #5 0x7fd079c20f52 in ??
general: critical: #6 0x7fd07995cea7 in ??
general: critical: #7 0x7fd079590def in ??
general: critical: exiting (due to assertion failure)
That assertion failed 13 times before I cleaned up.
Perhaps this is an old bug that's been fixed by now.
The only problems logged in the lead up to these
assertion failures were permission errors trying to
create jnl files in /etc/bind for the zones that
shouldn't have been signed anyway, e.g.:
general: error: /etc/bind/db.empty.jnl: create: permission denied
general: error: /etc/bind/db.255.jnl: create: permission denied
AppArmor prevented it, but the directory permissions
would have also prevented it (drwxr-sr-x root bind).
I'm convinced that the dnssec-policy usage directive
doesn't belong in the options {} stanza, and should
only appear in zone {} stanzas.
As for testing that approach on a separate VM, the
behaviour is very different, and completely wonderful.
Instead of overwriting my source zone files and then
crashing, it has created ZONE.jbk, ZONE.signed, and
ZONE.signed.jnl files, all of which are binary. But
last night, I definitely saw the overwritten ZONE files
as a text version of the signed zone. Wierd. Never
mind.
So it's looking good and I'm happy now. But how long
after the zone has been signed can I expect to see
CDS/CDNSKEY RRs appear? Why aren't they created at
the same time as the DNSKEY RRs? I assume there's
a good reason but I can't think what it is.
Also, please document the dangers of putting a
dnssec-policy usage directive in the options {} stanza
(unless something signficant has changed since version
9.16.15, and bind now knows not to sign zones that
really shouldn't be signed locally - but even if that's
the case, you could document what version that changed in).
Thanks again for making DNSSEC so easy to implement
(as long as you avoid classic rookie errors). :-)
cheers,
raf
___
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
debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
Hi,
I've just upgraded my bind9 server to debian-11 which
has bind-9.16.15. I've been looking forward to this. I
had my local dnssec-policy ("annual") all ready to go.
But it didn't go well at all.
For the first few seconds, I thought it was great. I
uncommented my new config to enable DNSSEC signing, and
the keys directory was full of new files, but there
were too many. There were key files for all of the
RFC1918 zones. I thought that can't be right.
I had put dnssec-policy "annual" in the options {}
stanza, so that it would apply to all zones. This is
suggested as a possibility in the DNSSEC guide and/or
the configuration reference.
But that means that it applies to all of the zones in
/etc/bind/named.conf.default-zones which is not
helpful. It also applies to the zones in
/etc/bind/zones.rfc1918 if that is included in
/etc/bind/named.conf.local (which a comment there
suggested). That's not helpful either. At least, I
can't see how. Can you sign 127.in-addr.arpa and
168.192.in-addr.arpa? Maybe this is a Debian package
issue. Maybe named.conf.default-zones isn't an
upstream thing. But it's good to be aware of when
writing the documentation.
I've come to the conclusion that putting dnssec-policy
in the options {} stanza, so that it applies to all
zones, is a terrible idea. It only makes sense (to me)
to add dnssec-policy to each individual (real)
authoritative zone {} stanza.
It would be great if the DNSSEC guide and the
configuration reference were updated to include a
warning about this.
But that was just a surprise, maybe wasteful, but
possibly harmless (although possibly not).
What I found more upsetting, was that my carefully
crafted, well documented zonefiles in /var/cache/bind
had been overwritten by bind so as to include the
DNSSEC records. It might seem obvious to anyone who
uses DNS updates that that was going to happen, but I
wasn't expecting it. It would be great if the DNSSEC
guide could be updated to mention that this happens,
and include advice to keep your zonefile sources
somewhere other than where bind looks for them.
I never received any indication when reading the
documentation about DNSSEC that this would happen. I
knew that bind would read in my zonefiles and construct
a signed version of it, but the documentation never
mentioned that that signed version would be written to
disk over my original source zonefiles. At least, I
never got that impression. Thank goodness for backups. :-)
I'll know for next time, and I'll restructure things,
but it would have been nice to be warned in advance
by the documentation.
But the real problem is that bind crashed, and dumped
core, and couldn't start at all. There were a hectic
few minutes there. :-) I deleted the coredump and the
key files, and the .jnl files, restored backup
zonefiles, updated the serials to be greater than that
of the new DNSSEC signed zones, and then bind was able
to start again.
Does anyone have any idea why bind-6.19.15 would have
crashed repeatedly? Here's the subset of the
config that I think could be relevant:
options
{
allow-recursion { localhost; };
dnssec-validation auto;
directory "/var/cache/bind";
key-directory "/var/cache/bind/keys";
dnssec-policy "annual"; # I'm moving this away!
};
dnssec-policy "annual"
{
keys
{
ksk key-directory lifetime 366d algorithm ecdsap256sha256;
zsk key-directory lifetime 61d algorithm ecdsap256sha256;
};
nsec3param iterations 5 optout no salt-length 16;
publish-safety 7d;
retire-safety 7d;
purge-keys 90d;
signatures-validity-dnskey 14d;
signatures-validity 14d;
signatures-refresh 7d;
dnskey-ttl 1d;
max-zone-ttl 1d;
parent-ds-ttl 1d;
zone-propagation-delay 300;
parent-propagation-delay 1d;
};
Might it just be because the RFC1918 zones were signed
and therefore invalid?
I'll try a more gradual approach on a separate test VM
and see how things go. But any advice would be greatly
appreciated. I want to be able to keep using whatever
version of bind9 is on debian stable. So workarounds
that don't involve an upgrade would be appreciated.
Hmm, on a separate VM just adding dnssec-policy "annual"
to one zone {} statement, and reloading, nothing happens.
I should come back to this tomorrow.
I have a new question about the process of updating
zonefiles when dnssec-policy is in use. From now on,
I'll have my zonefile sources somewhere other than
/var/cache/bind (e.g. /etc/bind/zone). When I make
changes, I'll install them to /var/cache/bind and
reload bind9. Bind9 will replace them with the signed
versions. Is it OK for me to modify my unsigned
sources, install them over the top of bind's signed
versions, and will bind happily recreate all of the
DNSSEC records each time? Is that what's expected? That
bind and I keep overwriting each other's zone files?
Th
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Wed, Aug 11, 2021 at 12:14:38PM -0500, Tim Daneliuk via bind-users wrote: > On 8/10/21 11:27 PM, raf via bind-users wrote: > > Does that help at all? > > Very much thank you. I have now discovered my DNS key and corresponding DS > record. I believe the DS record is what I have to provide my registrar > as I understand it. > -- > > Tim Daneliuk tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > ___ That's great. Although it should be a CDS record that you are seeing, not a DS record (yet), and its content is what you need to convey to your registrar so they can create the DS record in the parent zone. cheers, raf ___ 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Wed, Aug 11, 2021 at 09:40:00AM +0200, Matthijs Mekking wrote: > > Syntax question: > > In https://bind9.readthedocs.io/en/latest/dnssec-guide.html > > the double quotes are never used in the zone stanza > > where the dnssec-policy is referred to. The double > > quotes sometimes (but not always) appear in the > > dnssec-policy definition stanza. > > > > Are the double quotes optional in both cases? > > Yes, the dnssec-policy defines or refers to a name that is a string, which > may be a quoted or unquoted string. > > Some additional information on the subject: When it comes to strings, the > named.conf parser expects some options to be quoted strings (usually file > paths), some options to be unquoted strings (things like algorithm and class > names), and some options to be just strings (usually names). Thanks. ___ 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Tue, Aug 10, 2021 at 09:19:33PM -0500, Tim Daneliuk via bind-users wrote: > On 8/10/21 7:32 PM, raf via bind-users wrote: > > To get the DS record information to convey to the > > registrar, after starting to use the default policy. > > look for the CDS record (the child version of the DS > > record) with dig: > > > > dig CDS EXAMPLE.ORG > > > > For the default policy, you'll only have to do this > > once (or until your server gets compromised and you > > start again). But until you've done this, it's not > > done. The trust chain has to go all the way to the > > root, so you need the involvement of your registrar > > (to get your DS published and signed). > > That's quite helpful, thanks, but still unclear about one > thing. When I run the dig command above I do get a result > back with a "COOKIE" value in the response. This value > changes each time I run the dig. Is any one of these the > "DS record" I want to convey to my registrar? > > Other than this I see nothing that resembles a relevant response AND > the COOKIE field does not show up if I do the dig from outside the zone. I don't know what the cookie is for (Sorry). And I haven't signed my zones yet (I'm waiting for debian-11 to come out in a few days), so I can't show you anything definite. But this is what I'd expect to see. I'll use the real example.org as an example, and use host, rather than dig, for compact output. They have DNSKEY and DS records (too many of both for some reason): > host -t dnskey example.org example.org has DNSKEY record 257 3 8 AwEAAayIYwp6ixWfhYM4THrWtVOVLbtJLekeXoNANfroGA/9R5ynPhmR V5MufCgluPCXs0xcWKMxunggLfQm87L/KkL+9W6Ux5aCWIAlVIbD+Vio VXuHbmaW0SUXApi1wIaq9yP9P0oVfbKSqlQLQPbvrOTGXAeR+XAARkgr PJQadTDw3zA7YugzoH/jJEmjK3AGVRUb13ZByUsf+aAnVJmAtBdl3772 mN2rLoaCCa6wyCrT0YZcHrxiMGo8J/KjU/1IidfufsOHH1iQ3CLoV0Kf hQDBb33S8TH30cu8WCPmKhJNWjbhLaTKTDV0GKl/GIYX3IKcNLY9TZjk wUnOcEc1MxE= example.org has DNSKEY record 256 3 8 AwEAAcRJYEt01+ODGJx7oc/1gW8ABY3AwY5QO+b0wp+HcZFq/OK2ZZ57 RBx/nIeP+lWnQGGgKFjeJm04OpY9DKXG2i9Wg2bBxm6lA/Wsa5/flCEK bM3RqTuNzcnxcYEBgqbdmDlgqsK066nbl54DiPEQrEW8ZtroUmuEkrQB WM4xe+Uz example.org has DNSKEY record 257 3 8 AwEAAZtWmbB2NyRD8oX7JeNUfmJB928LBER6l44TokqhZDOL2g6IyxLv 9Ku02X/C50iyUeK1r4lr9s9WdSSAH+Qi3ozeXvhZvzAcgQzNJ1jUj4TX ufXkml4QIy9kwL18N3jRizs+Sj8gz56UQwPL1J3M3rhYvSrF0a2zQYt8 Vt0+HGUNJnaJ7dTBbfALiUJc0ATuHKOU1Le+Pb0b/3Q6b4AG3ZNKciwy 8Hb9wroeAwv5//tffTgTQy4D4544HZCUkRW8b/+jNCpzdw6x7g4edA93 8y+f4YnOn+0bI5pSpB4IDG+GKgrFO2gAEdttujylxJxsm+slx0Qn8Wrv R/ZZvcYnXvs= Only the last DNSKEY above has corresponding DS records below. The 257 means it's a KSK and so it needs a corresponding DS for it to be trusted. > host -t ds example.org example.org has DS record 31589 8 2 3FDC4C11FA3AD3535EA8C1CE3EAF7BFA5CA9AE8A834D98FEE10085CF AEB625AA example.org has DS record 31589 8 1 7B8370002875DDA781390A8E586C31493847D9BC example.org has DS record 37780 8 2 D96AFA9022000D368B5F497877DF289A1E9A13A1AB1F97BC1BF4D5DE 16879134 example.org has DS record 37780 8 1 B4A5CCE8D82DC585E327E5896EAE82E0B9A76DC6 example.org has DS record 3397 8 2 ED1168604BC6A14068B9905401E62698BB3663B6EC2073EBD3599B88 2A785BF6 example.org has DS record 3397 8 1 DEE10345942C98711EB058B25A749EE342FCE1DC The last two DS records above correspond to the last DNSKEY further up. I think the other four are just old ones that haven't been deleted yet. They don't correspond to any other DNSKEY records further up. You can tell which DNSKEY that a DS corresponds to by looking at the first number in the DS record (e.g. 3397), and using dig to extract the key id from the DNSKEY record: > dig dnskey example.org +multi [...] example.org. 2552 IN DNSKEY 257 3 8 ( AwEAAZtWmbB2NyRD8oX7JeNUfmJB928LBER6l44Tokqh ZDOL2g6IyxLv9Ku02X/C50iyUeK1r4lr9s9WdSSAH+Qi 3ozeXvhZvzAcgQzNJ1jUj4TXufXkml4QIy9kwL18N3jR izs+Sj8gz56UQwPL1J3M3rhYvSrF0a2zQYt8Vt0+HGUN JnaJ7dTBbfALiUJc0ATuHKOU1Le+Pb0b/3Q6b4AG3ZNK ciwy8Hb9wroeAwv5//tffTgTQy4D4544HZCUkRW8b/+j NCpzdw6x7g4edA938y+f4YnOn+0bI5pSpB4IDG+GKgrF O2gAEdttujylxJxsm+slx0Qn8WrvR/ZZvcYnXvs= ) ; KSK; alg = RSASHA256 ; key id = 3397 [...] They don't have CDS or CDNSKEY records: > host -t cds example.org example.org has no CDS record > host -t cdnskey example.org example.org has no CDNSKEY record But they would if they were using a recent version of bind. In general, in the lead up to a key rollover, you can tell which CDS is new by the fact that it will have a new key id that you didn't see before. The CDNSKEY records should look like the DNSKEY records (and be a hypothetical signal to the parent zone that they could use the CDNSKEY to derive a DS record that they could then publish and sign at the parent zone level). Similarly, the CDS records (which are der
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Tue, Aug 10, 2021 at 11:24:31AM -0500, Tim Daneliuk via bind-users wrote: > On 8/10/21 10:07 AM, Matthijs Mekking wrote: > >> So just to be sure I'm doing the right thing, I've added this to my > >> options stanza: > >> > >> dnssec-policy "default"; > >> > >> Then restarted named and now all the signing magic is taken care of for > >> me for all zones? (I was not previously using signing.) > > > > Correct. > > > > But you still need to manually submit the DS record to your > > registrar/parent and if you see the DS published run: > > > > rndc dnssec -checkds published . > > I've never done any of the signing work before (other than for master/slave). > Could you kindly point me to something like > > "DS Record Creation And Implementation For Dummies"? > > Thanks, > > > Tim Daneliuk tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > ___ Hi Tim, Here goes! My NOVICE understanding is that bind will create CDS (and CDNSKEY) records automatically to match the (KSK or CSK) DNSKEY records that it also creates automatically. Use dig cds ZONE to see them. The CDS record is the child version of the DS record and it contains same information. The CDS/CDNSKEY records reside in your zones, and they exist to facilitate the automatic uploading of DS records to parent zones, but registrars (or TLDs?) haven't implemented this yet. Even when they do, the first time will be manual. Until they do, it's always manual (if you do key rollovers - but that's not the default). So, that DS information MUST be manually conveyed to the registrar so that they can get it published and signed in the parent/TLD zone. How you do this is determined by each registrar. Hopefully, they will have a web interface for adding/removing DS records. Or it might be via email. If your registrar can't accept DS records, consider transferring to a registrar that does (and maybe let them know why you are leaving). Once you can see that the DS record has been published in the DNS (dig ds ZONE), you then tell bind that this has happened by running: rndc dnssec -checkds -key ID published ZONE The ID is the first number in the DS record (e.g. 12345). If using dnssec-policy default, that's it, because the key lasts forever. But if you have your own policy that involves key rollover, you will need to monitor for the future appearance of new KSK DNSKEY/CDS/CDNSKEY records as they get created by bind in the lead up to a rollover (dig cds ZONE). When they appear, you repeat the above process to convey the new DS information to the registrar, and you also manually delete the old DS record via the registrar (at the same time is OK, or afterwards, but NOT before), and when you see that the old DS has been removed from the DNS, you then tell bind that this has happened by running: rndc dnssec -checkds -key ID withdrawn ZONE I think that causes bind to delete the records related to the old KSK (i.e. DNSKEY/CDS/CDNSKEY), and to eventually delete the keys from disk. At least, that's what I'm planning to do. :-) And I'm setting up a cronjob to monitor for changes in DNSKEY/CDS records and email me when it happens. But that's not needed with the default policy. Here's Matthijs's short version: 1. Monitor, look for new KSKs 2. Upload the DS once the CDS/CDNSKEY for the KSK is published. 3. Request the old DS to be removed. 3. Wait for the new DS to appear (the old DS should be replaced). 4. Run "rndc dnssec -checkds -key ID published ZONE" 5. Run "rndc dnssec -checkds -key ID withdrawn ZONE" 6. Done. cheers, raf ___ 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Tue, Aug 10, 2021 at 08:51:04AM -0500, Tim Daneliuk via bind-users wrote: > On 8/10/21 7:51 AM, Matthijs Mekking wrote: > > Hi Klaus, > > > > On 10-08-2021 13:38, Klaus Darilion wrote: > >> Hi Matthijs! > >> > >>> We would like to encourage you to change your configurations to > >>> 'dnssec-policy'. See this KB article for migration help: > >>> > >>> https://kb.isc.org/docs/dnssec-key-and-signing-policy > >> > >> Some comments to this KB article and dnssec-policy: > >> > >> - The article should mention how to retrieve the DS record from > >> Bind. > > > So just to be sure I'm doing the right thing, I've added this to my > options stanza: > > dnssec-policy "default"; > > Then restarted named and now all the signing magic is taken care of for > me for all zones? (I was not previously using signing.) > > TIA, I'm very new to this myself (so be warned) but that seems to be almost it. BUT: You also MUST convey the DS for the default Combined Signing Key (CSK) to your registrar. That will be a manual process that your registrar can tell you about. For some, there's a web interface. For others, it's via email. For others, you have to use their DNS servers and let them do it for you (but that's a dull option). To get the DS record information to convey to the registrar, after starting to use the default policy. look for the CDS record (the child version of the DS record) with dig: dig CDS EXAMPLE.ORG For the default policy, you'll only have to do this once (or until your server gets compromised and you start again). But until you've done this, it's not done. The trust chain has to go all the way to the root, so you need the involvement of your registrar (to get your DS published and signed). Syntax question: In https://bind9.readthedocs.io/en/latest/dnssec-guide.html the double quotes are never used in the zone stanza where the dnssec-policy is referred to. The double quotes sometimes (but not always) appear in the dnssec-policy definition stanza. Are the double quotes optional in both cases? > -- > -------- > Tim Daneliuk tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > ___ cheers, raf ___ 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: DNSSEC questions
Hi Matthijs, On Mon, Aug 09, 2021 at 11:11:48AM +0200, Matthijs Mekking wrote: > Hi raf, > > On 09-08-2021 10:08, raf via bind-users wrote: > > Hi, > > > > I've got a bunch of DNSSEC questions. > > Any advice would be appreciated. > > > > The context is a little VM with six little zones, > > soon to be upgraded to debian-11 and bind-9.16.15. > > I haven't signed my zones before but now is the time. > > I'm going to rotate KSKs annually because it's > > finally so easy to on debian stable. Thanks for that. > > I know it won't be totally automatic, and that's OK, > > but I'd like to check that I have the right idea of > > what to monitor for and what to do each time. > > > > Q: Is it OK to use exact multiples for ksk/zsk lifetimes (e.g. 366d/61d)? > >I assume it's OK if there aren't too many keys to generate at once. > > Yes. > > > Q: Regarding "parent-propagation-delay" and CDS/CDNSKEY RRs: > > Assuming the registrar doesn't process them, does this equate to > > how long it takes me to notice there's a new DS to upload, > > plus how long it takes me to upload it via the registrar's website, > > plus how long it takes the registrar to publish the uploaded DS? > > Or is it, having instructed the registrar to add/remove a DS, > > how long after I've seen it published/withdrawn in the DNS and have > > run "rndc dnssec -checkds -key ID published/withdrawn ZONE" that > > the parent can be expected to propagate the DS addition/removal > > to all their servers? Or does "rndc dnssec -checkds" make > > "parent-propagation-delay" irrelevant except when the parent > > processes CDS/CDNSKEY RRs? I assume the last. > > No, with the latest version of BIND 9.16 you will have either tell named > that the DS is published with the "rndc dnssec -checkds published" command, > or you will have to configure parental-agents: > > parental-agents lists allow for a common set of parental agents to > be easily used by multiple primary and secondary zones in their > parental-agents lists. A parental agent is the entity that the zone > has a relationship with to change its delegation information > (defined in RFC 7344). > > > BIND will query the parental agents to see if the new DS is actually > published before withdrawing the old DNSSEC key. I won't be able to use parental-agents yet. Debian-11 only has bind-9.16.15 (to start with), and parental-agents was added in 9.16.19. Also, my new registrar doesn't implement RFC 7344 yet, but I suggested it, and they're considering it. In the meantime, I'll just use rndc. > > Q: Are CDS/CDNSKEY RRs always in the zone, or just temporarily > > there for a short time before and after KSK rollovers? > > I don't see them in the wild, so I assume the latter. > > I ask for monitoring purposes. What to monitor for withdrawal? > > I'm thinking I might want to monitor for DNSKEY additions and > > removals instead. More on that below. > > While not necessary, CDS and CDNSKEY RRs are always in the zone as long as > the corresponding DS record is expected to be published. That makes sense. > > Q: When would you want a DS RR for a ZSK (i.e. dnssec-dsfromkey -A)? > > Never, DS is meant to refer to the key that signs the DNSKEY RRset, thus > only applicable for KSK. > > > > Q: Any idea why example.com has two KSK DNSKEY RRs? > > Might they be mid-rollover at the moment? There's only a DS for one of > > them. > > Perhaps it's just an example. > > Most likely a mid-rollover, I will need more details on example.com to know > for sure. It's not important. I'm sure they have their reasons. > > Q: What software could a registrar use to process CDS/CDNSKEY automatically? > > Just curious. > > ... > > > > Q: Do any/many registrars support CDS/CDNSKEY/RFC7344 yet? It seems not. > > No, but I have heard about some registrars looking into it. > > > > > Q: Is a "key-directory" option value that doesn't start with "/" relative > > to the "directory" option (i.e. a subdirectory)? I assume it is. > > The "key-directory" is an optional option that signals that the configured > "key-directory" should be used. Currently it is the only key storage > supported, but in the future it may be possible to have per-key storage. I'll use an absolute path, just to be on the safe side. > > Q: Does the signed zone always have a serial that is the serial in the > > unsigned zone file plus
DNSSEC questions
Hi, I've got a bunch of DNSSEC questions. Any advice would be appreciated. The context is a little VM with six little zones, soon to be upgraded to debian-11 and bind-9.16.15. I haven't signed my zones before but now is the time. I'm going to rotate KSKs annually because it's finally so easy to on debian stable. Thanks for that. I know it won't be totally automatic, and that's OK, but I'd like to check that I have the right idea of what to monitor for and what to do each time. Q: Is it OK to use exact multiples for ksk/zsk lifetimes (e.g. 366d/61d)? I assume it's OK if there aren't too many keys to generate at once. Q: Regarding "parent-propagation-delay" and CDS/CDNSKEY RRs: Assuming the registrar doesn't process them, does this equate to how long it takes me to notice there's a new DS to upload, plus how long it takes me to upload it via the registrar's website, plus how long it takes the registrar to publish the uploaded DS? Or is it, having instructed the registrar to add/remove a DS, how long after I've seen it published/withdrawn in the DNS and have run "rndc dnssec -checkds -key ID published/withdrawn ZONE" that the parent can be expected to propagate the DS addition/removal to all their servers? Or does "rndc dnssec -checkds" make "parent-propagation-delay" irrelevant except when the parent processes CDS/CDNSKEY RRs? I assume the last. Q: Are CDS/CDNSKEY RRs always in the zone, or just temporarily there for a short time before and after KSK rollovers? I don't see them in the wild, so I assume the latter. I ask for monitoring purposes. What to monitor for withdrawal? I'm thinking I might want to monitor for DNSKEY additions and removals instead. More on that below. Q: When would you want a DS RR for a ZSK (i.e. dnssec-dsfromkey -A)? Q: Any idea why example.com has two KSK DNSKEY RRs? Might they be mid-rollover at the moment? There's only a DS for one of them. Perhaps it's just an example. Q: What software could a registrar use to process CDS/CDNSKEY automatically? Just curious. Q: Do any/many registrars support CDS/CDNSKEY/RFC7344 yet? It seems not. Q: Is a "key-directory" option value that doesn't start with "/" relative to the "directory" option (i.e. a subdirectory)? I assume it is. Q: Does the signed zone always have a serial that is the serial in the unsigned zone file plus one? If so, can I continue to use the following scheme for serials: a 10-digit number consisting of the date followed by a 2-digit sequence number, where I increment the serial in the zone file by one whenever I change the zone multiple times on the same day? e.g. serial in 1st zone file = 2021091000 signed and published as 202109101 serial in 2nd zone file = 2021091001 signed and published as 202109102 i.e. Is it OK that the never-published serial in a new unsigned zone file is the same as the previously/currently published serial in the signed zone? Or is it better to increment the serial in the file by 2 instead of 1? Q: Does the following sound right as a process for managing KSK rollovers? - Monitor for the appearance of new KSK DNSKEY RRs that bind creates (or monitor for the appearance of new CDS RRs) - Manually upload the DS RRs for the new KSKs via the registrar's website - Wait for the new DS RRs to appear in the DNS - Run "rndc dnssec -checkds -key ID published ZONE" to inform bind - Wait for bind to sign the ZSKs with the new KSKs - Wait a few TTLs - Manually delete the DS RRs for the old KSKs via the registrar's website - Wait for the old DS RRs to disappear from the DNS - Run "rndc dnssec -checkds -key ID withdrawn ZONE" to inform bind cheers, raf ___ 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-guide erratum
Hi,
I've just read:
https://bind9.readthedocs.io/en/latest/dnssec-guide.html
(excellent, by the way)
And I've noticed (only!) one typo.
In the "Migrating from NSEC to NSEC3" section, it says:
dnssec-policy "standard" {
nsec3param iterations optout no salt-length 16;
};
There should be an integer after "iterations".
Based on the following text, the number of iterations should be 10.
Should I submit a merge request, or can someone just fix it?
cheers,
raf
___
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: Different DNSSEC behaviour between two old versions
Hi again, Never mind. It wasn't the difference between versions. It was that the 9.10.3 server was forwarding all queries to my ISP's DNS servers which are not functioning well. They can't even resolve ietf.org at the moment. When forwarding to 8.8.8.8 instead, it behaves the same as the 9.11.5 server that's doing its own resolving. Apologies for the noise. cheers, raf On Fri, Aug 06, 2021 at 11:56:06AM +1000, raf wrote: > Hi, > > Firstly, I'd like to thank everyone involved with making bind. > I'm used to using old versions (9.10.3 on an old ubuntu host) > and (9.11.5 on debian-10 stable). And just as I'm about to start > using DNSSEC for my domains, debian-11 stable is about to come > out in a few days with bind-9.16.15 which will make DNSSEC so > much easier than I was expecting. Thanks again. > > Now to my question. I've seen an odd difference in behaviour > between 9.10.3 and 9.11.5 relating to DNSSEC, and I was wondering > if anyone knows the reason. > > With both servers configured with "dnssec-validation auto", > 9.10.3 won't resolve tools.ietf.org or datatracker.ietf.org, > but 9.11.5 will resolve them. 9.10.3 will only resolve them > without "dnssec-validation auto". Below is some dig output. > > Any thoughts? > > cheers, > raf ___ 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
Different DNSSEC behaviour between two old versions
Hi, Firstly, I'd like to thank everyone involved with making bind. I'm used to using old versions (9.10.3 on an old ubuntu host) and (9.11.5 on debian-10 stable). And just as I'm about to start using DNSSEC for my domains, debian-11 stable is about to come out in a few days with bind-9.16.15 which will make DNSSEC so much easier than I was expecting. Thanks again. Now to my question. I've seen an odd difference in behaviour between 9.10.3 and 9.11.5 relating to DNSSEC, and I was wondering if anyone knows the reason. With both servers configured with "dnssec-validation auto", 9.10.3 won't resolve tools.ietf.org or datatracker.ietf.org, but 9.11.5 will resolve them. 9.10.3 will only resolve them without "dnssec-validation auto". Below is some dig output. Any thoughts? cheers, raf Bind-9.10.3 (old ubuntu) without dnssec-validation auto: > dig tools.ietf.org +dnssec ; <<>> DiG 9.10.3-P4-Ubuntu <<>> tools.ietf.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2577 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;tools.ietf.org.IN A ;; ANSWER SECTION: tools.ietf.org. 600 IN A 4.31.198.62 tools.ietf.org. 600 IN A 64.170.98.42 ;; Query time: 466 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Aug 06 11:02:57 AEST 2021 ;; MSG SIZE rcvd: 75 Bind-9.10.3 (old ubuntu) with dnssec-validation auto: > dig tools.ietf.org +dnssec ; <<>> DiG 9.10.3-P4-Ubuntu <<>> tools.ietf.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22456 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;tools.ietf.org.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Aug 06 11:20:27 AEST 2021 ;; MSG SIZE rcvd: 43 Bind-9.11.5 (debian-10) with dnssec-validation auto: > dig tools.ietf.org +dnssec ; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> tools.ietf.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10705 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: bc0cbf3fc280195cff2fc080610c8f2371a53d64a2a8f7b4 (good) ;; QUESTION SECTION: ;tools.ietf.org.IN A ;; ANSWER SECTION: tools.ietf.org. 600 IN A 4.31.198.62 tools.ietf.org. 600 IN A 64.170.98.42 ;; AUTHORITY SECTION: tools.ietf.org. 560 IN NS zinfandel.levkowetz.com. tools.ietf.org. 560 IN NS dunkelfelder.levkowetz.com. tools.ietf.org. 560 IN NS dechaunac.levkowetz.com. tools.ietf.org. 560 IN NS heroldrebe.levkowetz.com. ;; ADDITIONAL SECTION: dechaunac.levkowetz.com. 126039 IN A 4.31.198.62 zinfandel.levkowetz.com. 126039 IN A 64.170.98.42 heroldrebe.levkowetz.com. 126039 IN A 194.8.197.114 dunkelfelder.levkowetz.com. 126039 IN A 217.69.81.146 dechaunac.levkowetz.com. 126039 IN 2001:1900:3001:11::3e zinfandel.levkowetz.com. 126039 IN 2001:1890:126c::1:2a heroldrebe.levkowetz.com. 126039 IN 2001:4dd0:200:405:dc40::1 dunkelfelder.levkowetz.com. 126039 IN 2001:aa8:ffdc::42 ;; Query time: 277 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Aug 06 11:23:47 AEST 2021 ;; MSG SIZE rcvd: 392 ___ 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
