DNS and SSL: DNS Records, DNSSEC, TLS, Certificates and a Complete Checklist

Examples:

• a valid certificate will not help if the A record points to an old server,
• a correct A record is not enough if AAAA directs IPv6 traffic to a non-working machine,
• automatic certificate renewal will not work if the _acme-challenge record cannot be created or port 80 is blocked,
• DNSSEC can increase trust in DNS responses, but an incorrect DS record can cause SERVFAIL for the entire domain,
• a short TTL will not fix a bad name server delegation,
• a wildcard certificate does not cover the root domain or multi-level subdomains unless they are entered separately.

In 2026, certificate handling should be fully automatic. As of 15 March 2026, public TLS certificates of the Subscriber Certificate type may have a maximum validity of 200 days. The limit will drop to 100 days in March 2027 and to 47 days in March 2029. Let's Encrypt still issues 90-day certificates by default, but also provides shorter profiles, and from May 2026 the tlsserver profile issues 45-day certificates for users who deliberately choose it.

TL;DR: maintain at least two independently available authoritative DNS servers, control the A and AAAA records, deploy DNSSEC only with a secure process for handling DS, restrict certificate authorities with CAA, use TLS 1.3 with TLS 1.2 as a compatible minimum, automate certificate issuance and renewal via ACME, and monitor the expiry date, certificate chain, SNI, HSTS and validation errors from multiple locations.

Information and requirements were verified on 23 July 2026.

DNS, SSL and TLS in a single table

Layer	Responsible for	Most important elements	Typical failures
Domain registrar	domain ownership and delegation	name servers, transfer lock, DS	account takeover, bad delegation, old DS
Authoritative DNS	the actual zone records	A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC	wrong address, missing record, split-brain, bad signature
Recursive resolver	finding and caching the response	TTL, cache, DNSSEC validation, DoH/DoT	stale data in cache, failed validation
TCP/QUIC and TLS	secure channel to the server	TLS 1.2/1.3, SNI, ALPN, certificate	weak protocol, bad chain, hostname mismatch
Certificate	confirming the identity of the name	SAN, issuer, validity, key, signature	expiry, missing name, wrong intermediate
HTTP	redirect and HTTPS policy	301/308, HSTS, security headers	redirect loop, mixed content, no HSTS

How does domain resolution really work?

DNS is a hierarchical and distributed naming system. The resolver does not receive the entire response from a single central server. In simplified terms:

1. the browser and system check the local cache,
2. the recursive resolver queries the root servers,
3. the root points to the servers of the appropriate top-level domain, for example .pl,
4. the TLD server points to the authoritative servers of the domain,
5. the authoritative server returns a record, for example A, AAAA or CNAME,
6. the response is stored according to the TTL.

użytkownik
   ↓
lokalny cache
   ↓
rekurencyjny resolver
   ↓
root → TLD → autorytatywny DNS
   ↓
A / AAAA / CNAME / HTTPS
   ↓
połączenie TLS z serwerem

DNS does not guarantee that the indicated server is healthy or that the HTTP response will be correct. It returns the data stored in the zone. DNS monitoring should therefore be combined with TCP, TLS and HTTP tests.

1. The most important DNS records

A and AAAA

example.com.      300 IN A     192.0.2.10
example.com.      300 IN AAAA  2001:db8::10

• A points to an IPv4 address,
• AAAA points to an IPv6 address.

The AAAA record is not a consequence-free addition. If it exists, IPv6-capable clients may try to connect to it. Do not publish AAAA until the firewall, routing, web server, certificate and ACME challenge work correctly over IPv6.

During http-01 validation, Let's Encrypt prefers IPv6 when the domain has an AAAA record. Faulty IPv6 can cause a failed certificate issuance or renewal even when IPv4 is correct.

CNAME

www.example.com.  300 IN CNAME app.hosting.example.

A CNAME creates an alias to another DNS name. A name with a CNAME should not simultaneously have other ordinary data, such as A, AAAA or MX, because a CNAME indicates that the actual data is located under a different name.

