-----BEGIN PGP SIGNED MESSAGE----- In order to extend the deployment of security technology, we switch to DNSSEC for us and our customers. Usually the collection of SEP keys on each resolver host is hard to maintain. This is the reason why, we set up an other DLV zone. The zone is automatically rechecked for new keys and subentries on each zone. Please allow AXFR (auth by DNSSEC key) to provide all necessary data. The bind lookaside mechanism is limited to small steps, so a many DLV entries as possible are needed. I copy also the data from dlv.verisignlabs.com, so you may even trust them. ;-) Necessary configuration in /etc/named.conf: options { ...; dnssec-enable yes; dnssec-lookaside "." trust-anchor "dnssec.iks-jena.de"; }; trusted-keys { "iks-jena.de." 257 3 5 "AQPRteOmx973cbeIMigT7nciz3dcbt8ssZPG OK2vtPQlEaZO2fKgnm1Fo6FPWcGqKv6O1Zpj Ew2upKVDnzwMCRHpGe0Qh2TawStviww/jxUt joZom9Hy6uIkTvo7TxqnWg55LoHlcsl1kxsF 1PsM2Z88F1XhXSrUtkiQnViXbfzR0joDE8xG J9zRNuzr9Jik+bcv4S4KFOE/Ocn4F5vF7+eo jz9m3/u0gvQdvgFsb7OHr9cYA5GeG++cJWGG 6xFF+yWEDdWuu2A7IJM3EQFWLr0kGDS6oWo/ 5Bz4PlrURjU5wahM1iwLnbKXhQQempzPYnSE s1CW+KH73WjMa76Dna9B"; }; It's recommended to set up a secondary for "dnssec.iks-jena.de". We send out notifies, too. I did not manage to install a web form right now. If you like to get listed, please send me an email. I'm looking for a *stable* ipv6 and dnssec able secondary server for our zones. If you like to exchange secondary DNS service in different AS, please contact me via OpenPGP mail. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQCiAwUBQ+JD3pFeTizbCJMJAQH3+QRmNxR+RIQYqlrEv2IbFBsAheZINPbSbUnw GkBCUvnTJIHmE9s2em0hxkUR+QQOpaih4szklG2B96aZ04eds5CH9ujovdfTMp0P rb1ri6SIdvHPez50Yp9EbG51Dsdde/8eQgU3P7HHU8ZXUY9x8d0EkMu9fHrsLgkv 66NNL6ezk9S25aoTknE51FlxknX1 =PyvH -----END PGP SIGNATURE-----
* Lutz Donnerhacke wrote:
I did not manage to install a web form right now. If you like to get listed, please send me an email.
Webform including some statistics is online: https://www.iks-jena.de/leistungen/dnssec.php If you are not listed, you might add yourself.
I'm looking for a *stable* ipv6 and dnssec able secondary server for our zones. If you like to exchange secondary DNS service in different AS, please contact me via OpenPGP mail.
Problem solved. Half a day after this message, Cable & Wireless announced, that the switched there DNS infrastructure (at least for secondaries) to DNSSEC. Great!
On Tue, 7 Feb 2006 17:13:56 +0000 (UTC), Lutz Donnerhacke <lutz@iks-jena.de> said:
* Lutz Donnerhacke wrote:
I did not manage to install a web form right now. If you like to get listed, please send me an email.
Webform including some statistics is online: https://www.iks-jena.de/leistungen/dnssec.php
I have several questions: Why do you include DLV Records for Zones that are below a secure entry point (those you call "chained")? They will never be used unless the parent zones become insecure. What exactly does "DNSKEY unchecked, DSSET given" mean? I suppose that you have received the DSSET by the maintainer of the zone through an authenticated channel (if not, you shouldn't add the DLV record at all). Why doesn't that make it a secure entry point and why should you "check" the DNSKEY? Why do you include DLV records for zones that you know are broken? Obviously, this classification has no meaning for a resolver that does lookaside validation. All DLV Records in this zone must have been authenticated by you (and we all trust you, of course :-), or the scheme is useless. Or am I missing the point and this zone should be used as a repository for secure entry points from which one creates local trusted keys rather than use it as a true lookaside zone? Personally, I have come to the conclusion that I don't like it at all that my cache considers the entire DNS bogus when the DLV zone becomes unreachable or corrupted. I'll stick to my locally configured trusted keys and wait for the root to be signed. BTW, there are some nasty bugs in the DLV implementation in BIND up to 9.3.2 (e.g. see what happens when you corrupt the trusted key of your DLV zone, but don't do it on your production server :-) I've been told that it has been improved a lot for 9.4 and these changes will be backported to 9.3.3.
I'm looking for a *stable* ipv6 and dnssec able secondary server for our zones. If you like to exchange secondary DNS service in different AS, please contact me via OpenPGP mail.
Problem solved. Half a day after this message, Cable & Wireless announced, that the switched there DNS infrastructure (at least for secondaries) to DNSSEC. Great!
Cool. In case you still need secondaries, I can offer two in Switzerland with excellent IPv6 connectivity :-) -- Alex
* Alexander Gall wrote:
Why do you include DLV Records for Zones that are below a secure entry point (those you call "chained")? They will never be used unless the parent zones become insecure.
My tests show, that some resolvers only go one step back to the origin to check the lookaside data. So if you query for host.sub.do.main, these resolvers do only query for host.sub.do.main.trust.an.chor and sub.do.main.trust.an.chor. I have to dig this problem much deeper, to see iff this is a configuration or software issue. In order to keep the lookaside zone useful, I included the subzones. OTOH it's possible, that the parent zone becomes unsigned. In this case the sub zones become new SEPs. If would be the only reason, I'll move the DLV entries to TXT entries in order to keep them as a backup. Furthermore, I regulary check the validity of the DNSKEYs with the DS parent entries to detect errors in chaining (i.e. after rollover errors).
What exactly does "DNSKEY unchecked, DSSET given" mean? I suppose that you have received the DSSET by the maintainer of the zone through an authenticated channel (if not, you shouldn't add the DLV record at all). Why doesn't that make it a secure entry point and why should you "check" the DNSKEY?
This entry means: Somebody added a zone. This process generates the DS entry from the queried DNSKEY. If possible the DNSKEY is queried using DNSSEC authenication, so you can't add a sub zone of a signed parent zone without correct chaining. I should add the validation step for the person, who adds this zone, of course. Thanks for this suggestion. The daily maintainance check "drops" all entries an requeries them using the old lookaside zone. Only authenicated responses are used to rebuild the zone. In this step the parent chaining is checked, too. And sub zones are added, if possible using AXFR or (on dlv.verisignlabs.com) by NSEC traversing. For new SEPs there exists currently no trustly off-band validation. Because everybody can set up a signed zone, any attacker can sign any zone unter his control and provide any typical validation. I only check, that the real zone is really signed. I do not trust other name servers than the ICANN root (and myself). Of course it is possible to attack to my infrastructure in order to fool my name servers.
Why do you include DLV records for zones that you know are broken?
The check is done from my point of view. I do not assume permanent access to every zone in the internet. Some broken zones might be truly operational in other networks. I assume that ct.nl and fnl.nl are operational on nlnetlabs. I also assume that demo.netsec.tislabs.com is operational on tislabs. It might be helpful for operators to have an outside view to this zone. There might be an TCP/53 block between AS15725 and the authorized name servers. The name servers might be offline or the zone is expired on the secondaries. There even might be an routing loop like this one: traceroute to dnssec1.jprs.co.jp (2001:200:132::2) from 2001:4bd8:0:666:280:adff:fe1e:79ba ...huge IPv6 delay on C&W backbone in USA... 12 pc8.otemachi.wide.ad.jp (2001:200:0:4401::11) 299.067 ms 13 otemachi.dnslab.jp (2001:200:132:4::2) 299.889 ms 14 fuundo.dnslab.jp (2001:200:132:5::1) 301.206 ms 15 otemachi.dnslab.jp (2001:200:132:4::2) 301.584 ms
Obviously, this classification has no meaning for a resolver that does lookaside validation. All DLV Records in this zone must have been authenticated by you (and we all trust you, of course :-), or the scheme is useless.
Exactly. At the moment there is a large gap between trusting the unknown and stay unusable because there are no entries at all. My way might be to risky for you. That's ok. Any suggestion is welcome.
Or am I missing the point and this zone should be used as a repository for secure entry points from which one creates local trusted keys rather than use it as a true lookaside zone?
It serves both issues, but the main subject it to generate trust.
Personally, I have come to the conclusion that I don't like it at all that my cache considers the entire DNS bogus when the DLV zone becomes unreachable or corrupted.
You are free to set up a secondary. You will get notifies automatically. Of course invalid signatures are really bad. Because I switched almost all name server I admin to this zone, such a mistake will be noticed very quickly ;-)
I'll stick to my locally configured trusted keys and wait for the root to be signed.
Of course. Do you configure the trusted keys to every of your name servers? How do to keep them in sync? You you really believe to see a signed root this life?
BTW, there are some nasty bugs in the DLV implementation in BIND up to 9.3.2 (e.g. see what happens when you corrupt the trusted key of your DLV zone, but don't do it on your production server :-) I've been told that it has been improved a lot for 9.4 and these changes will be backported to 9.3.3.
Thanx. The problems with the Windows DNS server software are much harder to solve. Is there any rewrite out there? Or do we have to write one yourself?
In case you still need secondaries, I can offer two in Switzerland with excellent IPv6 connectivity :-)
Thank you. Currently I prefer to complain using your service contracts.
On Wed, 8 Feb 2006 12:01:30 +0000 (UTC), Lutz Donnerhacke <lutz@iks-jena.de> said:
* Alexander Gall wrote:
Why do you include DLV Records for Zones that are below a secure entry point (those you call "chained")? They will never be used unless the parent zones become insecure.
My tests show, that some resolvers only go one step back to the origin to check the lookaside data. So if you query for host.sub.do.main, these resolvers do only query for host.sub.do.main.trust.an.chor and sub.do.main.trust.an.chor.
But DLV is only applied to the apex of a secure subtree. Let's take 0.176.195.in-addr.arpa as an example. This involves two secure delegations. The resolver walks up the tree using regular DNSSEC until it finds that 195.in-addr.arpa is insecure. No DLV is involved up to this point. Only then does it try to see if it can authenticate the DNSKEY of 195.in-addr.arpa with DLV. The sub-zones are never considered for DLV. I think that doing anything else is just plain broken. But then again, there is no spec how DLV is supposed to work, so who can say what's right ;-)
I have to dig this problem much deeper, to see iff this is a configuration or software issue.
In order to keep the lookaside zone useful, I included the subzones.
OTOH it's possible, that the parent zone becomes unsigned. In this case the sub zones become new SEPs. If would be the only reason, I'll move the DLV entries to TXT entries in order to keep them as a backup.
Furthermore, I regulary check the validity of the DNSKEYs with the DS parent entries to detect errors in chaining (i.e. after rollover errors).
Interesting. And what do you do when the DS doesn't match the DNSKEY? For a rollover, if both keys (old and new) are in the DNSKEY RRset and the RRset is signed by the old key, you can safely roll the DS as well. In all other cases, you *must* keep the broken chain. This will render the zone bogus, but this is precisely what should happen.
What exactly does "DNSKEY unchecked, DSSET given" mean? I suppose that you have received the DSSET by the maintainer of the zone through an authenticated channel (if not, you shouldn't add the DLV record at all). Why doesn't that make it a secure entry point and why should you "check" the DNSKEY?
This entry means: Somebody added a zone. This process generates the DS entry from the queried DNSKEY. If possible the DNSKEY is queried using DNSSEC authenication, so you can't add a sub zone of a signed parent zone without correct chaining. I should add the validation step for the person, who adds this zone, of course. Thanks for this suggestion.
But you don't need DLV if the parent zone is signed! This is covered by plain DNSSEC.
The daily maintainance check "drops" all entries an requeries them using the old lookaside zone. Only authenicated responses are used to rebuild the zone.
I'm not sure I understand the use of this. Can you give an example of what new information you can discover this way (apart from catching roll-overs in progress)?
In this step the parent chaining is checked, too. And sub zones are added, if possible using AXFR or (on dlv.verisignlabs.com) by NSEC traversing.
For new SEPs there exists currently no trustly off-band validation. Because everybody can set up a signed zone, any attacker can sign any zone unter his control and provide any typical validation. I only check, that the real zone is really signed. I do not trust other name servers than the ICANN root (and myself).
Many of the current islands of security publish their SEPs over https. This looks all right to me if you check the certificates carefully. I think you should not accept unauthenticated SEPs at all.
Of course it is possible to attack to my infrastructure in order to fool my name servers.
Why do you include DLV records for zones that you know are broken?
The check is done from my point of view. I do not assume permanent access to every zone in the internet. Some broken zones might be truly operational in other networks. I assume that ct.nl and fnl.nl are operational on nlnetlabs. I also assume that demo.netsec.tislabs.com is operational on tislabs.
Then you can probably also assume that they configure their resolvers with their own trusted keys and don't use your DLV zone :-)
It might be helpful for operators to have an outside view to this zone. There might be an TCP/53 block between AS15725 and the authorized name servers.
The name servers might be offline or the zone is expired on the secondaries. There even might be an routing loop like this one: traceroute to dnssec1.jprs.co.jp (2001:200:132::2) from 2001:4bd8:0:666:280:adff:fe1e:79ba ...huge IPv6 delay on C&W backbone in USA... 12 pc8.otemachi.wide.ad.jp (2001:200:0:4401::11) 299.067 ms 13 otemachi.dnslab.jp (2001:200:132:4::2) 299.889 ms 14 fuundo.dnslab.jp (2001:200:132:5::1) 301.206 ms 15 otemachi.dnslab.jp (2001:200:132:4::2) 301.584 ms
Obviously, this classification has no meaning for a resolver that does lookaside validation. All DLV Records in this zone must have been authenticated by you (and we all trust you, of course :-), or the scheme is useless.
Exactly. At the moment there is a large gap between trusting the unknown and stay unusable because there are no entries at all. My way might be to risky for you. That's ok. Any suggestion is welcome.
My suggestion is to establish real trust. Yes, that's hard. But I can't see how you can do without.
Or am I missing the point and this zone should be used as a repository for secure entry points from which one creates local trusted keys rather than use it as a true lookaside zone?
It serves both issues, but the main subject it to generate trust.
Right, but this is precisely what's missing right now, isn't?
Personally, I have come to the conclusion that I don't like it at all that my cache considers the entire DNS bogus when the DLV zone becomes unreachable or corrupted.
You are free to set up a secondary. You will get notifies automatically. Of course invalid signatures are really bad. Because I switched almost all name server I admin to this zone, such a mistake will be noticed very quickly ;-)
Yes. But this may have severe consequences. Suppose admin X uses your DLV zone. An attacker DoSes all the server for this zone. X can't resolve any queries any more and decides to disable DNSSEC. Now all zones that were previously protected by DNSSEC are spoofable. You may say that this is also possible with plain DNSSEC. True, but then the damage is restricted to the subtree of the zone that's being DoSed, where as the entire DNS is considered to be a child of the DLV zone. DoSing the root zone is considerably harder than DoSing your hadful of name servers. The problem is that DLV acts a lot like the true root zone when it brakes, but only protects very few zones when it works (the absence of a key in the DLV zone has no real meaning, I think, compared to a "provably insecure" zone in plain DNSSEC).
I'll stick to my locally configured trusted keys and wait for the root to be signed.
Of course. Do you configure the trusted keys to every of your name servers? How do to keep them in sync?
You you really believe to see a signed root this life?
I don't know. But I believe that DNSSEC will fail if it doesn't happen. -- Alex
* Alexander Gall wrote:
But DLV is only applied to the apex of a secure subtree. Let's take 0.176.195.in-addr.arpa as an example. This involves two secure delegations. The resolver walks up the tree using regular DNSSEC until it finds that 195.in-addr.arpa is insecure. No DLV is involved up to this point. Only then does it try to see if it can authenticate the DNSKEY of 195.in-addr.arpa with DLV. The sub-zones are never considered for DLV. I think that doing anything else is just plain broken. But then again, there is no spec how DLV is supposed to work, so who can say what's right ;-)
Of course, I'll remove the DLV entries for chained zones. These resolvers need to be fixed, not the zone. Give me a day.
On Wed, 8 Feb 2006 12:01:30 +0000 (UTC), Lutz Donnerhacke <lutz@iks-jena.de> said:
Furthermore, I regulary check the validity of the DNSKEYs with the DS parent entries to detect errors in chaining (i.e. after rollover errors).
Interesting. And what do you do when the DS doesn't match the DNSKEY?
After the change tomorrow, the DLV entry will be inserted to keep in touch with the changed zone. It will dismiss, if the parent reflects the change. Such behavior will only happen, if the new key is signed with a valid old one. It's not required, that the new key is used for signing in this very moment. Might only be happen if the rollover period is too short or if the client do not notify the parent at all. Oh, the parent might also simply drop the DS record. In this case the formerly verified DNSKEYs are used to generate DLV entries. I'd should display an error indicator due to broken chaining.
For a rollover, if both keys (old and new) are in the DNSKEY RRset and the RRset is signed by the old key, you can safely roll the DS as well.
On usual rollover, all keys are valid as long as there exists a valid chain to each of them. Valid keys are retained for chain breaks. So normal rollover does not harm.
In all other cases, you *must* keep the broken chain. This will render the zone bogus, but this is precisely what should happen.
IBTD. From the operational point of view the error in chaining is much more likely to be an mistake, than a thought decision. The new DNSKEYs has to be signed to be accepted, so there must exists a operational action to break this chain while staying in the DLV. I prefer to keep the network running. DNSKEY changes without a trust chain from already trusted entries are not accepted, so classical attacks will not cause the DLV to show up the attackers key as valid.
This entry means: Somebody added a zone. This process generates the DS entry from the queried DNSKEY. If possible the DNSKEY is queried using DNSSEC authenication, so you can't add a sub zone of a signed parent zone without correct chaining. I should add the validation step for the person, who adds this zone, of course. Thanks for this suggestion.
But you don't need DLV if the parent zone is signed! This is covered by plain DNSSEC.
This case will change tomorrow to only notice the existance of the signed sub zone. Usually new entries are added as islands.
The daily maintainance check "drops" all entries an requeries them using the old lookaside zone. Only authenicated responses are used to rebuild the zone.
I'm not sure I understand the use of this. Can you give an example of what new information you can discover this way (apart from catching roll-overs in progress)?
Apart rollovers? I try to detect legitimate rollovers. But there are other kinds of key changes, which are detected in this way. As long as they match the rollover procedure, I try to keep in touch. OTOH it's a simple "reachable" check from outside.
For new SEPs there exists currently no trustly off-band validation. Because everybody can set up a signed zone, any attacker can sign any zone unter his control and provide any typical validation. I only check, that the real zone is really signed. I do not trust other name servers than the ICANN root (and myself).
Many of the current islands of security publish their SEPs over https. This looks all right to me if you check the certificates carefully.
Please let me smile. First: There is no canonical way to get the DNSKEY information automatically. Second: If the zone is under attackers control, each validation can be forged. You might refer to SSL certificates, but I do not trust most of those CAs. We are in the CA bussiness since about nine years. I lost all my illusions.
I think you should not accept unauthenticated SEPs at all.
If I do not accept it, the zone can only be used unsigned. What a security improvement!
The check is done from my point of view. I do not assume permanent access to every zone in the internet. Some broken zones might be truly operational in other networks. I assume that ct.nl and fnl.nl are operational on nlnetlabs. I also assume that demo.netsec.tislabs.com is operational on tislabs.
Then you can probably also assume that they configure their resolvers with their own trusted keys and don't use your DLV zone :-)
I do not claim my assumptions as true. If you can reach those zones, the DLV entry might be useful. If you can't reach those zones, they do not harm you.
Exactly. At the moment there is a large gap between trusting the unknown and stay unusable because there are no entries at all. My way might be to risky for you. That's ok. Any suggestion is welcome.
My suggestion is to establish real trust. Yes, that's hard. But I can't see how you can do without.
It's very possible to be too paranoid. Unrelated and uncheckable information can be considered true without any damage. That's why I include it.
You are free to set up a secondary. You will get notifies automatically. Of course invalid signatures are really bad. Because I switched almost all name server I admin to this zone, such a mistake will be noticed very quickly ;-)
Yes. But this may have severe consequences. Suppose admin X uses your DLV zone. An attacker DoSes all the server for this zone.
If X set up a secondary (as recommened), the DoS does not harm unless the zone times out. In this case X get's a notice from its own name server and can use the secondary data as primary, if necessary. But if X has a minimal interest in his infrastructure, he will notice such a DoS of a "partner" much earlier. If the zone times out due to such an attack, it's very likely that my company does not exists anymore. So X has to contact an other source anyway.
X can't resolve any queries any more and decides to disable DNSSEC. Now all zones that were previously protected by DNSSEC are spoofable.
X has a long transition period to change. X is not required to disable DNSSEC at all, because backup data is available.
You may say that this is also possible with plain DNSSEC. True, but then the damage is restricted to the subtree of the zone that's being DoSed, where as the entire DNS is considered to be a child of the DLV zone. DoSing the root zone is considerably harder than DoSing your hadful of name servers.
Ack.
The problem is that DLV acts a lot like the true root zone when it brakes, but only protects very few zones when it works (the absence of a key in the DLV zone has no real meaning, I think, compared to a "provably insecure" zone in plain DNSSEC).
Nack. Provably insecure is not caused by unreachablity of a name server. It is caused by reaching the server and get a signed answer.
I'll stick to my locally configured trusted keys and wait for the root to be signed.
Of course. Do you configure the trusted keys to every of your name servers? How do to keep them in sync?
I'm really interested in an answer to this question, because this was the basic reason to set up the lookaside zone.
You you really believe to see a signed root this life?
I don't know. But I believe that DNSSEC will fail if it doesn't happen.
Global requirements are the main reason to fail projects. It would be nice to have, but it's unlikely. So we have to deal with. BTW: Congratulations to your signings. Your zones does appear last night in my monitoring and I'm very happy to see that deployment increases.
On Wed, 8 Feb 2006 17:35:44 +0000 (UTC), Lutz Donnerhacke <lutz@iks-jena.de> said:
* Alexander Gall wrote:
On Wed, 8 Feb 2006 12:01:30 +0000 (UTC), Lutz Donnerhacke <lutz@iks-jena.de> said:
Furthermore, I regulary check the validity of the DNSKEYs with the DS parent entries to detect errors in chaining (i.e. after rollover errors).
Interesting. And what do you do when the DS doesn't match the DNSKEY?
After the change tomorrow, the DLV entry will be inserted to keep in touch with the changed zone. It will dismiss, if the parent reflects the change.
Such behavior will only happen, if the new key is signed with a valid old one. It's not required, that the new key is used for signing in this very moment. Might only be happen if the rollover period is too short or if the client do not notify the parent at all.
Oh, the parent might also simply drop the DS record. In this case the formerly verified DNSKEYs are used to generate DLV entries.
I'd should display an error indicator due to broken chaining.
For a rollover, if both keys (old and new) are in the DNSKEY RRset and the RRset is signed by the old key, you can safely roll the DS as well.
On usual rollover, all keys are valid as long as there exists a valid chain to each of them. Valid keys are retained for chain breaks. So normal rollover does not harm.
Yes, that's what I meant.
In all other cases, you *must* keep the broken chain. This will render the zone bogus, but this is precisely what should happen.
IBTD. From the operational point of view the error in chaining is much more likely to be an mistake, than a thought decision. The new DNSKEYs has to be signed to be accepted, so there must exists a operational action to break this chain while staying in the DLV. I prefer to keep the network running.
Surely you don't mean to say that you remove a DLV RR when it no longer authenticates the DNSKEY RRset. Or are you? I might misunderstand what you mean by "keep the network running", so I'll try to rephrase what I wanted to say. DNSSEC doesn't tolerate mistakes that break the chain of trust because it can't be distinguished from an attack. Now, it would be perfectly fine for an end user to decide for himself whether he wants to accept the bogus information or not, but, of course, that's impossible without an API or DNSSEC support in the stub resolver which allows for a local policy. In any case, DNSSEC must provide this information (i.e. that the delegation is broken).
DNSKEY changes without a trust chain from already trusted entries are not accepted, so classical attacks will not cause the DLV to show up the attackers key as valid.
That would be really bad. I tried to argue that removing the DLV must not be done either.
The daily maintainance check "drops" all entries an requeries them using the old lookaside zone. Only authenicated responses are used to rebuild the zone.
I'm not sure I understand the use of this. Can you give an example of what new information you can discover this way (apart from catching roll-overs in progress)?
Apart rollovers? I try to detect legitimate rollovers. But there are other kinds of key changes, which are detected in this way. As long as they match the rollover procedure, I try to keep in touch. OTOH it's a simple "reachable" check from outside.
Sorry, I didn't realize that the main purpose of your daily job was checking for rollovers. We are in violent agreement here.
For new SEPs there exists currently no trustly off-band validation. Because everybody can set up a signed zone, any attacker can sign any zone unter his control and provide any typical validation. I only check, that the real zone is really signed. I do not trust other name servers than the ICANN root (and myself).
Many of the current islands of security publish their SEPs over https. This looks all right to me if you check the certificates carefully.
Please let me smile. First: There is no canonical way to get the DNSKEY information automatically. Second: If the zone is under attackers control, each validation can be forged.
I'm talking about OOB methods, of course (like <https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys.txt>).
You might refer to SSL certificates, but I do not trust most of those CAs. We are in the CA bussiness since about nine years. I lost all my illusions.
I know that PKIs are not what they were promised to be, but they are not completely worthless either. I try to maintain a level of trust that I feel comfortable with.
I think you should not accept unauthenticated SEPs at all.
If I do not accept it, the zone can only be used unsigned. What a security improvement!
Um, I prefer an unsigned zone over one whose signatures I cannot trust. What is the improvement there? [...]
Exactly. At the moment there is a large gap between trusting the unknown and stay unusable because there are no entries at all. My way might be to risky for you. That's ok. Any suggestion is welcome.
My suggestion is to establish real trust. Yes, that's hard. But I can't see how you can do without.
It's very possible to be too paranoid. Unrelated and uncheckable information can be considered true without any damage. That's why I include it.
As I said, it should be up to the user to decide whether he want's to use the information or not (just like he can chose to accept a bogus SSL certificate, which can be perfectly harmless, too). That's not the point, though. Signatures are completely useless without trust. It's even worse because they can give the casual user a false sense of security. I'm sure you know that better than me. Without trust, this whole excercise is essentially a test of DNSSEC implementations. That's fine, too, but it needs to be stated clearly.
You are free to set up a secondary. You will get notifies automatically. Of course invalid signatures are really bad. Because I switched almost all name server I admin to this zone, such a mistake will be noticed very quickly ;-)
Yes. But this may have severe consequences. Suppose admin X uses your DLV zone. An attacker DoSes all the server for this zone.
If X set up a secondary (as recommened), the DoS does not harm unless the
Having all users of the DLV zone become a secondary doesn't scale (because of the size of the NS RRset and possibly the load on the master).
zone times out. In this case X get's a notice from its own name server and can use the secondary data as primary, if necessary. But if X has a minimal interest in his infrastructure, he will notice such a DoS of a "partner" much earlier. If the zone times out due to such an attack, it's very likely that my company does not exists anymore. So X has to contact an other source anyway.
X can't resolve any queries any more and decides to disable DNSSEC. Now all zones that were previously protected by DNSSEC are spoofable.
X has a long transition period to change. X is not required to disable DNSSEC at all, because backup data is available.
I think this would be equivalent to the following. Let people download a signed file with the keys and install them as trusted keys in their servers (the key that signs the file would have to be authenticated just like the one for the zone dnssec.iks-jena.de). If all the information is local anyway, DLV would then just be a complicated way to check a local trust anchor. Using an established mechanism (AXFR) to distribute the zone is nice, but it's not a necessity (oops, I'm starting to sound like Dan Bernstein ;-) [...]
The problem is that DLV acts a lot like the true root zone when it brakes, but only protects very few zones when it works (the absence of a key in the DLV zone has no real meaning, I think, compared to a "provably insecure" zone in plain DNSSEC).
Nack. Provably insecure is not caused by unreachablity of a name server. It is caused by reaching the server and get a signed answer.
I'm not talking about unreachable servers but about getting a prove that a particular name does not exist in the DLV zone. What does it mean? It's the same as not having a local trust anchor configured for the zone, but it does not constitute a prove that the zone is unsigned. So, you have less information about the zone than when you get prove from the parent zone that no DS RRset exists. Essentially, you don't learn anything about zones that are not in the DLV zone, and yet, all of these zones are considered compromised when the DLV zone is broken. This trade-off is what bothers me the most.
I'll stick to my locally configured trusted keys and wait for the root to be signed.
Of course. Do you configure the trusted keys to every of your name servers? How do to keep them in sync?
I'm really interested in an answer to this question, because this was the basic reason to set up the lookaside zone.
This is easy. I centrally maintain a BIND configuration snippet for the "trusetd-key" clause and push it to my caching servers with scp (I also do some failsafe checking that the config is OK before doing a "rndc reconfig"). It's simple and reliable. The situation is a bit like with the now deprecated A6 RR. Renumbering your own DNS zones is easy. All you need is a bit of discipline and a perl script. You don't need A6 for that. The true value of A6 would have been renumbering across administative boundaries. Similarly, DLV is only needed if you use a "regular" DLV zone. If everybody keeps a local copy of the zone as you suggest, DLV is just overhead, as I tried to explain above.
You you really believe to see a signed root this life?
I don't know. But I believe that DNSSEC will fail if it doesn't happen.
Global requirements are the main reason to fail projects. It would be nice to have, but it's unlikely. So we have to deal with.
DNS just happens to be a global infrastructure :-) Idon't think it would have worked if it had started as a heap of disconnected pieces patched together by a mechanism that doesn't scale. If it were just a technological issue, I'd be all for it and use any hack to get it going (I should know, because I'm a long-term IPv6 and multicast user ;-) Unfortunatley, I don't think this will do much good if security is the main objective.
BTW: Congratulations to your signings. Your zones does appear last night in my monitoring and I'm very happy to see that deployment increases.
Yeah, I hadn't realized that RIPE NCC had signed 6.0.1.0.0.2.ip6.arpa until I spotted the entry on your site. Our zone 195.176.in-addr.arpa has been securely delegated since November. -- Alex
* Alexander Gall wrote:
IBTD. From the operational point of view the error in chaining is much more likely to be an mistake, than a thought decision. The new DNSKEYs has to be signed to be accepted, so there must exists a operational action to break this chain while staying in the DLV. I prefer to keep the network running.
Surely you don't mean to say that you remove a DLV RR when it no longer authenticates the DNSKEY RRset. Or are you?
No, I cleaned up the verification step so that DLVs are updated using the following parameters: Keys : valid, signed DNSKEYs DSs : valid, signed DS parent entries Old : DS entries from the active DLV zone If Keys and DSs exists, no DLV is generated. If Keys exists, DLVs are generated. If DSs exists, DLVs are generated for 30 days. If Old exists, DLVs are generated for 7 days.
DNSSEC doesn't tolerate mistakes that break the chain of trust because it can't be distinguished from an attack.
On rollover it's very likly to do not get the parent updated or the parent restores an old entry by accident. In this case, I generate DLVs based on validated information. I can't see what's wrong with it.
Now, it would be perfectly fine for an end user to decide for himself whether he wants to accept the bogus information or not, but, of course, that's impossible without an API or DNSSEC support in the stub resolver which allows for a local policy. In any case, DNSSEC must provide this information (i.e. that the delegation is broken).
Please explain why and how a delegation can break. This will clarify why I prefer to keep former validated data active.
Sorry, I didn't realize that the main purpose of your daily job was checking for rollovers. We are in violent agreement here.
The main purpose of providing a DLV zone is to keep this zone in sync with reality. I do not expect all DNSSEC opertators to update there keys on my website. So I have to do it myself.
Please let me smile. First: There is no canonical way to get the DNSKEY information automatically. Second: If the zone is under attackers control, each validation can be forged.
I'm talking about OOB methods, of course (like <https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys.txt>).
This page is used. On most other cases there is no way to be sure.
You might refer to SSL certificates, but I do not trust most of those CAs. We are in the CA bussiness since about nine years. I lost all my illusions.
I know that PKIs are not what they were promised to be, but they are not completely worthless either. I try to maintain a level of trust that I feel comfortable with.
Please explain how a PKI can be used, if the common ones are not trustworthy and most DNSSEC operators does offer there keys on various unstandardized ways. I can't see any automatic check usable. There are 418 island of trust in the DLV zone at the moment. Please try and check some of the unknown yourself.
I think you should not accept unauthenticated SEPs at all.
If I do not accept it, the zone can only be used unsigned. What a security improvement!
Um, I prefer an unsigned zone over one whose signatures I cannot trust. What is the improvement there?
If the keys are correct, you gain a valid signed zone. If the keys are wrong, you can be fooled about the zone content. If the keys are missing, you can be fooled about the zone content. The attacker has to modify the zone in order to get it listed in my list. If the attacker had modified the zone, the unsigned information are ...
It's very possible to be too paranoid. Unrelated and uncheckable information can be considered true without any damage. That's why I include it.
As I said, it should be up to the user to decide whether he want's to use the information or not
So you need a checklist with about 500 entries now customizable for each user. Not my task. Sorry.
Signatures are completely useless without trust.
No signatures are better?
It's even worse because they can give the casual user a false sense of security. I'm sure you know that better than me. Without trust, this whole excercise is essentially a test of DNSSEC implementations. That's fine, too, but it needs to be stated clearly.
DNSSEC does not provide security in the common sense. It protects DNS to intermedeate changes. This can be achived.
If X set up a secondary (as recommened), the DoS does not harm unless the
Having all users of the DLV zone become a secondary doesn't scale (because of the size of the NS RRset and possibly the load on the master).
I do not include them into the zone. They get notifies. That's all.
X has a long transition period to change. X is not required to disable DNSSEC at all, because backup data is available.
I think this would be equivalent to the following. Let people download a signed file with the keys and install them as trusted keys in their servers (the key that signs the file would have to be authenticated just like the one for the zone dnssec.iks-jena.de). If all the information is local anyway, DLV would then just be a complicated way to check a local trust anchor. Using an established mechanism (AXFR) to distribute the zone is nice, but it's not a necessity (oops, I'm starting to sound like Dan Bernstein ;-)
Of course. This is the distribution step I mentioned. It's easier to maintain using a DLV zone, than synching a lot of keys. Do rollover detection on those keys automatically and you end up in methods I use. If you do not maintain the key list, it's useless.
Nack. Provably insecure is not caused by unreachablity of a name server. It is caused by reaching the server and get a signed answer.
I'm not talking about unreachable servers but about getting a prove that a particular name does not exist in the DLV zone. What does it mean?
Nothing. The zone can't be checked even if it is signed.
but it does not constitute a prove that the zone is unsigned.
DLVs does not prove the signedness of a zone.
So, you have less information about the zone than when you get prove from the parent zone that no DS RRset exists.
If the parent has DS records, the zone is not in the DLV. The parent is.
Essentially, you don't learn anything about zones that are not in the DLV zone, and yet, all of these zones are considered compromised when the DLV zone is broken. This trade-off is what bothers me the most.
DLVs are a distribution medium. If the distribution of your key files breaks, you get an equivalent disaster.
Of course. Do you configure the trusted keys to every of your name servers? How do to keep them in sync?
I'm really interested in an answer to this question, because this was the basic reason to set up the lookaside zone.
This is easy. I centrally maintain a BIND configuration snippet for the "trusetd-key" clause and push it to my caching servers with scp (I also do some failsafe checking that the config is OK before doing a "rndc reconfig"). It's simple and reliable.
I do not like to maintain a list of servers to push configuration to. Often I even can not do this because those machines are not mine or not reachable for typical distribution mechanisms. How many entries do you maintain in your trust key file? Are they still valid?
boundaries. Similarly, DLV is only needed if you use a "regular" DLV zone. If everybody keeps a local copy of the zone as you suggest, DLV is just overhead, as I tried to explain above.
Setting up an hidden secondary is not an overhead.
Global requirements are the main reason to fail projects. It would be nice to have, but it's unlikely. So we have to deal with.
DNS just happens to be a global infrastructure :-)
IPv6 either. Do we have it all over the world?
Idon't think it would have worked if it had started as a heap of disconnected pieces patched together by a mechanism that doesn't scale.
I assume it scales. YMMV.
If it were just a technological issue, I'd be all for it and use any hack to get it going (I should know, because I'm a long-term IPv6 and multicast user ;-) Unfortunatley, I don't think this will do much good if security is the main objective.
I do think of DNSSEC deployment as a technological issue. Did you notice, that dnssec-deployment.org is not signed ;-?
BTW: Congratulations to your signings. Your zones does appear last night in my monitoring and I'm very happy to see that deployment increases.
Yeah, I hadn't realized that RIPE NCC had signed 6.0.1.0.0.2.ip6.arpa until I spotted the entry on your site. Our zone 195.176.in-addr.arpa has been securely delegated since November.
Great. An now you will notice, that some entries are going dead ...
* Lutz Donnerhacke wrote:
In order to extend the deployment of security technology, we switch to DNSSEC for us and our customers. [...] This is the reason why, we set up an other DLV zone.
Please do *not* try to use this zone with any public available bind version. There is a bug in long time behaivor of the caching algorithms. Invalidating of cache entries occurs unrelated to DNSSEC. This causes invalidating of any signed entries over the time. The race condition caused by cache invalitation is large enough to hit the lookaside zone itself after some hours on a busy server. Normal usage hits the problem after some days. Due to the bind architecture, even authorized servers can be unable to deliver there own data. Look for "empty name resolving" entries in the logfiles. Unfortunly there is no working DNSSECable DNS server software out at all.
dns-wg-admin@ripe.net wrote on 14-02-2006 12:16:57:
* Lutz Donnerhacke wrote:
In order to extend the deployment of security technology, we switch to DNSSEC for us and our customers. [...] This is the reason why, we set up an other DLV zone.
Please do *not* try to use this zone with any public available bind version. There is a bug in long time behaivor of the caching algorithms. Invalidating of cache entries occurs unrelated to DNSSEC. This causes invalidating of any signed entries over the time. The race condition caused by cache invalitation is large enough to hit the lookaside zone itself after some hours on a busy server. Normal usage hits the problem after some days. Due to the bind architecture, even authorized servers can be unable to deliver there own data.
Look for "empty name resolving" entries in the logfiles.
Unfortunly there is no working DNSSECable DNS server software out at all.
Try unbound as a validating DNSSEC resolver. http://www.rfc.se/unbound Roy
participants (3)
-
Alexander Gall -
Lutz Donnerhacke -
Roy.Arends＠nominet.org.uk