Lesson 014 · AWS Learning Path

AWS 014: DNS, HTTP, HTTPS and TLS

Anil Jalela · Published Jul 9, 2025 · 4 min read

The problem

A browser reports that a site cannot be reached. One engineer changes DNS, certificates, firewall rules, and the web server at the same time. The original cause is lost and new risks are introduced.

DNS, transport, TLS, and HTTP are different layers. Diagnose them in order.

Learning outcomes

You will be able to:

1. explain forward DNS resolution and common record purposes;
2. distinguish HTTP from TLS and HTTPS;
3. read an HTTP request and status code;
4. explain certificate name validation and trust at a useful level;
5. test resolution, connection, TLS, and HTTP separately;
6. identify the failing layer from evidence.

Request path

Application name
   |
   v
DNS resolution
   |
   v
Destination IP and route
   |
   v
Transport connection
   |
   v
TLS handshake for HTTPS
   |
   v
HTTP request and response
   |
   v
Application behavior

A failure near the top prevents later layers from being tested.

DNS

The Domain Name System maps names and other information through a distributed hierarchy.

Common records:

Resolvers cache answers according to time-to-live behavior. A changed record is not instantly visible from every cache.

Amazon Route 53 provides DNS services, but this lesson uses the protocol concept before service configuration.

HTTP

HTTP is an application protocol using request and response messages.

Simplified request:

GET /lesson HTTP/1.1
Host: example.com
Accept: text/html

Simplified response:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

Common methods include GET, HEAD, POST, PUT, PATCH, and DELETE. Application semantics determine whether an operation is safe and authorized.

Status families:

• 1xx: informational;
• 2xx: successful handling;
• 3xx: redirection;
• 4xx: request or client-side condition;
• 5xx: server-side failure.

A 200 response proves that one request received a success response. It does not prove that every dependency, user journey, or data write is healthy.

TLS and HTTPS

HTTPS applies HTTP semantics over a transport protected with TLS.

TLS can provide:

• confidentiality in transit;
• integrity protection;
• authentication of the server identity through certificate validation;
• optional client authentication.

The client checks items including:

• certificate validity period;
• requested hostname against certificate identities;
• trust chain to an accepted authority;
• signature and protocol requirements.

TLS does not prove:

• the application is free from vulnerabilities;
• the user is authorized;
• stored data is encrypted;
• the endpoint is honest merely because it obtained a certificate;
• DNS returned the intended destination in every threat model.

Practical layered test

Use example.com, which is reserved for documentation. Commands are read-only public requests.

Create:

mkdir -p "$HOME/nitwings-aws/evidence/aws-014"

1. DNS

getent ahosts example.com

getent asks the operating system's configured name-service mechanism. Output varies by resolver, network, and IPv6 support.

If unavailable, use a browser and record that the local tool was absent. Do not install software only to pass this exercise.

2. HTTPS and HTTP headers

Check for curl:

command -v curl

If present:

curl --fail --show-error --silent --head https://example.com/
echo "curl_exit=$?"

Options:

• --head requests headers without the normal response body;
• --fail returns a failure status for HTTP errors of 400 or higher;
• --show-error displays an error;
• --silent removes the progress meter.

Expected: an HTTP status line and headers. The exact HTTP version and headers can change.

3. TLS certificate

If openssl exists:

command -v openssl
openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -brief \
  </dev/null

-servername sends the requested hostname through Server Name Indication. Many endpoints host several names on one address.

Do not use an option that disables certificate verification as a generic fix.

4. Save evidence

{
  date -u
  getent ahosts example.com
  curl --fail --show-error --silent --head https://example.com/
} > "$HOME/nitwings-aws/evidence/aws-014/layer-test.txt" 2>&1

Failure isolation

Cache and retries

Retries can amplify an outage. A timeout should be bounded, retries limited, and backoff used where appropriate. A non-idempotent request can create duplicate work if retried without a safe token or application design.

DNS caching, HTTP caching, and application caching are separate mechanisms with separate correctness and invalidation rules.

Knowledge check

1. Which record maps a name to IPv6?
2. Does a DNS answer prove the application is healthy?
3. What does TLS protect?
4. Why is SNI important?
5. Does HTTP 200 prove a database write committed?

Expected answers: AAAA; no; data in transit plus endpoint authentication and integrity according to the negotiated connection; it identifies the requested hostname; no.

Completion gate

Pass when layer-test.txt records time, DNS evidence, and an HTTPS response, and you can diagnose one DNS, transport, TLS, and HTTP failure without changing several layers at once.

No AWS resource was created.

Official sources

• RFC 1034, DNS concepts
• RFC 9110, HTTP semantics
• RFC 8446, TLS 1.3
• Amazon Route 53 concepts
• Linux kernel TLS overview