At the zone apex, that is example.com, a classic CNAME conflicts with the mandatory SOA and NS records. Providers work around this with their own ALIAS, ANAME or flattening mechanisms, but these are not ordinary CNAME records transmitted in the zone.

NS and SOA

example.com.  86400 IN NS ns1.dns-provider.example.
example.com.  86400 IN NS ns2.dns-provider.example.

NS defines the authoritative name servers. The delegation at the registrar and the NS records inside the zone should be consistent.

SOA contains administrative zone data, including the serial number and parameters used by secondary servers. When maintaining a zone manually, the serial number must increase after changes.

A good operational practice is at least two authoritative servers operating in separate networks or locations. ICANN recommends multiple, separate authoritative servers, preferably separated geographically and topologically.

MX

example.com.  3600 IN MX 10 mail1.example.net.
example.com.  3600 IN MX 20 mail2.example.net.

A lower number means a higher priority. The target of an MX record should be a host name, not an IP address or a CNAME.

Changing web hosting should not automatically change email. Before a DNS migration, record the MX, SPF, DKIM and DMARC records.

TXT

TXT is a text container used, among other things, by:

• SPF,
• DKIM,
• DMARC,
• domain ownership validation,
• ACME dns-01,
• SaaS integrations.

example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
_acme-challenge.example.com. 60 IN TXT "TOKEN"

Multiple TXT records under one name can be valid, but several competing SPF records starting with v=spf1 are a design error.

CAA

CAA allows the domain owner to indicate which certificate authorities may issue certificates for the domain.

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

• issue applies to ordinary certificates,
• issuewild applies to wildcards,
• iodef indicates a channel for reporting policy violations.

CAA does not replace account control at the registrar, DNSSEC or Certificate Transparency monitoring. It is an additional restriction for public CAs. The absence of CAA usually means that any publicly trusted CA may issue a certificate after correct domain validation.

PTR

PTR provides reverse DNS, that is the mapping of an IP address to a name. The record is set by the owner of the IP range, usually the VPS or hosting provider. It is particularly important for mail servers.

192.0.2.10 → mail.example.com

For email, the PTR name should usually lead back through A or AAAA to the same address.

HTTPS and SVCB

The HTTPS and SVCB records can convey to the client information about how to connect to a service, alternative endpoints, supported protocols and the parameters needed before establishing a connection.

A conceptual example:

example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.10"

You should not enter ipv4hint or ipv6hint as a substitute for correct address records without understanding client behavior. The HTTPS RR is a mechanism for optimization and signaling, not a fix for broken DNS or TLS.

2. TTL and "DNS propagation"

TTL defines how long a resolver may keep a response in cache. There is no single global propagation clock. After a change:

• some resolvers still have the old response,
• some will query the server immediately,
• negative responses, such as NXDOMAIN, can also be cached,
• the local system, browser, operator and application may each have a separate cache.

Reasonable TTL values

Situation	Typical value
stable production record	3600-86400 s
migration preparation	300-600 s
ACME DNS-01 record	30-300 s, if the provider allows
NS or SOA record	usually longer
emergency failover	a low TTL only helps after the earlier cache expires

Before a migration, reduce the TTL at least one old TTL period in advance. Lowering the TTL five minutes before a change does not remove responses that a resolver has already stored for 24 hours.

After the migration is complete, raise the TTL to reduce the number of queries and the dependence on momentary problems with the authoritative DNS.

3. DNSSEC: response integrity, not encryption

DNSSEC adds authentication of DNS data origin and integrity protection using digital signatures. It does not encrypt queries and does not hide domain names from the network provider or resolver.

The chain of trust uses, among other things:

• DNSKEY - the public zone keys,
• RRSIG - signatures of record sets,
• DS - the key fingerprint stored in the parent zone,
• NSEC or NSEC3 - cryptographic proof of the non-existence of a name or type.

root
  ↓ podpisana delegacja
TLD
  ↓ rekord DS
example.com
  ↓ DNSKEY + RRSIG
rekord A / AAAA / MX / CAA

RFC 9364 defines the use of DNSSEC for authenticating the origin of DNS data as current best practice.

The biggest DNSSEC risk

