DNS servers¶
The university recursive DNS servers. They resolve domain names for devices in the TUKE network and also know internal names that public servers cannot see.
-
Three servers
Configure all three so that one outage stops nothing.
-
Low latency
A few milliseconds inside the university network.
-
Internal names
They resolve names that public DNS servers cannot.
-
IPv6 on rs2
The rs2 server also answers on an IPv6 address.
Server addresses¶
| Server | IPv4 | IPv6 |
|---|---|---|
| rs1.tuke.sk | 147.232.3.2 |
– |
| rs2.tuke.sk | 147.232.16.16 |
2001:4118:200:1000::16 |
| rs3.tuke.sk | 193.87.100.12 |
– |
Configure all three
rs1 and rs2 sit in the university network, rs3 is in a different
network. If the university network has trouble, rs3 is reachable by
another route. That is why it makes sense to configure all three rather
than just one.
Properties¶
| Property | State |
|---|---|
| Type | Recursive resolver |
| Port | 53/UDP and 53/TCP |
| EDNS(0) | Yes, 1232 B buffer size |
| Internal TUKE names | Yes |
| DNS over TLS (853) | No |
| DNS over HTTPS | No |
Response times measured from the university network:
| Server | Median response |
|---|---|
| rs1 | 3 ms |
| rs2 | 5 ms |
| rs3 | 2 ms |
Configuration on Ubuntu¶
Ubuntu Server is configured through netplan, which passes the result to the systemd-resolved service.
Find the interface name¶
On virtual servers in TUKE Cloud it is usually ens160 or ens192.
Edit the configuration¶
Add nameservers to your interface section:
network:
version: 2
ethernets:
ens160:
nameservers:
addresses:
- 147.232.3.2
- 147.232.16.16
- 193.87.100.12
search:
- tuke.sk
What search is for
Thanks to search: tuke.sk you can type just www instead of the
full www.tuke.sk.
Apply the change¶
The command applies the change and reverts it after 120 seconds unless you confirm. It protects you from losing connectivity through a bad configuration. Once everything works, confirm with Enter and save permanently:
If you would rather not touch netplan, set the servers globally:
DHCP settings take precedence
If the interface receives DNS servers over DHCP, those take precedence over the global setting. Use netplan in that case.
Graphically, without the terminal:
Open network settings¶
Settings → Network, then click the gear icon next to your connection.
Turn off automatic DNS¶
On the IPv4 tab switch DNS to Off (automatic) and enter the addresses separated by commas:
Reconnect¶
Turn the connection off and on again for the change to take effect.
Configuration on Windows¶
In a command prompt started as administrator:
netsh interface ip set dns name="Ethernet" static 147.232.3.2 primary
netsh interface ip add dns name="Ethernet" 147.232.16.16 index=2
netsh interface ip add dns name="Ethernet" 193.87.100.12 index=3
Find the interface name with:
Verification:
Verification¶
All three addresses should appear under DNS Servers in your interface section.
A test resolution:
A check that internal names work too:
What success looks like
The command returns an IP address without an error, and
resolvectl status shows the configured servers on the right interface.
Troubleshooting¶
Name resolution fails but IP addresses work
A typical symptom of a bad DNS configuration. Check who is actually answering:
If a direct query to the server works but the system one does not, the fault is in your configuration, not in the server.
The setting disappeared after a reboot
You only edited /etc/resolv.conf. On Ubuntu that file is generated by
systemd-resolved and overwritten on reboot. Use netplan or
resolved.conf.
Internal names do not resolve
You are using a public DNS server such as 8.8.8.8. Internal names are
known only to the university resolver, so put it first in the list.
netplan try reported an error
YAML is sensitive to indentation and uses spaces, not tabs. Check the syntax:
Frequently asked questions¶
Do I have to request access?
No. The servers are intended for devices in the TUKE network and require no registration.
Which server should come first?
The order does not matter much, the latency differences are a few milliseconds. What matters is having all three configured as backup.
Do they support DNS over TLS or DNS over HTTPS?
No. We verified that port 853 is closed and encrypted DNS is not available. Traffic therefore travels unencrypted across the network.
Do the servers validate DNSSEC?
No. They do not verify signatures and do not mark answers with the ad
flag. If you need validation, run a local validating resolver such as
unbound on your server and point it at these servers as upstream.
Are these servers also authoritative for tuke.sk?
No, they are purely recursive resolvers. Authoritative answers for the zone are served by different servers.