<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_06_25_1354212</id>
	<title>Kaminsky On DNS Bugs a Year Later and DNSSEC</title>
	<author>CmdrTaco</author>
	<datestamp>1245941520000</datestamp>
	<htmltext><a href="mailto:l3spau1@yahoo.com" rel="nofollow">L3sPau1</a> writes <i>"Network security researcher Dan Kaminsky has had <a href="http://searchsecurity.techtarget.com/news/interview/0,289202,sid14\_gci1360143,00.html">a year to reflect</a> on the impact of the cache poisoning vulnerability he discovered in the Domain Name System. In the time since, Kaminsky has become an advocate for improving security in DNS, and ultimately, trust on the Internet. One way to do this is with the widespread use of DNSSEC (DNS Security Extensions), which essentially brings PKI to website requests. In this interview, Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services."</i></htmltext>
<tokenext>L3sPau1 writes " Network security researcher Dan Kaminsky has had a year to reflect on the impact of the cache poisoning vulnerability he discovered in the Domain Name System .
In the time since , Kaminsky has become an advocate for improving security in DNS , and ultimately , trust on the Internet .
One way to do this is with the widespread use of DNSSEC ( DNS Security Extensions ) , which essentially brings PKI to website requests .
In this interview , Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services .
"</tokentext>
<sentencetext>L3sPau1 writes "Network security researcher Dan Kaminsky has had a year to reflect on the impact of the cache poisoning vulnerability he discovered in the Domain Name System.
In the time since, Kaminsky has become an advocate for improving security in DNS, and ultimately, trust on the Internet.
One way to do this is with the widespread use of DNSSEC (DNS Security Extensions), which essentially brings PKI to website requests.
In this interview, Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467227</id>
	<title>Re:You obviously have no idea what your talking ab</title>
	<author>Anonymous</author>
	<datestamp>1245949020000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>0</modscore>
	<htmltext>No, but he did get tons of publicity for a design bug that has been known about since the early 2000s.

<a href="http://cr.yp.to/djbdns/forgery.html" title="cr.yp.to" rel="nofollow">http://cr.yp.to/djbdns/forgery.html</a> [cr.yp.to]</htmltext>
<tokenext>No , but he did get tons of publicity for a design bug that has been known about since the early 2000s .
http : //cr.yp.to/djbdns/forgery.html [ cr.yp.to ]</tokentext>
<sentencetext>No, but he did get tons of publicity for a design bug that has been known about since the early 2000s.
http://cr.yp.to/djbdns/forgery.html [cr.yp.to]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466761</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28471111</id>
	<title>Re:I don't wanna put a subject.</title>
	<author>rho</author>
	<datestamp>1245920580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username.</p></div></blockquote><p>Your suggestion just gave me the piss-shudders.

</p><p>A lot of people are incapable of correctly setting up Outlook. You will build the worlds most secure site that nobody uses.</p></div>
	</htmltext>
<tokenext>If I were setting up a secure site , it 'd be SSL-only .
As part of the account-setup process , you 'd be asked to generate a client certificate and upload the public certificate ( over an SSL connection ) to the server to be attached to your account .
From that point on , when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username.Your suggestion just gave me the piss-shudders .
A lot of people are incapable of correctly setting up Outlook .
You will build the worlds most secure site that nobody uses .</tokentext>
<sentencetext>If I were setting up a secure site, it'd be SSL-only.
As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account.
From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username.Your suggestion just gave me the piss-shudders.
A lot of people are incapable of correctly setting up Outlook.
You will build the worlds most secure site that nobody uses.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28470725</id>
	<title>Re:Need DNSSEC tools</title>
	<author>Anonymous</author>
	<datestamp>1245962340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>In response to your post about implementing DNSSEC, there are other, less expensive options for a DNSSEC enabled managed DNS service. One of them is Dynect Platform, who just announced support for DNSSEC last week: http://dynamicnetworkservices.com/news-press/DynIncPushesDNSSECLiveandDrivesAdoption</p><p>Depending on your needs, you're talking about $100s of dollars a month, not $1000s.</p></htmltext>
<tokenext>In response to your post about implementing DNSSEC , there are other , less expensive options for a DNSSEC enabled managed DNS service .
One of them is Dynect Platform , who just announced support for DNSSEC last week : http : //dynamicnetworkservices.com/news-press/DynIncPushesDNSSECLiveandDrivesAdoptionDepending on your needs , you 're talking about $ 100s of dollars a month , not $ 1000s .</tokentext>
<sentencetext>In response to your post about implementing DNSSEC, there are other, less expensive options for a DNSSEC enabled managed DNS service.
One of them is Dynect Platform, who just announced support for DNSSEC last week: http://dynamicnetworkservices.com/news-press/DynIncPushesDNSSECLiveandDrivesAdoptionDepending on your needs, you're talking about $100s of dollars a month, not $1000s.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467089</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466761</id>
	<title>You obviously have no idea what your talking about</title>
	<author>Anonymous</author>
	<datestamp>1245946740000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Do you even know what DNSSEC is? It is nothing he is trying to sell, it is him trying to completely take care of the flaw he found in DNS last summer. A flaw that could have seriously fubared the net if he didn't go through massive patching with internet providers and large companies. So you know, just about all DNSSEC software is opensource, meaning it is free. He isn't a conartist and it is pretty ignorant to call him one, he spent countless hours last summer trying to get the patch out which he didn't make money off of since he released it for free.</htmltext>
<tokenext>Do you even know what DNSSEC is ?
It is nothing he is trying to sell , it is him trying to completely take care of the flaw he found in DNS last summer .
A flaw that could have seriously fubared the net if he did n't go through massive patching with internet providers and large companies .
So you know , just about all DNSSEC software is opensource , meaning it is free .
He is n't a conartist and it is pretty ignorant to call him one , he spent countless hours last summer trying to get the patch out which he did n't make money off of since he released it for free .</tokentext>
<sentencetext>Do you even know what DNSSEC is?
It is nothing he is trying to sell, it is him trying to completely take care of the flaw he found in DNS last summer.
A flaw that could have seriously fubared the net if he didn't go through massive patching with internet providers and large companies.
So you know, just about all DNSSEC software is opensource, meaning it is free.
He isn't a conartist and it is pretty ignorant to call him one, he spent countless hours last summer trying to get the patch out which he didn't make money off of since he released it for free.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28476707</id>
	<title>Re:Kaminsky/Vixie DNS Scam Known as Media Hack</title>
	<author>John Hasler</author>
	<datestamp>1245945300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt;<nobr> <wbr></nobr>...I could not get<nobr> <wbr></nobr>.ORG TLD officials to respond to questions about whether there was<br>&gt; regulatory approval for their actions.</p><p>Are you saying that they may actually have done something *without permission*?  Awful.  Just awful.</p></htmltext>
<tokenext>&gt; ...I could not get .ORG TLD officials to respond to questions about whether there was &gt; regulatory approval for their actions.Are you saying that they may actually have done something * without permission * ?
Awful. Just awful .</tokentext>
<sentencetext>&gt; ...I could not get .ORG TLD officials to respond to questions about whether there was&gt; regulatory approval for their actions.Are you saying that they may actually have done something *without permission*?
Awful.  Just awful.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472855</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468029</id>
	<title>Re:Is DNSSec really needed?</title>
	<author>Sancho</author>
	<datestamp>1245952020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's a matter of the scope of the attack.  Any resolver (including your ISP's caching nameserver) can be the target.  It wouldn't make much sense for an individual's resolver (their PC) to be the target--first of all, it's hard to get them to query for thousands of requests.  Second, your payoff is small--you got one machine to think that ns1.example.com resolves to your IP address.</p><p>The real target is any caching server that lots of people use.  It's much easier to get these to make requests for lots of subdomains (nslookup aaaaaaa1.example.com; nslookup aaaaaaa2.example.com, etc.)  And once you've compromised it, you've compromised the DNS for <b>everyone</b> using that server.</p><p>Implementing DNSSEC on the caching resolver fixes the wide-scale attack without ever having to touch the clients.  Now, an attacker can only target individual PCs.  It's an issue, but a much smaller one.  For one thing, you don't compromise a million people by attacking one host anymore.  You have to do it individually, which makes it much less attractive.  For another, it's <b>harder</b> to get into a position to target that user, as you have to get their computer to make the queries.  If you can do that, you probably have access to their computer and can make simpler attacks (such as modifying the hosts file.)</p></htmltext>
