Slashdot Mirror

The Wired article is terrible - the author didn't understand the Talos blog.

https://blog.talosintelligence...

The Talso blog post is opaque: they present no evidence that root servers for top level domains, such as .AM were compromised. They say it was possible, but a registrar != a registry, nor does that mean they masqueraded as the tech contact listed at IANA. IANA would have the history of any changes.

Notably, the threat actors were able to gain access to registrars that manage ccTLDs for Amnic, which is listed as the technical contact on IANA for the ccTLD .am. Obtaining access to this ccTLD registrars would have allowed attackers to hijack any domain that used those ccTLDs.

Perhaps you can explore the history here:
https://tldmon.dns-oarc.net/na...

It's abundantly clear that systemd-resolved has quickly become a train wreck. It's inclusion in Ubuntu 16.10 was widely lamented and many folks have pointed out huge concerns for several different assumptions that it makes for fallbacks and erroneous configurations. That's not including the several different bugs that have plagued systemd-resolved thus far. Granted many of them are fixed but with the breakage what have we bought? Something that's a pretty basic task now requiring patch after patch. Additionally, what has this solved? Now we can make DNS configuration a bit easier to integrate across the board?

The bad rep that systemd especially resolved has obtained isn't just simply one where grey breads say "it's too different". It is one that time and time again, ignorant assumptions, bloated egos, and hasty code have led to a general distrust, especially when tools that have always worked are suddenly not working or worse still, become methods for exploits. I still think systemd is a vast improvement over the "ye olde init scripts", but while the idea is commendable, it's execution has been somewhat lack luster to put it mildly. There needs to be a serious "Come to Jesus" moment for the systemd team. You need to build trust if your going to build something that's rewriting the books. This is just another example of how that trust is being chipped away. Complexity of the task at hand aside, either the team is up to delivering or they are not. This ostinato where breakage just keeps happening needs a serious all hands or something to restore trust in the team guiding this project. Poettering, you are doing no favors to yourself nor your team by these stories. Deliver us from the hell of bad init if that's what you seek, but don't plunge us deeper into a different hell of your making and say that it's alright because you're the one who built it.

Have you checked ? it really isn't that bad. Yes, it happends slightly more frequently.

I wouldn't be surprised if the use of tunnels because of IPv6 has a bigger impact.

Here is a plot for the DNSSEC signing of the root:

https://www.dns-oarc.net/files/blog-2009/plot1.png
https://www.dns-oarc.net/node/199

Most of it is misconfigured servers.

Have you checked ? it really isn't that bad. Yes, it happends slightly more frequently.

I wouldn't be surprised if the use of tunnels because of IPv6 has a bigger impact.

Here is a plot for the DNSSEC signing of the root:

https://www.dns-oarc.net/files/blog-2009/plot1.png
https://www.dns-oarc.net/node/199

Most of it is misconfigured servers.

Am I incorrect when I say that the root DNS servers are controlled by the US and all other servers are programmed to follow them?
Switching to a non-US DNS server would be silly since the other server only mirrors the root server.
What I think we need is a decentralized DNS equivalent.

There used to be several alternative DNS roots. One of the more notable ones was Open Root Server Network, which was created as a compatible alternative to ICANN's roots because of concerns about ICANN ultimately being controlled by the US government. Several ISPs actually used to use ORSN's services, but ORSN shut down in 2008.

(reference https://www.isc.org/software/bind/advisories/cve-2011-0414)

* As Larissa pointed out, this security advisory used ISC's phased disclosure process (see http://www.isc.org/security-vulnerability-disclosure-policy). The US CERT advisory stated they notified ISC on 2011-01-24. This is reversed. US CERT and all other National CSIRT Teams were notified at the same time (Feb 15th). We just recently added the step in our disclosure process to notify all National CSIRT Teams listed on first.org.

* US-CERT threw in the "2011-01-24" thinking the discovery of the vulnerability matched the time we asked for our next batch of CVE numbers. In this case, this vulnerability was discovered by Neustar, who found the initial defect, and JPRS, who built the feasible lab exploits. That was all in Feb 2011, not Jan 2011.

* The "high severity" is based on the CVSS _BASE_ Score of 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C). Network operators would use this CVSS base score and then run the Environmental and Temporal Score to get a CVSS actionable score. This is why you saw a low score from US CERT so low. They used their proprietary full metric, which scored it lower. Vendors are encouraged to use CVSS so the operator then takes accountability to gauge the risk specific to their environment.

Check out http://www.first.org/cvss/ for more information on CVSS. ISC has recently started using CVSS for all our security advisories (see http://www.isc.org/announcement/iscs-has-adopted-cvss-our-security-advisories).

