Re: [dns-operations] Mozilla Firefox and ANY queries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This has apparently been fixed in Firefox 36.0.1: The use of ANY DNS has been disabled. It disables the use of ANY DNS to get the TTL on Windows. http://www.ghacks.net/2015/03/05/firefox-36-0-1-fixes-a-number-of-critical-issues/ FYI, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 I am tormented with an everlasting itch for things remote. I love to sail forbidden seas. - Herman Melville -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlT4v+wACgkQKJasdVTchbLZ3QD/WEIjem2CO1iCxuN5WmWh7H32 Y9axDMXy+qGhQnKMRFkBANNDaQvoDtLuQA7VoaI7ZAi7zQ9N/Eymg5tinr6bWaXR =9rEi -END PGP SIGNATURE- ___ 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] Subverting BIND's SRTT Algorithm Derandomizing NS Selection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Can anyone from ISC (bind maintainer) comment on this vulnerability, especially regarding what versions are affected and if a fix is available? https://www.usenix.org/conference/woot13/workshop-program/presentation/hay I am presuming this is the same? http://thehackernews.com/2014/05/critical-vulnerability-in-bind-software.html Thanks, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNpCUsACgkQKJasdVTchbJuHQD9GBAit5nEjjI3BCcYOErcTawR ZBE6g4lTv1XneIVfdGcBALg18dpZ5euFZsv6OAbJHDtKvW6U+X0I40KN/Tub+2Xd =c728 -END PGP SIGNATURE- ___ 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] Subverting BIND's SRTT Algorithm Derandomizing NS Selection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Peter, On 5/6/2014 10:50 AM, Peter Losher wrote: On 6 May 2014, at 9:09, Paul Ferguson wrote: Can anyone from ISC (bind maintainer) comment on this vulnerability, especially regarding what versions are affected and if a fix is available? https://www.usenix.org/conference/woot13/workshop-program/presentation/hay We/ISC posted a Operational notice on this last August: https://kb.isc.org/article/AA-01030 I also notice this in the note: ISC plans to address this deficiency by reimplementing the SRTT algorithm in future maintenance releases of the BIND 9 code. Was this reimplementation done, and if so, what version was it implemented? Apologies -- I am not a BIND expert by any stretch of the imagination... Thanks, - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNpIjMACgkQKJasdVTchbKJBAD/Skj2J/cayJAJNZ4O36QN+MiJ 652QT868T1uLQ9QxBGsBALooRPCTZztcu4WcfgBJtUgabnq1SI5b4K8U4m3srYdq =Zayg -END PGP SIGNATURE- ___ 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] Subverting BIND's SRTT Algorithm Derandomizing NS Selection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 5/6/2014 11:05 AM, Evan Hunt wrote: On Tue, May 06, 2014 at 10:56:03AM -0700, Paul Ferguson wrote: ISC plans to address this deficiency by reimplementing the SRTT algorithm in future maintenance releases of the BIND 9 code. Was this reimplementation done, and if so, what version was it implemented? Not yet. Thank you for the response. - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNpKbMACgkQKJasdVTchbKeAQEAiHJ7Seylu8lNfnIOMyQuAt4L 6Ko20ezbDffSgIZboigBAMAnHf7JkFOnRCn3GfD8hWZ+UYRaGO9nacPYskb3wu4V =YpRr -END PGP SIGNATURE- ___ 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] Hijacking of Google Public DNS in Turkey documented
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 See also: http://www.renesys.com/2014/03/turkish-internet-censorship/ - - ferg On 3/30/2014 1:13 PM, Alexander Neilson wrote: Have you done a lookup on public IP Address of those two nodes? Or any analysis of this variance? Using over the border internet? tunnelling? Regards Alexander Alexander Neilson Neilson Productions Limited alexan...@neilson.net.nz 021 329 681 022 456 2326 On 31/03/2014, at 3:57 am, Stephane Bortzmeyer bortzme...@nic.fr wrote: http://www.bortzmeyer.org/dns-routing-hijack-turkey.html Here is the result of a lookup of whoami.akamai.net from the ten turkish RIPE Atlas probes: [74.125.18.80] : 2 occurrences [195.175.255.66] : 8 occurrences 74.125.18.80 is Google, 195.175.255.66 Turkish Telecom. So, no, Google Public DNS is not proxied but replaced by an impostor which is a full recursor. [All measurements show that 2 Atlas probes in Turkey do not see the hijacking (the first two in the output above). I don't know why these two are spared.] ___ 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 - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlM4lzgACgkQKJasdVTchbLI8wEAkoEJ6E90O/VGj8Ra6OVSjXA0 37Vi1jpB3Bb+eW8R0qYA/0Prd+xZEh+J4H3Uan/kKCaAyz1T02l8mEeTFRRTmF7Q =pCIc -END PGP SIGNATURE- ___ 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] authority outage for ns[1-5].msft.net?
They are responding to queries again. - ferg On 11/21/2013 3:17 PM, David Dagon wrote: Hi, Trying from various locations, I can't seem to reach these authorities: ns3.msft.net. 172800 IN A 213.199.180.53 ns1.msft.net. 172800 IN A 65.55.37.62 ns5.msft.net. 172800 IN A 65.55.226.140 ns2.msft.net. 172800 IN A 64.4.59.173 ns4.msft.net. 172800 IN A 207.46.75.254 which act as authority for xbox.com, outlook.com, various windows update domains, and 77K or so domains. I can see domains still in caches, some soon to time out. And traceroutes die at ntwk.msn.net, so perhaps traffic volume is not the cause. (Though surely there's a retry storm under way.) I note a few posts on forums, just a few minutes old. So perhaps this is a recent development. Is there someone on list who can contact Microsoft? (Surely they know about this.) -- Paul Ferguson PGP Public Key ID: 0x63546533 ___ 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] Should medium-sized companies run their own recursive resolver?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/16/2013 1:44 PM, James Cloos wrote: PH == Paul Hoffmanpaul.hoff...@vpnc.org writes: PH Should that company run its own recursive resolver for its PH employees, or should it continue to rely on its ISP? *Every* site should run its own (preferably verifying) resolver. I have no problem with that as long as they are not open resolvers -- we already have somewhere in the neighborhood of 28-30 million of them that pose a direct threat to the health wellbeing of the Internet at-large because they can be used to facilitate DNS amplification attacks. $.02, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSXv3jq1pz9mNUZTMRAtqnAKCP+X8u6KY7bM8tcRbE4OqR3vdFSgCfUFsP lYcnCGhTPGDYZ2Z1atVB6/8= =VvXW -END PGP SIGNATURE- -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID -- Connect and Collaborate -- www.internetidentity.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] Should medium-sized companies run their own recursive resolver?
On 10/14/2013 9:42 AM, Rich Goodson wrote: I default to yes as well, but if they only have the one local resolver, and don't have any kind of backup (Google/OpenDNS, etc as secondary/tertiary via DHCP or whatever means they use for workstation network configuration), these two imaginary IT staff members could be setting themselves up for an embarrassing outage. Or leaving the recursive resolvers open to the entire Internet for abuse. - ferg -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID -- Connect and Collaborate -- www.internetidentity.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] Should medium-sized companies run their own recursive resolver?
On 10/14/2013 12:43 PM, Suzanne Woolf wrote: I'm wondering what motivated the question, particularly in such a generic form. Maybe this? http://openresolverproject.org/ - ferg -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID -- Connect and Collaborate -- www.internetidentity.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] DNS Attack over UDP fragmentation
On 9/4/2013 7:57 AM, Ondřej Surý wrote: Check also ICMP packet too big coming in with ridiculous sizes, they might be the sign that someone is trying the Shulman attack. JFTR It's one ICMP packet per the fragmentation cache timeout and the unique destination IP. I wish we had found out some way to enforce BCP38 before spoofing became a problem:( Believe me, no one wishes that more than do I. :-/ - ferg -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID -- Connect and Collaborate -- www.internetidentity.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] Registration Open for DNS OARC Spring 2013 Workshop - Dublin, 12th/13th May
Somewhat related, and since the meeting is being held in Europe -- ENISA is recommending that Internet network providers implement long-known traffic filtering techniques, which could have countered a major cyber incident that hit services across western Europe last Month (March 2013): https://www.enisa.europa.eu/publications/flash-notes/flash-note-can-recent-attacks-really-threaten-internet-availability FYI, - ferg On Fri, Apr 12, 2013 at 2:54 AM, Keith Mitchell ke...@dns-oarc.net wrote: (With apologies for any duplication of this information) We have now opened registration for our workshop in Dublin next month, you can find full details, including a registration form and talks approved to date at: https://indico.dns-oarc.net/indico/conferenceDisplay.py?confId=0 Talks submitted so far include use of Elliptic Curve Cryptography in DNSSEC, Anycast service enumeration, and evaluations of RRL behaviour. We still have room for more presentations, please use the form on the above site to submit your abstracts for consideration by the programme committee. In view of recent events, we're setting aside a significant amount of time to the problem of DNS reflection attacks and open resolvers, and Merike Kaeo will be running a session on this topic. Please contact her at merike.k...@mail.internetidentity.com if you would like to contribute to this, particularly if you have new data. I can also confirm that we should be in a position to webcast the meeting. Please contact us at ad...@dns-oarc.net if you have any questions or need help registering/submitting. Keith (OARC President) ___ 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 -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.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] universal deployment of BCP38 and won't/can't semantics
Below: On Fri, Feb 22, 2013 at 11:45 AM, Jo Rhett jrh...@netconsonance.com wrote: On Feb 22, 2013, at 10:19 AM, Jim Reid j...@rfc1035.com wrote: There's no point arguing the semantics of don't and can't. As Paul mentioned earlier, let's remain realistic. Universal deployment of BCP38 simply isn't going to happen, no matter how much you or I *really want* that. [And I do.] Get over it. Good luck getting an ISP in downtown Mogadishu (say) to sign up to BCP38 and sticking to it. If their ability to pass traffic requires BCP38 and detected failures will lead to de-peering, it will happen. I've enforced BCP38 within both colocation facilities and large-scale peering. It can happen, and the fight has usually been much less than expected. My employers have been tentative about whether they'd risk a legal battle over it, but it has never come to that. And we lost zero, flat zero, opportunities over this unless you count some large spam operators that we turned away for multiple reasons. Stop saying it won't happen, and push back just a little every day. If enough of us do this, it will come to be. I am seriously looking for a great opportunity to sue a very large carrier for a failure to implement BCP38, since it very clearly meets the guidelines for reasonable and expected that the courts love to use. One very large carrier + one very large settlement, and the other carriers will notice. It's not impossible. It is hard, but many hard things are worth doing. As a co-author of BCP38, I am sick and tired of being sick and tired -- it is a good idea and we still need to push on this. And with regards to DNS amplification attacks I have a new way to do things I would prefer not to do -- spend more time flying around the world explaining to people how to stop being bad stewards in the basic hygiene of the Internet. If anyone can find some fault in that, then you are not part of the solution. Period. - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.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] Defending against DNS reflection amplification attacks
On Fri, Feb 22, 2013 at 7:13 PM, Randy Bush ra...@psg.com wrote: Are you willing to also help us do the hard work to do the right thing? I'm pretty sure the answer is Yes. So let's get busy, and stop finding reasons not to do the Right Thing. - ferg you may have a problem with your mail system. it seems to be re-sending messages from a decade ago, though they seem to have today's date. odd. Not at all odd -- we still have the same problems. I think that is indicative of several things, none of which I will expand on at this moment. perhaps, after the decade of us telling others how they should run their networks, an actual large operator who has deployed bcp38 can give us an analysis of the costs, capex and opex, and how they minimized them. I think we are far beyond that -- those are the things that have apparently already failed. It is several factors -- ignorance, negligence, among them. We as a community have not a good job of boiling it down to non-technical issues that those executives understand (with regards to revenue issues). I agree that we should have some hard stats on who has deployed these measures, and how it impacted them. Please speak up if you have any data. I can say, however, that we *do* have data on who has *not* deployed it, and how they are virtually criminally negligent for doing so. And don't get me wrong -- there are still some really hard problems. - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.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] Defending against DNS reflection amplification attacks
On Fri, Feb 22, 2013 at 7:38 PM, Randy Bush ra...@psg.com wrote: one urban definition of insanity is repeating the same thing expecting different results. i do not disagree with bcp38. i just don't think repeating that anyone who does not deploy it is an anti-internet asshole is going to get any more significent deployment. that approach has been failing for many years. randy I don't think I said anything even closely resembling that. I did said that we (community) are not doing a proper job of promoting proper behavior (and configuration) on the Internet. And it's not all about BCP38 either. There are tens of millions of open DNS recursive resolvers out there... - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.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
