[dns-operations] Does DNSSEC provide any mitigation for SSL bugs, like Apple's?
Hello, Last Friday, Apple released a patch for iOS 6/7 that fixes a bug in their recent SSL implementation. Without the fix, iOS is vulnerable to MITM attacks by attackers 'in a privileged network position', allowing them to intercept and influence SSL connections. OS X Mavericks (10.9) is still vulnerable at this time. There's been quite a bit of discussion about this over the past few days, but DNSSEC has been kind of absent from that. I've been wondering whether DNSSEC would provide any mitigation for such an attack, if there validating resolver between me and the attacker? As this is kind of at the edge of my current understanding of things, I figured I'd ask here. So what if; a) my target zone is signed, b) the local network is sufficiently trustworthy, c) this local network has a validating resolver, and d) firewalling rules that enforce the use of this resolver for DNS resolution. Would an attacker between me and the target zone, but outside the local network, still be able to impersonate a trusted endpoint in the target zone by exploiting a bug like this? My intuition says no, because the connection would be interrupted by a DNSSEC failure before it ever starts a SSL handshake with the endpoint? I could be wrong on this, but if so, I'd like to know where the fault in my reasoning lies :-) Mvg, Joni ___ 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] shunning malware-hosting registrars
On 29 Jan 2014, at 17:23, Mark E. Jeftovic mar...@easydns.com wrote: Paul Vixie wrote: what i'm specifically hoping for is total transparency. i consider whois privacy to be a blight on internet cohesiveness -- noone who holds a unique internet identifier should be able to hide behind their lawyer's contact details or their registar's contact details -- the internet social contract that i remember agreeing to is, if you want me to respect your allocations, then you will use them responsibly. I agree with the sentiment that if you hide your identity, you shouldn't be able to send email to me, etc. Having said that, I speak as a convert on whois privacy, having originally been opposed to it, I came around and see the point in a lot of cases (especially since the number #1 use for whois data is illegal data mining anyway) Total transparency only works when it is enforcable, otherwise you are just enabling those who can afford to mask themselves, while giving those who have a legitimate use for it a big fat middle finger. WHOIS privacy does have its uses, as long as you are not running any infrastructure under it. If you use the domain as RDNS for any publicly accessible servers, particurly those used for sending mail, WHOIS privacy pretty much doubles your chances of ending up blacklisted. but it's not just registrants i worry about. we've seen a handful of borderline-to-really bad registrars over the years, who are able to pollute the internet commons with malevolent and criminal waste for years at a time until icann or the courts finally have enough evidence to put them out of business. if every domain's registrar were reliably determinable at scale, then after blackholing the 10,000th or so domain from a single registrar, many of us might decide that our best interests lay in blackholing all future domains from that registrar. I have long pondered an idea for implementing this sort of mechanism via RBLs - and today there is certainly the processing power to do it. * An RBL per-registrar where you could simply drop a given registrar's domains traffic on the floor * RBL per nameserver sets (gets a lot of spammer, malware, botnet, etc) * even an RBL for domains with whois privacy enabled, in fact I started building this already (now that I think about it, my prototype list builder has been turned on for about a year and I haven't looked at it in nearly that time) This occurred to me as well, but I reckon it would need to be a central RBL per TLD if that was to work. Otherwise I'd reckon you would run into rate limits on queries and such? The third idea fits RBL mechanics rather well, but how would you envision the first idea (dropping anything from a particular registrar) working? Mvg, Joni ___ 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] A question about changing nameservers
On May 28, 2013, at 12:07, Feng He fen...@nsbeta.info wrote: My platform DNSbed.com has cloudwebdns.com as the nameserver domain. The DNS of cloudwebdns.com is currently hosted by: dns1.registrar-servers.com. dns2.registrar-servers.com. dns3.registrar-servers.com. dns4.registrar-servers.com. dns5.registrar-servers.com. Today I changed the nameservers to our own nameservers: ns1.cloudwebdns.com. ns2.cloudwebdns.com. ns3.cloudwebdns.com. ns4.cloudwebdns.com. I have added the zone to named.conf, created zone files, and reloaded BIND. But when I added a record by nsupdate, it got the error: response to SOA query was unsuccessful When I dig to localhost: dig cloudwebdns.com soa @localhost Got the status ServFail. Can you tell me what has happened? You made a boo-boo somewhere. Check your zones, your configuration, and especially your logs. Mvg, Jona ___ 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] Why would an MTA issue an ANY query instead of an MX query?
On Jun 12, 2012, at 14:46, Stephane Bortzmeyer wrote: On Sun, Jun 10, 2012 at 01:25:06PM +0200, DTNX Postmaster postmas...@dtnx.net wrote a message of 37 lines which said: Google is known to be obsessed with latency, for example, so I wouldn't be suprised if they deliberately request ANY and then parse and cache the results for a multitude of uses. But that's speculation. I checked the ANY requests coming into .FR name servers and Google (which should be an important user) does not appear. We are seeing them from 74.125.0.0/16, which is a range owned by Google, and they resolve to '*.1e100.net', a domain owned by Google. I do not know why they originate there; from the queries it seems that they may be the resolvers in use by the crawler bots, Gmail, or their open resolvers. I am speculating about the purpose of those requests, of course, but I am not making them up ;-) Also, they seem perfectly well behaved. Cya, Jona ___ 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] Why would an MTA issue an ANY query instead of an MX query?
On Jun 10, 2012, at 23:59, Kyle Creyts wrote: On Sun, Jun 10, 2012 at 2:33 PM, Paul Vixie p...@redbarn.org wrote: I'm afraid we may need more control. If my clients are generating a DDoS attack at 20 responses per second, and I limit this to 5 per second - the CC can get the same effect by mobilizing four times as many clients to do the job. no. the client ip is spoofed. the number of spoofers doesn't matter, when the reflector is looking at both the apparent client ip and the intended response. when most well-provisioned authority servers are running with some kind of rate limiting, then the only way to do a reflective amplifying ddos will be (a) do it through recursive not authority servers, or (b) send a small number of queries to a large number of authority servers, or (c) switch to some other wide area udp such as ntp or snmp or syslog or whatever. Someone mentioned that as soon as the spoofed client is blocked, that a new spoofed client is used... This behavior seems... strange. How quick is this shift? How would one know when to shift the target? The modes I _can_ come up with largely involve having some sort of information about what is reaching the target. (bandwidth or traffic sources) This just leads to more interesting questions about those perpetrating the attacks, and their intent. Is there an obvious way of discerning the time to switch targets that I am missing? Is this a non-interesting topic? From what I've seen, in our specific case, the apparent source address seems to swap every thousands requests or so, with a few exceptions. This is from running dnstop on our auth nameservers for a few hours. HTH, Jona ___ 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] Why would an MTA issue an ANY query instead of an MX query?
On Jun 10, 2012, at 16:23, Paul Vixie wrote: On 2012-06-10 12:59 PM, Patrick W. Gilmore wrote: A single ANY query for a domain gives you the NS, MX, TXT and SPF records, plus any A/ record present. At scale, who knows, the reduction in number of queries probably adds up. It strikes me as laziness and cost-shifting. If you need to do multiple queries (e.g. TXT MX), is it better for either side to do two queries instead of one? yes, since the queries can be transmitted simultaneously, and there's way less risk of TC=1 and followup TCP. Interesting, I did not know that. Does that mean that even from the perspective of a SMTP server, which may need between three and five queries, it may be more efficient to do seperate queries instead of a single, large ANY query? Cya, Jona ___ 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