* DNS Operational Risk and Reaction to any DNS issue is best addressed via DNS-OARC. If your DNS is critical, I recommend, as a minimum, to sign on to the public BIND forums (see https://lists.isc.org/mailman/listinfo) and the public DNS-OARC forums (see https://www.dns-oarc.net/oarc/services).

You mean like using the Day-Old-Bread RBL, which was set up to do exactly this four years ago?

The "misconfiguration" was apparently at the routing layer, caused by BGP. There are 13 DNS root servers, A-M. Several mirrors around the world actually share the same IP for a specific root server. Your DNS query to a root server IP is usually routed to the closest server with that IP, due to anycast routing. Apparently, a BGP misconfiguration caused an incorrect route to be advertised. Ars Technica apparently broke the story and has a very good description. They quote VeriSign spokesman Brad Williams:

"In our regular network checks, we recently noticed that routes were being announced outside of China for our anycast server there," Williams said in a statement. "As this was an aberration, we notified our technical partner in China and helped them resolve the issue. Our network checks show that the issue is now resolved."

Mauricio Vergara Ereche, a DNS Admin for Chile NIC, first noticed the problem. Queries to the I root server i.root-servers.net at IP 192.36.148.17 for www.facebook.com resolved to an actual IP address (in China) instead of redirecting to the .com DNS server as it should have. He posted this in his message to the dns-operations mailing list:

This is an example of what are wee seeing:

$ dig @i.root-servers.net www.facebook.com A

; DiG 9.6.1-P3 @i.root-servers.net www.facebook.com A

; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 7448
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.facebook.com. IN A

;; ANSWER SECTION:

www.facebook.com. 86400 IN A 8.7.198.45

;; Query time: 444 msec
;; SERVER: 192.36.148.17#53(192.36.148.17)
;; WHEN: Wed Mar 24 14:21:54 2010
;; MSG SIZE rcvd: 66

It's more than that. According to the post at https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005266.html someone is actively spoofing DNS replies to DNS request packets bound for entire class A and B net ranges.

The only way someone is going to "actively spoofing DNS replies" is via a sophisticated MITM attack. The problem here, is that some idiot forgot to keep his "root.hints" file current on his DHCP published name server. A "firewall" has always been understood as a bastion host and/or a packet filter. Breaking DNS doesn't break routing. The inverse may not be true, but routing doesn't depend on DNS.

It's more than that. According to the post at https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005266.html someone is actively spoofing DNS replies to DNS request packets bound for entire class A and B net ranges.

What's worse is they use BIND!

https://lists.dns-oarc.net/pipermail/dns-operations/2009-September/004481.html

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

Apparently the ORSN project has been shut down, at least for the moment, due to lack of involvement and resources.

Some of the servers continue to operate, but it was officially discontinued as of 31 Dec 2008. Too bad.

Hell even a lot of high end products didn't do things correctly until patches were released in response to the DNS issue. We run one of the big 3 at work and ours did not do port randomization correctly so we forwarded all requests to a properly patched 3rd party without an affected firewall because AT&T at the time also did not have the correct solution in place. We are going to go to a direct resolver configuration when we upgrade our firewalls later this year which will give us a slight increase in performance but due to having a working solution it hasn't been a priority. Have you verified that your version of IOS does port randomization correctly by testing your resolver? The easiest way to test correctly is documented here.

You might be interested in this thread:
https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. The only difference being that DNSSEC is hugely more complex to use and implement.

This DNS test is much better. https://www.dns-oarc.net/oarc/services/dnsentropy

Which is why you should test it

This is an even niftier check

dns-oarc.net? I think something is wrong at their end. (either they're FUBAR or the 4.2.2.* nameservers are down, and if the nameservers are down, I'm not connecting to anyone... which would appear not to be the case)

Details of how to use dig to test this DNS vunerability are at DNS-OARC.NET (the source of the test)

There's a couple issues with the one Dan created. First, its slashdotted. Secondly, some ISPs don't allow querying from just anywhere, only from its own customers (IPs). Here's a test you can run from any machine with dig on it:
https://www.dns-oarc.net/oarc/services/porttest

http://entropy.dns-oarc.net/test/

Yes, this is a simple way: https://www.dns-oarc.net/oarc/services/porttest

This is a very good point. I run my own DNS server here, and the NAT that it sits behind remaps the ports from the random ports that BIND uses, to sequential ports on the other side of the NAT, which gives a straight line graph on the already recommended DNS OARC test. http://entropy.dns-oarc.net/test/

Generally the proxy on a SOHO router runs as a forward-only cache (or even just a simple proxy) to your ISP's DNS. As such it's really your ISP's DNS that is or isn't vulnerable, because you aren't ever going to see records from anyone else, nor will anyone else know you're asking for them.

The test listed above -- http://entropy.dns-oarc.net/test/ -- will let you know what the rest of the world sees as your DNS source address, and whether or not that source is sufficiently randomized.

He also links to a way to check from the command line: porttest.dns-oarc.net -- Check your resolver's source port behavior. That method also allows you to test DNS servers other than the one you are using, so it provides a simply way to tell if your ISP has fixed their servers yet without changing your own config. The sidebar on doxpara just shows a 404 for me.

The DNS OARC (http://dns-oarc.net) has an improved version:

http://entropy.dns-oarc.net/test/