<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_11_16_1933256</id>
	<title>DNSSEC Implementation Held Up By Tech Delays</title>
	<author>timothy</author>
	<datestamp>1258400400000</datestamp>
	<htmltext>Jack Spine writes <i>"VeriSign has said that the main obstacle to <a href="//it.slashdot.org/story/09/02/24/2114206/VeriSign-Will-Support-DNSSEC-In-com-By-2011">DNSSEC implementation</a> has been <a href="http://news.zdnet.co.uk/security/0,1000000189,39877966,00.htm">technical delays</a>. The large size of the .com and .net domains would have made it impractical to deploy earlier versions of DNSSEC, according to VeriSign vice president of naming services Pat Kane. Deployment of DNSSEC will close a major security flaw in the DNS, the internet's equivalent to a telephone directory. The problem of DNS cache poisoning was <a href="//it.slashdot.org/story/08/07/21/2212227/Kaminskys-DNS-Attack-Disclosed-Then-Pulled">thrown into sharp relief by researcher Dan Kaminsky last year</a>."</i></htmltext>
<tokenext>Jack Spine writes " VeriSign has said that the main obstacle to DNSSEC implementation has been technical delays .
The large size of the .com and .net domains would have made it impractical to deploy earlier versions of DNSSEC , according to VeriSign vice president of naming services Pat Kane .
Deployment of DNSSEC will close a major security flaw in the DNS , the internet 's equivalent to a telephone directory .
The problem of DNS cache poisoning was thrown into sharp relief by researcher Dan Kaminsky last year .
"</tokentext>
<sentencetext>Jack Spine writes "VeriSign has said that the main obstacle to DNSSEC implementation has been technical delays.
The large size of the .com and .net domains would have made it impractical to deploy earlier versions of DNSSEC, according to VeriSign vice president of naming services Pat Kane.
Deployment of DNSSEC will close a major security flaw in the DNS, the internet's equivalent to a telephone directory.
The problem of DNS cache poisoning was thrown into sharp relief by researcher Dan Kaminsky last year.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30127542</id>
	<title>Re:Why use digital signatures?</title>
	<author>TheRaven64</author>
	<datestamp>1258461060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That is the idea.  However, once you have DNS records that you can guarantee are authoritative, it's possible to store a key along with the address-to-name mapping.  RFC 4025, for example, provides a way of putting IPSEC keys into DNS.  These can then be used to establish an end-to-end encrypted connection at the IP layer so every packet sent to the IP looked up by the DNS query is encrypted.  This eliminates most of the need for SSL on any protocol, because the connection is secured at a lower level.  <p>
CAs generally try to take this one step further and certify not only that you're connecting to the domain that you requested, but that the domain is owned by the right person or company.  For example, when you go to paypal.com, you should get a thing saying 'PayPal Inc.' somewhere in your browser UI.  DNSSEC + IPSEC does not provide this assurance (although, given the stories in recent years of how easy it is to get CAs like Verisign to sign fake requests, CAs don't really either).</p></htmltext>
<tokenext>That is the idea .
However , once you have DNS records that you can guarantee are authoritative , it 's possible to store a key along with the address-to-name mapping .
RFC 4025 , for example , provides a way of putting IPSEC keys into DNS .
These can then be used to establish an end-to-end encrypted connection at the IP layer so every packet sent to the IP looked up by the DNS query is encrypted .
This eliminates most of the need for SSL on any protocol , because the connection is secured at a lower level .
CAs generally try to take this one step further and certify not only that you 're connecting to the domain that you requested , but that the domain is owned by the right person or company .
For example , when you go to paypal.com , you should get a thing saying 'PayPal Inc. ' somewhere in your browser UI .
DNSSEC + IPSEC does not provide this assurance ( although , given the stories in recent years of how easy it is to get CAs like Verisign to sign fake requests , CAs do n't really either ) .</tokentext>
<sentencetext>That is the idea.
However, once you have DNS records that you can guarantee are authoritative, it's possible to store a key along with the address-to-name mapping.
RFC 4025, for example, provides a way of putting IPSEC keys into DNS.
These can then be used to establish an end-to-end encrypted connection at the IP layer so every packet sent to the IP looked up by the DNS query is encrypted.
This eliminates most of the need for SSL on any protocol, because the connection is secured at a lower level.
CAs generally try to take this one step further and certify not only that you're connecting to the domain that you requested, but that the domain is owned by the right person or company.
For example, when you go to paypal.com, you should get a thing saying 'PayPal Inc.' somewhere in your browser UI.
DNSSEC + IPSEC does not provide this assurance (although, given the stories in recent years of how easy it is to get CAs like Verisign to sign fake requests, CAs don't really either).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121198</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120610</id>
	<title>Re:Can someone explain ZSK and KSK?</title>
	<author>Anonymous</author>
	<datestamp>1258362420000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>-1</modscore>
	<htmltext><p>http://en.wikipedia.org/wiki/Domain\_Name\_System\_Security\_Extensions</p></htmltext>
<tokenext>http : //en.wikipedia.org/wiki/Domain \ _Name \ _System \ _Security \ _Extensions</tokentext>
<sentencetext>http://en.wikipedia.org/wiki/Domain\_Name\_System\_Security\_Extensions</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120998</id>
	<title>Re:Why use digital signatures?</title>
	<author>Burdell</author>
	<datestamp>1258364100000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>You should understand DNSSEC before criticizing it.  It doesn't work with SSL-style certificates that have to be signed by a recognized certificate authority.  Also, it doesn't change the existing protocol, it extends it in a (mostly) backwards-compatible way.  DNS servers just have to know how to request and handle the new additional records; old servers and clients keep working fine.</p><p>Your proposed solutions only fix one small piece of the DNS problem, that of spoofed network packets.  DNSSEC authenticates the entire response chain, so that (for example) you can be sure that your ISP isn't modifying responses to point you somewhere else (such as their servers) rather than what you requested.</p><p>With DNSSEC, you could possibly eliminate the SSL certificate authorities and use signed DNS records to include the certificate information (so you can make sure that when you go to <a href="https://www.foo.com/" title="foo.com">https://www.foo.com/</a> [foo.com], you really got www.foo.com's certificate and not that of a man-in-the-middle attacker).</p></htmltext>
<tokenext>You should understand DNSSEC before criticizing it .
It does n't work with SSL-style certificates that have to be signed by a recognized certificate authority .
Also , it does n't change the existing protocol , it extends it in a ( mostly ) backwards-compatible way .
DNS servers just have to know how to request and handle the new additional records ; old servers and clients keep working fine.Your proposed solutions only fix one small piece of the DNS problem , that of spoofed network packets .
DNSSEC authenticates the entire response chain , so that ( for example ) you can be sure that your ISP is n't modifying responses to point you somewhere else ( such as their servers ) rather than what you requested.With DNSSEC , you could possibly eliminate the SSL certificate authorities and use signed DNS records to include the certificate information ( so you can make sure that when you go to https : //www.foo.com/ [ foo.com ] , you really got www.foo.com 's certificate and not that of a man-in-the-middle attacker ) .</tokentext>
<sentencetext>You should understand DNSSEC before criticizing it.
It doesn't work with SSL-style certificates that have to be signed by a recognized certificate authority.
Also, it doesn't change the existing protocol, it extends it in a (mostly) backwards-compatible way.
DNS servers just have to know how to request and handle the new additional records; old servers and clients keep working fine.Your proposed solutions only fix one small piece of the DNS problem, that of spoofed network packets.
DNSSEC authenticates the entire response chain, so that (for example) you can be sure that your ISP isn't modifying responses to point you somewhere else (such as their servers) rather than what you requested.With DNSSEC, you could possibly eliminate the SSL certificate authorities and use signed DNS records to include the certificate information (so you can make sure that when you go to https://www.foo.com/ [foo.com], you really got www.foo.com's certificate and not that of a man-in-the-middle attacker).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30126454</id>
	<title>Re:Technical delays, Yeah Right.</title>
	<author>WolfWithoutAClause</author>
	<datestamp>1258400580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There was also a political argument about who should be the root signatory.</p><p>Since I would expect that the root signatory is able to forge DNS records for any part of the internet (or some such thing), it might be perhaps cynical of me to suggest that this wasn't entirely the simple prestige thing that everyone claimed it to be.<nobr> <wbr></nobr>;-)</p></htmltext>
