DNSSEC DSSET KEYSET
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. 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. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
* 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 Weimerfwei...@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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
Is there a tool/process to verify if the parenet domain has DSSET, KEYSET, or keys in place for the child domain? Thanks. --- On Thu, 1/28/10, Florian Weimer fwei...@bfk.de wrote: From: Florian Weimer fwei...@bfk.de Subject: Re: DNSSEC DSSET KEYSET To: prock...@yahoo.com prock...@yahoo.com Cc: bind-users@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 fwei...@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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
* prock: 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. -- Florian Weimerfwei...@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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
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? --- On Thu, 1/28/10, Evan Hunt e...@isc.org wrote: From: Evan Hunt e...@isc.org Subject: Re: DNSSEC DSSET KEYSET To: prock...@yahoo.com prock...@yahoo.com Cc: Florian Weimer fwei...@bfk.de, bind-users@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: $ 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 -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
On 01/28/10 07:57, prock...@yahoo.com wrote: 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
On Jan 28 2010, Florian Weimer wrote: * 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: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
* Chris Thompson: 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). -- Florian Weimerfwei...@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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
On Thu, Jan 28, 2010 at 03:42:11PM +, 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? Thanks. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
On Jan 28 2010, Joseph S D Yao wrote: On Thu, Jan 28, 2010 at 03:42:11PM +, 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. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
On Thu, 28 Jan 2010, prock...@yahoo.com wrote: 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC DSSET KEYSET
In message 888060.89769...@web110304.mail.gq1.yahoo.com, prock...@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 ( BEOfDU7lEMzlyr3z7cRBzlD4HVyg3CwQX4FycN7u 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 ( BEOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hW 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 ( BEO4r5Xw/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
