RE: A beginner's guide to DNSSEC with BIND 9
Jan-Piet Mens wrote:
>> A Beginner's Guide to DNSSEC with BIND 9.
> Well done! A few comments, if I may:
{snip}
Thanks JP, I really appreciate the feedback. I'll take all of that onboard,
change my zones and guide from master/slave to primary/secondary, and take a
look at TSIG as well.
As PGNet Dev said, I would also be interested to hear more about
"inline-signing might go away". In fact when creating my first DNSSEC zone I
initially *did not* include this statement in the zone file, but this caused
named to fail to start and it threw the following error:
'dnssec-policy;' requires dynamic DNS or inline-signing to be configured for
the zone
Like PGNet Dev I would also prefer to continue to hand-edit my zone files for
the time being (rather than using a tool such as nsupdate) so I'm interested to
hear if this will still be supported or what the roadmap is for deprecating the
ability to hand-edit these files for DNSSEC-enabled zones.
Once again many thanks for taking the time to provide feedback and advice, I
really appreciate it. I'll take any further comments off-list.
Best,
Richard.
--
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
'inline-signing' might go away and be replaced by dnssec-policy ?
i've read this comment
'inline-signing' might go away and be replaced by dnssec-policy
now a few times, in posts and in docs
currently, WITH 'dnssec-policy' signing enabled & in-use, i've
zone "example.com" IN {
type master; file "namedb/primary/example.com.zone";
dnssec-policy "test";
inline-signing yes;
...
the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in order to
_not_ overwrite original zone files/data on signing. e.g., with the config
above
cd namedb/primary/
ls -1 *example*
example.com.zone < THIS is the original, unsigned
zone data
example.com.zone.jbk
example.com.zone.jnl
example.com.zone.signed < THIS is the signing-generated
zone data, which gets propagated
example.com.zone.signed.jnl
without it, the original "example.com.zone" is overwritten with signed data.
is there already config in, or planned for, 'dnssec-policy' that preserves that
separate-file functionality, preserving the original?
--
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: A beginner's guide to DNSSEC with BIND 9
A Beginner's Guide to DNSSEC with BIND 9.
Well done! A few comments, if I may:
1. in your zone stanzas you use the term "master" (type: master, ... masters
{}). BIND has been updated already a while ago to support the term primary, e.g. `type
primary;' and `primaries {};' (likewise for 'secondary'). It might be a good time to
switch to the new nomenclature, particularly as you rightly call the primary primary and
secondary a secondary :)
2. I tend to use `rndc reconfig' for re-configuration (after adding a new zone,
say) rather than `reload', which I used when I wish named to load a modified
primary zone.
3. on your primary you have an allow-transfer{} ACL for your secondary using its IP address. You might wish to look into using TSIG for that.
4. note that `inline-signing' might go away and be replaced by dnssec-policy
which you may wish to look into at some point.
5. I'm not familiar with the paths used by your Ubuntu distro, but the command
at #6 appears to be incorrect:
sudo ./etc/bind/named-checkconf named.conf.local
named-checkconf(8) is likely in /usr/sbin and it will use a compiled-in
default configuration file.
6. just as a FYI: instead of "and if you quickly type tail var/log/syslog" I
typically `tail -f' (follow) the log file in a second window/pane/console or even in the
same session in order to have logs show up immediately. :)
7. Instead of querying for the SOA (dig ... SOA +dnssec), I like querying for
the DNSKEY RRset so that I see the key tags (key IDs): `dig @::1 example.com
DNSKEY +dnssec +multi' (the +multi flag shows me the key types and tags, or use
+nocrypto to omit the base64-encdoded stuff)
8. in the section on externally validating, I'd love to recommend dnsviz.net: I
cannot think of another testing site which I would *pay* to use. These chaps
are grand!
Feel free to talk to me off-list if I've not made sense.
Best regards,
-JP
--
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?
The good news it is not stuck. What indicator flags that it IS 'stuck'? Is it explicitly logged? BIND is waiting to make sure the new DS is also known to the validators. The time being evaluated here is the DS TTL, plus parent-propagation-delay, plus retire-safety. All these three values are configurable within dnssec-policy. my current config has parent-ds-ttl PT1H; parent-propagation-delay PT1H; retire-safety PT1H; @ parental-agents, the DS is cached; ttl appears spec'd other than my set ttl. e.g., @ cloudflare, it's 1 day ... in any case, all of my domains still returned "DSState: rumoured" at < 4 days. since then, about 1/4 of the domains have flipped from "rumoured" -> "omnipresent", with no manual intervention; the rest are still unchanged. again, i've noticed no actual operational problems -- e.g., queries failing, etc -- other than these delays. seems, tho, i've still got a likely misconfig somewhere in here. -- 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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?
Hi, On 21-10-2022 23:05, PGNet Dev wrote: I exec rndc dnssec -checkds -key 63917 published example.com IN external with dnssec loglevel -> debug, on exec, in logs 2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 dnssec: debug 1: keymgr: examine KSK example.com/ECDSAP256SHA256/63917 type DS in state RUMOURED 2022-10-21T16:55:22.690608-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 dnssec: debug 1: keymgr: can we transition KSK example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state OMNIPRESENT? 2022-10-21T16:55:22.690615-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 dnssec: debug 1: keymgr: dnssec evaluation of KSK example.com/ECDSAP256SHA256/63917 record DS: rule1=(~true or true) rule2=(~true or true) rule3=(~false or false) 2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 dnssec: debug 1: keymgr: time says no to KSK example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state OMNIPRESENT (wait 93600 seconds) which certainly looks like a 'no' reason is "time says no", after "dnssec evaluation". which time is being evaluated here? The good news it is not stuck. BIND is waiting to make sure the new DS is also known to the validators. The time being evaluated here is the DS TTL, plus parent-propagation-delay, plus retire-safety. All these three values are configurable within dnssec-policy. 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
