Introduction

From now on, everybody is an admin of their own $login.una domain! You’re now responsible for the management of all records for that domain, so that anybody in the network can easily access the services your VMs provide.

Lecture left-overs

We didn’t get to a few things during the lecture.

DNS privacy

If you’re using your ISP’s DNS servers, you’re making it exceptionally easy for your ISP to spy on you. Your ISP likely has your full browsing history (all hostnames you visit), can guess what kind of OS you’re using, whether you’re using antivirus software, etc. That’s not great! Luckily, there are multiple ways to make it a bit harder for your ISP to sniff on you.

The simplest option is not to use your ISP’s DNS servers, and use one of the public DNS servers instead. That way:

  • It’s a bit harder for the ISP to sniff your traffic, since it’s no longer enough to just read the DNS logs. They have to bother to decode the DNS traffic, which at least will cost them some processing power. (As we’ve seen, DNS is unencrypted by default, and very easy to analyze.)
  • Now the public DNS provider can sniff on you, but there are security minded providers, such as Quad9, who claim not to collect any data.

OK, let’s use a privacy-minded public DNS provider then, and then get the ISP out of the game for good. That means we need to encrypt our DNS traffic. That’s exceptionally simple thanks to DNS over TLS (DoT) and DNS over HTTPS (DoH).

To enhance the privacy of your machine, simply configure a locally running Unbound instance with the following directive:

...
forward-zone:
  name: .
  forward-tls-upstream: yes
  forward-addr: 9.9.9.9@853#dns.quad9.net
...

And then configure your network manager to use that DNS server (details depend on your setup, but you could also just replace /etc/resolv.conf and point it to your local DNS server).

This way,

  • Your ISP can see you’re making DNS queries, but cannot see the payload.
  • The public DNS provider, as far as we can tell, can be trusted not to collect your data.
  • Data cannot be modified in transit.
  • (DNSSEC implications, will be discussed later.)
  • All programs on your machine which respect /etc/resolv.conf will be secure by default.
  • All DNS lookups will be much faster as a bonus, since your local Unbound handles caching for you, so you don’t have to query the upstream public DNS server every time.
    • This also means you’re sending fewer queries—even if the public provider wanted to spy on you, they would only see the uncached subset of your DNS traffic.

Don’t forget to do a before-and-after packet capture to verify that your setup works as intended!

Please note that DoT/DoH is also built into browsers, and at least in Firefox, it can be enabled from Settings. That will, however, only protect your browser. It also won’t have the performance advantages of the locally running Unbound.

Final note, don’t get a false sense of security. All TLS traffic, such as all HTTPS traffic, is still using Server Name Indication (SNI) extension, a set of clear-text fields in the Client Hello packet, which contain the hostname you’re connecting to (yes, really—this part of TLS is, unfortunately, unencrypted to this day). There’s not much you can do about that. In other words, unless you’re using a trustworthy VPN provider, the ISP still can spy on your TLS traffic. However, it’s easier to sniff DNS, so that’s what they’ll likely do—as few people bother to do anything about it—and you’ll be invisible. But you’re not secure. (In fact, you never are.) You can read more about this issue here. You can also capture and analyze your HTTPS traffic, and you’ll see the clear-text hostname in Wireshark.

Reverse lookup

We didn’t get to describe how reverse zones (zones used for reverse DNS lookup) are used. An example zone file would be:

~/mff/linux-adm/dns% cat 1.168.192.zone
$ORIGIN 1.168.192.in-addr.arpa.
$TTL    30M

@            IN      SOA     ns.example.local.      d.dcepelik.cz.  ( 2 30M 15M 2W 15M )
ns           IN      A       127.0.0.1

1            IN      PTR     foo.example.local.
2            IN      PTR     mx.example.local.

In NSD, such a zone can be configured with:

zone:
  name: 1.168.192.in-addr.arpa
  zonefile: 1.168.192.zone

(Note the order of bytes in the IP address.)

Homework

  • Use lecture notes and this nice tutorial.
  • Configure NSD on your ns1 and ns2. ns1 is your master DNS server.
  • Set up the following records:
    • gw.login.una A ...
    • router.login.una CNAME gw.login.una
    • ns1.login.una A ...
    • ns2.login.una A ...
    • (and any other records you need to make your server authoritative for $login.una).
  • Configure AXFR between primary (ns1) and secondary (ns2) authoritative name server. What AXFR is and how to configure it is your self-study task.
  • Configure Unbound on gw. Make it forward all queries to 10.10.50.8, but create a stub zone for $login.una which is served by your two authoritative name servers.
  • I will configure glue records for your name servers on 10.10.50.8 myself.
  • (90+0 points)

hw/09/01-glue

  • There’s Unbound running on 10.10.50.8, and that’s what everybody is using as their DNS server.
  • What is a glue record, and why do you need it?
  • What exactly did I have to configure to make sure that when you use 10.10.50.8 as your DNS server, everybody in the network can correctly resolve any hostname in any student’s .una domain?
  • (10+0 points)

hw/09/02-feedback

  • If you have any valuable feedback, please do provide it here.
  • Points are only awarded for feedback which is actionable and can be used to improve the quality of the course.
  • Any constructive criticism is appreciated (and won’t be weaponized).

(Total = 100+0 points)

Don’t forget to git push all your changes! Also, make sure that VM still works by the deadline—otherwise we have no way of grading your work.