<tokenext>It 's a matter of the scope of the attack .
Any resolver ( including your ISP 's caching nameserver ) can be the target .
It would n't make much sense for an individual 's resolver ( their PC ) to be the target--first of all , it 's hard to get them to query for thousands of requests .
Second , your payoff is small--you got one machine to think that ns1.example.com resolves to your IP address.The real target is any caching server that lots of people use .
It 's much easier to get these to make requests for lots of subdomains ( nslookup aaaaaaa1.example.com ; nslookup aaaaaaa2.example.com , etc .
) And once you 've compromised it , you 've compromised the DNS for everyone using that server.Implementing DNSSEC on the caching resolver fixes the wide-scale attack without ever having to touch the clients .
Now , an attacker can only target individual PCs .
It 's an issue , but a much smaller one .
For one thing , you do n't compromise a million people by attacking one host anymore .
You have to do it individually , which makes it much less attractive .
For another , it 's harder to get into a position to target that user , as you have to get their computer to make the queries .
If you can do that , you probably have access to their computer and can make simpler attacks ( such as modifying the hosts file .
)</tokentext>
<sentencetext>It's a matter of the scope of the attack.
Any resolver (including your ISP's caching nameserver) can be the target.
It wouldn't make much sense for an individual's resolver (their PC) to be the target--first of all, it's hard to get them to query for thousands of requests.
Second, your payoff is small--you got one machine to think that ns1.example.com resolves to your IP address.The real target is any caching server that lots of people use.
It's much easier to get these to make requests for lots of subdomains (nslookup aaaaaaa1.example.com; nslookup aaaaaaa2.example.com, etc.
)  And once you've compromised it, you've compromised the DNS for everyone using that server.Implementing DNSSEC on the caching resolver fixes the wide-scale attack without ever having to touch the clients.
Now, an attacker can only target individual PCs.
It's an issue, but a much smaller one.
For one thing, you don't compromise a million people by attacking one host anymore.
You have to do it individually, which makes it much less attractive.
For another, it's harder to get into a position to target that user, as you have to get their computer to make the queries.
If you can do that, you probably have access to their computer and can make simpler attacks (such as modifying the hosts file.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467991</id>
	<title>Question for Dan: signing the root</title>
	<author>Anonymous</author>
	<datestamp>1245951840000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>Hi Dan,</p><p>Stupid question: can whoever holds the root key forge requests from all domains?</p><p>e.g. if I am the US government, can I spoof an<nobr> <wbr></nobr>.ir domain?</p><p>Thanks.</p></htmltext>
<tokenext>Hi Dan,Stupid question : can whoever holds the root key forge requests from all domains ? e.g .
if I am the US government , can I spoof an .ir domain ? Thanks .</tokentext>
<sentencetext>Hi Dan,Stupid question: can whoever holds the root key forge requests from all domains?e.g.
if I am the US government, can I spoof an .ir domain?Thanks.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469189</id>
	<title>Re:Optimistic guy</title>
	<author>jafiwam</author>
	<datestamp>1245956160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Hey, if there is enthusiasm, there must be a good idea!<br><br>Just look at Mr. Moller and his wonderful new car!</htmltext>
<tokenext>Hey , if there is enthusiasm , there must be a good idea ! Just look at Mr. Moller and his wonderful new car !</tokentext>
<sentencetext>Hey, if there is enthusiasm, there must be a good idea!Just look at Mr. Moller and his wonderful new car!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466865</id>
	<title>Re:Optimistic guy</title>
	<author>Anonymous</author>
	<datestamp>1245947280000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>There are numerous issues with implementing DNSSEC. The idea has been around for like 14 years now.  Also, there are alternatives like DNSCurve which provide more security with considerable ease of deployment.</htmltext>
<tokenext>There are numerous issues with implementing DNSSEC .
The idea has been around for like 14 years now .
Also , there are alternatives like DNSCurve which provide more security with considerable ease of deployment .</tokentext>
<sentencetext>There are numerous issues with implementing DNSSEC.
The idea has been around for like 14 years now.
Also, there are alternatives like DNSCurve which provide more security with considerable ease of deployment.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468761</id>
	<title>Dumb Question</title>
	<author>Anonymous</author>
	<datestamp>1245954720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>But since I don't claim to understand DNSSEC I'll ask it: how secure is DNSSEC against abuse by governments?</p></htmltext>
<tokenext>But since I do n't claim to understand DNSSEC I 'll ask it : how secure is DNSSEC against abuse by governments ?</tokentext>
<sentencetext>But since I don't claim to understand DNSSEC I'll ask it: how secure is DNSSEC against abuse by governments?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468307</id>
	<title>I don't wanna put a subject.</title>
	<author>Anonymous</author>
	<datestamp>1245953040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I was actually thinking about this the other day.<br>
Http has absolutely no security at all built into the protocol.  It is all hacked together with cookies and the server remembering sessions etc.<br>
The protocol itself is dumb.  Make a request... get a response, thats it.  Any security is on top of that.<br>
If there was a standard for secure HTTP, all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server.</htmltext>
<tokenext>I was actually thinking about this the other day .
Http has absolutely no security at all built into the protocol .
It is all hacked together with cookies and the server remembering sessions etc .
The protocol itself is dumb .
Make a request... get a response , thats it .
Any security is on top of that .
If there was a standard for secure HTTP , all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server .</tokentext>
<sentencetext>I was actually thinking about this the other day.
Http has absolutely no security at all built into the protocol.
It is all hacked together with cookies and the server remembering sessions etc.
The protocol itself is dumb.
Make a request... get a response, thats it.
Any security is on top of that.
If there was a standard for secure HTTP, all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468185</id>
	<title>Re:Questions from a DNS implementor</title>
	<author>Effugas</author>
	<datestamp>1245952560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>(This is Dan)</p><p>Heh Sam,</p><p>
&nbsp; &nbsp; &nbsp; It's a bit tricky, but we can work with you on the trickiness.  DNSSEC is *much* easier to implement if you drop the somewhat unnecessary requirement for offline key signing, which is why BIND is so messy.  Libunbound/ldns is flexible enough so you can integrate it, otherwise we can help you with the various wonkiness.  Email me offline, dan@doxpara.com ?</p></htmltext>
<tokenext>( This is Dan ) Heh Sam ,       It 's a bit tricky , but we can work with you on the trickiness .
DNSSEC is * much * easier to implement if you drop the somewhat unnecessary requirement for offline key signing , which is why BIND is so messy .
Libunbound/ldns is flexible enough so you can integrate it , otherwise we can help you with the various wonkiness .
Email me offline , dan @ doxpara.com ?</tokentext>
<sentencetext>(This is Dan)Heh Sam,
      It's a bit tricky, but we can work with you on the trickiness.
DNSSEC is *much* easier to implement if you drop the somewhat unnecessary requirement for offline key signing, which is why BIND is so messy.
Libunbound/ldns is flexible enough so you can integrate it, otherwise we can help you with the various wonkiness.
Email me offline, dan@doxpara.com ?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467417</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472999</id>
	<title>Re:new security products and services? great.</title>
	<author>Effugas</author>
	<datestamp>1245926760000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>(This is Dan)</p><p>I actually completely agree with your desire to see trust in the edges.  That's what's so interesting about DNSSEC -- DNS, by its very design, is all about getting the core the hell out of the way and delegating, delegating, and delegating some more until the organization that manages the namespace can directly control it.</p><p>Indeed, in the ultimate vision of DNSSEC, we have full on validating resolvers in clients.  The endpoints themselves can finally - finally! - recognize their peers directly, without having to trust anyone or depend on the admitted messiness of the existing SSL CA infrastructure.</p><p>The reality about Active MITM is that it's out there.  See the BGP work that came out in tune with my talk -- note that all that still works, today, even with my big fix.  Active MITM isn't some theoretical attack, and the reality is that everything is vulnerable to it.  An ounce of cryptography is worthless without a metric asston of key management.  DNSSEC is just the best way I can see to do it.</p><p>Regarding the trust anchor size, the reality is that we have 25 years of it not being a problem.  That's the simple truth.  Everything I did last year could have been done by a malicious root.  It wasn't.</p><p>Your corporate/intranet myth is funny, because it strikes at the heart of the problem.  You think there's just one corporate/intranet to authenticate.  It's literally like you're suggesting, email to other companies is complicated, so lets just do email to our own company.  Nice, but not good enough.  We need cross organizational trust.  We need something to bootstrap it.  DNSSEC should be that.</p></htmltext>
<tokenext>( This is Dan ) I actually completely agree with your desire to see trust in the edges .
That 's what 's so interesting about DNSSEC -- DNS , by its very design , is all about getting the core the hell out of the way and delegating , delegating , and delegating some more until the organization that manages the namespace can directly control it.Indeed , in the ultimate vision of DNSSEC , we have full on validating resolvers in clients .
The endpoints themselves can finally - finally !
- recognize their peers directly , without having to trust anyone or depend on the admitted messiness of the existing SSL CA infrastructure.The reality about Active MITM is that it 's out there .
See the BGP work that came out in tune with my talk -- note that all that still works , today , even with my big fix .
Active MITM is n't some theoretical attack , and the reality is that everything is vulnerable to it .
An ounce of cryptography is worthless without a metric asston of key management .
DNSSEC is just the best way I can see to do it.Regarding the trust anchor size , the reality is that we have 25 years of it not being a problem .
That 's the simple truth .
Everything I did last year could have been done by a malicious root .
It was n't.Your corporate/intranet myth is funny , because it strikes at the heart of the problem .
You think there 's just one corporate/intranet to authenticate .
It 's literally like you 're suggesting , email to other companies is complicated , so lets just do email to our own company .
Nice , but not good enough .
We need cross organizational trust .
We need something to bootstrap it .
DNSSEC should be that .</tokentext>
<sentencetext>(This is Dan)I actually completely agree with your desire to see trust in the edges.
That's what's so interesting about DNSSEC -- DNS, by its very design, is all about getting the core the hell out of the way and delegating, delegating, and delegating some more until the organization that manages the namespace can directly control it.Indeed, in the ultimate vision of DNSSEC, we have full on validating resolvers in clients.
The endpoints themselves can finally - finally!
- recognize their peers directly, without having to trust anyone or depend on the admitted messiness of the existing SSL CA infrastructure.The reality about Active MITM is that it's out there.
See the BGP work that came out in tune with my talk -- note that all that still works, today, even with my big fix.
Active MITM isn't some theoretical attack, and the reality is that everything is vulnerable to it.
An ounce of cryptography is worthless without a metric asston of key management.
DNSSEC is just the best way I can see to do it.Regarding the trust anchor size, the reality is that we have 25 years of it not being a problem.
That's the simple truth.
Everything I did last year could have been done by a malicious root.
It wasn't.Your corporate/intranet myth is funny, because it strikes at the heart of the problem.
You think there's just one corporate/intranet to authenticate.
It's literally like you're suggesting, email to other companies is complicated, so lets just do email to our own company.
Nice, but not good enough.
We need cross organizational trust.
We need something to bootstrap it.
DNSSEC should be that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468455</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467557</id>
	<title>Is DNSSec really needed?</title>
	<author>mr exploiter</author>
	<datestamp>1245950280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The kaminsky attack is an attack on a client that is dumb enough to allow to make thousands of dns requests to subdomains of a domain. If the solution is changing to DNSSEC the clients will have to change to DNSSEC too, so we may as well prevent the attack by making the DNS clients smarter. For example a rule could be added that says that if there were more than 10 invalid responses for subdomains of the same domain then when a valid response arrives only to cache the IP for the subdomain requested and not for additional domain names included on the response.</htmltext>
<tokenext>The kaminsky attack is an attack on a client that is dumb enough to allow to make thousands of dns requests to subdomains of a domain .
If the solution is changing to DNSSEC the clients will have to change to DNSSEC too , so we may as well prevent the attack by making the DNS clients smarter .
For example a rule could be added that says that if there were more than 10 invalid responses for subdomains of the same domain then when a valid response arrives only to cache the IP for the subdomain requested and not for additional domain names included on the response .</tokentext>
<sentencetext>The kaminsky attack is an attack on a client that is dumb enough to allow to make thousands of dns requests to subdomains of a domain.
If the solution is changing to DNSSEC the clients will have to change to DNSSEC too, so we may as well prevent the attack by making the DNS clients smarter.
For example a rule could be added that says that if there were more than 10 invalid responses for subdomains of the same domain then when a valid response arrives only to cache the IP for the subdomain requested and not for additional domain names included on the response.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467089</id>
	<title>Need DNSSEC tools</title>
	<author>snsh</author>
	<datestamp>1245948420000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>I haven't deployed DNSSEC yet on my external domains because of cost/complexity.  When I looked into it, my options for DNSSEC were:<br>
<br>
1) implement BIND and do the key management and rotation from the command line<br>
2) spend $10,000 or so for an appliance from secure64 or nixu<br>
3) spend $1k/month for a hosted DNS provider like neustar or verisign<br>
4) install Win2008R2 RC and use it in producition<br>
<br>
I work in a windows shop, so I'll probably go with option 4, but I'm surprised there aren't more set-it-and-forget-it tools out there for DNSSEC deployment.  I'm open to recommendations.</htmltext>
<tokenext>I have n't deployed DNSSEC yet on my external domains because of cost/complexity .
When I looked into it , my options for DNSSEC were : 1 ) implement BIND and do the key management and rotation from the command line 2 ) spend $ 10,000 or so for an appliance from secure64 or nixu 3 ) spend $ 1k/month for a hosted DNS provider like neustar or verisign 4 ) install Win2008R2 RC and use it in producition I work in a windows shop , so I 'll probably go with option 4 , but I 'm surprised there are n't more set-it-and-forget-it tools out there for DNSSEC deployment .
I 'm open to recommendations .</tokentext>
<sentencetext>I haven't deployed DNSSEC yet on my external domains because of cost/complexity.
When I looked into it, my options for DNSSEC were:

