OPS345 Lab 5

DNS overview

The Domain Name System converts human-friendly domain names to IP addresses. Computers on the internet can only communicate with each other using IP addresses. But people aren't very good at remembering long strings of numbers (up to 12 digits for ipv4) or even longer strings of numbers and characters mixed (24 characters for ipv6).

Therefore DNS is a critical part of the internet infrastructure, and just about everyone who has a website needs to do something with it. Some all-inclusive web hosts offer domain name registration and automatically connect their hosting service to the domain registration, but that comes at the cost of any flexibility. From a technical point of view your domain name registration has nothing to do with the server that your DNS records are pointing to.

DNS records

DNS servers store records of different types. Here are the ones you'll see most often:

• A records (the most common ones) map fully-qualified donain names (FQDNs) to IP addresses.
• CNAME records (also called aliases) map a name to another name.
• MX records store the FQDN of the mail server for that domain.
• TXT records can store almost anything and are often used for various security features.

You can use several command-line tools to query DNS servers. Some are more useful than others. Try the following:

1. ping littlesvr.ca

   Notice that ICMP (ping) packets are sent to an IP address, not the FQDN. That means the ping command had to first do a DNS query (for the A record for littlesvr.ca) and therefore this is a simple way to do a DNS query, which is useful if you don't have any better tools. Notice also that this works even if the server won't respond to pings, or even if it's offline.

2. host littlesvr.ca
   host -a littlesvr.ca

   This is a much more DNS-specific command and has parameters that will let you ask for different record types.

3. dig littlesvr.ca
   dig littlesvr.ca MX
   dig littlesvr.ca @8.8.8.8

   This is the one we'll use mostly in this course. The output is the most difficult to read, but the details it provides are useful when troubleshooting your DNS setup. The first dig command above asks for the A record (the default). The second asks for the MX record for littlesvr.ca. The third asks for the A record from a specific DNS server (8.8.8.8).
4. Do your best to construct DNS queries using dig to get all the records set up for littlesvr.ca. Following is a screenshot of the registrar's interface:

If you can't obtain all these records using dig: you either don't understand how DNS works or you need more practice with dig. Keep trying until you figure it out.

Registering a domain name

You can't get a publicly-resolvable domain name just by doing some magic on your server. You need to pay a registrar (usually a yearly fee of around 20$) to connect your records to the global DNS network.

Wikipedia sometimes has useful information, and the Address resolution mechanism section has a reasonably comprehensible diagram and description of a simple query process.

You would typically be interested in controlling somedomain.com (or .ca or .org, etc.) and therefore you would:

• Find a registrar who's authorized to sell domains under that TLD (top-level domain), which is .com in this example.
• Check whether somedomain.com is available.
  • If it's available: you pay the registrar and in return you get exclusive control over the DNS records for that domain for the period of time you paid for.
  • If it's not available: you're most likely out of luck. It can cost tens or hundreds of thousands of dollars to buy a domain from someone who already bought it.
• You can add whatever DNS records you want for your domain, and you also control all the subdomains of that domain. You won't need to pay extra for one.two.three.four.somedomain.com
• After you add you records - they will be available to the world almost immediately. Except: see next section.

If you're a more advanced user: you can configure your domain records to be stored on and served by your own DNS server(s). You won't be doing that in this course. It's a lot of hard work and requires a cooparative registrar to set up glue records for you.

Caching

Because DNS is used so much (see a typical webpage): there are countless DNS queries done everywhere all the time.

The responses to those queries are cached (stored closer to the questioner) in order to minimize load on the authoritative servers. They are cached for a specific amount of time - typically controlled by the domain owner, though cheaper registries have minimum limits.

That means that if you have an A record linking somedomain.com to 1.2.3.4, and someone does a DNS query for somedomain.com: their next query for somedomain.com will not make it to your DNS server until after the TTL expires.

That means if you change your A record to link somedomain to 2.3.4.5 instead: it may take as long as 48 hours for everyone in the world to be guaranteed to get the new record. You can see the TTL (in seconds) for a record when you use dig to do a query:

There are websites available that can help you figure out whether your records are up to date around the world, for example https://www.whatsmydns.net/

Private DNS

If you only need DNS records inside your organization (e.g. on an LAN/intranet): you can avoid paying a registrar for each domain.

You do that by running a DNS server on your LAN, and making sure all the machines on that network are configured to use your internal DNS server. Curiously: in such a setup the administrator can have control over all DNS records including for domains owned by someone else:

Your DNS records

In this course you'll get to experience something like a real domain registration process with some limitations:

• You'll get full control over a subdomain of ops345.ca (e.g. asmith15.ops345.ca), rather than a second-level domain (like asmith15.ca).
• You can only create A, MX, CNAME, and TXT records.
• You have no control over the TTL.

But you get to do this for free.

You should have received an email about a Bindistrar account that's been created for you. The email will include your username and a random password. Please keep the password secret. You cannot change it. I can change it for you but I'd really rather not.

After you log in: Bindistrar will allow you to create public DNS records for yourusername.ops345.ca

• Set up an A record for yourusername.ops345.ca to point to your elastic IP (the one assigned to router).
• Set up a CNAME record for www, so that it points to yourusername.ops345.ca

Mind the dots
Technically every FQDN ends with a dot, it's just normally hidden from the users. Try it in a web brwoser, using ping, etc. When you're configuring DNS records: pay attention whether your host/value has a trailing dot or not. If you're missing the trailing dot: your value will have your domain appended to it. Practice it to understand what this means.

• Test your two new records you just created using dig. If you're not sure whether the problem is with caching: you can query the authoritative DNS server directly, e.g.:

  dig asmith15.ops345.ca @littlesvr.ca

• You should also be able to go to www.yourusername.ops345.ca in a web browser:

Access your Nextcloud via FQDN

• Try to go to www.yourusername.ops345.ca/nextcloud in a web browser. You should see an error like this:

• Since you are the administrator: there's noone else for you to contact. Good thing you've had a little bit of practice with PHP. Fix the error so that you can log in to your Nextcloud installation. This Nextcloud help page might help too.

Encryption, certificates, etc.

Encryption means converting plain text (something you can read/use, it doesn't need to be text) into cyphertext. The cyphertext created by a good encryption algorithm is impossible (or, for weak algorithms: at least impractical) to decrypt (covert back into plain text) without a key.

You've been using public key cryptography for your entire life (unless you were born before the 1990s). And you've been setting up public key cryptography for yourself since at least OPS245. If you actually understand how this stuff works: you'll be far ahead of the average sysadmin.

We don't have the time to do a comprehensive overview of cryptography, so I strongly encourage you to put the book Crypto by Steven Levy on your "must-read" list. You can borrow a copy from the Toronto Public Library. I have yet to see a better introduction to encryption. It's not a course reqirement - but if you don't want to be clueless about security fundamentals online - read that book and understand it. It reads like a novel, and it's perfectly readable even if you have no interest in math:

In a nutshell, here are the most important points, the absolute minimum you need to be comfortable with this:

• Public key encryption (also called assymetric encryption) uses two keys: a public key and a private key.
• The two keys are permanently tied to each other by complex mathematics (read the book to get a feel for the fundamentals). You can't mix one public key with an unrelated private key.
• The private key is like your password, you never give it to anyone. The public key is of no value to attackers, so there's no point in trying to protect it.
• Anyone can encrypt something with the public key, but only the private key can be used to decrypt that.
• Anyone can verify that a file signed using the private key has not been modified except by the owner of the private key.
• A certificate is a public key typically signed by a third party's private key.
• Symmetric encryption only has one private key, no public key. That makes it very hard to use with strangers on the internet.
• Hashing is used a lot in cryptography, but it's not an encryption tool.

With those fundamentals you should be able to follow this diagram which describes how SSH key authentication works. The diagram is from Sébastien Saunier's blog.:

A diagram explaining how public / private keys work.

Certificate Authorities (CAs)

The problem with assymetric encryption is the distribution of public keys. The encryption strength is meaningless if the client can't be sure it has the unmodified public key for the server. That's where a third party gets involved. This third party is called a Certificate Authority.

The exact same concepts from the section above are used for CA-signed certificates. There's just a third party involved - which makes it seem like magic for too many people, including professionals in our field.

If you have any ambitions in this field: set a goal for yourself to understand this stuff fully. At least eventually, if not now.

Setup on the server

Let's take a web browser and web server for an example - since that's the most common use of this setup.

1. First the web server administrator needs to generate a key pair, roughly the same as what you've been using for SSH (but using different commands).
2. The server admin needs to have the public key from that pair signed by a CA which browsers will accept as reliable. There are many such CAs, you can look in your browser's settings to see a full list. Typically people choose the cheapest option that will work in their setup. That's around 60$ a year.
3. The admin needs to pay the CA for the service. There's only one free option available which we'll use in this course.
4. The CA will use their private key to sign the web server's public key. That will allow people who already have the CA's public key to verify that the web server's public key has not been modified (by anyone other than the people who have access to any trusted CAs private key).
5. The server admin can download this signed public key (a.k.a. a certificate) from the CA.
6. The server admin will configure the web server to use the server's private key and the CA-signed version of its pair public key for secure communication over HTTPS.

A certificate will always be linked to an FQDN. That mostly makes sense since web browsers connect to a web server using a domain name. Sometimes that's a pain in the neck for the administrator (you'll see why later) and the concept of "wildcard certificate" exists, but I was never able to set one up to work properly.