<tokenext>There was also a political argument about who should be the root signatory.Since I would expect that the root signatory is able to forge DNS records for any part of the internet ( or some such thing ) , it might be perhaps cynical of me to suggest that this was n't entirely the simple prestige thing that everyone claimed it to be .
; - )</tokentext>
<sentencetext>There was also a political argument about who should be the root signatory.Since I would expect that the root signatory is able to forge DNS records for any part of the internet (or some such thing), it might be perhaps cynical of me to suggest that this wasn't entirely the simple prestige thing that everyone claimed it to be.
;-)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120430</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30122498</id>
	<title>Re:Can someone explain ZSK and KSK?</title>
	<author>hardaker</author>
	<datestamp>1258369440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Because DNS tries to keep replies as small as possible for most of the data they introduced two types of keys into DNSSEC.  One is a Zone Signing Key (ZSK) which signs all the data in a zone.  The other is a Key Signing Key (KSK) which is used to sign <b>just</b> they keys in the zone (both ZSKs and KSKs are signed by it and the ZSK signs they keys too for that matter).  This provides a number of benefits.  Some people believe that ZSKs can be smaller and you can change them more frequently (on the order of every 1-6 months).  Since the only one that signs these keys is the zone owner it's very easy to swap in a new ZSK (there are some timing issues involved, but there is no third-party communication that has to happen).  Some people also use the fact that ZSKs can be easily replaced to treat them with a bit less protection security and key them online (required for dynamic DNS support) or in a less security containment system which lets them be used more easily and freely (e.g. for DNS zones that change frequently).  The KSK only needs to be brought out when the signatures on the keys are expiring or the keys need changing.  When you change a KSK, however, you typically need to inform your parent (e.g.<nobr> <wbr></nobr>.com) about the key change so that they can sign your new KSK (by signing a DS fingerprinting record).  This is more of a pain, so people tend to only want to change KSKs on a infrequent basis (2-5 years is the common thinking).</htmltext>
<tokenext>Because DNS tries to keep replies as small as possible for most of the data they introduced two types of keys into DNSSEC .
One is a Zone Signing Key ( ZSK ) which signs all the data in a zone .
The other is a Key Signing Key ( KSK ) which is used to sign just they keys in the zone ( both ZSKs and KSKs are signed by it and the ZSK signs they keys too for that matter ) .
This provides a number of benefits .
Some people believe that ZSKs can be smaller and you can change them more frequently ( on the order of every 1-6 months ) .
Since the only one that signs these keys is the zone owner it 's very easy to swap in a new ZSK ( there are some timing issues involved , but there is no third-party communication that has to happen ) .
Some people also use the fact that ZSKs can be easily replaced to treat them with a bit less protection security and key them online ( required for dynamic DNS support ) or in a less security containment system which lets them be used more easily and freely ( e.g .
for DNS zones that change frequently ) .
The KSK only needs to be brought out when the signatures on the keys are expiring or the keys need changing .
When you change a KSK , however , you typically need to inform your parent ( e.g .
.com ) about the key change so that they can sign your new KSK ( by signing a DS fingerprinting record ) .
This is more of a pain , so people tend to only want to change KSKs on a infrequent basis ( 2-5 years is the common thinking ) .</tokentext>
<sentencetext>Because DNS tries to keep replies as small as possible for most of the data they introduced two types of keys into DNSSEC.
One is a Zone Signing Key (ZSK) which signs all the data in a zone.
The other is a Key Signing Key (KSK) which is used to sign just they keys in the zone (both ZSKs and KSKs are signed by it and the ZSK signs they keys too for that matter).
This provides a number of benefits.
Some people believe that ZSKs can be smaller and you can change them more frequently (on the order of every 1-6 months).
Since the only one that signs these keys is the zone owner it's very easy to swap in a new ZSK (there are some timing issues involved, but there is no third-party communication that has to happen).
Some people also use the fact that ZSKs can be easily replaced to treat them with a bit less protection security and key them online (required for dynamic DNS support) or in a less security containment system which lets them be used more easily and freely (e.g.
for DNS zones that change frequently).
The KSK only needs to be brought out when the signatures on the keys are expiring or the keys need changing.
When you change a KSK, however, you typically need to inform your parent (e.g.
.com) about the key change so that they can sign your new KSK (by signing a DS fingerprinting record).
This is more of a pain, so people tend to only want to change KSKs on a infrequent basis (2-5 years is the common thinking).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121496</id>
	<title>Obligatory</title>
	<author>mac1235</author>
	<datestamp>1258366200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Young whipper-snappers!  Back when I wanted a secure DNS server, I had to use djbdns!  And this was before it was it was open-sourced, no apt-get or rpm -i for me.  Why back in my days, you had to set your IP address yourself, none of this new-fangled DHCP....