1) implement BIND and do the key management and rotation from the command line
2) spend $10,000 or so for an appliance from secure64 or nixu
3) spend $1k/month for a hosted DNS provider like neustar or verisign
4) install Win2008R2 RC and use it in producition

I work in a windows shop, so I'll probably go with option 4, but I'm surprised there aren't more set-it-and-forget-it tools out there for DNSSEC deployment.
I'm open to recommendations.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468923</id>
	<title>Re:Questions from a DNS implementor</title>
	<author>Anonymous</author>
	<datestamp>1245955320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I was very pleased to see this discussion taking place in an open forum, and would loved to have had the opportunity to follow it.  I regret you've taken your interaction offline.</p><p>I myself have been a DNS administrator (among other things) since the original implementation.  I remember converting from host tables wasn't particularly fun at the time.</p></htmltext>
<tokenext>I was very pleased to see this discussion taking place in an open forum , and would loved to have had the opportunity to follow it .
I regret you 've taken your interaction offline.I myself have been a DNS administrator ( among other things ) since the original implementation .
I remember converting from host tables was n't particularly fun at the time .</tokentext>
<sentencetext>I was very pleased to see this discussion taking place in an open forum, and would loved to have had the opportunity to follow it.
I regret you've taken your interaction offline.I myself have been a DNS administrator (among other things) since the original implementation.
I remember converting from host tables wasn't particularly fun at the time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468185</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473009</id>
	<title>Re:Question for Dan: signing the root</title>
	<author>Anonymous</author>
	<datestamp>1245926760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yes. But the us govt could do that before.  DNSSEC doesn't enable this.</p><p>DNSSEC only enables a false sense of security that it wouldn't happen, while leaving the man-in-the-middle attack ignored and vulnerable.</p><p>There are basically two kinds of attacks: Man-in-the-middle (MITM) and blind attack which cannot see responses.  UDP Port randomization makes blind attacks quite nearly impossible, and this has been known since 1999 or before. TCP DNS makes blind attacks impossible.</p><p>If the attacker is in the middle, it does not matter what DNS does, because the attacker can intercept the packets to the "right" IP address returned by DNS. So to protect against MITM attacks, one MUST use TLS or similar, and one MUST check that the correct certificates are returned.  Nothing else will suffice, so DNSSEC is useless and solves no problem.</p></htmltext>
<tokenext>Yes .
But the us govt could do that before .
DNSSEC does n't enable this.DNSSEC only enables a false sense of security that it would n't happen , while leaving the man-in-the-middle attack ignored and vulnerable.There are basically two kinds of attacks : Man-in-the-middle ( MITM ) and blind attack which can not see responses .
UDP Port randomization makes blind attacks quite nearly impossible , and this has been known since 1999 or before .
TCP DNS makes blind attacks impossible.If the attacker is in the middle , it does not matter what DNS does , because the attacker can intercept the packets to the " right " IP address returned by DNS .
So to protect against MITM attacks , one MUST use TLS or similar , and one MUST check that the correct certificates are returned .
Nothing else will suffice , so DNSSEC is useless and solves no problem .</tokentext>
<sentencetext>Yes.
But the us govt could do that before.
DNSSEC doesn't enable this.DNSSEC only enables a false sense of security that it wouldn't happen, while leaving the man-in-the-middle attack ignored and vulnerable.There are basically two kinds of attacks: Man-in-the-middle (MITM) and blind attack which cannot see responses.
UDP Port randomization makes blind attacks quite nearly impossible, and this has been known since 1999 or before.
TCP DNS makes blind attacks impossible.If the attacker is in the middle, it does not matter what DNS does, because the attacker can intercept the packets to the "right" IP address returned by DNS.
So to protect against MITM attacks, one MUST use TLS or similar, and one MUST check that the correct certificates are returned.
Nothing else will suffice, so DNSSEC is useless and solves no problem.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467991</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473253</id>
	<title>Re:You obviously have no idea what your talking ab</title>
	<author>Anonymous</author>
	<datestamp>1245927780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work. Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.</p></div><p>False. The recursor will also return SERVFAIL.</p><p><div class="quote"><p>- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone.</p></div><p>False. Look up NSEC3.</p><p><div class="quote"><p>- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago.</p></div><p>Yeah, that was a year ago. Search Slashdot for announcments of TLDs and even the root that they support DNSSEC or will do so in the close future.</p></div>
	</htmltext>
<tokenext>- If you are an ISP , running a validating DNSSEC compatible resolver will likely end in more customer complaints , since it treats signed-but-expired DNS zones as NXDOMAIN , whereas a standard DNS setup would continue to work .
Paul Vixie himself ran into this problem with one of his domains , forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.False .
The recursor will also return SERVFAIL.- As one of the new requirements of DNSSEC , it is now impossible to not publish a list of every single subdomain on your DNS zone.False .
Look up NSEC3.- The root and second level DNS providers are probably not going to support DNSSEC , or at least that was the feeling a year ago.Yeah , that was a year ago .
Search Slashdot for announcments of TLDs and even the root that they support DNSSEC or will do so in the close future .</tokentext>
<sentencetext>- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work.
Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.False.
The recursor will also return SERVFAIL.- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone.False.
Look up NSEC3.- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago.Yeah, that was a year ago.
Search Slashdot for announcments of TLDs and even the root that they support DNSSEC or will do so in the close future.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468997</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687</id>
	<title>Optimistic guy</title>
	<author>Anonymous</author>
	<datestamp>1245946380000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>Kaminsky is incredibly enthusiastic about DNSSEC.<nobr> <wbr></nobr>... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.</p></htmltext>
<tokenext>Kaminsky is incredibly enthusiastic about DNSSEC .
... to the point where someone not too knowledgeable ( like I am ) wonders if DNSSEC really is that amazing or if he was just high .</tokentext>
<sentencetext>Kaminsky is incredibly enthusiastic about DNSSEC.
... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472071</id>
	<title>key point: DNSSEC enables NON-dns security stuff</title>
	<author>Anonymous</author>
	<datestamp>1245923400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The slashdot discussion is focussing on the implications for DNS itself, when <b>DNS is the least interesting benefit from DNSSEC</b>.</p><p>Kaminsky, FTA:</p><blockquote><div><p>[...]I don't think people fully realize DNSSEC is not interesting because of DNS. <b>The lack of DNSSEC is why all these other protocols are broken.</b> That 60\% of attacks that happen because of poor authentication -- do you know why authentication was poor? Because it was too expensive do anything better. DNSSEC will enable better authentication technologies; stuff we can't even dream about yet.</p></div></blockquote></div>
	</htmltext>
<tokenext>The slashdot discussion is focussing on the implications for DNS itself , when DNS is the least interesting benefit from DNSSEC.Kaminsky , FTA : [ ... ] I do n't think people fully realize DNSSEC is not interesting because of DNS .
The lack of DNSSEC is why all these other protocols are broken .
That 60 \ % of attacks that happen because of poor authentication -- do you know why authentication was poor ?
Because it was too expensive do anything better .
DNSSEC will enable better authentication technologies ; stuff we ca n't even dream about yet .</tokentext>
<sentencetext>The slashdot discussion is focussing on the implications for DNS itself, when DNS is the least interesting benefit from DNSSEC.Kaminsky, FTA:[...]I don't think people fully realize DNSSEC is not interesting because of DNS.
The lack of DNSSEC is why all these other protocols are broken.
That 60\% of attacks that happen because of poor authentication -- do you know why authentication was poor?
Because it was too expensive do anything better.
DNSSEC will enable better authentication technologies; stuff we can't even dream about yet.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28470693</id>
	<title>KillerNapalm</title>
	<author>Anonymous</author>
	<datestamp>1245962160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Security is a process... not necessarily a product or a deployment of a new technology.</p><p>DNSSEC has the ability help, but its no substitute for proper design, management, and the continuing upgrade/improvement roadmap thereto.  Anything and everything eventually is found to have weaknesses.  True security is the ability to stay at least one step ahead of the bad guys.</p></htmltext>