The most common problem is not the absence of DNSSEC, but a broken DNSSEC chain. If a DS record pointing to an old key remains at the registrar while the new DNS operator signs the zone with a different key, validating resolvers will return SERVFAIL.

A safe DNSSEC migration requires:

1. checking who signs the zone,
2. determining the method of key transfer or rollover,
3. publishing the correct DS in the parent domain,
4. waiting out the TTL of the DNSKEY and DS records,
5. only then removing the old keys or the old zone,
6. testing through validating resolvers.

Do not enable DNSSEC if the provider does not offer a clear process for handling DS and key rotation.

4. DNSSEC versus DoH and DoT

These mechanisms solve different problems:

Mechanism	Protects	Does not provide
DNSSEC	the authenticity and integrity of DNS data	query confidentiality
DNS over TLS	encryption between the client and the resolver via TLS, usually port 853	data authenticity without DNSSEC validation
DNS over HTTPS	encryption of DNS within HTTPS	data authenticity without DNSSEC
plain DNS	basic name resolution	confidentiality and cryptographic integrity

DNS over TLS is described by RFC 7858, and DNS over HTTPS by RFC 8484. Encrypted transport protects the query from simple eavesdropping on the client-resolver segment, but the resolver operator still sees the queries, and further resolution depends on its policy.

5. SSL versus TLS: correct terminology

"SSL certificate" is still a common marketing term, but modern sites use TLS. SSL 2.0 and SSL 3.0 are obsolete, and TLS 1.0 and 1.1 have been formally withdrawn by the IETF.

In 2026:

• TLS 1.3 should be preferred,
• TLS 1.2 remains the compatible minimum for older, still supported clients,
• TLS 1.0, TLS 1.1, SSLv2 and SSLv3 should be disabled,
• a TLS 1.2 configuration should use modern suites with AEAD and forward secrecy,
• the server should not offer obsolete algorithms and key exchanges.

RFC 9325 contains current recommendations for the secure use of TLS and has replaced the earlier BCP 195.

6. What does the browser check in a certificate?

During a TLS connection, the client checks, among other things:

1. whether the certificate is within its validity period,
2. whether the host name appears in subjectAltName,
3. whether the signature leads through a correct intermediate chain to a trusted root CA,
4. whether the certificate is not used for an inappropriate purpose,
5. whether the connection parameters are acceptable,
6. whether the browser's policies do not reject the certificate.

Server identity is currently verified based on the SAN, not the Common Name field as the primary source of the name.

SAN

A single certificate can cover multiple names:

example.com
www.example.com
api.example.com

Each name must appear in the SAN.

Wildcard

*.example.com

covers:

www.example.com
api.example.com
shop.example.com

but does not automatically cover:

example.com
www.eu.example.com

The root domain must be added separately, and a wildcard works only for one label level.

SNI

Server Name Indication allows the client to pass the host name during the handshake, so that a single IP address can serve multiple certificates. A misconfigured SNI often causes the certificate of another domain to be displayed.

Certificate chain

The server should send the domain certificate along with the necessary intermediate certificates, but usually not the root. A missing intermediate may work on one device that previously stored the certificate and fail on another.

7. Certificate validity in 2026

The CA/Browser Forum has adopted a schedule for shortening public TLS certificates:

Issue date	Maximum validity
before 15 March 2026	398 days
15 March 2026 - 14 March 2027	200 days
15 March 2027 - 14 March 2029	100 days
from 15 March 2029	47 days

This does not mean that every CA issues a certificate for the maximum period. Let's Encrypt still issues 90-day certificates by default, has optional six-day certificates and a tlsserver profile with 45-day certificates available for early deployments from May 2026.

The conclusion is simple: manual certificate renewal is ceasing to be a reasonable operational practice.

8. ACME and certificate automation

ACME is a standard protocol that automates account registration, domain control validation, issuance, renewal and revocation of a certificate.

HTTP-01

The CA fetches a file:

http://example.com/.well-known/acme-challenge/TOKEN

Advantages:

• simple configuration for a single web server,
• easy automation,
• does not require a DNS API.

Limitations:

• requires an available port 80,
• does not issue wildcards,
• the challenge must reach the correct server,
• a faulty AAAA, proxy, redirect or load balancer can break validation.

