|
Ticket ID: SIXXS #9670834 Ticket Status: Won't fix PoP: sesto01 - Availo (Stockholm)
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
![[se]](/s/countries/se.gif) Shadow Hawkins on Tuesday, 02 July 2013 11:28:30
My zone 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. (R224218) has a secured delegation from
its parent 8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. From there on the validation chain seems broken.
As I understand it from reading the DNSSEC status page, the zone f.f.8.d.6.1.1.0.0.2.ip6.arpa. should be secured through DLV, and the child zones 0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. and 8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. through DS records in the parent. However all of these seem broken:
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +nostats f.f.8.d.6.1.1.0.0.2.ip6.arpa.dlv.isc.org. DLV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7790
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;f.f.8.d.6.1.1.0.0.2.ip6.arpa.dlv.isc.org. IN DLV
;; AUTHORITY SECTION:
dlv.isc.org. 3373 IN SOA ns-int.isc.org. hostmaster.isc.org. 2013070207 7200 3600 2419200 3600
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +nostats 0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6890
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. IN DS
;; AUTHORITY SECTION:
f.f.8.d.6.1.1.0.0.2.ip6.arpa. 11789 IN SOA localhost. hostmaster.sixxs.net. 2013062502 10800 3600 2419200 14400
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +nostats 8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17045
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. IN DS
;; AUTHORITY SECTION:
0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 11868 IN SOA localhost. hostmaster.sixxs.net. 2013062602 10800 3600 2419200 14400
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
![[ch]](/s/countries/ch.gif) Shadow Hawkins on Sunday, 22 September 2013 10:25:18
Is this still an issue?
I'm trying to configure DNSSEC signed reverse lookup for 2001:1620:f00:827b::1 and I'm having problems to figure out whether there are any configuration errors on my side or whether they are further up the chain.
(If there's anyone who understands this well reading this, it would be awfully nice if you could take a look and say "you need to fix this" or "problem is out of your hands".)
Cheers,
Fredrik Roubert
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
Shadow Hawkins on Saturday, 05 October 2013 06:37:11
Yes, the problem is still there. If your resolver has a trust anchor for the ISC DLV service, then a lokkup for 2001:1620:f00:827b::1 (actually anything in 0.0.f.0.0.2.6.1.1.0.0.2.ip6.arpa. or below) will return SERVFAIL (be "bogus"). If your resolver does not have a DLV trust anchor configured, then the lookup will succeed (but be "insecure").
The DNSVIZ web page for this zone highlights the problem: In the delegation from f.0.0.2.6.1.1.0.0.2.ip6.arpa. to 0.0.f.0.0.2.6.1.1.0.0.2.ip6.arpa., the SixXS name servers return neither a DS record nor an NSEC3 record proving that there is no DS record. Thus no data in 0.0.f.0.0.2.6.1.1.0.0.2.ip6.arpa. or below should be trusted, if the parent zone f.0.0.2.6.1.1.0.0.2.ip6.arpa. can be validated.
Additionally, one can see that your DS records for b.7.2.8.0.0.f.0.0.2.6.1.1.0.0.2.ip6.arpa. are for you Zone Signing Key (id 22716). If you have both a a KSK and a ZSK, the DS record should be for the KSK (id 57814). As it it now, the KSK has no function (but validation would still work, were it not for the SixXS problem).
State change: wontfix
The state of this ticket has been changed to wontfix
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
Something in the key-update-to-DLV script is going wrong, not entirely sure what, and currently do not have time to see what/where it goes wrong exactly. I'll mark this as wishlist for when I have to to figure out what goes wrong and resolve it.
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
Shadow Hawkins on Friday, 12 July 2013 06:00:43
Thank you. Let me take the opportunity to express my greatest appreciation for the excellent services provided by SixXS.
Some updated information on this problem:
The secure delegation from dlv.isc.org to f.f.8.d.6.1.1.0.0.2.ip6.arpa. now seems to be working. The secure delegation from f.f.8.d.6.1.1.0.0.2.ip6.arpa. to 0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. still does not work, so everything under 0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. is now marked as bogus, if you have a dlv trust anchor configured. The secure delgation from 0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. to 8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. has exactly the same problem.
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +dnssec +norecurse @ns1.sixxs.net 0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. DS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48426
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 12, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. IN DS
;; AUTHORITY SECTION:
f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN SOA localhost. hostmaster.sixxs.net. 2013071003 10800 3600 2419200 14400
f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG SOA 8 12 14400 20130809213001 20130710203001 5805 f.f.8.d.6.1.1.0.0.2.ip6.arpa. bCP+/Rwd653GdFnUZXex975IWia5WLuuYAWxZpYxSwwrV/IemGgxbXVT ZvnXxGiYDxqktWpe+CP/m2pBI/hIFRHsnIF5ypZ5zpz7EvttBgr08QV4 3OkEPuqeiDvPeqFKjEm6XkTkex93jLUJ7aqPtmAJBsR+KL2i94RcVIe4 8Ek=
f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG SOA 8 12 14400 20130809213001 20130710203001 59388 f.f.8.d.6.1.1.0.0.2.ip6.arpa. q5ldA5RcNvrLvWw5s3h2m+Vp8dxLfbJTttMNYiOjPQa0GoLn2axQ6hyy GlGIvaYPDygXfkygxuTdHDjH8qa98cyd4jTVjyUOoAVd66kVtPJtd58C NqUnGGyez7Eq+0sJt/RGhxC/uD7WgQ7wmzorC8JQGAC1rZDQ0XFHeIcG BFY=
8m782q23d53o99fqo5238ltgl1gi7j80.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN NSEC3 1 1 100 C360D340E3C6D08D 9V182QU1USSBTO5IMEV6CLTTD059PE1Q NS SOA RRSIG DNSKEY NSEC3PARAM
8m782q23d53o99fqo5238ltgl1gi7j80.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG NSEC3 8 13 14400 20130809213001 20130710203001 5805 f.f.8.d.6.1.1.0.0.2.ip6.arpa. gZSi1P7URTpzriQW5XtrzAIV7sMjmrW5i6Rz4LoVgrfzxHAlRX94WvpV oeUsOSPrVAGx6qj2PXl2T8sSt7vj1ZV4a8vy8vmt8lqmWnbv8Hku9nLD nrFa4Bu0jd+Aj4NGuTQ9ZNCY2rUnM5t3ZrcPWvY7QNXt7fBFIJa87j9r 8Qw=
8m782q23d53o99fqo5238ltgl1gi7j80.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG NSEC3 8 13 14400 20130809213001 20130710203001 59388 f.f.8.d.6.1.1.0.0.2.ip6.arpa. icltmkTZo1I08W2EXXfAXoidzLF9Db2R3TN1NL2TUFQyrz3chKHzO5ic 1DpCt4VFifo2qEE6+6wkEzhBMotaKHFENCs6eXOo60CL/RXhaD+PVkXY Jm9HkBmOQC23lbMpK0Wh90ibAFKuymGOLE/mnu7ADPuQmNegZ9Xmon8F Be4=
shoeokth6ai6pfm6771i3utonekcolgt.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN NSEC3 1 1 100 C360D340E3C6D08D 5VSDQ3UUVICQ4HBBL9HAO3VVS3HJAMTD
shoeokth6ai6pfm6771i3utonekcolgt.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG NSEC3 8 13 14400 20130809213001 20130710203001 5805 f.f.8.d.6.1.1.0.0.2.ip6.arpa. oasF+gmzOO7USRdfigWDA3P79tRegUCR9NslXPF1P8QU6pVR39GR5tOW +0aGAB+YaITya/FZu/cdFnKfHytBfQ/5xSLY5c9GMzb3I6QawfjviCfj 9zKSb7IDWa4vH7ASe/2d1+34VjDwYXl9RI0wqUPA+aFf8/4SKck82aHD ATg=
shoeokth6ai6pfm6771i3utonekcolgt.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG NSEC3 8 13 14400 20130809213001 20130710203001 59388 f.f.8.d.6.1.1.0.0.2.ip6.arpa. rQr9zIeUBnIcIzqY0Ft10BxbVj7755gvY2fz7fZXUP5dSNSINMTdQBoG N5G0MJtSLuuiJWSDih0Vo47SONLtRSrmalaEES8bWF6b4RG4cznOKwsT SCkBby/FtClCGHd9dD83eh+n0pRUQrogXx8bEoPFT5255kxmafEnTtmo guQ=
bsnbtfgr7d53nqmvhb6lrmvldsu7dko8.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN NSEC3 1 1 100 C360D340E3C6D08D F2HPCQF2FLP655B7VKD1UA0EBRSONQP6 TXT RRSIG
bsnbtfgr7d53nqmvhb6lrmvldsu7dko8.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG NSEC3 8 13 14400 20130809213001 20130710203001 5805 f.f.8.d.6.1.1.0.0.2.ip6.arpa. apWTXfcDuGFAAunJWUf82nALpAE8b6dPgfG+fzpBhQDgy6BQA18S3VVT HHqdYwgbkSR1CF6UIWU6iFZi0597j9PC6wFeaQVU6MAZF7oTzEgbFx+E E95TwHFwzP96JR+PeUYUIlnPjckdjKYCVfzDj/hC490wLzdsmzgvet1S ZD4=
bsnbtfgr7d53nqmvhb6lrmvldsu7dko8.f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG NSEC3 8 13 14400 20130809213001 20130710203001 59388 f.f.8.d.6.1.1.0.0.2.ip6.arpa. 5FQcdQ7hue3aBqyYp2gQYn2kDXtdd8KKqx4PECJ5eRH8k+FvpSogbi1u axqeCfwbOXAJCU3Gk4gpQybojONKXBaGYFCkp3Fv1SqUhqcImT5j/JnS /+7AKR8hIMwNFDSlIklnofRcPHwMdlYHnwT3GBzF/dsOA2iZQ6OhJEoz ni4=
;; Query time: 48 msec
;; SERVER: 2a02:578:1:8::2#53(2a02:578:1:8::2)
;; WHEN: Fri Jul 12 07:36:14 2013
;; MSG SIZE rcvd: 1912
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +dnssec +norecurse @ns2.sixxs.net 0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. DS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51957
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa. IN DS
;; AUTHORITY SECTION:
f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN SOA localhost. hostmaster.sixxs.net. 2013071003 10800 3600 2419200 14400
f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG SOA 8 12 14400 20130809213001 20130710203001 5805 f.f.8.d.6.1.1.0.0.2.ip6.arpa. bCP+/Rwd653GdFnUZXex975IWia5WLuuYAWxZpYxSwwrV/IemGgxbXVT ZvnXxGiYDxqktWpe+CP/m2pBI/hIFRHsnIF5ypZ5zpz7EvttBgr08QV4 3OkEPuqeiDvPeqFKjEm6XkTkex93jLUJ7aqPtmAJBsR+KL2i94RcVIe4 8Ek=
f.f.8.d.6.1.1.0.0.2.ip6.arpa. 14400 IN RRSIG SOA 8 12 14400 20130809213001 20130710203001 59388 f.f.8.d.6.1.1.0.0.2.ip6.arpa. q5ldA5RcNvrLvWw5s3h2m+Vp8dxLfbJTttMNYiOjPQa0GoLn2axQ6hyy GlGIvaYPDygXfkygxuTdHDjH8qa98cyd4jTVjyUOoAVd66kVtPJtd58C NqUnGGyez7Eq+0sJt/RGhxC/uD7WgQ7wmzorC8JQGAC1rZDQ0XFHeIcG BFY=
;; Query time: 67 msec
;; SERVER: 2001:770:18:8::4#53(2001:770:18:8::4)
;; WHEN: Fri Jul 12 07:37:09 2013
;; MSG SIZE rcvd: 530
Note that while ns1.sixxs.net. returns NSEC3 records, ns2.sixxs.net. (and ns3.sixxs.net) does not, for some reason.
Arne
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
Shadow Hawkins on Tuesday, 30 July 2013 14:06:33
In case this was not already clear:
The broken DS delegation problem is present in all "internal" (both parent and child zone served by SixXS nameservers) delegations I have tried. Thus this is surely a systematic problem in the (automatic?) generation of DS records from DNSKEY information for "internal" delegations.
Another random example, taken from the list of zones server by SixXS:
Try something in the parent zone.
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +adflag 2.0.8.9.1.0.1.0.a.2.ip6.arpa soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42501
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;2.0.8.9.1.0.1.0.a.2.ip6.arpa.IN SOA
;; ANSWER SECTION:
2.0.8.9.1.0.1.0.a.2.ip6.arpa. 14400 IN SOA localhost. hostmaster.sixxs.net. 2013072202 10800 3600 2419200 14400
;; AUTHORITY SECTION:
2.0.8.9.1.0.1.0.a.2.ip6.arpa. 14400 IN NS ns1.sixxs.net.
2.0.8.9.1.0.1.0.a.2.ip6.arpa. 14400 IN NS ns2.sixxs.net.
2.0.8.9.1.0.1.0.a.2.ip6.arpa. 14400 IN NS ns3.sixxs.net.
;; Query time: 1792 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 30 15:30:56 2013
;; MSG SIZE rcvd: 165
Good answer, secured by DNSSEC (through the DLV trust anchor), as seen by the "ad" flag in the answer.
Now try something in the child zone.
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +adflag 0.0.2.0.8.9.1.0.1.0.a.2.ip6.arpa soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17377
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;0.0.2.0.8.9.1.0.1.0.a.2.ip6.arpa. IN SOA
;; Query time: 510 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 30 15:31:15 2013
;; MSG SIZE rcvd: 50
No answer, and SERVFAIL error code, since both parent and child are signed, but the DS record for the child zone is missing in the parent zone.
Try something in the child zone, now without validation.
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +cdflag 0.0.2.0.8.9.1.0.1.0.a.2.ip6.arpa soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39315
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;0.0.2.0.8.9.1.0.1.0.a.2.ip6.arpa. INSOA
;; ANSWER SECTION:
0.0.2.0.8.9.1.0.1.0.a.2.ip6.arpa. 14390 IN SOA localhost. hostmaster.sixxs.net. 2013072402 10800 3600 2419200 14400
;; AUTHORITY SECTION:
0.0.2.0.8.9.1.0.1.0.a.2.ip6.arpa. 14390 IN NS ns1.sixxs.net.
0.0.2.0.8.9.1.0.1.0.a.2.ip6.arpa. 14390 IN NS ns2.sixxs.net.
0.0.2.0.8.9.1.0.1.0.a.2.ip6.arpa. 14390 IN NS ns3.sixxs.net.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 30 15:31:24 2013
;; MSG SIZE rcvd: 169
Turning DNSSEC validation off through the "cd" flag, an answer is returned.
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
Thus this is surely a systematic problem in the (automatic?) generation of DS records from DNSKEY information for "internal" delegations.
Yes, as I stated "Something in the key-update-to-DLV script is going wrong".
ENOTIME to dig into it at the moment though unfortunately.
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
Shadow Hawkins on Friday, 14 March 2014 13:08:56
So maybe a temporary "solution" would be to get the DLV delegations removed from the ISC zone. With no secured chain from either the root or dlv trust anchors, the broken DNSSEC delegations within SixXS would do little harm, and the reverse domains would no longer be bogus for resolvers with a dlv trust anchor, merely insecure. The only downside would be that the topmost SixXS reverse domains would go from secure to insecure.
Just a thought.
DNSSEC validation chain broken for 7.e.5.8.0.0.f.f.8.d.6.1.1.0.0.2.ip6.arpa.
Shadow Hawkins on Saturday, 27 June 2015 06:51:27
Arne Birger Nordmark wrote:
So maybe a temporary "solution" would be to get the DLV delegations removed from the ISC zone.
Since the DLV delegations have now been removed, reverse resolution works again and this ticket can be closed.
Thanks for fixing this!
|
on Saturday, 27 June 2015 12:56:40
Posting is only allowed when you are