<tokenext>Security is a process... not necessarily a product or a deployment of a new technology.DNSSEC has the ability help , but its no substitute for proper design , management , and the continuing upgrade/improvement roadmap thereto .
Anything and everything eventually is found to have weaknesses .
True security is the ability to stay at least one step ahead of the bad guys .</tokentext>
<sentencetext>Security is a process... not necessarily a product or a deployment of a new technology.DNSSEC has the ability help, but its no substitute for proper design, management, and the continuing upgrade/improvement roadmap thereto.
Anything and everything eventually is found to have weaknesses.
True security is the ability to stay at least one step ahead of the bad guys.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467549</id>
	<title>Wow, an acronym explained</title>
	<author>hey</author>
	<datestamp>1245950220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Wow an acronym explained was explained in a slashdot story posting... "DNSSEC (DNS Security Extensions)".  Oh, the DNS part wasn't<nobr> <wbr></nobr>:)<br>Yeah, I know its a very common acronym.</p></htmltext>
<tokenext>Wow an acronym explained was explained in a slashdot story posting... " DNSSEC ( DNS Security Extensions ) " .
Oh , the DNS part was n't : ) Yeah , I know its a very common acronym .</tokentext>
<sentencetext>Wow an acronym explained was explained in a slashdot story posting... "DNSSEC (DNS Security Extensions)".
Oh, the DNS part wasn't :)Yeah, I know its a very common acronym.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468997</id>
	<title>Re:You obviously have no idea what your talking ab</title>
	<author>Anonymous</author>
	<datestamp>1245955560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>DNSSEC must be the most wildly overrated technology to ever come out of the internet.</p><p>Seriously, it's just terrible from a system administrator's perspective.</p><p>It's been a year since I listened to a speech about DNSSEC (from an official ISC representative) at a Linux User Group meeting, so I don't have every last detail on the tip of my brain. However, it provides a little more security in some ways, while making other things worse.</p><p>Among the highlights:</p><p>- You need to sign your DNS zones every thirty days or so, because the crypto in DNSSEC isn't really that good for speed optimization reasons</p><p>- If the signatures on your DNS zones expire, any validating DNSSEC resolver will pretend like your zone doesn't exist (since it was too late to use anything other than NXDOMAIN to indicate signing problems to keep backwards compatibility)</p><p>- You therefore need to set up a cron job on a second server to make sure that the DNS zones were signed properly. At the time this bug was published, there weren't any tools to do this in a sane manner, so you'd have to write your own scripts</p><p>- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work. Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.</p><p>- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone. This is because every record in the zone has a pointer to the next record, kind of like a circular linked list. ISC maintains that this is no big deal, but there are plenty of people (myself included) that feel otherwise.</p><p>- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago. As a result, ISC came up with something called DLV, or Domain Lookaside Validation (RFC 5074). This essentially sets up ISC as the official arbiter of which second level DNS zones (like google.com, microsoft.com, etc) are official and can sign their own zones.</p><p>ISC may not be selling anything, but they stand to gain significantly if they become the de facto authority on which internet domains are valid, and the presentation was more full of FUD than anything I had ever heard come out of Microsoft. Seriously.</p><p>I got the strong feeling that DNSSEC in general really feels half baked and rushed out, rather than something simple and well thought out. I would advise everyone to avoid it like the plague, and hold out for a better solution.</p></htmltext>
<tokenext>DNSSEC must be the most wildly overrated technology to ever come out of the internet.Seriously , it 's just terrible from a system administrator 's perspective.It 's been a year since I listened to a speech about DNSSEC ( from an official ISC representative ) at a Linux User Group meeting , so I do n't have every last detail on the tip of my brain .
However , it provides a little more security in some ways , while making other things worse.Among the highlights : - You need to sign your DNS zones every thirty days or so , because the crypto in DNSSEC is n't really that good for speed optimization reasons- If the signatures on your DNS zones expire , any validating DNSSEC resolver will pretend like your zone does n't exist ( since it was too late to use anything other than NXDOMAIN to indicate signing problems to keep backwards compatibility ) - You therefore need to set up a cron job on a second server to make sure that the DNS zones were signed properly .
At the time this bug was published , there were n't any tools to do this in a sane manner , so you 'd have to write your own scripts- If you are an ISP , running a validating DNSSEC compatible resolver will likely end in more customer complaints , since it treats signed-but-expired DNS zones as NXDOMAIN , whereas a standard DNS setup would continue to work .
Paul Vixie himself ran into this problem with one of his domains , forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.- As one of the new requirements of DNSSEC , it is now impossible to not publish a list of every single subdomain on your DNS zone .
This is because every record in the zone has a pointer to the next record , kind of like a circular linked list .
ISC maintains that this is no big deal , but there are plenty of people ( myself included ) that feel otherwise.- The root and second level DNS providers are probably not going to support DNSSEC , or at least that was the feeling a year ago .
As a result , ISC came up with something called DLV , or Domain Lookaside Validation ( RFC 5074 ) .
This essentially sets up ISC as the official arbiter of which second level DNS zones ( like google.com , microsoft.com , etc ) are official and can sign their own zones.ISC may not be selling anything , but they stand to gain significantly if they become the de facto authority on which internet domains are valid , and the presentation was more full of FUD than anything I had ever heard come out of Microsoft .
Seriously.I got the strong feeling that DNSSEC in general really feels half baked and rushed out , rather than something simple and well thought out .
I would advise everyone to avoid it like the plague , and hold out for a better solution .</tokentext>
<sentencetext>DNSSEC must be the most wildly overrated technology to ever come out of the internet.Seriously, it's just terrible from a system administrator's perspective.It's been a year since I listened to a speech about DNSSEC (from an official ISC representative) at a Linux User Group meeting, so I don't have every last detail on the tip of my brain.
However, it provides a little more security in some ways, while making other things worse.Among the highlights:- You need to sign your DNS zones every thirty days or so, because the crypto in DNSSEC isn't really that good for speed optimization reasons- If the signatures on your DNS zones expire, any validating DNSSEC resolver will pretend like your zone doesn't exist (since it was too late to use anything other than NXDOMAIN to indicate signing problems to keep backwards compatibility)- You therefore need to set up a cron job on a second server to make sure that the DNS zones were signed properly.
At the time this bug was published, there weren't any tools to do this in a sane manner, so you'd have to write your own scripts- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work.
Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone.
This is because every record in the zone has a pointer to the next record, kind of like a circular linked list.
ISC maintains that this is no big deal, but there are plenty of people (myself included) that feel otherwise.- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago.
As a result, ISC came up with something called DLV, or Domain Lookaside Validation (RFC 5074).
This essentially sets up ISC as the official arbiter of which second level DNS zones (like google.com, microsoft.com, etc) are official and can sign their own zones.ISC may not be selling anything, but they stand to gain significantly if they become the de facto authority on which internet domains are valid, and the presentation was more full of FUD than anything I had ever heard come out of Microsoft.
Seriously.I got the strong feeling that DNSSEC in general really feels half baked and rushed out, rather than something simple and well thought out.
I would advise everyone to avoid it like the plague, and hold out for a better solution.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466761</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469011</id>
	<title>Re:I don't wanna put a subject.</title>
	<author>Lennie</author>
	<datestamp>1245955620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is actually one of the things I'd love to see if DNSSEC actually does get going for real.</p><p>I'll love to be able to put SSH pub-keys and SSL(https) pub-keys in a verifiable DNS.</p><p>At this point tooling, etc. really needs to be improved if I'm going to implement DNSSEC on my domains.</p><p>The whole key-rollover stuff is still to complicated.</p></htmltext>
<tokenext>This is actually one of the things I 'd love to see if DNSSEC actually does get going for real.I 'll love to be able to put SSH pub-keys and SSL ( https ) pub-keys in a verifiable DNS.At this point tooling , etc .
really needs to be improved if I 'm going to implement DNSSEC on my domains.The whole key-rollover stuff is still to complicated .</tokentext>
<sentencetext>This is actually one of the things I'd love to see if DNSSEC actually does get going for real.I'll love to be able to put SSH pub-keys and SSL(https) pub-keys in a verifiable DNS.At this point tooling, etc.
really needs to be improved if I'm going to implement DNSSEC on my domains.The whole key-rollover stuff is still to complicated.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531</id>
	<title>new security products and services? great.</title>
	<author>Anonymous</author>
	<datestamp>1245945540000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><p>I have never met a bigger group of shysters and con-artists than "security consultants" in all my life.</p><p><i> Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services</i></p><p>that says it all, right there. This isn't about securing your assets, this is about generating fear so an army of security consultants can sell you an entirely new class of products you don't need.</p></htmltext>
<tokenext>I have never met a bigger group of shysters and con-artists than " security consultants " in all my life .
Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and servicesthat says it all , right there .
This is n't about securing your assets , this is about generating fear so an army of security consultants can sell you an entirely new class of products you do n't need .</tokentext>
<sentencetext>I have never met a bigger group of shysters and con-artists than "security consultants" in all my life.
Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and servicesthat says it all, right there.
This isn't about securing your assets, this is about generating fear so an army of security consultants can sell you an entirely new class of products you don't need.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466723</id>
	<title>Re:new security products and services? great.</title>
	<author>Anonymous</author>
	<datestamp>1245946560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>The Kaminisky bug is real, and its being used out in the wild. This is not a hypothetical academic exercise. DNS needs to be secured. Its not fear mongering, and its not for profit.</p><p>Many of these security consultants you speak of are not consultants at all, but experts working on this stuff in their free time for the betterment of the internet.</p></htmltext>
<tokenext>The Kaminisky bug is real , and its being used out in the wild .
This is not a hypothetical academic exercise .
DNS needs to be secured .
Its not fear mongering , and its not for profit.Many of these security consultants you speak of are not consultants at all , but experts working on this stuff in their free time for the betterment of the internet .</tokentext>
<sentencetext>The Kaminisky bug is real, and its being used out in the wild.
This is not a hypothetical academic exercise.
DNS needs to be secured.
Its not fear mongering, and its not for profit.Many of these security consultants you speak of are not consultants at all, but experts working on this stuff in their free time for the betterment of the internet.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467417</id>
	<title>Questions from a DNS implementor</title>
	<author>Ex-Linux-Fanboy</author>
	<datestamp>1245949740000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>