mutter mutter Arcnet! mutter...</htmltext>
<tokenext>Young whipper-snappers !
Back when I wanted a secure DNS server , I had to use djbdns !
And this was before it was it was open-sourced , no apt-get or rpm -i for me .
Why back in my days , you had to set your IP address yourself , none of this new-fangled DHCP... . mutter mutter Arcnet !
mutter.. .</tokentext>
<sentencetext>Young whipper-snappers!
Back when I wanted a secure DNS server, I had to use djbdns!
And this was before it was it was open-sourced, no apt-get or rpm -i for me.
Why back in my days, you had to set your IP address yourself, none of this new-fangled DHCP....
mutter mutter Arcnet!
mutter...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120778</id>
	<title>Re:Can someone explain ZSK and KSK?</title>
	<author>nine-times</author>
	<datestamp>1258363200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>IANAE, but it sounds like the KSK is used to sign all the other keys to assure their validity.  So you have a KSK for all of DNS, and you use that to sign ZSKs for each TLD...?
</p><p>I don't really know, but it seemed like it might be more helpful to guess and let someone correct me than to just post a link to a long technical explanation.</p></htmltext>
<tokenext>IANAE , but it sounds like the KSK is used to sign all the other keys to assure their validity .
So you have a KSK for all of DNS , and you use that to sign ZSKs for each TLD... ?
I do n't really know , but it seemed like it might be more helpful to guess and let someone correct me than to just post a link to a long technical explanation .</tokentext>
<sentencetext>IANAE, but it sounds like the KSK is used to sign all the other keys to assure their validity.
So you have a KSK for all of DNS, and you use that to sign ZSKs for each TLD...?
I don't really know, but it seemed like it might be more helpful to guess and let someone correct me than to just post a link to a long technical explanation.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121126</id>
	<title>Re:Why use digital signatures?</title>
	<author>JesseMcDonald</author>
	<datestamp>1258364700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever.</p></div><p>I don't see anything in the DNSSEC specs which would require any external chain-of-trust similar to the current CA system. You just need a secure way to update your resource records with your registrar, which includes your DS (designated signer) record, a public key of your choosing. There's no authentication involved beyond your credentials to update the domain. It's too early to be sure, but this should be included with the purchase of a domain. Once you have your DS record in place you can use it to designate signers for any subdomains.</p><p>You could even use it to sign a resource record containing your web server's public TLS key, which allows a real solution to the problem of encryption-only websites: a self-signed certificate which can be securely matched against the host domain, preventing the trivial MITM attacks which currently render such certificates useless. CA-signed certificates would still be useful for establishing real-world identity, of course.</p></div>
	</htmltext>
<tokenext>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $ 100/year or whatever.I do n't see anything in the DNSSEC specs which would require any external chain-of-trust similar to the current CA system .
You just need a secure way to update your resource records with your registrar , which includes your DS ( designated signer ) record , a public key of your choosing .
There 's no authentication involved beyond your credentials to update the domain .
It 's too early to be sure , but this should be included with the purchase of a domain .
Once you have your DS record in place you can use it to designate signers for any subdomains.You could even use it to sign a resource record containing your web server 's public TLS key , which allows a real solution to the problem of encryption-only websites : a self-signed certificate which can be securely matched against the host domain , preventing the trivial MITM attacks which currently render such certificates useless .
CA-signed certificates would still be useful for establishing real-world identity , of course .</tokentext>
<sentencetext>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever.I don't see anything in the DNSSEC specs which would require any external chain-of-trust similar to the current CA system.
You just need a secure way to update your resource records with your registrar, which includes your DS (designated signer) record, a public key of your choosing.
There's no authentication involved beyond your credentials to update the domain.
It's too early to be sure, but this should be included with the purchase of a domain.
Once you have your DS record in place you can use it to designate signers for any subdomains.You could even use it to sign a resource record containing your web server's public TLS key, which allows a real solution to the problem of encryption-only websites: a self-signed certificate which can be securely matched against the host domain, preventing the trivial MITM attacks which currently render such certificates useless.
CA-signed certificates would still be useful for establishing real-world identity, of course.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30123852</id>
	<title>Re:Why use digital signatures?</title>
	<author>amorsen</author>
	<datestamp>1258375980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever.</p></div><p>DNSSEC, as originally conceived, did the exact opposite. Signing a zone was either-or, so the registrars couldn't charge each client for signing their records. Once you signed it for one client, you signed for them all. At the same time DNSSEC obsoletes SSL certificate authorities.</p><p>Now, if you happen to be Verisign and make a lot of money selling SSL certificates, how does that sound to you? A bit of work, no potential income from it, and destruction of a major part of your business...</p><p>This all lead to NSEC3, where you can sign each subdomain individually and thereby preserve the business model of charging each client.</p></div>
	</htmltext>