Let's Encrypt recommends leaving port 80 open for public web servers and redirecting normal traffic to HTTPS.

DNS-01

The client publishes a TXT:

_acme-challenge.example.com. 60 IN TXT "VALIDATION_TOKEN"

Advantages:

• supports wildcards,
• works without a public HTTP server,
• is suitable for centralized certificate handling.

Risks:

• requires secure access to the DNS API,
• propagation and caching can delay validation,
• an API token with the right to edit the entire zone increases the impact of a leak,
• old TXT records can make diagnostics harder.

Let's Encrypt explicitly recommends using DNS-01 with a provider that offers an API, because automating renewals is crucial. Assign the token the smallest possible scope: ideally only for _acme-challenge records, not for managing the domain, account or all zones.

Wildcards in Let's Encrypt require DNS-01.

TLS-ALPN-01

Validation takes place over a special TLS connection on port 443 and the ALPN protocol. It is useful for specialized proxies and certificate management systems, but is less often configured manually.

Renewal Information

A modern ACME client should support ACME Renewal Information, that is ARI. Instead of renewing each certificate according to a single fixed threshold, the client can receive a suggested renewal window from the CA. Let's Encrypt recommends checking ARI information at least twice a day.

9. CAA and ACME: a practical example

For Let's Encrypt certificates:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"

If you do not want wildcards:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"

Before issuance, a public CA is obligated to check CAA. As of 15 March 2026, the CA/Browser Forum requirements also mandate DNSSEC validation for CAA-related queries performed from the primary network perspective, and a DNSSEC validation error must not be treated as consent to issue.

After changing CA, remember to update CAA before starting the new issuance process.

10. HTTPS, redirects and HSTS

The minimal scheme:

http://example.com
        ↓ 301 lub 308
https://example.com

After confirming that HTTPS fully works, you can add:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS tells the browser to use only HTTPS in the future and not to allow bypassing some certificate errors.

Do not start with a long max-age, includeSubDomains and preload if:

• there are subdomains without HTTPS,
• part of the infrastructure is managed by a partner,
• the renewal process has not been tested,
• there is no certificate monitoring,
• it is not known whether the old service will still be needed.

HSTS preload places the rule in browser distributions. Removing an entry can take weeks.

11. The most common DNS errors

Faulty AAAA record

IPv4 works, but some clients choose non-working IPv6. The symptoms are random depending on the user's network.

CNAME and other records under the same name

The alias conflicts with address, MX or TXT records. The provider's panel may block the change or generate an ambiguous zone.

Inconsistent NS delegation

The registrar points to different servers than the zone, or one of the servers has an older version of the data.

Old DS after a DNS change

The domain returns SERVFAIL only on DNSSEC-validating resolvers.

Permanently too low a TTL

It increases the number of queries and sensitivity to momentary DNS unavailability, and does not automatically provide fast failover.

Too high a TTL before a migration

Old addresses remain in cache for many hours.

Leftover TXT records

Old verification and ACME tokens make auditing harder and increase operational chaos.

Lack of consistency between www and apex

example.com and www.example.com point to different systems, have different certificates or create a redirect loop.

12. The most common TLS and certificate errors

Expired certificate

Most often the cause is not a lack of automation, but an automated process that stopped working without an alert.

Certificate does not cover the host

A certificate for example.com does not automatically secure www.example.com.

Incomplete chain

An intermediate certificate is missing. The problem may occur only on new devices or selected clients.

Wrong certificate due to SNI

The reverse proxy has a wrong default virtual host, or the new domain has not been added to the mapping.

Old protocols and cipher suites

The server still offers TLS 1.0/1.1 or old suites, because the configuration dates from many years ago.

Lack of consistency across multiple layers

The CDN has a valid public certificate, but the CDN→origin connection is unencrypted or does not verify the host name.

Renewal performed, but the process did not reload the server

A new certificate file exists on disk, but Nginx, Apache, HAProxy or the application still uses the old certificate from memory.

13. Step-by-step diagnostics

DNS records

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Delegation

dig example.com NS
dig +trace example.com

DNSSEC