OK, since Mr. Kaminsky is following this thread, I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky.
</p><p>
Let me introduce myself: My name is Sam Trenholme and I am the implementor of <a href="http://maradns.org/" title="maradns.org">MaraDNS</a> [maradns.org], a recursive and caching DNS server.  Right now, I am in the slow process of <a href="http://maradns.blogspot.com/search/label/Deadwood" title="blogspot.com">re-writing the recursive DNS resolver</a> [blogspot.com].  While <a href="http://maradns.blogspot.com/2008/07/maradns-is-immune-to-new-cache.html" title="blogspot.com">MaraDNS has <em>always</em> been as secure as non-DNSSEC can be against Mr. Kaminsky's bug</a> [blogspot.com] (DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001), I am wondering:
</p><p>
How hard is it to implement DNSSEC in my recursive cache?  How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it?  About how long will it take me to code MaraDNS to have full DNSSEC support?
</p><p>
I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it; right now BIND and Unbound appear to be the only DNS servers to support it.  DjbDNS doesn't support it, of course, and probably never will.  My own MaraDNS and PowerDNS also don't support.
</p><p>
What are your thoughts?  Has a reasonable effort been made to make DNSSEC easy to implement?</p></htmltext>
<tokenext>OK , since Mr. Kaminsky is following this thread , I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky . Let me introduce myself : My name is Sam Trenholme and I am the implementor of MaraDNS [ maradns.org ] , a recursive and caching DNS server .
Right now , I am in the slow process of re-writing the recursive DNS resolver [ blogspot.com ] .
While MaraDNS has always been as secure as non-DNSSEC can be against Mr. Kaminsky 's bug [ blogspot.com ] ( DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001 ) , I am wondering : How hard is it to implement DNSSEC in my recursive cache ?
How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it ?
About how long will it take me to code MaraDNS to have full DNSSEC support ?
I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it ; right now BIND and Unbound appear to be the only DNS servers to support it .
DjbDNS does n't support it , of course , and probably never will .
My own MaraDNS and PowerDNS also do n't support .
What are your thoughts ?
Has a reasonable effort been made to make DNSSEC easy to implement ?</tokentext>
<sentencetext>
OK, since Mr. Kaminsky is following this thread, I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky.

Let me introduce myself: My name is Sam Trenholme and I am the implementor of MaraDNS [maradns.org], a recursive and caching DNS server.
Right now, I am in the slow process of re-writing the recursive DNS resolver [blogspot.com].
While MaraDNS has always been as secure as non-DNSSEC can be against Mr. Kaminsky's bug [blogspot.com] (DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001), I am wondering:

How hard is it to implement DNSSEC in my recursive cache?
How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it?
About how long will it take me to code MaraDNS to have full DNSSEC support?
I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it; right now BIND and Unbound appear to be the only DNS servers to support it.
DjbDNS doesn't support it, of course, and probably never will.
My own MaraDNS and PowerDNS also don't support.
What are your thoughts?
Has a reasonable effort been made to make DNSSEC easy to implement?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467049</id>
	<title>Re:Optimistic guy</title>
	<author>Anonymous</author>
	<datestamp>1245948240000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Kaminsky is incredibly enthusiastic about DNSSEC.<nobr> <wbr></nobr>... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.</p></div><p>I guess it depends if you care about getting the correct IP address back when resolving a host or not.</p><p>Personally, when i type google.com into a resolver, I kinda like to get one of the IPs google wants returned for it, and not an IP the ISP or a hacker wants returned for it.</p><p>To each their own thou!</p></div>
	</htmltext>
<tokenext>Kaminsky is incredibly enthusiastic about DNSSEC .
... to the point where someone not too knowledgeable ( like I am ) wonders if DNSSEC really is that amazing or if he was just high.I guess it depends if you care about getting the correct IP address back when resolving a host or not.Personally , when i type google.com into a resolver , I kinda like to get one of the IPs google wants returned for it , and not an IP the ISP or a hacker wants returned for it.To each their own thou !</tokentext>
<sentencetext>Kaminsky is incredibly enthusiastic about DNSSEC.
... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.I guess it depends if you care about getting the correct IP address back when resolving a host or not.Personally, when i type google.com into a resolver, I kinda like to get one of the IPs google wants returned for it, and not an IP the ISP or a hacker wants returned for it.To each their own thou!
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466797</id>
	<title>Re:new security products and services? great.</title>
	<author>Anonymous</author>
	<datestamp>1245946920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>(This is Dan)</p><p>No, it really is about securing your assets, instead of trying to deploy yet another magic box that conveniently fails just as you try to get it out of testing.</p></htmltext>
<tokenext>( This is Dan ) No , it really is about securing your assets , instead of trying to deploy yet another magic box that conveniently fails just as you try to get it out of testing .</tokentext>
<sentencetext>(This is Dan)No, it really is about securing your assets, instead of trying to deploy yet another magic box that conveniently fails just as you try to get it out of testing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472855</id>
	<title>Kaminsky/Vixie DNS Scam Known as Media Hack</title>
	<author>Anonymous</author>
	<datestamp>1245926220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think my comments to the NTIA on DNSSEC hit the point on Kaminsky and the DNS scam.  As others pointed out, this is a group of shysters.  MIT's "Technology Review" picked up the "Media Hack" aspect of the Story in December. That article is a good read if someone has a link.</p><p>Here are my NTIA comments which detail the Kaminsky/Vixie scam aspects and expose problems with DNSSEC:<br><a href="http://www.ntia.doc.gov/dns/comments/comment027.pdf" title="doc.gov" rel="nofollow">http://www.ntia.doc.gov/dns/comments/comment027.pdf</a> [doc.gov]</p><p>One of the things not detailed in my NTIA comments is that Kaminsky tells people to move to OpenDNS.ORG, run by Vixie associates David Ulevitch and Bill Fumerola. Fumerola is also a friend of Chris Neill. IADL has a page on Neill and his connection to spam-abuse at<br><a href="http://www.iadl.org/cn/cn-story.html" title="iadl.org" rel="nofollow">http://www.iadl.org/cn/cn-story.html</a> [iadl.org]</p><p>On<nobr> <wbr></nobr>.ORG Signing</p><p>While the<nobr> <wbr></nobr>.ORG TLD was indeed recently signed, I could not get<nobr> <wbr></nobr>.ORG TLD officials to respond to questions about whether there was regulatory approval for their actions.  It is also telling that Vixie is involved with<nobr> <wbr></nobr>.ORG TLD. The<nobr> <wbr></nobr>.ORG signing appears to be an effort at "persuasion"--Sort of 'See, we did it'.   But as my NTIA comments spell out, there are two serious DDoS attacks created by DNSSEC.   While one perhaps might block<nobr> <wbr></nobr>.ORG servers during an attack, one cannot block the root DNS servers.</p></htmltext>
<tokenext>I think my comments to the NTIA on DNSSEC hit the point on Kaminsky and the DNS scam .
As others pointed out , this is a group of shysters .
MIT 's " Technology Review " picked up the " Media Hack " aspect of the Story in December .
That article is a good read if someone has a link.Here are my NTIA comments which detail the Kaminsky/Vixie scam aspects and expose problems with DNSSEC : http : //www.ntia.doc.gov/dns/comments/comment027.pdf [ doc.gov ] One of the things not detailed in my NTIA comments is that Kaminsky tells people to move to OpenDNS.ORG , run by Vixie associates David Ulevitch and Bill Fumerola .
Fumerola is also a friend of Chris Neill .
IADL has a page on Neill and his connection to spam-abuse athttp : //www.iadl.org/cn/cn-story.html [ iadl.org ] On .ORG SigningWhile the .ORG TLD was indeed recently signed , I could not get .ORG TLD officials to respond to questions about whether there was regulatory approval for their actions .
It is also telling that Vixie is involved with .ORG TLD .
The .ORG signing appears to be an effort at " persuasion " --Sort of 'See , we did it' .
But as my NTIA comments spell out , there are two serious DDoS attacks created by DNSSEC .
While one perhaps might block .ORG servers during an attack , one can not block the root DNS servers .</tokentext>
<sentencetext>I think my comments to the NTIA on DNSSEC hit the point on Kaminsky and the DNS scam.
As others pointed out, this is a group of shysters.
MIT's "Technology Review" picked up the "Media Hack" aspect of the Story in December.
That article is a good read if someone has a link.Here are my NTIA comments which detail the Kaminsky/Vixie scam aspects and expose problems with DNSSEC:http://www.ntia.doc.gov/dns/comments/comment027.pdf [doc.gov]One of the things not detailed in my NTIA comments is that Kaminsky tells people to move to OpenDNS.ORG, run by Vixie associates David Ulevitch and Bill Fumerola.
Fumerola is also a friend of Chris Neill.
IADL has a page on Neill and his connection to spam-abuse athttp://www.iadl.org/cn/cn-story.html [iadl.org]On .ORG SigningWhile the .ORG TLD was indeed recently signed, I could not get .ORG TLD officials to respond to questions about whether there was regulatory approval for their actions.
It is also telling that Vixie is involved with .ORG TLD.
The .ORG signing appears to be an effort at "persuasion"--Sort of 'See, we did it'.
But as my NTIA comments spell out, there are two serious DDoS attacks created by DNSSEC.
While one perhaps might block .ORG servers during an attack, one cannot block the root DNS servers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466787</id>
	<title>Re:Optimistic guy</title>
	<author>Anonymous</author>
	<datestamp>1245946860000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Sadly, I'm willing to agree.  DNSSEC may, in fact, be the cat's meow and and end-all-be-all to security, everywhere, but the way Kaminsky's advocating it seems disturbingly similar to some raving lunatic who finally, by a dumb stroke of luck, got one doomsday prediction right (in some way, shape, or form), and is now running around to anyone who'll listen, punctuating all his arguments with "Oh yeah?  Well, <i> <b>I</b> </i> was right about DNS security!  Remember?  REMEMBER THAT, SONNY??!?  I WAS RIGHT AND EVERYONE ELSE WAS WRONG SO LISTEN TO ME BECAUSE I KNOW MORE THAN YOU DO."</p></htmltext>
