TREX is making DNS64 resolvers available to Finnish end users as part of a research project in association with the Finnish Future Internet programme and Internet Testbed Finland. Resolvers are recursive DNS servers used by web browsers and other programs to map hostnames to numerical addresses and vice versa. The DNS64 specification defines a method that the servers use to convert IPv4 addresses found in A records into IPv6 addresses that the resolvers serve in AAAA records when there would otherwise be no AAAA record.
Windows users can manually configure name servers from the network settings window and add the below addresses into the list. If you are using some other operating system and you want to test how the DNS64/NAT64 system would work for you, try adding these lines into your /etc/resolv.conf:
nameserver 2001:67c:2b0::4 nameserver 2001:67c:2b0::6
There is a helpful alias for the resolvers to help remember their addresses:
dns64.trex.fi IN A 126.96.36.199 IN AAAA 2001:67c:2b0::4 IN A 188.8.131.52 IN AAAA 2001:67c:2b0::6The servers have IPv4 addresses for the benefit of those users who can only autoconfigure DNS resolvers via DHCPv4.
One of the recursors is running Bind9. The other one is running Power DNS. The generated AAAA records point to a address blocks in TREX's public address space 2001:67c:2b0::/48 so they are usable from anywhere on the Internet. That address space is routed by NAT64 devices.
The IPv4 side of the NAT64 devices use an address pool at 184.108.40.206/24. We reserve the right to change the address ranges used by the NAT64 devices to load balance traffic. So if you want to point something directly at the address pools, please consult us first. If we change the address pools, your own hacks will fail.
If you have any problems with this service, please consult this web page first, in case we have some service announcements. Users should also be aware that we will sometimes divert NAT64 traffic from our network to NAT64 boxes that are closer to the user. In those cases the servers will serve addresses outside TREX's public address space.
The recursors only serve standard DNS information, as defined by ICANN and IANA. They do not serve any special Top Level Domains and there are no altered responses, except as required by DNS64. NB: This may break DNSSEC validation.
The following IPv6 address ranges are regarded as non-native and they will be replaced with NAT64 mappings:
- 2001::/32 (Teredo)
- 2002::/16 (6to4)
- 2001:7f8::/32 (non-routable IXP range in Europe)
- 2001:db8::/32 (documentation prefix)
Acceptable Usage Policy
The servers are made available as is. Their main intended userbase is Finland. We reserve the right to deny this service if we uncover abuse or malicious activities. We may also limit the NAT64 traffic to less than 100Mbps for the same reason. The maximum acceptable rate of queries to the recursive name servers from a single network is one thousand queries per second or 1000q/s. If you have any problems with this service, please contact us.
We've blocked TCP connections to port 25 (SMTP) to prevent abuse by spammers. This may cause you problems if the mail server you use does not have IPv6 connectivity.
The primary aim of the research project is to uncover problems that users of the DNS64 mechanism may run into under real world usage. The system has already been tested extensively in a lab environment, where it functioned perfectly of course. Please let us know of any problems you uncover, however small they may be, while using these servers so we can advance the science and standardization in this field.
NAT64 is expected to have the same problems as "normal" NAT (aka NAT44) such as not being able to connect from the outside in. Another typical problem occurs with protocols that carry IP addresses inside them (e.g. SIP and FTP). It is also highly likely that you will have problems printing when using DNS64 name servers. Many applications, especially games, use IP addresses directly instead of DNS names to connect to the network. All such applications will fail to use NAT64.
This is a research project, so we may be capturing some traffic to try and find the causes for any unexpected features we run into. Actual traffic will be held strictly confidential. It would still be prudent to use encryption.