Re: [dns-operations] Another whitepaper on DDOS
Good example. I have argued for quite some time, that one of the DNSSEC primary benefits is to fight misconfigurations. With DNSSEC an misconfigured domain just fails instead of continuing to work somehow. There are lots of misconfigured domains on the Internet and plenty clueless DNS admins. Those are the primary resistance to widespread adoption of DNSSEC. Unfortunately, most management types who could enforce an DNSSEC-only policy don't know or just don't care. For most does the web site open in a browser? is good enough. Daniel Sent from my iPad On 27.02.2013, at 09:08, Edward Lewis ed.le...@neustar.biz wrote: On Feb 22, 2013, at 23:18, David Conrad wrote: Has there been any documented attack that would have been prevented by DNSSEC that one can point to? Well, prevented...no, nothing can ever prevent an attack. But I realized yesterday I should answer yes to the question of whether DNSSEC would have stemmed a cache poisoning attack - with a public reference. http://blog.neustar.biz/dns-matters/a-case-where-dnssec-would-help-part-1/ http://blog.neustar.biz/dns-matters/a-case-where-dnssec-would-help-part-2/ Here's the weird thing. I wrote the above article. I wasn't aware it was publicly visible until about a month ago. I found it via a web search engine myself. Second, the quick story behind this is that this indeed is a cache poisoning attack, but not as described by Dan Kaminsky. That it was an attack nonetheless didn't occur to me until just this week. Third - when I was presented with the problem and I learned a few crucial facts, the thought gee, I wish there was DNSSEC here' did cross my mind. Not that the validation was needed, but had the data been signed I would have known where it was coming from. (You'd have to read the article to understand the context.) So, yes, finally I can say I've seen a case that's publicly documented - up to the point of providing anonymity to the victims involved. (I'm still waiting for the first full disclosure case, but this is what I can offer for now.) PS - As many of you know, I do not adhere to name and shame policy and take strides to protect identities when I present any sort of case study. So, the anonymity I hope to be supplying here (I think I've left no breadcrumbs) is not only because it involves a customer but the data being poisoned is not mine nor is the cache being poisoned mine. I just happened to look into the problem and turned the results over to the others. Because of this, I realize, it's not possible to very my claims and that's a regret I'll take. So - take this as you will. And finally - the event happened last summer and was ongoing when I wrote the blog entry in the fall. I don't know if it is still ongoing, I don't expect to hear back from anyone nor is it really my business to know. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
Mike Jones m...@mikejones.in wrote: What if you add your server to the delegation, and either leave one of their servers in the list or clone their zone and host that on a separate server? Resolvers with the old keys cached will only take answers from the old servers. Resolvers that have refreshed and got the new keys will only take answers from the new servers. Interesting thought. This will work for validating recursive servers that are able to iteratively try authority servers until they find one that works. Validators that can't do that (stub resolvers, resolvers in walled gardens) are likely to have problems. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
From: Daniel Kalchev dan...@digsys.bg There are lots of misconfigured domains on the Internet and plenty clueless DNS admins. Those are the primary resistance to widespread adoption of DNSSEC. Unfortunately, most management types who could enforce an DNSSEC-only policy don't know or just don't care. For most does the web site open in a browser? is good enough. Yes, I was one of those clueless DNS admins. I know more than I used to, but am I truly clueful? The jury is still out. When I started doing DNS here, a consultant set it up, said here's how you add records, and walked out the door. Everything else I knew for the next 15 years I learned on my own, thanks to Albitz, Liu, and the Grasshopper Book. I didn't even know about this list. I finally took the three day Intro to BIND and DNS class 2 years ago. The instructor talked about how most DNS admins learned from the tribal elders. I wish I had had such a mentor! A certain large software company has made it easy to install DNS servers, but because it is so easy, it doesn't require knowledge. Without knowledge, cluelessness is inevitable. The same applies to that companies email server. For a long time I've said Just because someone can install Exchange, doesn't mean they know what they're doing. As long as management gets their web page and email, they're happy. And if management is happy, why should they spend money to fix what isn't perceived as broken? And would the DNS (or email) admin even recognize the brokenness? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
On 26 February 2013 19:45, Tony Finch d...@dotat.at wrote: Vernon Schryver v...@rhyolite.com wrote: From: Tony Finch d...@dotat.at In addition to vjs's points, note that DNSSEC makes theft of a domain even more visible because it is likely to cause horrible breakage for validating users. I didn't mention those alarms, because I assumed the domain was stolen at the registrar or in the registry so that glue and DS records would be corrected by the adversary. I assumed that too :-) It's a common problem (see Educause recently...) The problem occurs because it is likely for caches to contain different parts of the validation chain (DS from parent, DNSKEYs and RRSIGs from child) from before and after the hack. What if you add your server to the delegation, and either leave one of their servers in the list or clone their zone and host that on a separate server? Resolvers with the old keys cached will only take answers from the old servers. Resolvers that have refreshed and got the new keys will only take answers from the new servers. This gives you a 'transition period' where you can't attack everyone yet, but you should be able to selectively attack the ones that have the new key set without causing any disruption to ones that don't. Does that idea sound viable? I would like to pre-empt anyone calling this a flaw with DNSSEC though as DNSSEC is not meant to protect against someone who can submit new keys for your domain. - Mike ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
On Feb 22, 2013, at 23:18, David Conrad wrote: Has there been any documented attack that would have been prevented by DNSSEC that one can point to? Well, prevented...no, nothing can ever prevent an attack. But I realized yesterday I should answer yes to the question of whether DNSSEC would have stemmed a cache poisoning attack - with a public reference. http://blog.neustar.biz/dns-matters/a-case-where-dnssec-would-help-part-1/ http://blog.neustar.biz/dns-matters/a-case-where-dnssec-would-help-part-2/ Here's the weird thing. I wrote the above article. I wasn't aware it was publicly visible until about a month ago. I found it via a web search engine myself. Second, the quick story behind this is that this indeed is a cache poisoning attack, but not as described by Dan Kaminsky. That it was an attack nonetheless didn't occur to me until just this week. Third - when I was presented with the problem and I learned a few crucial facts, the thought gee, I wish there was DNSSEC here' did cross my mind. Not that the validation was needed, but had the data been signed I would have known where it was coming from. (You'd have to read the article to understand the context.) So, yes, finally I can say I've seen a case that's publicly documented - up to the point of providing anonymity to the victims involved. (I'm still waiting for the first full disclosure case, but this is what I can offer for now.) PS - As many of you know, I do not adhere to name and shame policy and take strides to protect identities when I present any sort of case study. So, the anonymity I hope to be supplying here (I think I've left no breadcrumbs) is not only because it involves a customer but the data being poisoned is not mine nor is the cache being poisoned mine. I just happened to look into the problem and turned the results over to the others. Because of this, I realize, it's not possible to very my claims and that's a regret I'll take. So - take this as you will. And finally - the event happened last summer and was ongoing when I wrote the blog entry in the fall. I don't know if it is still ongoing, I don't expect to hear back from anyone nor is it really my business to know. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
Vernon Schryver v...@rhyolite.com wrote: Lutz Donnerhacke l...@iks-jena.de wrote: But the errornous transfer of ebay.de would create a deasaster with DANE. In what way would DANE make the theft of a domain worse? In addition to vjs's points, note that DNSSEC makes theft of a domain even more visible because it is likely to cause horrible breakage for validating users. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
From: Tony Finch d...@dotat.at But the errornous transfer of ebay.de would create a deasaster with DANE. In what way would DANE make the theft of a domain worse? In addition to vjs's points, note that DNSSEC makes theft of a domain even more visible because it is likely to cause horrible breakage for validating users. I didn't mention those alarms, because I assumed the domain was stolen at the registrar or in the registry so that glue and DS records would be corrected by the adversary. I didn't recall the particular theft, but assumed it involved the common modes of seizure by the registrar or the use of stolen credentials at the registrar. Only if the theft is downstream of the registry such as in a master authoritative server for the domain would DNSSEC raise alarms. Those alarms are valuable, but I didn't want to argue nits with people who after much more than a decade and many public scandles, still haven't twigged to the unredeemable fraud that is commercial PKI. Never mind the irony in the likely fact that the use of stolen registrar credentials would be protected (sic) by commercial PKI. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
I wonder if DANE could have prevented Microsoft's recent difficulty with expired SSL certs. https://www.google.com/search?tbm=nwsas_q=microsoft+azure+ssl Instead of an annual bout with internal purchase order and invoice red tape and with red tape at the CA, could Microsoft have automated the generation of certs and fingerprint TLSA RRs just as many automate their generation of zone signing RRSIG RRs? (Never mind that microsoft.com lacks RRSIG RRs.) ... From: Doug Barton do...@dougbarton.us Are there CA vendors who give out EV certificates for $fee + answer the e-mail? I know you can get basic SSL certs simply by answering the e-mail from the CA. I can't find anything about EV verification from registrars. Maybe I'm blind and stupid, or maybe writing down what they actually do would be too funny. I suspect you might need to submit a government registration document and answer a press-1-if-you're-human robo phone call. You won't forge the registration document, because the real things are so cheap, easy, and unverified. It's obvious nothing that I put in the online form other to get http://www.sos.state.co.us/biz/BuildCertificate.do?masterFileId=20051118531 was verified other than the credit card number for the $1.00 charge. (You might need to 'get' that URL twice.) See also http://www.sos.state.co.us/pubs/info_center/fees/business.html I've had DBA registrations in other states, and found them just as unimpressive. How would you interpret section 5 of https://www.cabforum.org/EV_Certificate_Guidelines.pdf to sell me a $1500 EV cert? https://www.symantec.com/theme.jsp?themeid=compare-ssl-certificates You couldn't afford to have someone to drive past my address to see if it's a vacant lot, not to mention ask my neighbors if they've seen anything shady or even ever seen me. If you want to sell certs to small businesses, then you cannot charge enough to do any checking. Not that look for the green bar is going to be a whole lot more successful than Don't say yes to security exceptions you don't understand, but I'm curious. :) Yes, EV certs are expensive tickets for slapstick security theater. Standards certs and the mailboxes (not SMTP but only for use after you log into your GoDaddy account), theft protection, scanning, and other hookum that GoDaddy sells are cheap seats. (Your recent claim that all registrars up-sell the same junk as GoDaddy is wrong. I'm trust that all of the registrars you've seen are as you said and like GoDaddy, but I've seen nothing like GoDaddy. That might be because I don't look at registrars that I've heard bad things about or that advertise prices below what I know of their costs (e.g. registry fees). I know they'll more than make up their losses in ways I'm too dumb to catch.) Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
On Feb 22, 2013, at 2:58 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: they keep pretending that the DNS attack in Brazil was cache poisoning, while it has been widely documented for a long time http://www.securelist.com/en/blog/208193852/The_tale_of_one_thousand_and_one_DSL_modems. I keep running into the Brazil had an attack that could've been prevented by DNSSEC too. Gets boring after a while. Has there been any documented attack that would have been prevented by DNSSEC that one can point to? Thanks, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
Warren, On Feb 22, 2013, at 7:42 AM, Warren Kumari war...@kumari.net wrote: http://dnssec-deployment.org/pipermail/dnssec-deployment/2012-July/006003.html Thanks! Missed that message somehow. BIND 4.8.anything in 2010? I weep for humanity. Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
David Conrad d...@virtualized.org wrote: Has there been any documented attack that would have been prevented by DNSSEC that one can point to? DigiNotar's bogus Google certificate would not have worked with DANE. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
* David Conrad [2013-02-22 16:18]: Has there been any documented attack that would have been prevented by DNSSEC that one can point to? This paper describes a censorship attack which could be mitigated by DNSSEC: http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Kryptografische Unterschrift ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
* Tony Finch wrote: DigiNotar's bogus Google certificate would not have worked with DANE. But the errornous transfer of ebay.de would create a deasaster with DANE. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
From: Lutz Donnerhacke l...@iks-jena.de But the errornous transfer of ebay.de would create a deasaster with DANE. In what way would DANE make the theft of a domain worse? Without DANE, the new possessor of a domain need only get SMTP working, create a new cert, apply for signature for a new cert, answer the email from the CA verifying ownership of the domain, and start using that new cert on new HTTP servers with improved web pages. With DANE, only a few things differ. One difference is that the new cert can be used as soon as DNS TTLs allow without waiting to answer ownership-verifying email from the CA. The second difference is that before and after the transfer, browser users can be more confident that the web pages they see are unchanged between HTTP server and HTTP client. In no case can you be sure that ebay.de is what you assume it is without some sort of out-of-band exchange of keys and secrets between you and ebay.de. Paying a CA $500 cannot buy more than $500 worth of identity checking and authentication, and that cannot penetrate more than $500 worth of smoke, mirrors, forged business licenses, etc. $500 is plenty for a hobby domain but ridiculous for an eBay. (Never mind the free CAs.) Commercial PKI verifications of the identities of strangers have always been frauds and snake oil sold to punters. That commercial PKI fees have always been too small to allow honest identity checks even for organizations more famous than Ebay was proven more than 10 years ago. https://www.cert.org/advisories/CA-2001-04.html http://technet.microsoft.com/en-us/security/advisory/2524375 Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
On Fri, Feb 22, 2013 at 07:42:17PM +, Vernon Schryver wrote: From: Lutz Donnerhacke l...@iks-jena.de But the errornous transfer of ebay.de would create a deasaster with DANE. In what way would DANE make the theft of a domain worse? On top of all the excellent points Vernon makes about how DANE is no worse, DANE gives you a couple mechanisms to make detection slightly easier. For the erroneous registrar or registrant transfer of the domain name is reflected in the WHOIS (or, let's hope, the eventual output of WEIRDS), so it's possible to see that the sponsorship of the name has changed. If it's merely all the name servers that have changed, that too might be useful evidence that something is up. None of this is perfect, but it is surely more evidence that can be taken into account. And there's the obvious benefit that with DANE, you're not stuck depending on every self-asserting trust vehicle that manages to convince the browser vendors to put in an anchor. I note that none of these mechanisms are built today, of course, but there's no reason reputation systems couldn't develop based on DANE along these lines, particularly if we get something like WEIRDS that would allow profiling of some classes of behaviour without disclosing all the PII that WHOIS does today. A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
Are there CA vendors who give out EV certificates for $fee + answer the e-mail? I know you can get basic SSL certs simply by answering the e-mail from the CA. Not that look for the green bar is going to be a whole lot more successful than Don't say yes to security exceptions you don't understand, but I'm curious. :) Doug On 02/22/2013 11:42 AM, Vernon Schryver wrote: From: Lutz Donnerhacke l...@iks-jena.de But the errornous transfer of ebay.de would create a deasaster with DANE. In what way would DANE make the theft of a domain worse? Without DANE, the new possessor of a domain need only get SMTP working, create a new cert, apply for signature for a new cert, answer the email from the CA verifying ownership of the domain, and start using that new cert on new HTTP servers with improved web pages. With DANE, only a few things differ. One difference is that the new cert can be used as soon as DNS TTLs allow without waiting to answer ownership-verifying email from the CA. The second difference is that before and after the transfer, browser users can be more confident that the web pages they see are unchanged between HTTP server and HTTP client. In no case can you be sure that ebay.de is what you assume it is without some sort of out-of-band exchange of keys and secrets between you and ebay.de. Paying a CA $500 cannot buy more than $500 worth of identity checking and authentication, and that cannot penetrate more than $500 worth of smoke, mirrors, forged business licenses, etc. $500 is plenty for a hobby domain but ridiculous for an eBay. (Never mind the free CAs.) Commercial PKI verifications of the identities of strangers have always been frauds and snake oil sold to punters. That commercial PKI fees have always been too small to allow honest identity checks even for organizations more famous than Ebay was proven more than 10 years ago. https://www.cert.org/advisories/CA-2001-04.html http://technet.microsoft.com/en-us/security/advisory/2524375 Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
At 09:26 22-02-2013, Matthäus Wander wrote: This paper describes a censorship attack which could be mitigated by DNSSEC: http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf See https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005343.html Regards, -sm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Another whitepaper on DDOS
Given the recent hubbub over the CloudShield posting, I would be interested to see what anyone thinks of the following whitepaper. Note that I have not yet read it, and in any case, I don't count myself as qualified to comment. But I enjoy reading people's opinions of other people's opinions...it is educational for me. http://docs.media.bitpipe.com/io_10x/io_106675/item_584633/Gartner%20and%20Arbor%20Focus%20on%20DDoS%20FINAL.PDF Jeff Wright ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
With all due respect to friends at both Arbor and Gartner, this is light weight by their standards and factually wrong on both details and recommendations having to do with DNS rate limiting. --vix Jeff Wright jwri...@isc.org wrote: Given the recent hubbub over the CloudShield posting, I would be interested to see what anyone thinks of the following whitepaper. Note that I have not yet read it, and in any case, I don't count myself as qualified to comment. But I enjoy reading people's opinions of other people's opinions...it is educational for me. http://docs.media.bitpipe.com/io_10x/io_106675/item_584633/Gartner%20and%20Arbor%20Focus%20on%20DDoS%20FINAL.PDF Jeff Wright ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
From: Jeff Wright jwri...@isc.org http://docs.media.bitpipe.com/io_10x/io_106675/item_584633/Gartner%20and%20Arbor%20Focus%20on%20DDoS%20FINAL.PDF On one hand, it - gets significant bits of history wrong, such as the claim that SSL had nothing to do with authentication and authorization until EV certificates. If confidentiality (encryption) were the sole point of SSL, then SSL would have gone straight to a DH exchange and done no public key computing. EV would not be a minor elaboration of the old, widely used PKI. (page 15) - urges the use of DNS Authentication. I guess DNS authentication [would work] to ensure that source queries to a DNS server ... are in fact coming from a valid host if you can find and deploy DNS stub resolvers that support DNS authentication and then deploy them. I think that's practically impossible for the forseeable futgure. It might instead be referring to ACLs in servers and relying on IP source addresses as authentication tokens, but that would be almost as lame. (page 6) - advocates naive and so bad query rate limiting and separate NXDOMAIN rate limiting. It should have mentioned RRL. (page 6) - advoctees applying RexEx's and packet capture for no purpose. Looking for text in DNS packets will find lots of it separated by what look like ASCII control characters. Unless you have a specific target, you're unlikely to do more than waste time by manually staring at packets for any port. (page 6) On the other hand, those are all minor nits and mostly reflect my prejudiced and overly strict reading. Overall, I found it innocuous and entertaining. If it seems revolutionary or eye opening and you have relevant responsibilities, then you urgently need more than any such document can offer. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