<tokenext>Sadly , I 'm willing to agree .
DNSSEC may , in fact , be the cat 's meow and and end-all-be-all to security , everywhere , but the way Kaminsky 's advocating it seems disturbingly similar to some raving lunatic who finally , by a dumb stroke of luck , got one doomsday prediction right ( in some way , shape , or form ) , and is now running around to anyone who 'll listen , punctuating all his arguments with " Oh yeah ?
Well , I was right about DNS security !
Remember ? REMEMBER THAT , SONNY ? ? ! ?
I WAS RIGHT AND EVERYONE ELSE WAS WRONG SO LISTEN TO ME BECAUSE I KNOW MORE THAN YOU DO .
"</tokentext>
<sentencetext>Sadly, I'm willing to agree.
DNSSEC may, in fact, be the cat's meow and and end-all-be-all to security, everywhere, but the way Kaminsky's advocating it seems disturbingly similar to some raving lunatic who finally, by a dumb stroke of luck, got one doomsday prediction right (in some way, shape, or form), and is now running around to anyone who'll listen, punctuating all his arguments with "Oh yeah?
Well,  I  was right about DNS security!
Remember?  REMEMBER THAT, SONNY??!?
I WAS RIGHT AND EVERYONE ELSE WAS WRONG SO LISTEN TO ME BECAUSE I KNOW MORE THAN YOU DO.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467785</id>
	<title>Re:new security products and services? great.</title>
	<author>Anonymous</author>
	<datestamp>1245951120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>This isn't about securing your assets, this is about generating fear so an army of security consultants can sell you an entirely new class of products you don't need</p></div><p>Yea, just like I hate how microsoft is trying to sell me crap I don't need every other Tuesday with their hotfixes and... oh, those are free?  just like dnssec?  hmm</p><p>So, what is being sold again?</p></div>
	</htmltext>
<tokenext>This is n't about securing your assets , this is about generating fear so an army of security consultants can sell you an entirely new class of products you do n't needYea , just like I hate how microsoft is trying to sell me crap I do n't need every other Tuesday with their hotfixes and... oh , those are free ?
just like dnssec ?
hmmSo , what is being sold again ?</tokentext>
<sentencetext>This isn't about securing your assets, this is about generating fear so an army of security consultants can sell you an entirely new class of products you don't needYea, just like I hate how microsoft is trying to sell me crap I don't need every other Tuesday with their hotfixes and... oh, those are free?
just like dnssec?
hmmSo, what is being sold again?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28479597</id>
	<title>Re:new security products and services? great.</title>
	<author>deananderson</author>
	<datestamp>1246014060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The "Kaminsky bug" is a hoax. Kaminsky didn't discover anything. The only thing that Kaminsky can put his name on is the hoax.  In my NTIA comments<br><a href="http://www.ntia.doc.gov/dns/comments/comment027.pdf" title="doc.gov" rel="nofollow">http://www.ntia.doc.gov/dns/comments/comment027.pdf</a> [doc.gov] I traced down everything Kaminsky claimed to have discovered to find the true author.</p><p>There are no (or rare) "Kaminsky exploits" in the wild.  All servers but BIND have implmented UDP port randomization for years. <b>WITHOUT</b> port randomization, one can exhaust the 16bit of Query ID in 65000 spoofed UDP packets--if one does this before the genuine packet is returned, the attack is successful. <b>WITH</b> port randomization, one needs to send 26 million UDP packets if 256 ports are used by the nameserver---much harder.  And DNS TCP is invulnerable to blind attacks.</p><p>The Spring 2009 2600 Magazine has an article "Spoofing DNS on a LAN" but it is Man-in-the-middle attack, not the blind attack that Kaminsky describes.   In the 2600 article, an an ARP message is used to intercept DNS packets. The DNS packets are altered with a new IP address to cause an http request to go to a proxy server for "inspection".</p><p>If DNSSEC were used in the same case as the article, the attacker just has to note the IP address given by DNSSEC, and send an ARP for *that* address which would cause its http proxy to intercept traffic to *that* address.  Same result. DNSSEC is irrelevant to this attack.  In fact, since the attacker can see the DNS request, it can just turn off the DNSSEC flag in the request so that a non-secure response is returned.</p><p>It is possible that the requesting resolver might be configured not to accept unsecure requests, but this is very tedious and impractical. Each resolver has be configured with keys and updated at just the right time or "DNSSEC suicide" results.  Related to this is an attack on the caching nameserver that can result in Denial of Service to the client.</p><p>Worse yet, the DNSSEC responses are very large, and so a spoofed request have easily have a 126X amplification factor. If this response is coming from Root DNS servers, there is no way to block the attack. Blocking packets from the root servers effectively disables <b>ALL</b> DNS.</p><p>The "Kaminsky bug" is a blind attack using brute force to exhaust the 16bit of Query ID in 65000 forged packets.  This was discovered in 1999 by Dr. Dan Bernstein, and is fixed by port randomization.  BIND/Vixie stubbornly refused to implement this change and even harrassed and censored and blocked Bernstein's messages to IETF DNS lists. The next part of the Kaminsky hoax is to alter the Nameserver records provided as glue. But this was discovered in 2006.</p><p>Kaminsky/Vixie et al really are making money on DNSSEC and the Kaminsky/Vixie Hoax is just scaring people into adopting DNSSEC, which doesn't solve any problem, but lines their pockets.  Other DNS experts like Masataka Ohta have noted that DNSSEC is not secure end to end.</p></htmltext>
<tokenext>The " Kaminsky bug " is a hoax .
Kaminsky did n't discover anything .
The only thing that Kaminsky can put his name on is the hoax .
In my NTIA commentshttp : //www.ntia.doc.gov/dns/comments/comment027.pdf [ doc.gov ] I traced down everything Kaminsky claimed to have discovered to find the true author.There are no ( or rare ) " Kaminsky exploits " in the wild .
All servers but BIND have implmented UDP port randomization for years .
WITHOUT port randomization , one can exhaust the 16bit of Query ID in 65000 spoofed UDP packets--if one does this before the genuine packet is returned , the attack is successful .
WITH port randomization , one needs to send 26 million UDP packets if 256 ports are used by the nameserver---much harder .
And DNS TCP is invulnerable to blind attacks.The Spring 2009 2600 Magazine has an article " Spoofing DNS on a LAN " but it is Man-in-the-middle attack , not the blind attack that Kaminsky describes .
In the 2600 article , an an ARP message is used to intercept DNS packets .
The DNS packets are altered with a new IP address to cause an http request to go to a proxy server for " inspection " .If DNSSEC were used in the same case as the article , the attacker just has to note the IP address given by DNSSEC , and send an ARP for * that * address which would cause its http proxy to intercept traffic to * that * address .
Same result .
DNSSEC is irrelevant to this attack .
In fact , since the attacker can see the DNS request , it can just turn off the DNSSEC flag in the request so that a non-secure response is returned.It is possible that the requesting resolver might be configured not to accept unsecure requests , but this is very tedious and impractical .
Each resolver has be configured with keys and updated at just the right time or " DNSSEC suicide " results .
Related to this is an attack on the caching nameserver that can result in Denial of Service to the client.Worse yet , the DNSSEC responses are very large , and so a spoofed request have easily have a 126X amplification factor .
If this response is coming from Root DNS servers , there is no way to block the attack .
Blocking packets from the root servers effectively disables ALL DNS.The " Kaminsky bug " is a blind attack using brute force to exhaust the 16bit of Query ID in 65000 forged packets .
This was discovered in 1999 by Dr. Dan Bernstein , and is fixed by port randomization .
BIND/Vixie stubbornly refused to implement this change and even harrassed and censored and blocked Bernstein 's messages to IETF DNS lists .
The next part of the Kaminsky hoax is to alter the Nameserver records provided as glue .
But this was discovered in 2006.Kaminsky/Vixie et al really are making money on DNSSEC and the Kaminsky/Vixie Hoax is just scaring people into adopting DNSSEC , which does n't solve any problem , but lines their pockets .
Other DNS experts like Masataka Ohta have noted that DNSSEC is not secure end to end .</tokentext>
<sentencetext>The "Kaminsky bug" is a hoax.
Kaminsky didn't discover anything.
The only thing that Kaminsky can put his name on is the hoax.
In my NTIA commentshttp://www.ntia.doc.gov/dns/comments/comment027.pdf [doc.gov] I traced down everything Kaminsky claimed to have discovered to find the true author.There are no (or rare) "Kaminsky exploits" in the wild.
All servers but BIND have implmented UDP port randomization for years.
WITHOUT port randomization, one can exhaust the 16bit of Query ID in 65000 spoofed UDP packets--if one does this before the genuine packet is returned, the attack is successful.
WITH port randomization, one needs to send 26 million UDP packets if 256 ports are used by the nameserver---much harder.
And DNS TCP is invulnerable to blind attacks.The Spring 2009 2600 Magazine has an article "Spoofing DNS on a LAN" but it is Man-in-the-middle attack, not the blind attack that Kaminsky describes.
In the 2600 article, an an ARP message is used to intercept DNS packets.
The DNS packets are altered with a new IP address to cause an http request to go to a proxy server for "inspection".If DNSSEC were used in the same case as the article, the attacker just has to note the IP address given by DNSSEC, and send an ARP for *that* address which would cause its http proxy to intercept traffic to *that* address.
Same result.
DNSSEC is irrelevant to this attack.
In fact, since the attacker can see the DNS request, it can just turn off the DNSSEC flag in the request so that a non-secure response is returned.It is possible that the requesting resolver might be configured not to accept unsecure requests, but this is very tedious and impractical.
Each resolver has be configured with keys and updated at just the right time or "DNSSEC suicide" results.
Related to this is an attack on the caching nameserver that can result in Denial of Service to the client.Worse yet, the DNSSEC responses are very large, and so a spoofed request have easily have a 126X amplification factor.
If this response is coming from Root DNS servers, there is no way to block the attack.
Blocking packets from the root servers effectively disables ALL DNS.The "Kaminsky bug" is a blind attack using brute force to exhaust the 16bit of Query ID in 65000 forged packets.
This was discovered in 1999 by Dr. Dan Bernstein, and is fixed by port randomization.
BIND/Vixie stubbornly refused to implement this change and even harrassed and censored and blocked Bernstein's messages to IETF DNS lists.
The next part of the Kaminsky hoax is to alter the Nameserver records provided as glue.
But this was discovered in 2006.Kaminsky/Vixie et al really are making money on DNSSEC and the Kaminsky/Vixie Hoax is just scaring people into adopting DNSSEC, which doesn't solve any problem, but lines their pockets.
Other DNS experts like Masataka Ohta have noted that DNSSEC is not secure end to end.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466723</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28474477</id>
	<title>Re:Question for Dan: signing the root</title>
	<author>Anonymous</author>
	<datestamp>1245932820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>why would there be only one root? key management would be a serious issue, but i doubt that the any government would be given sole control of the root key.<br>1) an NGO such as ICANN/ISV/etc<br>2) per domain tld root keys with com/net/org being NGO controlled (even if its something US based)</p></htmltext>