dig example.com A +dnssec
delv example.com A

SERVFAIL while it works without validation is a strong signal of a DNSSEC problem.

Certificate and SNI

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Certificate dates

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

TLS

openssl s_client -connect example.com:443 -servername example.com -tls1_3
openssl s_client -connect example.com:443 -servername example.com -tls1_2

HTTP and HSTS

curl -I http://example.com/
curl -I https://example.com/
curl -IL http://example.com/

Check the redirect, Strict-Transport-Security, host name, final status and the absence of a loop.

You can also use the free POLPROG DNS and SSL Inspector, which shows DNS records and TLS certificate information. Complement the test with the Security Headers Inspector, Website Health Check and the article Web Application Security Basics.

14. Production monitoring

Do not monitor only the homepage from a single location. The minimal set:

• the response of the authoritative DNS,
• the A, AAAA, CNAME, NS, MX and CAA records,
• DNSSEC validation,
• availability over IPv4 and IPv6,
• certificate dates,
• SAN compliance,
• the full chain,
• TLS 1.2 and TLS 1.3,
• the final HTTP→HTTPS redirect,
• HSTS,
• the origin response behind the CDN,
• ACME operation and the last successful renewal.

Certificate alert thresholds

For a fully automatic system:

Time remaining	Response
30 days	warning or trend check
14 days	alert requiring analysis
7 days	operational incident
3 days	critical alert and escalation
less than 24 h	pending outage

The thresholds should be matched to the certificate length. For six-day or 45-day certificates, monitoring must react much earlier, proportionally to the renewal cycle.

15. Secure DNS and TLS checklist

Registrar and DNS

• The registrar account has MFA.
• Domain transfer is locked.
• Contact details and the recovery process are up to date.
• At least two authoritative DNS servers are used.
• The servers operate in separate networks or locations.
• NS delegation at the registrar and in the zone is consistent.
• The A and AAAA records point to active infrastructure.
• IPv6 is actually monitored.
• The MX, SPF, DKIM and DMARC records are preserved during migrations.
• CAA allows only the CAs in use.
• There are no unnecessary TXT records and verification tokens.
• The TTL was lowered in advance before the migration.
• The TTL was raised after stabilization.
• Access to the DNS API has minimal permissions.

DNSSEC

• The provider supports DNSSEC and key rotation.
• The DS record at the registrar matches the active DNSKEY.
• Changes of DNS operator have a DNSSEC migration plan.
• Old DS records and keys are removed only after the cache expires.
• The domain is tested through a validating resolver.
• An alert detects SERVFAIL and signature expiry.

Certificates

• Certificates are issued and renewed via ACME.
• Renewal has been tested, not just the first issuance.
• The process reloads the server after installing a new certificate.
• All hosts appear in the SAN.
• Wildcards are used deliberately.
• The chain contains the correct intermediates.
• The private key does not leave the appropriate system.
• Permissions to the key are restricted.
• Alerts work independently of the ACME client itself.
• DNS-01 uses a restricted API token.
• HTTP-01 works over IPv4 and IPv6.
• A staging CA is used for automation tests.

TLS and HTTPS

• TLS 1.3 is enabled.
• TLS 1.2 remains only for the compatibility that is needed.
• TLS 1.0, TLS 1.1 and SSL are disabled.
• The server does not offer obsolete cipher suites.
• SNI returns the correct certificate for each host.
• HTTP redirects directly to HTTPS.
• There is no mixed content.
• HSTS was deployed in stages.
• includeSubDomains is safe for the entire domain.
• Preload was analyzed before submission.
• CDN→origin also uses correctly verified TLS.

Verdict

A good DNS and TLS configuration in 2026 rests on four principles:

1. DNS must be consistent and operationally resilient.
2. DNSSEC should be deployed only with correct DS and key management.
3. Certificates must be handled automatically via ACME.
4. TLS 1.3, a correct chain, monitoring and HSTS are part of a single process, not separate tasks.

The biggest risk is not the absence of a "green padlock" on launch day. It is a silent failure a few months later: an expired certificate, an outdated AAAA record, a leftover DS, a DNS token with excessive permissions or a renewal process that no one monitored.