When deciding how to allocate DNS resources on a network it’s important to implement some separation between external and internal Domain Name Services. Having all DNS servers configured to handle both external and internal resolution can impact the performance and security of a network.
The popular business-focused social network LinkedIn was unavailable for several hours over the 19th and 20th of June because of a DNS redirection incident which lead to users of the service being directed to IPs in the range managed by Confluence Networks, an Internet services company registered in the British Virgin Islands. It’s unclear at the time of writing whether the incident is due to a malicious attack on LinkedIn’s DNS servers or a misconfiguration on the part of LinkedIn’s DNS providers.
The DNS redirection, also known as DNS hijacking, puts users of LinkedIn at risk of having private data made available to third parties. In the normal course of events, LinkedIn users would connect to the service using SSL encryption. That would make it very difficult for a third party to intercept the data in any meaningful form, but, because the Confluence Network servers don’t implement SSL, and LinkedIn’s session cookies are not set to reject non-encrypted connections, it’s possible that connections made during the outage sent session cookie data in the clear to those servers. That data may have included login credentials and passwords if users logged-in during the attack.
When the protocols that underlie how email works were first developed, little thought was given to security. At the time, most of the networks that were later to join together to form the nascent Internet were in large corporations, universities, and government agencies. Because it was only employees of these organizations that had access to email, there wasn’t much need to authenticate senders.
SMTP (Simple Mail Transfer Protocol), when it was developed in the mid–70s by Jon Postel, didn’t include any functionality to make sure that senders of email were authorized to use the email servers. These open email relays accepted incoming mail from everyone.
As the Internet grew and became available to ordinary people, email’s popularity snowballed, and abuse of the email system grew along with it. We’re all familiar with spam email; open relays make it easy for spammers to distribute huge amounts of email with no checks on who they are.
Are you seeing this when you try to reach your domain?
Did you recently change where your domain points to? Move your domain to a CMS (like WordPress or Joomla)?
You don’t need to be a DNS expert to fix it, but it helps to have some understanding of how the system works.
Unresponsive Domain Name Services result in slow sites that are disadvantaged in the SERPs relative to more speedy competitors
Site speed is one among many factors that Google takes into account when it is deciding how to rank sites.
There are two major speed related signals that Google can use to determine SERP position. The first is the responsiveness of the site as measured by its crawlers. If Googlebot is often left waiting, that’s an indication to Google that the site may not offer the best experience for its users, even if the information is relevant to the query.
Secondly, Internet users are impatient: they want their requests for data fulfilled immediately and aren’t prepared to wait more than a couple of seconds. Slow-loading sites cause visitors to bounce right back to the SERPs to click on the next blue link. Google records the bounce as a signal that the searcher wasn’t satisfied with the results and adjusts the ranking accordingly.