<tokenext>why would there be only one root ?
key management would be a serious issue , but i doubt that the any government would be given sole control of the root key.1 ) an NGO such as ICANN/ISV/etc2 ) per domain tld root keys with com/net/org being NGO controlled ( even if its something US based )</tokentext>
<sentencetext>why would there be only one root?
key management would be a serious issue, but i doubt that the any government would be given sole control of the root key.1) an NGO such as ICANN/ISV/etc2) per domain tld root keys with com/net/org being NGO controlled (even if its something US based)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467991</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468751</id>
	<title>Re:I don't wanna put a subject. -OK, house analogy</title>
	<author>Anonymous</author>
	<datestamp>1245954660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's kind of the point.  Dan has found a flaw in the basement of your house.<br>The entire house is in jeopardy, no matter how well built.  Every house affected.</p><p>Do you :<br>A:  Call Kaminsky a damn liar, denounce his snake oil, sip your turpentine.<br>B:  Stucco and paint every 10 days, whistling to yourself forcefully.<br>C:  Try to jackhammer out the flaw and form up some new foundation meantime<br>D:  Nuke the house from orbit, start from scratch, total web tech re-over in IPv6</p><p>I think Dan proposes C and eventually D.  Most people stuck on A and B.</p><p>But hey, when the internet fails, just think of all the free time you'll have.</p></htmltext>
<tokenext>That 's kind of the point .
Dan has found a flaw in the basement of your house.The entire house is in jeopardy , no matter how well built .
Every house affected.Do you : A : Call Kaminsky a damn liar , denounce his snake oil , sip your turpentine.B : Stucco and paint every 10 days , whistling to yourself forcefully.C : Try to jackhammer out the flaw and form up some new foundation meantimeD : Nuke the house from orbit , start from scratch , total web tech re-over in IPv6I think Dan proposes C and eventually D. Most people stuck on A and B.But hey , when the internet fails , just think of all the free time you 'll have .</tokentext>
<sentencetext>That's kind of the point.
Dan has found a flaw in the basement of your house.The entire house is in jeopardy, no matter how well built.
Every house affected.Do you :A:  Call Kaminsky a damn liar, denounce his snake oil, sip your turpentine.B:  Stucco and paint every 10 days, whistling to yourself forcefully.C:  Try to jackhammer out the flaw and form up some new foundation meantimeD:  Nuke the house from orbit, start from scratch, total web tech re-over in IPv6I think Dan proposes C and eventually D.  Most people stuck on A and B.But hey, when the internet fails, just think of all the free time you'll have.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468307</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468455</id>
	<title>Re:new security products and services? great.</title>
	<author>Anonymous</author>
	<datestamp>1245953640000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>0</modscore>
	<htmltext><p>I don't care if you really did invent the Internet.. This does not make DNSSEC any less of a retarded idea.</p><p>The Internet can not be free and trustworthy at the same time.  Keeping the network dumb and the edges smart where trust is best positioned to be established is the only design decision not rooted in nonsense.</p><p>The problem with IETF standards process is that the realistic concept of "more is less" or "good enough" is constantly drowned out by the voices foolishly seeking to write the perfect protocol even if the result is unreasonable in practice or adds significant complexity and overhead without providing any tangable benefit in return.</p><p>The Internets DNS does *NOT* need to be secure -- It mearly needs to protect against everything short of an active MITM which requires less than an ounce of cryptography to implement effectivly.</p><p>Making the trust anchor so large that it encompasses the entire planet for a given tld is the very definition of futility.  Some hacker or government somewhere will eventually get a root key and sign whatever domain they damn well please regardless of how careful and dilligent all of the players involed are.</p><p>Now for corporate/intranet environments DNSSEC has a great deal of value.</p></htmltext>
<tokenext>I do n't care if you really did invent the Internet.. This does not make DNSSEC any less of a retarded idea.The Internet can not be free and trustworthy at the same time .
Keeping the network dumb and the edges smart where trust is best positioned to be established is the only design decision not rooted in nonsense.The problem with IETF standards process is that the realistic concept of " more is less " or " good enough " is constantly drowned out by the voices foolishly seeking to write the perfect protocol even if the result is unreasonable in practice or adds significant complexity and overhead without providing any tangable benefit in return.The Internets DNS does * NOT * need to be secure -- It mearly needs to protect against everything short of an active MITM which requires less than an ounce of cryptography to implement effectivly.Making the trust anchor so large that it encompasses the entire planet for a given tld is the very definition of futility .
Some hacker or government somewhere will eventually get a root key and sign whatever domain they damn well please regardless of how careful and dilligent all of the players involed are.Now for corporate/intranet environments DNSSEC has a great deal of value .</tokentext>
<sentencetext>I don't care if you really did invent the Internet.. This does not make DNSSEC any less of a retarded idea.The Internet can not be free and trustworthy at the same time.
Keeping the network dumb and the edges smart where trust is best positioned to be established is the only design decision not rooted in nonsense.The problem with IETF standards process is that the realistic concept of "more is less" or "good enough" is constantly drowned out by the voices foolishly seeking to write the perfect protocol even if the result is unreasonable in practice or adds significant complexity and overhead without providing any tangable benefit in return.The Internets DNS does *NOT* need to be secure -- It mearly needs to protect against everything short of an active MITM which requires less than an ounce of cryptography to implement effectivly.Making the trust anchor so large that it encompasses the entire planet for a given tld is the very definition of futility.
Some hacker or government somewhere will eventually get a root key and sign whatever domain they damn well please regardless of how careful and dilligent all of the players involed are.Now for corporate/intranet environments DNSSEC has a great deal of value.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466723</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468011</id>
	<title>Will DNSSEC my ISP's dns hijacking?</title>
	<author>Anonymous</author>
	<datestamp>1245951960000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've got verizon and when I look up non-existent TLDs I get back a records of 8.15.7.117, 63.251.179.13, and 67.63.55.15.</p><p>Now, maybe that would be cool if I were using their DNS servers but I'm using dnscache running on localhost, so they're hijacking requests to root servers.</p><p>So, WTF, and will DNSSEC make any difference in this?</p></htmltext>