<tokenext>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $ 100/year or whatever.DNSSEC , as originally conceived , did the exact opposite .
Signing a zone was either-or , so the registrars could n't charge each client for signing their records .
Once you signed it for one client , you signed for them all .
At the same time DNSSEC obsoletes SSL certificate authorities.Now , if you happen to be Verisign and make a lot of money selling SSL certificates , how does that sound to you ?
A bit of work , no potential income from it , and destruction of a major part of your business...This all lead to NSEC3 , where you can sign each subdomain individually and thereby preserve the business model of charging each client .</tokentext>
<sentencetext>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever.DNSSEC, as originally conceived, did the exact opposite.
Signing a zone was either-or, so the registrars couldn't charge each client for signing their records.
Once you signed it for one client, you signed for them all.
At the same time DNSSEC obsoletes SSL certificate authorities.Now, if you happen to be Verisign and make a lot of money selling SSL certificates, how does that sound to you?
A bit of work, no potential income from it, and destruction of a major part of your business...This all lead to NSEC3, where you can sign each subdomain individually and thereby preserve the business model of charging each client.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120198</id>
	<title>Trollin</title>
	<author>Anonymous</author>
	<datestamp>1258404240000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Patrollin<br>Tryin to catch me terdin dirty</p><p>#GNAA irc.hardchats.com</p></htmltext>
<tokenext>PatrollinTryin to catch me terdin dirty # GNAA irc.hardchats.com</tokentext>
<sentencetext>PatrollinTryin to catch me terdin dirty#GNAA irc.hardchats.com</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30124428</id>
	<title>Must use digital signatures?</title>
	<author>omb</author>
	<datestamp>1258379580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As computers/algorithms get faster quick hacks fail ever sooner.<br><br>Ther is little wrong with the design of DNSSEC except it allows --- FOR MONEY --- trust vendors a completely unrequired role in the system, DNSSEC could have easliy avoided this but this is a political question, you should provide your public key, self signed or not, and that needs basically to be the end of it. I can now advertise the fingerprint of my public key on my business card or signature.</htmltext>
<tokenext>As computers/algorithms get faster quick hacks fail ever sooner.Ther is little wrong with the design of DNSSEC except it allows --- FOR MONEY --- trust vendors a completely unrequired role in the system , DNSSEC could have easliy avoided this but this is a political question , you should provide your public key , self signed or not , and that needs basically to be the end of it .
I can now advertise the fingerprint of my public key on my business card or signature .</tokentext>
<sentencetext>As computers/algorithms get faster quick hacks fail ever sooner.Ther is little wrong with the design of DNSSEC except it allows --- FOR MONEY --- trust vendors a completely unrequired role in the system, DNSSEC could have easliy avoided this but this is a political question, you should provide your public key, self signed or not, and that needs basically to be the end of it.
I can now advertise the fingerprint of my public key on my business card or signature.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121126</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121198</id>
	<title>Re:Why use digital signatures?</title>
	<author>nine-times</author>
	<datestamp>1258364940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I thought the idea was that all responses to DNS queries would be signed and therefore verifiable, and not that people would need to buy individual certificates from CAs.</htmltext>
<tokenext>I thought the idea was that all responses to DNS queries would be signed and therefore verifiable , and not that people would need to buy individual certificates from CAs .</tokentext>
<sentencetext>I thought the idea was that all responses to DNS queries would be signed and therefore verifiable, and not that people would need to buy individual certificates from CAs.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120284</id>
	<title>First post</title>
	<author>Anonymous</author>
	<datestamp>1258404480000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>:-)</p></htmltext>
<tokenext>: - )</tokentext>
<sentencetext>:-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708</id>
	<title>Why use digital signatures?</title>
	<author>Myria</author>
	<datestamp>1258362900000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever.  I don't feel that it's necessary to use digital signatures to secure the system.</p><p>The fundamental flaw of DNS is that the "nonce" - the one-time-use random constant used to prevent spoofing - is only 16 bits.  If you're going to change the DNS protocol, why not just increase the size of that field to 64 bits and be done with it?  Then it's only a software change to DNS servers rather than an expensive certificate and far less of an administrative headache.</p><p>Also, I don't think that it's even necessary to change the protocol.  The protocol allows for multiple DNS queries in one packet.  When doing a DNS query, ask for both www.google.com and a nonce domain like eujrdyhtaeoym.example.com.  If the query comes back saying that eujrdyhtaeoym.example.com does not exist (or even if it says it does!), you know nobody is spoofing DNS queries back at you because unless they were snooping traffic, they wouldn't have a way to know that your nonce was eujrdyhtaeoym.</p></htmltext>
<tokenext>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $ 100/year or whatever .
I do n't feel that it 's necessary to use digital signatures to secure the system.The fundamental flaw of DNS is that the " nonce " - the one-time-use random constant used to prevent spoofing - is only 16 bits .
If you 're going to change the DNS protocol , why not just increase the size of that field to 64 bits and be done with it ?
Then it 's only a software change to DNS servers rather than an expensive certificate and far less of an administrative headache.Also , I do n't think that it 's even necessary to change the protocol .
The protocol allows for multiple DNS queries in one packet .
When doing a DNS query , ask for both www.google.com and a nonce domain like eujrdyhtaeoym.example.com .
If the query comes back saying that eujrdyhtaeoym.example.com does not exist ( or even if it says it does !
) , you know nobody is spoofing DNS queries back at you because unless they were snooping traffic , they would n't have a way to know that your nonce was eujrdyhtaeoym .</tokentext>
<sentencetext>This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever.
I don't feel that it's necessary to use digital signatures to secure the system.The fundamental flaw of DNS is that the "nonce" - the one-time-use random constant used to prevent spoofing - is only 16 bits.
If you're going to change the DNS protocol, why not just increase the size of that field to 64 bits and be done with it?
Then it's only a software change to DNS servers rather than an expensive certificate and far less of an administrative headache.Also, I don't think that it's even necessary to change the protocol.
The protocol allows for multiple DNS queries in one packet.
When doing a DNS query, ask for both www.google.com and a nonce domain like eujrdyhtaeoym.example.com.
If the query comes back saying that eujrdyhtaeoym.example.com does not exist (or even if it says it does!
), you know nobody is spoofing DNS queries back at you because unless they were snooping traffic, they wouldn't have a way to know that your nonce was eujrdyhtaeoym.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121314</id>
	<title>Re:Why use digital signatures?</title>
	<author>Anonymous</author>
	<datestamp>1258365360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Your idea sounds similar to <a href="http://en.wikipedia.org/wiki/DNSCurve" title="wikipedia.org" rel="nofollow">DNSCurve</a> [wikipedia.org], which solves a fundamentally different problem: it ensures that you really are communicating with the DNS server you think you are communicating with, but it does not ensure the DNS server is telling the truth.</p></htmltext>
