new root trust anchor confirmation
Is there any method to confirm that my validator has accepted new root KSK trust anchor and can actually validates with new TA before 11 Oct? Any test records signed with _only_ new KSK in root zone? Regards, -- Daisuke Higashi
On Aug 10, 2017, at 9:57 AM, Daisuke HIGASHI <daisuke.higashi@gmail.com> wrote:
Is there any method to confirm that my validator has accepted new root KSK trust anchor and can actually validates with new TA before 11 Oct?
In general, no. If you happen to run a recent unbound you could query your validator for trustanchor.unbound CH TXT
Any test records signed with _only_ new KSK in root zone?
This doesn't work. Such a record would validate even if your trust anchor didn't get updated. DW
Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at
On 10 Aug 2017, at 21:03, Wessels, Duane via ksk-rollover <ksk-rollover@icann.org> wrote:
On Aug 10, 2017, at 9:57 AM, Daisuke HIGASHI <daisuke.higashi@gmail.com> wrote:
Is there any method to confirm that my validator has accepted new root KSK trust anchor and can actually validates with new TA before 11 Oct?
In general, no.
If you happen to run a recent unbound you could query your validator for trustanchor.unbound CH TXT
And for recent BIND, use `rndc managed-keys status` or for less recent BIND use `rndc secroots` (which dumps to named.secroots in the server's working directory instead of stdout). The new key should start being trusted about now, since it is 30 days after publication :-) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at
Tony Finch (dot) writes:
And for recent BIND, use `rndc managed-keys status` or for less recent BIND use `rndc secroots` (which dumps to named.secroots in the server's working directory instead of stdout).
Got an old 9.8.4-P2 I'm keeping around to check behaviour. It supports rndc secroots, but not rndc managed-keys status. Here's what I get, FYI: -rw-r--r-- 1 bind bind 1175 Aug 10 16:02 managed-keys.bind -rw-r--r-- 1 bind bind 512 Aug 10 16:02 managed-keys.bind.jnl -rw-r--r-- 1 bind bind 76 Aug 11 11:24 named.secroots ... named secroots still lists 19036: 11-Aug-2017 11:24:26.711 Start view _default ./RSASHA256/19036 ; managed ... but managed-keys *does* contain both keys (20326 and 19036). Nothing in the logs indicating it's considering trusting 20326 anytime soon. Cheers, Phil
On Fri, Aug 11, 2017 at 11:29:22AM +0200, Phil Regnauld wrote:
11-Aug-2017 11:24:26.711
Start view _default
./RSASHA256/19036 ; managed
This means that it isn't yet a trust anchor...
... but managed-keys *does* contain both keys (20326 and 19036).
...but will be at some point, which you can determine by looking at the KEYDATA line in managed-keys.bind. The second date field is the when the add hold-down period will end, in UTC. (My server has 20170811222637, about five hours from now.) More recent versions of BIND added comments to the file that say "trust pending" with a more human-readable date, and the 'rndc managed-keys' command so you can query the server directly. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.
On 11 Aug 2017, at 20:11, Evan Hunt <each@isc.org> wrote:
This means that it isn't yet a trust anchor...
... but managed-keys *does* contain both keys (20326 and 19036).
...but will be at some point, which you can determine by looking at the KEYDATA line in managed-keys.bind. The second date field is the when the add hold-down period will end, in UTC. (My server has 20170811222637, about five hours from now.)
More recent versions of BIND added comments to the file that say "trust pending" with a more human-readable date, and the 'rndc managed-keys' command so you can query the server directly.
For red-hatted retronauts who rock like it's 9.7.0, years ago I wrote a script for parsing managed-keys.bind and explaining its contents. It has not turned out to be amazingly robust, but the splendid people at ISC.org have kept it working. (You probably want to run `rndc sync` first to ensure the journal has been folded into the master file.) https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=contrib/scrip... Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at
On Thu, Aug 10, 2017 at 06:03:42PM +0000, Wessels, Duane via ksk-rollover wrote:
In general, no.
If you happen to run a recent unbound you could query your validator for trustanchor.unbound CH TXT
If you run a recent BIND, "rndc managed-keys status" I'm told powerdns has "rec_control get-tas". -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.
Moin! On 10 Aug 2017, at 23:03, Evan Hunt wrote:
On Thu, Aug 10, 2017 at 06:03:42PM +0000, Wessels, Duane via ksk-rollover wrote:
In general, no.
If you happen to run a recent unbound you could query your validator for trustanchor.unbound CH TXT
If you run a recent BIND, "rndc managed-keys status"
I'm told powerdns has "rec_control get-tas". Nominum Cacheserve has: nom-tell cacheserve resolver.mget fields='(managed-keys-state)' and the setup I have has by now picked up and accepted the new root key.
So long -Ralf
On Tue, Aug 15, 2017 at 07:54:55PM +0000, Paul Hoffman wrote:
On Aug 10, 2017, at 2:03 PM, Evan Hunt <each@isc.org> wrote:
If you run a recent BIND, "rndc managed-keys status"
That works in BIND 9.11.x; is there any equivalent for BIND 9.10.x, which is still much more prevalent in distros?
"rndc secroots" will dump a list of trusted keys, and the managed-keys.bind file is readable and has comments that indicate whether trust is pending or active for each key. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.
Could someone give me a hand. I added the new root KSK to my bind 9 configuration using the trusted-keys configuration. How to I know if its trusted and validated? Thank you for any assistance On Tue, Aug 15, 2017 at 4:47 PM, Evan Hunt <each@isc.org> wrote:
On Tue, Aug 15, 2017 at 07:54:55PM +0000, Paul Hoffman wrote:
On Aug 10, 2017, at 2:03 PM, Evan Hunt <each@isc.org> wrote:
If you run a recent BIND, "rndc managed-keys status"
That works in BIND 9.11.x; is there any equivalent for BIND 9.10.x, which is still much more prevalent in distros?
"rndc secroots" will dump a list of trusted keys, and the managed-keys.bind file is readable and has comments that indicate whether trust is pending or active for each key.
-- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- -- Sameka S. McNeil
so the dnssec-debugger.verisignlabs.com showed my DS=20326/SHA-256 is now in the chain-of-trust On Tue, Aug 15, 2017 at 7:36 PM, Sameka McNeil - NOAA Affiliate < sameka.s.mcneil@noaa.gov> wrote:
Could someone give me a hand.
I added the new root KSK to my bind 9 configuration using the trusted-keys configuration.
How to I know if its trusted and validated?
Thank you for any assistance
On Tue, Aug 15, 2017 at 4:47 PM, Evan Hunt <each@isc.org> wrote:
On Tue, Aug 15, 2017 at 07:54:55PM +0000, Paul Hoffman wrote:
On Aug 10, 2017, at 2:03 PM, Evan Hunt <each@isc.org> wrote:
If you run a recent BIND, "rndc managed-keys status"
That works in BIND 9.11.x; is there any equivalent for BIND 9.10.x, which is still much more prevalent in distros?
"rndc secroots" will dump a list of trusted keys, and the managed-keys.bind file is readable and has comments that indicate whether trust is pending or active for each key.
-- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- -- Sameka S. McNeil
-- -- Sameka S. McNeil Phone: 301.628.5644 Cell: 202.360.9428
Sameka, That's the DNSSEC Debugger's trust anchor, not yours. Unfortunately the Debugger only tests authoritative name server configurations. It cannot test anything about your validating name server. Per some previous emails on this list, you can run either 'rndc secroots' or 'rndc managed-keys' depending on your particular version of BIND 9. DW
On Aug 15, 2017, at 8:14 PM, Sameka McNeil - NOAA Affiliate <sameka.s.mcneil@noaa.gov> wrote:
so the
dnssec-debugger.verisignlabs.com showed my DS=20326/SHA-256 is now in the chain-of-trust
On Tue, Aug 15, 2017 at 7:36 PM, Sameka McNeil - NOAA Affiliate <sameka.s.mcneil@noaa.gov> wrote: Could someone give me a hand.
I added the new root KSK to my bind 9 configuration using the trusted-keys configuration.
How to I know if its trusted and validated?
Thank you for any assistance
On Tue, Aug 15, 2017 at 4:47 PM, Evan Hunt <each@isc.org> wrote: On Tue, Aug 15, 2017 at 07:54:55PM +0000, Paul Hoffman wrote:
On Aug 10, 2017, at 2:03 PM, Evan Hunt <each@isc.org> wrote:
If you run a recent BIND, "rndc managed-keys status"
That works in BIND 9.11.x; is there any equivalent for BIND 9.10.x, which is still much more prevalent in distros?
"rndc secroots" will dump a list of trusted keys, and the managed-keys.bind file is readable and has comments that indicate whether trust is pending or active for each key.
-- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- -- Sameka S. McNeil
-- -- Sameka S. McNeil Phone: 301.628.5644 Cell: 202.360.9428
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Tue, Aug 15, 2017 at 10:36 PM, Sameka McNeil - NOAA Affiliate <sameka.s.mcneil@noaa.gov> wrote:
Could someone give me a hand.
I added the new root KSK to my bind 9 configuration using the trusted-keys configuration.
Unless you have a really good reason, 'trusted-keys' is probably not what you want -- you should almost definitely be using 'managed-keys' instead. Trusted keys basically says: This is the trust anchor, and will always be the trust anchor. I take full responsibility for updating it if it changes in the future. Managed keys says: This is the trust anchor. Please use the process in RFC5011 to manage this for me -- when a new trust anchor is introduced (and signed by the old one), start using it, and revoke this one when told to. More details here: https://www.isc.org/blogs/2017-root-key-rollover-what-does-it-mean-for-bind-... W
How to I know if its trusted and validated?
Thank you for any assistance
On Tue, Aug 15, 2017 at 4:47 PM, Evan Hunt <each@isc.org> wrote:
On Tue, Aug 15, 2017 at 07:54:55PM +0000, Paul Hoffman wrote:
On Aug 10, 2017, at 2:03 PM, Evan Hunt <each@isc.org> wrote:
If you run a recent BIND, "rndc managed-keys status"
That works in BIND 9.11.x; is there any equivalent for BIND 9.10.x, which is still much more prevalent in distros?
"rndc secroots" will dump a list of trusted keys, and the managed-keys.bind file is readable and has comments that indicate whether trust is pending or active for each key.
-- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- -- Sameka S. McNeil
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
participants (9)
-
Daisuke HIGASHI -
Evan Hunt -
Paul Hoffman -
Phil Regnauld -
Ralf Weber -
Sameka McNeil - NOAA Affiliate -
Tony Finch -
Warren Kumari -
Wessels, Duane