<tokenext>I 've got verizon and when I look up non-existent TLDs I get back a records of 8.15.7.117 , 63.251.179.13 , and 67.63.55.15.Now , maybe that would be cool if I were using their DNS servers but I 'm using dnscache running on localhost , so they 're hijacking requests to root servers.So , WTF , and will DNSSEC make any difference in this ?</tokentext>
<sentencetext>I've got verizon and when I look up non-existent TLDs I get back a records of 8.15.7.117, 63.251.179.13, and 67.63.55.15.Now, maybe that would be cool if I were using their DNS servers but I'm using dnscache running on localhost, so they're hijacking requests to root servers.So, WTF, and will DNSSEC make any difference in this?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469149</id>
	<title>Re:You obviously have no idea what your talking ab</title>
	<author>jafiwam</author>
	<datestamp>1245956040000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>You don't host anything for real paying customers do you?<br><br>Let me give you a summary of how interaction with "security consultants" usually goes:<br><br>1. Customer gets cold called or sees some FUD on local TV, or portscans or the "consultant" has some dude in Malaysia digging around to find the sites hosted for pennies an hour.<br>2. Customer gets bilked out of a couple hundred dollars for a 'security audit' (a scan using a common tool with default settings usually)<br>3. Customer fails to understand any of it.<br>4. Passes a FUD report on to my desk, and proceeds to piss and moan or wring hands.<br>5. I have to stop what I am doing and examine the bogus report, then make a time consuming write up, explaining why having port 80 open is not a big deal and that it's typically not possible to be running both IIS and AIX  (Unix) on the same box.<br>6. "security consultant" either tries to sell the user a open source program, Barracuda box (puke) or just laughs all the way to the bank, or even better yet starts bugging me about being honest with the customer (who is now unhappy about the fee charged).<br><br>This sequence repeats with every new BS bug, news story, or any time the economy is flush with IT money.<br><br>The "security consultant" is never really concerned about security, only money.  Most of the time they don't know anything, sometimes they are outright brain-dead stupid and want to do things like put a notice "Please do not hack our web site" on every page because they think it won't be illegal to deface if the notice is not there. (Yes, that's really what they wanted.)<br><br>Replace the "security consultant" with the following types; "copyright protection scanning" and "defacement warning monitoring" (THAT is a bullshit scam) and "version back ups" and you have a whole world of suck.  Thankfully the economy has been bad for a while so mom&amp;pop shops are slamming the door on a two hundred dollar expense for an audit.<br><br>Maybe Kimansky himself won't be doing this, however a legion of other folks will be following shortly behind that will. The dream to update DNS is nice, but it's a stupidly impractical thing to be demanding everybody do right now.  Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?</htmltext>
<tokenext>You do n't host anything for real paying customers do you ? Let me give you a summary of how interaction with " security consultants " usually goes : 1 .
Customer gets cold called or sees some FUD on local TV , or portscans or the " consultant " has some dude in Malaysia digging around to find the sites hosted for pennies an hour.2 .
Customer gets bilked out of a couple hundred dollars for a 'security audit ' ( a scan using a common tool with default settings usually ) 3 .
Customer fails to understand any of it.4 .
Passes a FUD report on to my desk , and proceeds to piss and moan or wring hands.5 .
I have to stop what I am doing and examine the bogus report , then make a time consuming write up , explaining why having port 80 open is not a big deal and that it 's typically not possible to be running both IIS and AIX ( Unix ) on the same box.6 .
" security consultant " either tries to sell the user a open source program , Barracuda box ( puke ) or just laughs all the way to the bank , or even better yet starts bugging me about being honest with the customer ( who is now unhappy about the fee charged ) .This sequence repeats with every new BS bug , news story , or any time the economy is flush with IT money.The " security consultant " is never really concerned about security , only money .
Most of the time they do n't know anything , sometimes they are outright brain-dead stupid and want to do things like put a notice " Please do not hack our web site " on every page because they think it wo n't be illegal to deface if the notice is not there .
( Yes , that 's really what they wanted .
) Replace the " security consultant " with the following types ; " copyright protection scanning " and " defacement warning monitoring " ( THAT is a bullshit scam ) and " version back ups " and you have a whole world of suck .
Thankfully the economy has been bad for a while so mom&amp;pop shops are slamming the door on a two hundred dollar expense for an audit.Maybe Kimansky himself wo n't be doing this , however a legion of other folks will be following shortly behind that will .
The dream to update DNS is nice , but it 's a stupidly impractical thing to be demanding everybody do right now .
Aside from a few articles here and there , the " real world exploits " for this stuff , where someone actually gets harmed... well , where are THOSE reports ?</tokentext>
<sentencetext>You don't host anything for real paying customers do you?Let me give you a summary of how interaction with "security consultants" usually goes:1.
Customer gets cold called or sees some FUD on local TV, or portscans or the "consultant" has some dude in Malaysia digging around to find the sites hosted for pennies an hour.2.
Customer gets bilked out of a couple hundred dollars for a 'security audit' (a scan using a common tool with default settings usually)3.
Customer fails to understand any of it.4.
Passes a FUD report on to my desk, and proceeds to piss and moan or wring hands.5.
I have to stop what I am doing and examine the bogus report, then make a time consuming write up, explaining why having port 80 open is not a big deal and that it's typically not possible to be running both IIS and AIX  (Unix) on the same box.6.
"security consultant" either tries to sell the user a open source program, Barracuda box (puke) or just laughs all the way to the bank, or even better yet starts bugging me about being honest with the customer (who is now unhappy about the fee charged).This sequence repeats with every new BS bug, news story, or any time the economy is flush with IT money.The "security consultant" is never really concerned about security, only money.
Most of the time they don't know anything, sometimes they are outright brain-dead stupid and want to do things like put a notice "Please do not hack our web site" on every page because they think it won't be illegal to deface if the notice is not there.
(Yes, that's really what they wanted.
)Replace the "security consultant" with the following types; "copyright protection scanning" and "defacement warning monitoring" (THAT is a bullshit scam) and "version back ups" and you have a whole world of suck.
Thankfully the economy has been bad for a while so mom&amp;pop shops are slamming the door on a two hundred dollar expense for an audit.Maybe Kimansky himself won't be doing this, however a legion of other folks will be following shortly behind that will.
The dream to update DNS is nice, but it's a stupidly impractical thing to be demanding everybody do right now.
Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466761</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473103</id>
	<title>Re:You obviously have no idea what your talking ab</title>
	<author>Effugas</author>
	<datestamp>1245927120000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>(This is Dan)</p><p>There's lots of shysters in every field.  Doesn't change the fact that there are problems out there that need fixing.  Security is in fact a problem.</p><p>In concrete terms, just for my vuln, about 1\% of one of Brazil's largest bank's customers had their info taken by my bug.  That wasn't fun.  And China Netcom got hit pretty hard too, go Google that.  Of course, there's a lot of data we're missing, because nobody needs to report.  But anecdotally, this was a problem, but not the end of the world.  Good!  I didn't exactly set out to end the world<nobr> <wbr></nobr>:)</p><p>In terms of what I see fixing, I see a lot of technologies repeatedly sold as "and then you get certificates", and nobody does, because it's just such a cross organizational nightmare to manage.  Certs aren't working, and it's holding back auth technology after auth technology.  Verizon Business' data says that 60\% of vulns aren't implementation flaws -- they're authentication flaws, with passwords at the heart of them.</p><p>Why so many passwords?  Because they work.  Well, DNS works too.  Maybe we can use it to make all the better things scale across organizational boundaries.</p></htmltext>
<tokenext>( This is Dan ) There 's lots of shysters in every field .
Does n't change the fact that there are problems out there that need fixing .
Security is in fact a problem.In concrete terms , just for my vuln , about 1 \ % of one of Brazil 's largest bank 's customers had their info taken by my bug .
That was n't fun .
And China Netcom got hit pretty hard too , go Google that .
Of course , there 's a lot of data we 're missing , because nobody needs to report .
But anecdotally , this was a problem , but not the end of the world .
Good ! I did n't exactly set out to end the world : ) In terms of what I see fixing , I see a lot of technologies repeatedly sold as " and then you get certificates " , and nobody does , because it 's just such a cross organizational nightmare to manage .
Certs are n't working , and it 's holding back auth technology after auth technology .
Verizon Business ' data says that 60 \ % of vulns are n't implementation flaws -- they 're authentication flaws , with passwords at the heart of them.Why so many passwords ?
Because they work .
Well , DNS works too .
Maybe we can use it to make all the better things scale across organizational boundaries .</tokentext>
<sentencetext>(This is Dan)There's lots of shysters in every field.
Doesn't change the fact that there are problems out there that need fixing.
Security is in fact a problem.In concrete terms, just for my vuln, about 1\% of one of Brazil's largest bank's customers had their info taken by my bug.
That wasn't fun.
And China Netcom got hit pretty hard too, go Google that.
Of course, there's a lot of data we're missing, because nobody needs to report.
But anecdotally, this was a problem, but not the end of the world.
Good!  I didn't exactly set out to end the world :)In terms of what I see fixing, I see a lot of technologies repeatedly sold as "and then you get certificates", and nobody does, because it's just such a cross organizational nightmare to manage.
Certs aren't working, and it's holding back auth technology after auth technology.
Verizon Business' data says that 60\% of vulns aren't implementation flaws -- they're authentication flaws, with passwords at the heart of them.Why so many passwords?
Because they work.
Well, DNS works too.
Maybe we can use it to make all the better things scale across organizational boundaries.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469149</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466763</id>
	<title>Plenty of Boring Topics on Slashdot</title>
	<author>Anonymous</author>
	<datestamp>1245946740000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext>Has anyone noticed the recent increase in the number of shockingly boring topics on Slashdot?</htmltext>
<tokenext>Has anyone noticed the recent increase in the number of shockingly boring topics on Slashdot ?</tokentext>
<sentencetext>Has anyone noticed the recent increase in the number of shockingly boring topics on Slashdot?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468615</id>
	<title>Re:I don't wanna put a subject.</title>
	<author>Todd Knarr</author>
	<datestamp>1245954120000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>There already is a standard: SSL. It includes encryption (to secure the content going across the channel against eavesdropping) along with bidirectional authentication (server certificates to verify that you're talking to the server you think you're talking to, as well as the less-commonly-used client certificates to authenticate to the server that you're who you claim to be).</p><p>If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username. And I've long suggested that, for user security, browsers have a feature where the user can associate server certificates with identities and then, by selecting an identity to communicate with, limit the browser to accepting only servers presenting one of the certificates associated with that identity. Have a way for the user to download the server certificate as part of the account setup process and you pretty much eliminate the need for PKI to support the whole thing, self-signed certificates will work since they were gotten directly from the source. You still need verification of both ends, but it's limited to just during the account setup process and isn't an ongoing thing.</p></htmltext>
<tokenext>There already is a standard : SSL .
It includes encryption ( to secure the content going across the channel against eavesdropping ) along with bidirectional authentication ( server certificates to verify that you 're talking to the server you think you 're talking to , as well as the less-commonly-used client certificates to authenticate to the server that you 're who you claim to be ) .If I were setting up a secure site , it 'd be SSL-only .
As part of the account-setup process , you 'd be asked to generate a client certificate and upload the public certificate ( over an SSL connection ) to the server to be attached to your account .
From that point on , when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username .
And I 've long suggested that , for user security , browsers have a feature where the user can associate server certificates with identities and then , by selecting an identity to communicate with , limit the browser to accepting only servers presenting one of the certificates associated with that identity .
Have a way for the user to download the server certificate as part of the account setup process and you pretty much eliminate the need for PKI to support the whole thing , self-signed certificates will work since they were gotten directly from the source .
You still need verification of both ends , but it 's limited to just during the account setup process and is n't an ongoing thing .</tokentext>
<sentencetext>There already is a standard: SSL.
It includes encryption (to secure the content going across the channel against eavesdropping) along with bidirectional authentication (server certificates to verify that you're talking to the server you think you're talking to, as well as the less-commonly-used client certificates to authenticate to the server that you're who you claim to be).If I were setting up a secure site, it'd be SSL-only.
As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account.
From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username.
And I've long suggested that, for user security, browsers have a feature where the user can associate server certificates with identities and then, by selecting an identity to communicate with, limit the browser to accepting only servers presenting one of the certificates associated with that identity.
Have a way for the user to download the server certificate as part of the account setup process and you pretty much eliminate the need for PKI to support the whole thing, self-signed certificates will work since they were gotten directly from the source.
You still need verification of both ends, but it's limited to just during the account setup process and isn't an ongoing thing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468307</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472071
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467557
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469011
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468615
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468307
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466797
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467049
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467227
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466761
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28476707
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472855
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466787
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469189
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466865
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28474477
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467991
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468751
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468307
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28471111
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468615
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468307
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468923
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468185
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467417
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473103
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469149
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466761
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28479597
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466723
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468029
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467557
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472999
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468455
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466723
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467785
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473009
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467991
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473253
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468997
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466761
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_25_1354212_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28470725
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467089
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466531
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466797
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466723
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468455
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472999
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28479597
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466761
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467227
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468997
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473253
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469149
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473103
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467785
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467417
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468185
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468923
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467991
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28474477
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28473009
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468307
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468751
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468615
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28471111
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469011
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466687
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466865
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28469189
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28466787
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467049
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28470693
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468761
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472855
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28476707
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467089
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28470725
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_25_1354212.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28467557
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28468029
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_25_1354212.28472071
</commentlist>
</conversation>
