Follow

DNS Settings

To ensure you take full advantage of AARNet's on-net content and services, particularly the CDNs (Content Distribution Networks) such as Akamai, AARNet provides DNS forwarders at:

 

202.158.207.1      and      202.158.207.2

 

 And for IPv6:   2001:388:1:1::1      and      2001:388:1:1::2

 

Summary

For best value and performance configure a DNS forwarder located within the AARNet network. This can include AARNet's DNS forwarder. This can include a DNS forwarder you run on the IP addresses AARNet supplied to you. You can also use a public DNS service which supports the EDNS0 Client Subnet Option.

 You should not use the DNS forwarder of another Internet service provider or of another enterprise network. This will provide less performance and the misdirected traffic from content distribution networks may result in higher AARNet charges.

 IPv4 configuration to use AARNet's DNS forwarder

If you wish to use AARNet's DNS forwarder to resolve domain names then set your site's DNS forwarder to be 202.158.207.1 and 202.158.207.2. It is fine to leave empty any request for a third address.

 AARNet's DNS forwarders are highly available and spread around the continent. You will automatically use the DNS forwarder closest to you.

Using AARNet's forwarder places a large cache of DNS names close to your network. It is typically faster than using a more remote public DNS service.

For a small site, like a school, running your own DNS service results in a too-small cache with too many queries missing the cache and needing to be fully resolved.  A large site, such as a university, might not find much performance benefit in using the AARNet DNS forwarder; although a medium-sized university did measurements in 2015 which showed the AARNet DNS forwarder's cache was larger than that of the medium-sized university and the resulting performance gain was worthwhile.

 

Using a different DNS forwarder

 

You are welcome to use a different DNS forwarder, you are even welcome to run your own DNS forwarder, but there are some rules which you should follow.

(1) The DNS forwarder should cause the selection of the closest CDN server.

(2) The DNS forwarder should not be an "open DNS forwarder". Both of these rules are described in the following sections.

 

(1) DNS and content distribution networks

Content distribution networks use the IP address of the DNS query to determine which server within the CDN will provide the requested content. That is, CDN servers within AARNet are selected when the DNS forwarder is within AARNet.

 AARNet hosts many CDN servers, so you want to use those servers rather than servers located outside the AARNet network.  CDN servers located outside of the AARNet network will be slower. Traffic from CDN servers outside of the AARNet network may be outside the "unmetered" billing category.

 To ensure that content distribution networks choose servers located within AARNet's network select one of these two options:

 Option 1: use a DNS forwarder on an IP address within the AARNet network

  • AARNet's own DNS forwarder is exactly this case
  • You can also run your own DNS forwarder on the IP addressing which AARNet supplied to you

 Option 2: use a public DNS forwarder which supports EDNS0 Client Subnet Option.

 

* this adds the IP address of your computer to the DNS query forwarded to the Content Distribution Network. The CDN then uses the IP address of your computer to choose the closest CDN server.

 * the ENDS0 Client Subnet Option is only sent in queries which the DNS forwarder knows are CDN services. So there is no simple technical test which can show a DNS forwarder is setting the Option.

 * both the public DNS forwarder and the content distribution network need to support EDNS0 Client Subnet Option for the Client Subnet Option to have effect.

 * the following public DNS forwarders have stated that they supply EDNS0 Client Subnet Option: Dyn.com, Google Public DNS, Hurricane Electric, OpenDNS (aka Cisco Umbrella), IBM Quad9 and other less well known public DNS services.

 * the following content distribution networks have stated that they examine the EDNS0 Client Subnet Option: Akamai, Amazon AWS and CloudFront, CloudFlare, Microsoft Azure, Google, Netflix and other less well-known content distribution networks.

 

Akamai have a nice tool for showing which IP address it feeds into its algorithm to determine which of its servers to supply content from:

     $ dig +short TXT whoami.ds.akahelp.net

 A technical examination of the details of the EDNS0 Client Subnet Option is at https://developers.google.com/speed/public-dns/docs/ecs

 

(2) Don't run an "open DNS forwarder"

If you run your own DNS forwarder then you must ensure that only your IP addresses can submit queries to your DNS forwarder. In Unix-like platforms this is done by providing a list of acceptable interior IP addresses within the server. For Windows Server this is done by configuring a list of acceptable interior IP addresses on a firewall.

"Open DNS forwarders" are a common culprit in network abuse incidents.

 Public DNS servers are not open DNS forwarders.

 

DNS rules for firewalls

The domain name system uses both UDP port 53 and TCP port 53 for looking up DNS names. It is a common error to configure only UDP port 53. Configuring only UDP port 53 will cause problems when larger DNS responses become more common with the increasing use of DNSSEC.

 

IPv6 records

Even when AARNet's DNS forwarders are accessed using an IPv4 address the forwarders will also return`AAAA` DNS records which supply the IPv6 address for a website.  A site doesn't need to use a IPv6 connection to AARNet's DNS forwarder to resolve DNS names to IPv6 address records.

 

IPv6 configuration to use AARNet's DNS forwarder

If you wish to use AARNet's DNS forwarder to resolve domain names and your site has no IPv4 connectivity then set your site's DNS forwarder to be 2001:388:1:1::1 and 2001:388:1:1::2. It is fine to leave empty any request for a third address.

 

DNSSEC

AARNet's DNS forwarder does not yet support DNSSEC secured DNS names.

  

Fault finding

Sometimes the Network Operations Centre will ask you to determine which of the AARNet DNS forwarders is being used.  Please send the output of these two commands. Run the commands from the computer which hosts your site's interior DNS forwarder or the computer which implements your site's Network Address Translation:

 

    $ dig @202.158.207.1 ch txt id.server.

    $ dig @202.158.207.2 ch txt id.server.

 

If the `dig` command is not present then the `nslookup` command can be

used:

 

    $ nslookup

    > set class=CH

    > set type=TXT

    > server 202.158.207.1

    > id.server.

    > server 202.158.207.2

    > id.server.

    > exit

 

I am seeing a message from Interpol

The HTTP servers on AARNet's DNS forwarder addresses display a message which usually only appears when the resolver is asked to resolve DNS names on a list supplied by the Attorney-General's Department.

Sometimes when investigating DNS issues it is possible to reach that HTTP site in error. In that case the usual error is typing the address into the web browser rather than into the terminal window.