Re: DNSSEC DSSET & KEYSET
Evan Hunt
> Is there a tool/process to verify if the parenet domain has DSSET,
> KEYSET, or keys in place for the child domain? Thanks.
"dig ds <yourdomain>", and check that a) DS records are returned, and
B) the first field of at least some of the DS records match the key ID of
the key-signing key for your zone. For example, isc.org is using key 12892:
$ dig +short ds isc.org
12892 5 1 982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759
12892 5 2 F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5
...so we're fine.
And of course, you could also configure a validating resolver (or drill
or dig +sigchase) with a trust anchor for the parent, and make sure the
validation process works.
--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.
Joseph S D Yao
>
> > Is there a tool/process to verify if the parenet domain has DSSET,
> > KEYSET, or keys in place for the child domain? Thanks.
>
> "dig ds <yourdomain>", and check that a) DS records are returned, and
> B) the first field of at least some of the DS records match the key ID of
> the key-signing key for your zone. For example, isc.org is using key 12892:
Apologies if I'm missing something, but wouldn't this read the DS
records off the domain's own name servers, rather than the parent's?
Shouldn't there be an additional @parent.name.server argument?
Thanks.
--
/*********************************************************************\
**
** Joe Yao js...@tux.org - Joseph S. D. Yao
**
\*********************************************************************/
Michael Sinatra
> That was very helpful. Thanks.
>
> One last query. For signed domains registered with and using ISC.ORG trust anchor, is there a sanity check similar to what you displayed below?
If you mean ISC DLV registry, that service continually does sanity
checks on domains that are registered with it. If you register your
domain with ISC DLV, it will notify you if your zone keys are
inconsistent or broken.
Be aware, though, if you register with DLV, there are resolvers that
will try to validate your domain. Ideally, you should make sure that
you are good to go before registering it. That includes re-signing your
zone(s) periodically to prevent the signatures from expiring.
michael
proc...@yahoo.com
--- On Thu, 1/28/10, Florian Weimer <fwe...@bfk.de> wrote:
> From: Florian Weimer <fwe...@bfk.de>
> Subject: Re: DNSSEC DSSET & KEYSET
> To: "proc...@yahoo.com" <proc...@yahoo.com>
> Cc: bind-...@lists.isc.org
> Date: Thursday, January 28, 2010, 10:17 AM
> * prock:
>
> > In a DNSSEC compliant world (I know we're not there
> yet) we need to
> > give a copy of our DSSET and KEYSET to our parent
> domain. Please
> > confirm that is an accurate statement.
>
> Parent zone policies vary. Some require DS RRs, some
> DNSKEY RRs.
> Demanding DNSKEY RRs can prolong the life of signature
> schemes with
> certain weaknesses (which might be helpful at some point in
> the
> future).
>
> --
> Florian Weimer
> <fwe...@bfk.de>
> BFK edv-consulting GmbH http://www.bfk.de/
> Kriegsstraße 100
> tel: +49-721-96201-1
> D-76133 Karlsruhe
> fax: +49-721-96201-99
>
Florian Weimer
>>Parent zone policies vary. Some require DS RRs, some DNSKEY RRs.
>>Demanding DNSKEY RRs can prolong the life of signature schemes with
>>certain weaknesses (which might be helpful at some point in the
>>future).
>
> I take it you refer there to the digest type field in the DS record?
No, there are attacks on hash functions which cause a collision by
extending two non-colliding messages, that is, for given p_1, p_2,
find s_1 and s_2 such that h(p_1 s_1) = h(p_2 s_2). If you demand
DNSKEYs, the attacker lacks direct control over the s_i because of the
additional hashing step, requiring a much stronger attack. (In an
attack, p_1 and p_2 would contain different domain names, for the
victim name and another name which the attacker can register. The
parent zone will sign p_1 s_1, and the attacker will use p_2 s_2, for
which the signature on p_1 s_1 is also valid because of the hash
collision. AFAICT, this is just a minor variant of the well-published
attack on MD5 certificates.)
This is all theoretical because no such attacks are currently known
against SHA-1.
In retrospect, the fact that all major certification-like schemes
require something much stronger than second preimage resistance from
the underlying hash function seems like a blunder of WEP-like
proportions. Fortunately, there are workarounds for DNSSEC and X.509
(you don't even need the DNSKEYs if you employ randomized hashing, and
there's enough wiggle room for that, as discussed on the namedroppers
list).
Chris Thompson
>* prock:
>
>> In a DNSSEC compliant world (I know we're not there yet) we need to
>> give a copy of our DSSET and KEYSET to our parent domain. Please
>> confirm that is an accurate statement.
>
>Parent zone policies vary. Some require DS RRs, some DNSKEY RRs.
>Demanding DNSKEY RRs can prolong the life of signature schemes with
>certain weaknesses (which might be helpful at some point in the
>future).
I take it you refer there to the digest type field in the DS record?
Even if the child provides only a DS using SHA-1, it is of course
possible to recover the DNSKEY record (provided it actually exists!)
and validate it (providing you still trust SHA-1!) and make a DS record
using SHA-256 instead. In fact, that seems to be what ISC do when
they take the IANA ITAR (in which many entries only have digesttype=1)
and massage them for inclusion in dlv.isc.org (where the DLV records
always come in pairs with digesttype=1 and digesttype=2). [Self
registration at dlv.isc.org asks for DNSKEY records in the first
place, of course.]
--
Chris Thompson
Email: ce...@cam.ac.uk
proc...@yahoo.com
So my question is, is there a way through DIG (or some other utility) to confirm that the parent domain has the DSSET and KEYSET records required to support the child domain?
Thanks in advance.
Florian Weimer
> In a DNSSEC compliant world (I know we're not there yet) we need to
> give a copy of our DSSET and KEYSET to our parent domain. Please
> confirm that is an accurate statement.
Parent zone policies vary. Some require DS RRs, some DNSKEY RRs.
Demanding DNSKEY RRs can prolong the life of signature schemes with
certain weaknesses (which might be helpful at some point in the
future).
--
proc...@yahoo.com
One last query. For signed domains registered with and using ISC.ORG trust anchor, is there a sanity check similar to what you displayed below?
--- On Thu, 1/28/10, Evan Hunt <ea...@isc.org> wrote:
> From: Evan Hunt <ea...@isc.org>
> Subject: Re: DNSSEC DSSET & KEYSET
> To: "proc...@yahoo.com" <proc...@yahoo.com>
> Cc: "Florian Weimer" <fwe...@bfk.de>, bind-...@lists.isc.org
> Date: Thursday, January 28, 2010, 10:42 AM
>
> > Is there a tool/process to verify if the parenet
> domain has DSSET,
> > KEYSET, or keys in place for the child domain?
> Thanks.
>
> "dig ds <yourdomain>", and check that a) DS records
> are returned, and
> B) the first field of at least some of the DS records match
> the key ID of
> the key-signing key for your zone. For example,
> isc.org is using key 12892:
>
Florian Weimer
> Is there a tool/process to verify if the parenet domain has DSSET,
> KEYSET, or keys in place for the child domain? Thanks.
No, such parent domain policies are not obvious from looking at the
DNS.
Chris Thompson
>On Thu, Jan 28, 2010 at 03:42:11PM +0000, Evan Hunt wrote:
>>
>> > Is there a tool/process to verify if the parenet domain has DSSET,
>> > KEYSET, or keys in place for the child domain? Thanks.
>>
>> "dig ds <yourdomain>", and check that a) DS records are returned, and
>> B) the first field of at least some of the DS records match the key ID of
>> the key-signing key for your zone. For example, isc.org is using key 12892:
>
>
>Apologies if I'm missing something, but wouldn't this read the DS
>records off the domain's own name servers, rather than the parent's?
>Shouldn't there be an additional @parent.name.server argument?
Not necessary if the nameserver you are sending the dig request to
is DNSSEC-aware, and therefore following RFC 4035 section 3.1.4.1.
Paul Wouters
> So my question is, is there a way through DIG (or some other utility) to confirm that the parent domain has the DSSET and KEYSET records required to support the child domain?
http://opensource.iis.se/trac/dnscheck/
$ dnscheck -test=dnssec xelerance.org.
0.000: INFO Begin testing DNSSEC for xelerance.org..
19.914: INFO Found DS record for xelerance.org. at parent.
25.983: INFO Nameserver 193.110.157.135 does DNSSEC extra processing.
26.256: INFO Nameserver 209.237.247.134 does DNSSEC extra processing.
26.256: INFO Servers for xelerance.org. have consistent extra processing status.
26.256: INFO Found DNSKEY record for xelerance.org. at child.
26.256: INFO Consistent security for xelerance.org..
26.256: INFO Checking DNSSEC at child (xelerance.org.).
26.256: INFO DNSKEY xelerance.org. (tag 10146) is marked as a secure entry point (SEP).
26.257: INFO At least one mandatory algorithm found for DNSKEY xelerance.org..
26.257: WARNING DNSSEC signature expired: RRSIG(xelerance.org/IN/DNSKEY/10146)
26.257: INFO DNSSEC signature expires at: Fri Feb 5 12:54:58 2010
26.278: INFO DNSSEC signature RRSIG(xelerance.org/IN/DNSKEY/49550) matches records.
26.278: INFO DNSSEC signature valid: RRSIG(xelerance.org/IN/DNSKEY/49550)
26.278: INFO Enough valid signatures found for xelerance.org..
31.598: INFO DNSSEC signature expires at: Sun Feb 7 12:53:42 2010
31.598: INFO DNSSEC signature RRSIG(xelerance.org/IN/SOA/49550) matches records.
31.598: INFO DNSSEC signature valid: RRSIG(xelerance.org/IN/SOA/49550)
31.598: INFO Enough valid signatures over SOA RRset found for xelerance.org..
31.598: INFO DNSSEC child checks for xelerance.org. complete.
31.599: INFO Checking DNSSEC at parent of xelerance.org..
31.599: INFO Parent DS(xelerance.org.) refers to valid key at child: DS(xelerance.org./5/1/10146)
31.599: INFO Parent DS(xelerance.org.) refers to secure entry point (SEP) at child: DS(xelerance.org./5/1/10146)
31.599: INFO At least one mandatory DS algorithm found for xelerance.org..
31.599: INFO DNSSEC parent checks for xelerance.org. complete.
31.599: INFO Done testing DNSSEC for xelerance.org..
Paul
Mark Andrews
In message <888060....@web110304.mail.gq1.yahoo.com>, "proc...@yahoo.com"
writes:
> In a DNSSEC compliant world (I know we're not there yet) we need to give a co
> py of our DSSET and KEYSET to our parent domain. Please confirm that is an a
> ccurate statement.
More correctly the parent needs to publish the DS RRset that matches
your SEP keys. Some parents prefer to be given the public key,
other are happy with just the DS records.
> So my question is, is there a way through DIG (or some other utility) to conf
> irm that the parent domain has the DSSET and KEYSET records required to suppo
> rt the child domain?
To a first approximation you can use key ids to check this. The
key ID field in the DS record is the first field (12892 in this
case). You can then ask dig to display the key ids of the DNSKEY
records with +multi.
If you need to go further there are tools which can take a DNSKEY
record and produce DS records and you can compare the hash fields.
I've never needed to do this later step when debugging a validation
failure.
In addition to the key ids matching one of the keys identified by
the DS RRset MUST also sign the DNSKEY RRset for it to be a secure
linkage. This can also be done to a first approximation by looking
at the key id field in the RRSIG record.
When debugging a actual failure adding +cd will allow you to see
what named is getting even though it is not being return to normal
queries.
Mark
; <<>> DiG 9.3.6-P1 <<>> ds isc.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44326
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;isc.org. IN DS
;; ANSWER SECTION:
isc.org. 900 IN DS 12892 5 2 F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5
isc.org. 900 IN DS 12892 5 1 982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759
;; Query time: 430 msec
;; SERVER: 192.168.191.233#53(192.168.191.233)
;; WHEN: Fri Jan 29 07:50:55 2010
;; MSG SIZE rcvd: 109
; <<>> DiG 9.3.6-P1 <<>> dnskey isc.org +multi +dnssec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30104
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;isc.org. IN DNSKEY
;; ANSWER SECTION:
isc.org. 31 IN DNSKEY 257 3 5 (
BEAAAAOfDU7lEMzlyr3z7cRBzlD4HVyg3CwQX4FycN7u
HAbRdGmwlorB3dnQO/TjnyC5f8ik0wgKJ6092WTnNNxG
IqbtFLC6xn0P1ES1LlCe0HmVSokKl7JS/753B4m7moOc
Oo/50sGM+vlZXO4pxmrW1EduobMgl/M1wpLvdBs+FFtY
idmeM8ECaSy/CHehlnY+BzoPH5/W+5CSRg4B7uK6GquI
syW34MbQIzRrRrp/VMiIVm1WSCwhE22+OMkaW+iX7h/S
gjzwh6T2+iUccDtyoBop6A5OVYj6DHip1WmwepiPjmTW
6dTmRo64QS/5S+0xZlvOU8NPgMSuW5pcgImp1/w/
) ; key id = 47407
isc.org. 31 IN DNSKEY 257 3 5 (
BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hW
LDMvoOMRXjGrhhCeFvAZih7yJHf8ZGfW6hd38hXG/xyl
YCO6Krpbdojwx8YMXLA5/kA+u50WIL8ZR1R6KTbsYVMf
/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy347cBB1zM
nnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/z
ZrQzBkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix
5WcJt+xzqZ7+ysyLKOOedS39Z7SDmsn2eA0FKtQpwA6L
XeG2w+jxmw3oA8lVUgEf/rzeC/bByBNsO70aEFTd
) ; key id = 12892
isc.org. 31 IN DNSKEY 256 3 5 (
BEAAAAO4r5Xw/jbd+p7UiuzpoXQRjUzDaBIP0GaF2h8N
rzydq8Faopgc29K9elYlNjC39T0qlaV2J2iqZS9g90AA
TKsXKPy7E9NSe/+Bsr0Uipehvt4K6jqaqSSLubuSisIM
R/q5x+wP6QUUKT0kjnycfDjjeORdiINckWHsbM87rtNw
8Q==
) ; key id = 8496
isc.org. 31 IN RRSIG DNSKEY 5 2 7200 20100224205023 (
20100125205023 8496 isc.org.
bXGIYbjQbuLU4yzve/NxzhOKz8JLnCiuBnAKkqj0NEX3
c2IHY3pANw0itH3LuhQp0mrYx8/39vF/XYYT10V3NK2T
TiGUgZa0nOjRhPZNvs2+G5kcfHUvQvwbmldTvtjEADrx
q55tI5Qax8kf61CFWBjTdXpWVTM+asY0TD6GXSw= )
isc.org. 31 IN RRSIG DNSKEY 5 2 7200 20100224205023 (
20100125205023 12892 isc.org.
U67k/VAaIBdAOEQhEVtbEY8lhqHfnDHbir/PntlqYRvg
4LjlILpNbHRcyWzHKsBb0bnHp+qMYkiBYczNvZ4zD4nh
FR7ZVh6z046IcAzI8G1KD6n96GraXBXFJN2z+kE+B/gY
xMy3xWfrIoxj/L8hEy3mqjpPXfcdtzrD3/bjf/og3Mrn
WZJuawTcn3/ptMyQYbD5J7yr8xvpq7EjjclOR1u4WCXr
pjEbRN/OmlPSSmM9RI/1w8/ONmCDJSIBaRgc8cMvHvgJ
utPGMmW1ci/LTHVA7dBXb9K/fvOMyuJJMmN4p6Q6KQbY
cNwwktZlkIBO8KdojAsI+Z904XvThCYgbA== )
isc.org. 31 IN RRSIG DNSKEY 5 2 7200 20100224205023 (
20100125205023 47407 isc.org.
RNdtNlmH1MJasaAM2pM1/jo+fr0/UBauutDoR0TlZR1+
5SeuE5LLs1rqGc3Q8poVgCEFVX6MtFDf78wrSn/aQ+YD
ubvg/O8H8a98MyJaInHJZza265LnjsfVYJprExnnJFug
olzIuAQ+F5obSWXKx/WdyXXzzwcD2qWXOovRo4FN6xyE
KqdcaPECZfTJo8T+EqU5KpnHDvCyKf6F2v07GGyXe69t
tRzgCsEIsYGoagLANNSGnb53DqHYQWVJaOEGoEQRa0Ox
QrB8oGyvfCEE3AtFhR/UY9mq+rXDVRUkp9DeqqNRX1uf
OCeIHgkjynUUq8iEsjwhzn+bRbtUR8aNgA== )
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 29 08:08:37 2010
;; MSG SIZE rcvd: 1496
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Michael Milligan
> Is there a tool/process to verify if the parenet domain has DSSET, KEYSET, or keys in place for the child domain? Thanks.
>
You can use 'dig' or 'drill' for this, which are available as part of
the BIND9 distribution (contrib) or from NLNet Labs, respectively.
First, make sure you have the DNSKEY for the parent zone (since the root
zone is just now starting to roll out with DNSSEC info, there is no
trusted root yet). If it's a TLD, you can find the trust anchors at
https://itar.iana.org/ with instructions to validate and store DNSKEYs
for the signed TLDs. Dig/drill need to be fed trusted DNSKEYs to function.
If you save the above trusted DNSKEY into a file called 'trusted-keys',
then you can use either:
dig +sigchase +trusted-key=trusted-keys your.domain.tld
or
drill -TD -k trusted-keys your.domain.tld
and the output will show you if all the right things are in place and
that there is (or is not) a chain of trust from your trusted anchor
(DNSKEY) to your domain, and if not, where the chain is broken.
Regards,
Mike
--
Michael Milligan -> mi...@acmeps.com