DNS and HTTP

01The problem

When a customer opens app.tallybook.example, two things happen before any Tallybook code runs: their phone asks DNS for the server's address, then sends an HTTP request to it. Both are configured in plain text files, and both are behind a large share of real outages: a wrong DNS record, a forgotten one, or a misunderstanding of what an HTTP status code means.

Tallybook's DNS zone is in tallybook.example.zone. Reading it carefully turns up a risk nobody had noticed.

02The concept

DNS records

TTL (time to live) says how long others may cache an answer, in seconds. Before moving a service, lower the TTL a day ahead so the change spreads quickly.

Dangling records

A CNAME pointing to a cloud resource that has been deleted is dangling. If an attacker can create a resource with that name on the same cloud service, they control your subdomain. Remove records when you remove what they point to.

HTTP

A request has a method (GET reads, POST creates or sends, PUT and PATCH update, DELETE removes), a path, and headers. The response has a status code:

03Example

The zone file, without its first two lines (the default TTL and the SOA record):

%%bash
curl -sO https://academy.cloudtechanalytics.com/datasets/linux/tallybook.example.zone
tail -n +3 tallybook.example.zone

@        IN NS    ns1.dnshost.example.
@        IN NS    ns2.dnshost.example.
@        IN A     196.43.12.10
www      IN CNAME tallybook.example.
app      IN A     196.43.12.10
api      IN A     196.43.12.10
pay      IN CNAME app.tallybook.example.
status   IN CNAME tallybook.statuspage.example.
staging  IN CNAME staging-lb-2025.cloudhost.example.
@        IN MX    10 mx1.mailhost.example.
@        IN MX    20 mx2.mailhost.example.
@        IN TXT   "v=spf1 include:mailhost.example ~all"
_dmarc   IN TXT   "v=DMARC1; p=none; rua=mailto:dmarc@tallybook.example"

Count records by type:

%%bash
awk 'NR > 1 {print $3}' tallybook.example.zone | sort | uniq -c | sort -rn

4 CNAME
      3 A
      2 TXT
      2 NS
      2 MX
      1 SOA

Two findings. staging is a CNAME to staging-lb-2025.cloudhost.example, a load balancer name from 2025; Tallybook's current staging load balancer is staging-lb (lesson 1 of the cloud course lists it). If the old one was deleted, this is a dangling record. And the DMARC record says p=none: emails pretending to come from tallybook.example are reported but not rejected, which matters for a company whose emails ask customers to pay invoices.

Now HTTP, from the access log: requests by status class and method.

%%bash
curl -sO https://academy.cloudtechanalytics.com/datasets/linux/access.log
awk '{print substr($9, 1, 1) "xx", substr($6, 2)}' access.log | sort | uniq -c | sort -k2,2 -k1,1nr

4026 2xx GET
   2272 2xx POST
    362 3xx GET
    180 4xx GET
     37 4xx POST
    146 5xx GET
    118 5xx POST

(substr($6, 2) drops the quote before the method.) The 4xx responses are the scanner and failed logins: the clients' problem. The 5xx responses are all from the outage: Tallybook's problem. A live check of any website's headers looks like this (it needs the internet, so it isn't run here):

%%bash
curl -sI https://academy.cloudtechanalytics.com/

04Walkthrough

1. Run the cells. Which names point to the same address as the bare domain?
2. What would happen to pay.tallybook.example if the app record changed?
3. If you have internet access in Colab, run the curl -sI cell and identify the status code and two headers.
4. Write the DNS fixes (the task below).

05Practice

06Check your understanding