<tokenext>Your idea sounds similar to DNSCurve [ wikipedia.org ] , which solves a fundamentally different problem : it ensures that you really are communicating with the DNS server you think you are communicating with , but it does not ensure the DNS server is telling the truth .</tokentext>
<sentencetext>Your idea sounds similar to DNSCurve [wikipedia.org], which solves a fundamentally different problem: it ensures that you really are communicating with the DNS server you think you are communicating with, but it does not ensure the DNS server is telling the truth.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30132738</id>
	<title>Re:Can someone explain ZSK and KSK?</title>
	<author>rs79</author>
	<datestamp>1258488600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Keep in mind they may be lying. We're supposed to believe with 10 years to work on this they're surprised that tha files are big? Uh, hello, no.</p><p>I suspect what's really going on is they just found the intellectual property gotcha inherant in DNSSEC that IMO is gonna prevent it from ever being widespread. It's as damning to the IP/TM guys as the Kaminsky was to technical correctness of the DNS and I suspect the project's been put on hold... and may not come back in its present form.</p><p>And then there's the<nobr> <wbr></nobr>.se debacle, and<nobr> <wbr></nobr>.de dropping off the net briefly last week.</p><p>Imagine a world without<nobr> <wbr></nobr>.com</p></htmltext>
<tokenext>Keep in mind they may be lying .
We 're supposed to believe with 10 years to work on this they 're surprised that tha files are big ?
Uh , hello , no.I suspect what 's really going on is they just found the intellectual property gotcha inherant in DNSSEC that IMO is gon na prevent it from ever being widespread .
It 's as damning to the IP/TM guys as the Kaminsky was to technical correctness of the DNS and I suspect the project 's been put on hold... and may not come back in its present form.And then there 's the .se debacle , and .de dropping off the net briefly last week.Imagine a world without .com</tokentext>
<sentencetext>Keep in mind they may be lying.
We're supposed to believe with 10 years to work on this they're surprised that tha files are big?
Uh, hello, no.I suspect what's really going on is they just found the intellectual property gotcha inherant in DNSSEC that IMO is gonna prevent it from ever being widespread.
It's as damning to the IP/TM guys as the Kaminsky was to technical correctness of the DNS and I suspect the project's been put on hold... and may not come back in its present form.And then there's the .se debacle, and .de dropping off the net briefly last week.Imagine a world without .com</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</id>
	<title>Can someone explain ZSK and KSK?</title>
	<author>Anonymous</author>
	<datestamp>1258404600000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>Kane said that VeriSign will create and manage the zone-signing key (ZSK) for the root zone, and sign the root zone, for<nobr> <wbr></nobr>.net and<nobr> <wbr></nobr>.com. Icann will create, manage and publish the root zone key-signing key (KSK).</p></div></blockquote><p>This is over my head, as the terminology seems repetitive (ZSK for root zone vs. root zone for KSK ?!?!)... can anyone explain the details to a DNSSEC initiate (A quick google search didn't yield any easily understandable content).</p></div>
	</htmltext>
<tokenext>Kane said that VeriSign will create and manage the zone-signing key ( ZSK ) for the root zone , and sign the root zone , for .net and .com .
Icann will create , manage and publish the root zone key-signing key ( KSK ) .This is over my head , as the terminology seems repetitive ( ZSK for root zone vs. root zone for KSK ? ! ? ! ) .. .
can anyone explain the details to a DNSSEC initiate ( A quick google search did n't yield any easily understandable content ) .</tokentext>
<sentencetext>Kane said that VeriSign will create and manage the zone-signing key (ZSK) for the root zone, and sign the root zone, for .net and .com.
Icann will create, manage and publish the root zone key-signing key (KSK).This is over my head, as the terminology seems repetitive (ZSK for root zone vs. root zone for KSK ?!?!)...
can anyone explain the details to a DNSSEC initiate (A quick google search didn't yield any easily understandable content).
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121078</id>
	<title>Re:Why use digital signatures?</title>
	<author>Anonymous</author>
	<datestamp>1258364400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>These only protect against blind attacks. DNSSEC protects against an attacker who can view your traffic.</p></htmltext>
<tokenext>These only protect against blind attacks .
DNSSEC protects against an attacker who can view your traffic .</tokentext>
<sentencetext>These only protect against blind attacks.
DNSSEC protects against an attacker who can view your traffic.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121490</id>
	<title>forward, stop or reverse</title>
	<author>SgtChaireBourne</author>
	<datestamp>1258366200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Unable or unwilling admins is more like it.</p></div><p>
A side effect of buying into the so-simple a monkey could run it sales pitch from Microsoft: You end up with monkeys that can only stroke the big boss telling him or her to sit tight till the next free t-shirt^H^H^H^H^H^H^H service pack.  As these monkeys are able to bullshit their way into training positions, they will do what any other weak or insecure monkey will do: bogart their already limited knowledge.  Thus with each iteration you get progressively more ignorant monkeys, that have to rely and specialize more and more in social engineering and keeping the managers away from real it staff to keep their jobs.  That same level of skill and knowledge permeate that one vendor's products and <a href="http://www.neowin.net/news/main/09/11/10/bing-cashback-exploit-discovered-microsoft-sends-in-lawyers" title="neowin.net">services</a> [neowin.net].  When the products or services get enough bad press, they just rename them. Enough of that though.
</p><p>
There are some good interviews about the DNS flaw, like the one at
<a href="http://venturebeat.com/2008/08/07/black-hat-an-interview-with-dan-kaminsky-the-dns-dude-who-saved-the-internet/" title="venturebeat.com">Black Hat</a> [venturebeat.com].  For the details of the 2008 flaw, not the <a href="http://searchsecurity.techtarget.com/news/article/0,289142,sid14\_gci1363108,00.html" title="techtarget.com">x.509 cert flaw</a> [techtarget.com], Steve Friedl has <a href="http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html" title="unixwiz.net">An Illustrated Guide to the Kaminsky DNS Vulnerability</a> [unixwiz.net].  If you played with DNS during 2006 or 2007 you probably at least spotted symptoms of the flaw as it seemed to be in growing use.  </p><p>
Frustratingly, the solution has been there in front of us for many years and most systems have been more than capable of deploying DNSSEC, either as part of IPv4 or IPv6, for many years.  Except for one vendor that can't.  Take a guess which one.  Take a guess how much it has cost us to let them hold back the net.
</p></div>
	</htmltext>
<tokenext>Unable or unwilling admins is more like it .
A side effect of buying into the so-simple a monkey could run it sales pitch from Microsoft : You end up with monkeys that can only stroke the big boss telling him or her to sit tight till the next free t-shirt ^ H ^ H ^ H ^ H ^ H ^ H ^ H service pack .
As these monkeys are able to bullshit their way into training positions , they will do what any other weak or insecure monkey will do : bogart their already limited knowledge .
Thus with each iteration you get progressively more ignorant monkeys , that have to rely and specialize more and more in social engineering and keeping the managers away from real it staff to keep their jobs .
That same level of skill and knowledge permeate that one vendor 's products and services [ neowin.net ] .
When the products or services get enough bad press , they just rename them .
Enough of that though .
There are some good interviews about the DNS flaw , like the one at Black Hat [ venturebeat.com ] .
For the details of the 2008 flaw , not the x.509 cert flaw [ techtarget.com ] , Steve Friedl has An Illustrated Guide to the Kaminsky DNS Vulnerability [ unixwiz.net ] .
If you played with DNS during 2006 or 2007 you probably at least spotted symptoms of the flaw as it seemed to be in growing use .
Frustratingly , the solution has been there in front of us for many years and most systems have been more than capable of deploying DNSSEC , either as part of IPv4 or IPv6 , for many years .
Except for one vendor that ca n't .
Take a guess which one .
Take a guess how much it has cost us to let them hold back the net .</tokentext>
<sentencetext>Unable or unwilling admins is more like it.
A side effect of buying into the so-simple a monkey could run it sales pitch from Microsoft: You end up with monkeys that can only stroke the big boss telling him or her to sit tight till the next free t-shirt^H^H^H^H^H^H^H service pack.
As these monkeys are able to bullshit their way into training positions, they will do what any other weak or insecure monkey will do: bogart their already limited knowledge.
Thus with each iteration you get progressively more ignorant monkeys, that have to rely and specialize more and more in social engineering and keeping the managers away from real it staff to keep their jobs.
That same level of skill and knowledge permeate that one vendor's products and services [neowin.net].
When the products or services get enough bad press, they just rename them.
Enough of that though.
There are some good interviews about the DNS flaw, like the one at
Black Hat [venturebeat.com].
For the details of the 2008 flaw, not the x.509 cert flaw [techtarget.com], Steve Friedl has An Illustrated Guide to the Kaminsky DNS Vulnerability [unixwiz.net].
If you played with DNS during 2006 or 2007 you probably at least spotted symptoms of the flaw as it seemed to be in growing use.
Frustratingly, the solution has been there in front of us for many years and most systems have been more than capable of deploying DNSSEC, either as part of IPv4 or IPv6, for many years.
Except for one vendor that can't.
Take a guess which one.
Take a guess how much it has cost us to let them hold back the net.

	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120430</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121690</id>
	<title>"technical reasons"</title>
	<author>leto</author>
	<datestamp>1258366980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Three years to deploy <a href="http://www.faqs.org/rfcs/rfc4956.html" title="faqs.org">RFC 4956</a> [faqs.org] is not "technical reasons"</p></htmltext>
<tokenext>Three years to deploy RFC 4956 [ faqs.org ] is not " technical reasons "</tokentext>
<sentencetext>Three years to deploy RFC 4956 [faqs.org] is not "technical reasons"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121720</id>
	<title>Re:Technical delays, Yeah Right.</title>
	<author>F.Ultra</author>
	<datestamp>1258367100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I would say that the insane costs of a DNSSEC certificate is more probable as the reason...</htmltext>
<tokenext>I would say that the insane costs of a DNSSEC certificate is more probable as the reason.. .</tokentext>
<sentencetext>I would say that the insane costs of a DNSSEC certificate is more probable as the reason...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120430</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30124306</id>
	<title>Dont worry about the Details, thes are Lies</title>
	<author>omb</author>
	<datestamp>1258378620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This is typical Marketeer speak and crap. The existing DNS is data driven, via the Zone files for each (group) of Domains, the basic problem is that contrary to the small, simple friendly days of the arpa net, the distributed nature of the existing network of DNS servers is easily subverted by servers who deliberately lie in answer to DNS queries.<br><br>The solution is well understood, use cryptographic signing, with a known Public Key, so that clients can verify that the answer they get is Genuine Signed. This would be simple if we only had a few zones, and the root could sign all of them, we don't we have zillions so, to prevent changes becomming an impossible bottleneck we need a heirachy of keys so that, when I the admin of a zone, edit the zone I can sign the changed entries with the private key for that zone. The way DNSSEC is designed this turns the problem into one of private key authentication, management and distribution. A bit trickey, but really not that hard.<br><br>What Verisign are setting you up for is this is a HUGE problem so signed zones are going to cost a lot of MONEY.<br><br>The greed and averice if the potential Certificate issuers (yes I am looking at Verisign) and its interaction with OS and Browser vendors is the main reason the internet is not secure, and this way of working dosn't scale and isn't agile.<br><br>Certificates need to be nearly free 1 CHF, 1 USD, 1 GBP, 1 EUR each, and you need to be able to generate your own and have it signed, semi automatically, by your government, and everyone should be issued with a personal certificate, at birth, free. On a CD or something. All the Bolony of investigating who you are before issuing the Certificate is self serving and expensive Crap. It only benefits the technical registrars and needs to go away.<br><br>Verisign are telling us that they need a year, at least to convert a 50m row database<nobr> <wbr></nobr>... absolute nonsense.<br><br>Finally, given all the nonsense on the other side let me tell you about Self Signed certificates; I deal with maybe 20 organizations where I really care about the risks of a MITM attack or being able to Digitally Sign things, and if there was a Public Registrar, that would be the 21st, and I have a complex, multi national digital life, so most people need less but I cannot see anybody needing &gt; 100. You can manage this manually.<br><br>If I do business with you all I need to do is give you a copy of my Public key, and a printed paper with the key-signature, when I sign something you check my public key signature, decrypt the document and verify the hash, if it is all OK you can trust it. If you want to look pretty you can use smart cards, but you can also use paper and the telephone. Even with an MD5 digest you have about three times the domestic security for a Swiss Bank.</htmltext>
<tokenext>This is typical Marketeer speak and crap .
The existing DNS is data driven , via the Zone files for each ( group ) of Domains , the basic problem is that contrary to the small , simple friendly days of the arpa net , the distributed nature of the existing network of DNS servers is easily subverted by servers who deliberately lie in answer to DNS queries.The solution is well understood , use cryptographic signing , with a known Public Key , so that clients can verify that the answer they get is Genuine Signed .
This would be simple if we only had a few zones , and the root could sign all of them , we do n't we have zillions so , to prevent changes becomming an impossible bottleneck we need a heirachy of keys so that , when I the admin of a zone , edit the zone I can sign the changed entries with the private key for that zone .
The way DNSSEC is designed this turns the problem into one of private key authentication , management and distribution .
A bit trickey , but really not that hard.What Verisign are setting you up for is this is a HUGE problem so signed zones are going to cost a lot of MONEY.The greed and averice if the potential Certificate issuers ( yes I am looking at Verisign ) and its interaction with OS and Browser vendors is the main reason the internet is not secure , and this way of working dos n't scale and is n't agile.Certificates need to be nearly free 1 CHF , 1 USD , 1 GBP , 1 EUR each , and you need to be able to generate your own and have it signed , semi automatically , by your government , and everyone should be issued with a personal certificate , at birth , free .
On a CD or something .
All the Bolony of investigating who you are before issuing the Certificate is self serving and expensive Crap .
It only benefits the technical registrars and needs to go away.Verisign are telling us that they need a year , at least to convert a 50m row database ... absolute nonsense.Finally , given all the nonsense on the other side let me tell you about Self Signed certificates ; I deal with maybe 20 organizations where I really care about the risks of a MITM attack or being able to Digitally Sign things , and if there was a Public Registrar , that would be the 21st , and I have a complex , multi national digital life , so most people need less but I can not see anybody needing &gt; 100 .
You can manage this manually.If I do business with you all I need to do is give you a copy of my Public key , and a printed paper with the key-signature , when I sign something you check my public key signature , decrypt the document and verify the hash , if it is all OK you can trust it .
If you want to look pretty you can use smart cards , but you can also use paper and the telephone .
Even with an MD5 digest you have about three times the domestic security for a Swiss Bank .</tokentext>
<sentencetext>This is typical Marketeer speak and crap.
The existing DNS is data driven, via the Zone files for each (group) of Domains, the basic problem is that contrary to the small, simple friendly days of the arpa net, the distributed nature of the existing network of DNS servers is easily subverted by servers who deliberately lie in answer to DNS queries.The solution is well understood, use cryptographic signing, with a known Public Key, so that clients can verify that the answer they get is Genuine Signed.
This would be simple if we only had a few zones, and the root could sign all of them, we don't we have zillions so, to prevent changes becomming an impossible bottleneck we need a heirachy of keys so that, when I the admin of a zone, edit the zone I can sign the changed entries with the private key for that zone.
The way DNSSEC is designed this turns the problem into one of private key authentication, management and distribution.
A bit trickey, but really not that hard.What Verisign are setting you up for is this is a HUGE problem so signed zones are going to cost a lot of MONEY.The greed and averice if the potential Certificate issuers (yes I am looking at Verisign) and its interaction with OS and Browser vendors is the main reason the internet is not secure, and this way of working dosn't scale and isn't agile.Certificates need to be nearly free 1 CHF, 1 USD, 1 GBP, 1 EUR each, and you need to be able to generate your own and have it signed, semi automatically, by your government, and everyone should be issued with a personal certificate, at birth, free.
On a CD or something.
All the Bolony of investigating who you are before issuing the Certificate is self serving and expensive Crap.
It only benefits the technical registrars and needs to go away.Verisign are telling us that they need a year, at least to convert a 50m row database ... absolute nonsense.Finally, given all the nonsense on the other side let me tell you about Self Signed certificates; I deal with maybe 20 organizations where I really care about the risks of a MITM attack or being able to Digitally Sign things, and if there was a Public Registrar, that would be the 21st, and I have a complex, multi national digital life, so most people need less but I cannot see anybody needing &gt; 100.
You can manage this manually.If I do business with you all I need to do is give you a copy of my Public key, and a printed paper with the key-signature, when I sign something you check my public key signature, decrypt the document and verify the hash, if it is all OK you can trust it.
If you want to look pretty you can use smart cards, but you can also use paper and the telephone.
Even with an MD5 digest you have about three times the domestic security for a Swiss Bank.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120392</id>
	<title>uh</title>
	<author>Anonymous</author>
	<datestamp>1258404840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Deployment of DNSSEC will close a major security flaw in the DNS, the internet's equivalent to a telephone directory"</p><p>If you don't know what DNS is, why are you reading Slashdot? Go back to Digg.</p></htmltext>
<tokenext>" Deployment of DNSSEC will close a major security flaw in the DNS , the internet 's equivalent to a telephone directory " If you do n't know what DNS is , why are you reading Slashdot ?
Go back to Digg .</tokentext>
<sentencetext>"Deployment of DNSSEC will close a major security flaw in the DNS, the internet's equivalent to a telephone directory"If you don't know what DNS is, why are you reading Slashdot?
Go back to Digg.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121630</id>
	<title>Re:Can someone explain ZSK and KSK?</title>
	<author>F.Ultra</author>
	<datestamp>1258366800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The KSK is the master key with which the various vendors ZSK keys are signed with. The ZSK key is then signing your key for domain.com

This is so that the DNS-client does not have to have a long list of the various vendors keys as is the case with web browsers, all it needs to have is the KSK and with it it can verify the complete chain of certificates.</htmltext>
<tokenext>The KSK is the master key with which the various vendors ZSK keys are signed with .
The ZSK key is then signing your key for domain.com This is so that the DNS-client does not have to have a long list of the various vendors keys as is the case with web browsers , all it needs to have is the KSK and with it it can verify the complete chain of certificates .</tokentext>
<sentencetext>The KSK is the master key with which the various vendors ZSK keys are signed with.
The ZSK key is then signing your key for domain.com

This is so that the DNS-client does not have to have a long list of the various vendors keys as is the case with web browsers, all it needs to have is the KSK and with it it can verify the complete chain of certificates.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121620</id>
	<title>Re:Can someone explain ZSK and KSK?</title>
	<author>cakefragment</author>
	<datestamp>1258366740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The KSK signs only DNSKEY records, and the ZSK signs all other relevant resource records in the zone.  Your DNSSEC delegation comes from a DS record (a fingerprint of your KSK) which is included (and signed) in the delegating zone.  The practical upshot of this is you can change your ZSK frequently without having to update the DS record upstream (thus contacting your delegator) every time you do so.</p></htmltext>
<tokenext>The KSK signs only DNSKEY records , and the ZSK signs all other relevant resource records in the zone .
Your DNSSEC delegation comes from a DS record ( a fingerprint of your KSK ) which is included ( and signed ) in the delegating zone .
The practical upshot of this is you can change your ZSK frequently without having to update the DS record upstream ( thus contacting your delegator ) every time you do so .</tokentext>
<sentencetext>The KSK signs only DNSKEY records, and the ZSK signs all other relevant resource records in the zone.
Your DNSSEC delegation comes from a DS record (a fingerprint of your KSK) which is included (and signed) in the delegating zone.
The practical upshot of this is you can change your ZSK frequently without having to update the DS record upstream (thus contacting your delegator) every time you do so.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120430</id>
	<title>Technical delays, Yeah Right.</title>
	<author>Anonymous</author>
	<datestamp>1258404960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Unable or unwilling admins is more like it.</htmltext>
<tokenext>Unable or unwilling admins is more like it .</tokentext>
<sentencetext>Unable or unwilling admins is more like it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120566</id>
	<title>Re:Can someone explain ZSK and KSK?</title>
	<author>John Hasler</author>
	<datestamp>1258362300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><a href="http://en.wikipedia.org/wiki/Dnssec" title="wikipedia.org"> DNSSEC </a> [wikipedia.org]</htmltext>
<tokenext>DNSSEC [ wikipedia.org ]</tokentext>
<sentencetext> DNSSEC  [wikipedia.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120704</id>
	<title>In a nutshell</title>
	<author>Anonymous</author>
	<datestamp>1258362840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>In a nutshell, verisign will provide the keys for the root dns servers as well at the<nobr> <wbr></nobr>.com and<nobr> <wbr></nobr>.net gtld's (generic top level domains). It will be the responsibility of the Icann to publish the signing key to be used on the domain servers.</p></htmltext>
<tokenext>In a nutshell , verisign will provide the keys for the root dns servers as well at the .com and .net gtld 's ( generic top level domains ) .
It will be the responsibility of the Icann to publish the signing key to be used on the domain servers .</tokentext>
<sentencetext>In a nutshell, verisign will provide the keys for the root dns servers as well at the .com and .net gtld's (generic top level domains).
It will be the responsibility of the Icann to publish the signing key to be used on the domain servers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30123500</id>
	<title>Re:Can someone explain ZSK and KSK?</title>
	<author>klapaucjusz</author>
	<datestamp>1258374000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It means that VeriSign will be signing the zone, while Icann will be acting as a CA and certifying the keys used by VeriSign.</htmltext>
<tokenext>It means that VeriSign will be signing the zone , while Icann will be acting as a CA and certifying the keys used by VeriSign .</tokentext>
<sentencetext>It means that VeriSign will be signing the zone, while Icann will be acting as a CA and certifying the keys used by VeriSign.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120834</id>
	<title>MoMoney</title>
	<author>Anonymous</author>
	<datestamp>1258363440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Hmm... sounds like just another way for Verisign to add to their bottom line by making everyone purchase additional signed certificates for their DNS servers.</p></htmltext>
<tokenext>Hmm... sounds like just another way for Verisign to add to their bottom line by making everyone purchase additional signed certificates for their DNS servers .</tokentext>
<sentencetext>Hmm... sounds like just another way for Verisign to add to their bottom line by making everyone purchase additional signed certificates for their DNS servers.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121620
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121490
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121078
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120566
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121630
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120778
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120998
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30132738
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30122498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30123500
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30123852
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30127542
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121198
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121720
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30124306
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30124428
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121126
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1933256_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30126454
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120430
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1933256.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120326
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120778
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120610
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121630
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30122498
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30132738
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120566
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30123500
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30124306
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121620
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1933256.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120392
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1933256.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120430
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121720
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30126454
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121490
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1933256.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120708
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30120998
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121078
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121198
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30127542
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121314
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30121126
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30124428
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1933256.30123852
</commentlist>
</conversation>
