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.
DNS forwarding is the process by which particular sets of DNS queries are handled by a designated server, rather than being handled by the initial server contacted by the client. Usually, all DNS servers that handle address resolution within the network are configured to forward requests for addresses that are outside the network to a dedicated forwarder.
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.
Setting up a new domain name or changing where it points can be one of the most confusing aspects of configuring a new site for less experienced web masters. The most common question asked of web hosting companies’ support teams is: “Why is my domain name not working.” They’ve followed the instructions carefully, changed the records at their domain registrar so it’s using the right domain name servers, and yet, when they or other users try to visit the site by entering the domain name into their browser address bar, they get an error page.
Understanding why this happens requires a basic knowledge of how DNS works. The Domain Name System converts human readable web addresses like “www.example.com” into a set of machine readable numbers called an IP address that looks like this: “255.255.255.255”, or like this:“3ffe:1900:4545:3:200:f8ff:fe21:67cf”. It’s similar to how, in the old days, people used to look up phone numbers; they knew the name of the person they wanted to call and used that to find the number in the alphabetical list of a phone book.
DNS is a bit more complicated. When you enter the web address into your browser’s address bar a number of things happen very quickly.
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.