In addition to dns-prefetch, you can take browser performance one step further by actually creating a new connection to a resource.
By initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, you allow the user agent to mask the high latency costs of establishing a connection.
- Firefox 39+ (Firefox 41 for crossorigin)
- Chrome 46+
<link rel="preconnect" href="//example.com" />
<link rel="preconnect" href="//cdn.example.com" crossorigin />
I often get into some fringe areas of micro-optimizations of website performance, DNS prefetching is another one of those topics.
To understand how this can help, you must first understand the underlying concepts that are used within the communications used to build your web page.
The first of these is a “DNS Lookup”, where the domain name (www.example.com) is converted into a numerical address, the IP address of the server that contains the file(s).
In many websites, content is included from other domains for performance or security purposes.
When the domain names are known in advance, this approach can save time on the connection as the lookup can fetched in advance, before it is required on the page to retrieve assets.
This can be particularly useful for users with slow connections, such as those on mobile browsers.
<link rel="dns-prefetch" href="//www.example.com" />
- MSIE9+ (MSIE10+ as dns-prefetch)/Edge
As an IT professional, I’ve long been aware of the impending IPv4 exhaustion. To the layperson, this can easily be compared to phone numbers… there are now so many devices connected to the Internet that the size of the number used to identify and reach each of them uniquely is impossible.
IPv6 is a newer addressing system that supports a drastically increased number of addresses/numbers for use. Unfortunately, like Digital TV (in the US), adoption and migration of users and websites is slow.
To do your part as a user, you can change the settings in your gateway/router/modem to allow for IPv6 DNS lookups as most providers already support IPv6 traffic.
You can test your connection here:
Here are a few common values, I’ve also provided the Comcast/Xfinity values for reference:
- 126.96.36.199 (resolver1.opendns.com)
- 188.8.131.52 (resolver2.opendns.com)
- 184.108.40.206 (resolver3.opendns.com)
- 220.127.116.11 (resolver4.opendns.com)
DMARC was published in 2012 to build upon the SPF and DKIM email conventions for authorizing senders. It allows specification of policies and provides for reporting of actions performed under those policies.
DNS Entry Resembles:
_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=0; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; sp=none
Simple verification…. send an email to this address and you will receive a response with your SPF, DKIM and DMARC compliance status:
DomainKeys (originally from Yahoo!) and Cisco, and later as an industry collaboration, is a means for and organization to claim responsibility for sending a message, in a way that can be validated by a recipient. As a result, emails are “signed” by the outgoing SMTP server and can be verified against a DNS record. Depending upon the receiver, unsigned emails MAY be treated or marked as SPAM as they could be forgeries.
The below instructions assume Ubuntu (Debian) and Postfix, but could likely be modified for other platforms.
This is a simple mechanism, using DNS to certify that email from your domain comes from authorized servers. This is accomplished by adding a DNS record to identify the servers from which you send legitimate email. Emails sent from other servers MAY then be assumed as forged (SPAM) and blocked by the receiving email server.
NOTE: This can be easily spoofed, as such it should be a portion of your email security strategy, look into DKIM and DMARC too!
One thing that I initially did not understand… if you are supporting IPv6 and IPv4, you should merge your records onto a single DNS TXT entry:
example.com TXT v=spf1 a mx ip4:xxx.xxx.xxx.xxx ip6:xxxx:x:xxx:xxxx:xxx:xxxx:xxxx:xxx -all
In these examples, I have used the OpenDNS servers, please change as appropriate.
sudo vi /etc/network/interfaces
auto l0 eth0
iface lo inet loopback
iface eth0 inet static
dns-nameservers 18.104.22.168 22.214.171.124
sudo vi /etc/resolv.conf
NOTE: I’m not 100% sure if this is required!
Add appropriate content, example:
sudo restart networking
sudo ifdown eth0 && ifup eth0
Working on a Windows machine without elevated permissions can often be difficult for developers. One item that is often useful to change is the ‘hosts’ file. IN Windows 7 and 8 you can often ‘Self-Elevate’ to run a file, but it’s not always obvious how to edit a file in this manner. Some simple batch files can be helpful in this case as you can elevate them to do the actual work requiring permissions.
For example to make all requests to ‘example.com’ to be directed to your own machine…
echo 127.0.0.1 www.example.com >> %hostspath%
echo 127.0.0.1 example.com >> %hostspath%
To replace the existing hosts file with one of your chosing from your desktop. (NOTE: you can change this file or path to anything).
copy "%UserProfile%\Desktop\hosts" "c:\Windows\System32\drivers\etc"
A standard ‘hosts’ file in Windows appears as such:
# Copyright (c) 1993-2009 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
# 126.96.36.199 rhino.acme.com # source server
# 188.8.131.52 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
DNS is much like a phone book for the internet. For each domain name (or subdomain like ‘www’), there is an IP address that resembles a phone number. Getting the matching number for each domain can take some time and make your site appear slow, particularly on mobile connections. Fortunately, you can pre-request this information and speed up your site in most cases.
To enable a domains DNS lookup to be performed in advance of the request, you can add a single line to the
<head> section of your page.
<link rel="dns-prefetch" href="//giantgeek.com" />
If you want to explicitly turn on (or off) this behavior, you can add one of the following, or their HTTP Header equivalents:
<meta http-equiv="x-dns-prefetch-control" content="on" />
<meta http-equiv="x-dns-prefetch-control" content="off" />
This is supported in all modern browsers:
- Firefox 3.5+
- Safari 5.0+
- MSIE 9.0+
If should be noted that a similar method can be used to prefetch as page, but I will save that for a different article:
<link rel="prefetch" href="http://www.skotfred.com/" />
If you take a close look at your logs you may occasionally see requests for a file named
wpad.dat. This file is related to automatic proxy configuration in many browsers.
To provide this capability to your users and website,
Default behavior is to traverse the domain in reverse, looking for one with a file named
Example (using my domain for example):
- Then in httpd.conf, set the MIME type:
AddType application/x-ns-proxy-autoconfig .pac
- Also in httpd.conf, add a redirect to the actual file you wish to use.
Redirect permanent /wpad.dat http://www.giantgeek.com/proxy.pac
- In the new file, add the following default contents, modify if you use a proxy:
/* 'proxy.pac' - This is the main function called by any browser
NOTE: there is NO proxy!
function FindProxyForURL(url, host)
} // End function FindProxyForUrl