Client communicating with server

Now that the server is configured, let's look at what happens when a web browser connects to a web server using HTTPS.

1. The web browser connects to a web server, expecting to establish encrypted communication.
2. The web server will send to the client its CA-signed public key.
3. The browser came installed with a list of trusted CAs' public keys. Good luck figuring out how this list was compiled by whom when and how it's kept up to date. Let's just assume for now that those are all trustworthy, since everyone else assumes the same. It uses the appropriate CA's public key from that list to verify the server's public key.
4. At this point a combination of signing, encryption, and exchange of symmetrical encryption keys can be used to establish a connection where all traffic in both directions is encrypted.

• certificates, CAs, relationship with DNS
• CA-signed certs cost money. we have to use let's encrypt which is lame because it expires quickly unless you run their software on your server. but it's free
• follow this except the deploy part: https://help.datica.com/hc/en-us/articles/360044373551-Creating-and-Deploying-a-LetsEncrypt-Certificate-Manually
• install certbot in your workstation using apt or the software manager

$ sudo su
root@p51:/home/andrew# certbot certonly --manual --preferred-challenges dns
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): asmith15@myseneca.ca

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: n
Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel): asmith15.ops345.ca
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for asmith15.ops345.ca

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.asmith15.ops345.ca with the following value:

SUobA6iJARuujmCDhb-4I0m61Zdtqe_uBgyX1ExrCPg

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/asmith15.ops345.ca/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/asmith15.ops345.ca/privkey.pem
   Your cert will expire on 2022-02-16. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

You have new mail in /var/mail/root

root@p51:/home/andrew# cp /etc/letsencrypt/live/asmith15.ops345.ca/cert.pem ~andrew/prog/seneca/ops345/new/keys/asmith15.ops345.ca.cert.pem
root@p51:/home/andrew# cp /etc/letsencrypt/live/asmith15.ops345.ca/privkey.pem ~andrew/prog/seneca/ops345/new/keys/asmith15.ops345.ca.key.pem
root@p51:/home/andrew# chown andrew ~andrew/prog/seneca/ops345/new/keys/asmith15.ops345.ca.*
root@p51:/home/andrew# exit

• The file in /etc/letsencrypt/live/asmith15.ops345.ca/cert.pem is what a CA would send you after you paid them. This one is free but it expires in 90 days, which is good enough for this course.
• Get Apache to use the key:
  • /etc/httpd/conf/httpd.conf ServerName asmith15.ops345.ca:80
  • yum install mod_ssl
  • scp -P 2211 -i keys/ssh/ops345-all-aws-machines.pem keys/asmith15.ops345.ca.* andrew@34.202.103.43:~
  • [root@www andrew]# cp asmith15.ops345.ca.cert.pem /etc/pki/tls/certs/
  • [root@www andrew]# cp asmith15.ops345.ca.key.pem /etc/pki/tls/private/
  • /etc/httpd/conf.d/ssl.conf
    • SSLCertificateFile /etc/pki/tls/certs/asmith15.ops345.ca.cert.pem
    • SSLCertificateKeyFile /etc/pki/tls/private/asmith15.ops345.ca.key.pem
  • restart apache, confirm no errors
• Edit ops345sgprivate, add https
• Edit ops345sg, add https
• On router: iptables -t nat -I PREROUTING 2 -p tcp --dport 443 -j DNAT --to 10.3.45.11:443
• On www: iptables -I INPUT 4 -p tcp --dport 443 -j ACCEPT
• Test with firefox https. www gives a warning because the certificate is not for that FQDN. fix it for homework.