How and.guide Is Served: A Teardown of Our Own Domain

and.guide is a static Astro site on Cloudflare Pages, with DNS on Cloudflare and a small Worker in front of the static files. Everything below was captured from the outside, the way a reader’s browser or a crawler sees it, on 26 September 2026 between 14:37 and 15:05 UTC from a workstation in South Korea. The last section lists what we would change.

The captures used DiG 9.10.6, curl 8.7.1, and OpenSSL 3.6.3 (the openssl in the commands), against Cloudflare’s resolver (1.1.1.1), Google’s (8.8.8.8), and our ISP’s default resolver. The site was being reorganized the same day, so legacy paths in particular may behave differently later.

The request path at a glance

Layer	What we observed
Delegation	`.guide` delegates to `frida.ns.cloudflare.com` and `roan.ns.cloudflare.com`; no DS record, so no DNSSEC
Apex, `and.guide`	Flattened A and AAAA answers identical to `and-guide.pages.dev`; no HTTPS (type 65) record
`www.and.guide`	Different Cloudflare addresses, an HTTPS record with `h3` and ECH, and one 301 to the apex
`*.and.guide`	Deliberate DNS-only wildcard to `115.68.101.36`, our self-hosted deployment server for our own apps
TLS	Apex: Google Trust Services, `and.guide` only. `www`: Let’s Encrypt, `*.and.guide` and `and.guide`. No CAA record anywhere
HTTP	HTML with `Link` discovery headers and `Vary: Accept`; Markdown on request; no HSTS, CSP, or frame policy
Edge location	Apex answered from Seoul (ICN) in every sample; `www` from Hong Kong, Tokyo, or Osaka

Delegation and DNSSEC: signed TLD, unsigned zone

Live capture, 26 September 2026. Our delegation as Cloudflare’s resolver returns it, as the .guide registry server hands it out, and the zone’s SOA:

$ dig +nocmd +noall +answer and.guide NS @1.1.1.1
and.guide.		86400	IN	NS	frida.ns.cloudflare.com.
and.guide.		86400	IN	NS	roan.ns.cloudflare.com.
$ dig +nocmd +noall +authority +norec and.guide NS @v0n0.nic.guide
and.guide.		3600	IN	NS	roan.ns.cloudflare.com.
and.guide.		3600	IN	NS	frida.ns.cloudflare.com.
$ dig +nocmd +noall +answer and.guide SOA @1.1.1.1
and.guide.		1800	IN	SOA	frida.ns.cloudflare.com. dns.cloudflare.com. 2414193944 10000 2400 604800 1800

The registry publishes the delegation with a 3,600-second TTL, while 1.1.1.1 returned the NS set from Cloudflare’s authoritative servers with 86,400 seconds. The SOA names frida as the primary server and dns.cloudflare.com as the responsible mailbox.

Live capture, 26 September 2026. Asking the registry for a DS record, checking whether our zone publishes keys, and comparing the ad flag that 1.1.1.1 sets for the TLD and for our apex:

$ dig +nocmd +norec +dnssec and.guide DS @v0n0.nic.guide | grep "^;; flags"
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
$ dig +nocmd +norec +dnssec +noall +authority and.guide DS @v0n0.nic.guide | awk '$4 != "RRSIG"'
coa0vaq2vtpst74nonfu1e1f368i8ebo.guide.	3600 IN	NSEC3 1 1 0 73 CPMLMM2UR01DPL704V9G2IM6K1SR481P  NS SOA RRSIG DNSKEY NSEC3PARAM
guide.			3600	IN	SOA	v0n0.nic.guide. hostmaster.donuts.email. 1790433683 7200 900 1209600 3600
4gskn6mqgok4db5hmf2q9dk5lk75nr3o.guide.	3600 IN	NSEC3 1 1 0 73 4J7EL1MFRS1T2UDSMT3T4LRVVUM5RGF9  NS DS RRSIG
$ dig +nocmd +noall +answer +authority and.guide DNSKEY @roan.ns.cloudflare.com
and.guide.		1800	IN	SOA	frida.ns.cloudflare.com. dns.cloudflare.com. 2414193944 10000 2400 604800 1800
$ dig +nocmd +dnssec guide SOA @1.1.1.1 | grep "^;; flags"
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
$ dig +nocmd +dnssec and.guide A @1.1.1.1 | grep "^;; flags"
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

The registry answers authoritatively (aa) with ANSWER: 0 and NSEC3 records instead of a DS record: a signed statement that no DS exists for and.guide. Cloudflare’s servers return no DNSKEY for our zone either. 1.1.1.1 sets the ad (authenticated data) flag on the .guide SOA but not on our A records, so the chain of trust ends at the TLD. According to Cloudflare’s DNSSEC documentation, turning it on takes two steps: Cloudflare signs the zone and generates a DS record, and we add that DS record at our registrar.

The apex borrows the Pages project’s addresses

Live capture, 26 September 2026. Addresses for the apex, the Pages project hostname, and www, from 1.1.1.1:

$ dig +nocmd +noall +answer and.guide A @1.1.1.1
and.guide.		300	IN	A	172.66.47.12
and.guide.		300	IN	A	172.66.44.244
$ dig +nocmd +noall +answer and.guide AAAA @1.1.1.1
and.guide.		300	IN	AAAA	2606:4700:310c::ac42:2cf4
and.guide.		300	IN	AAAA	2606:4700:310c::ac42:2f0c
$ dig +nocmd +noall +answer and-guide.pages.dev A @1.1.1.1
and-guide.pages.dev.	300	IN	A	172.66.47.12
and-guide.pages.dev.	300	IN	A	172.66.44.244
$ dig +nocmd +noall +answer www.and.guide A @1.1.1.1
www.and.guide.		300	IN	A	172.67.138.236
www.and.guide.		300	IN	A	104.21.70.196
$ dig +nocmd +noall +answer www.and.guide AAAA @1.1.1.1
www.and.guide.		300	IN	AAAA	2606:4700:3031::6815:46c4
www.and.guide.		300	IN	AAAA	2606:4700:3035::ac43:8aec

The apex and and-guide.pages.dev return the same two IPv4 and two IPv6 addresses. Each IPv6 address carries its IPv4 twin in the last 32 bits: ac42:2cf4 is 172.66.44.244 written in hexadecimal. www.and.guide gets a different pair, 172.67.138.236 and 104.21.70.196, mirrored the same way in its AAAA records. 8.8.8.8 and our ISP’s resolver returned the same apex addresses.

Live capture, 26 September 2026. Asking Cloudflare’s authoritative server directly for a CNAME at the apex, then for its A records, then for mail:

$ dig +nocmd +norec +noall +answer +authority and.guide CNAME @roan.ns.cloudflare.com
and.guide.		1800	IN	SOA	frida.ns.cloudflare.com. dns.cloudflare.com. 2414193944 10000 2400 604800 1800
$ dig +nocmd +norec +noall +answer and.guide A @roan.ns.cloudflare.com
and.guide.		300	IN	A	172.66.44.244
and.guide.		300	IN	A	172.66.47.12
$ dig +nocmd +noall +answer and.guide MX @1.1.1.1
and.guide.		300	IN	MX	10 mail.and.guide.

Cloudflare’s Pages documentation says that for an apex custom domain it creates a CNAME record, yet the authoritative server returns no CNAME at and.guide, only A records. That is CNAME flattening, which Cloudflare applies by default at the zone apex on every plan. It has to: the apex also holds SOA, NS, MX, and TXT records, and a standard CNAME cannot share its name with other data. Our guide to CNAME flattening covers the mechanism.

Live capture, 26 September 2026. HTTPS (type 65) records through Cloudflare’s and Google’s DNS-over-HTTPS JSON APIs:

$ curl -s -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=www.and.guide&type=HTTPS'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"www.and.guide","type":65}],"Answer":[{"name":"www.and.guide","type":65,"TTL":300,"data":"1 . alpn=h3,h2 ipv4hint=104.21.70.196,172.67.138.236 ech=AEX+DQBBegAgACC7qEZkgW2KJxglVK52B5L+RN3FIyTY0YGe9CBJrCxaRwAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3031::6815:46c4,2606:4700:3035::ac43:8aec"}]}
$ curl -s -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=and-guide.pages.dev&type=HTTPS'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"and-guide.pages.dev","type":65}],"Answer":[{"name":"and-guide.pages.dev","type":65,"TTL":300,"data":"1 . alpn=h3,h2 ipv4hint=172.66.44.244,172.66.47.12 ech=AEX+DQBBegAgACC7qEZkgW2KJxglVK52B5L+RN3FIyTY0YGe9CBJrCxaRwAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:310c::ac42:2cf4,2606:4700:310c::ac42:2f0c"}]}
$ curl -s -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=and.guide&type=HTTPS'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"and.guide","type":65}],"Authority":[{"name":"and.guide","type":6,"TTL":1800,"data":"frida.ns.cloudflare.com. dns.cloudflare.com. 2414193944 10000 2400 604800 1800"}]}
$ curl -s 'https://dns.google/resolve?name=and.guide&type=HTTPS'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"and.guide.","type":65}],"Authority":[{"name":"and.guide.","type":6,"TTL":1800,"data":"frida.ns.cloudflare.com. dns.cloudflare.com. 2414193944 10000 2400 604800 1800"}],"Comment":"Response from 162.159.38.137."}

www.and.guide and and-guide.pages.dev each return an HTTPS record with alpn=h3,h2, address hints, and an ech value whose public name decodes to cloudflare-ech.com. The apex returns nothing from either resolver, only our SOA. Cloudflare documents that it synthesizes these records for proxied names so a client can learn how to connect before its first request, and the Encrypted Client Hello (ECH) configuration, which Cloudflare enables by default on Free zones, travels inside them. So the redirect-only host has ECH and an HTTP/3 hint in DNS, while the canonical host has neither and announces HTTP/3 only through its alt-svc response header.

We do not know exactly how Cloudflare routes the apex internally. The outside evidence (the Pages project’s addresses, no synthesized HTTPS record, and a different certificate, shown next) is consistent with the apex being served through the Pages custom-domain path rather than as an ordinary proxied record in our zone.

Two certificates from two CAs, and no CAA

Live capture, 26 September 2026. Leaf certificates for the apex and www:

$ openssl s_client -connect and.guide:443 -servername and.guide </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN=and.guide
issuer=C=US, O=Google Trust Services, CN=WE1
notBefore=Aug  8 05:34:39 2026 GMT
notAfter=Nov  6 06:34:36 2026 GMT
X509v3 Subject Alternative Name: 
    DNS:and.guide
$ openssl s_client -connect www.and.guide:443 -servername www.and.guide </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN=and.guide
issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  6 14:25:26 2026 GMT
notAfter=Dec  5 14:25:25 2026 GMT
X509v3 Subject Alternative Name: 
    DNS:*.and.guide, DNS:and.guide

Live capture, 26 September 2026. The chain each host sends:

$ openssl s_client -connect and.guide:443 -servername and.guide </dev/null 2>/dev/null | grep -E '^ *[0-9] s:|^ *i:'
 0 s:CN=and.guide
   i:C=US, O=Google Trust Services, CN=WE1
 1 s:C=US, O=Google Trust Services, CN=WE1
   i:C=US, O=Google Trust Services LLC, CN=GTS Root R4
 2 s:C=US, O=Google Trust Services LLC, CN=GTS Root R4
   i:C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
$ openssl s_client -connect www.and.guide:443 -servername www.and.guide </dev/null 2>/dev/null | grep -E '^ *[0-9] s:|^ *i:'
 0 s:CN=and.guide
   i:C=US, O=Let's Encrypt, CN=YE2
 1 s:C=US, O=Let's Encrypt, CN=YE2
   i:C=US, O=ISRG, CN=Root YE
 2 s:C=US, O=ISRG, CN=Root YE
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
 3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1

The apex certificate comes from Google Trust Services (intermediate WE1), names only and.guide, and runs 90 days from 8 August to 6 November 2026; its chain ends at GTS Root R4 with a cross-certificate from GlobalSign Root CA. The www certificate comes from Let’s Encrypt (intermediate YE2), covers *.and.guide and and.guide, and runs 90 days from 6 September to 5 December 2026; its chain runs through ISRG Root YE and ISRG Root X2 to ISRG Root X1. Both leaf keys are ECDSA P-256. One registered domain, two issuers.

Live capture, 26 September 2026. The apex handshake:

$ openssl s_client -connect and.guide:443 -servername and.guide -alpn h2,http/1.1 </dev/null 2>/dev/null | grep -E '^New,|group|ALPN|Verify return'
Negotiated TLS1.3 group: X25519MLKEM768
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
ALPN protocol: h2
Verify return code: 0 (ok)

TLS 1.3, AES-256-GCM, HTTP/2 through ALPN, and the X25519MLKEM768 group: the hybrid key agreement Cloudflare documents as protection against harvest-now, decrypt-later attacks. That group depends on the client as much as the server. curl on the same machine, built against LibreSSL, negotiated plain X25519 (the kex= lines in the trace output further down).

Live capture, 26 September 2026. CAA at our name and at the TLD:

$ dig +nocmd +noall +answer +authority and.guide CAA @1.1.1.1
and.guide.		1800	IN	SOA	frida.ns.cloudflare.com. dns.cloudflare.com. 2414193944 10000 2400 604800 1800
$ dig +nocmd +noall +answer +authority guide CAA @1.1.1.1
guide.			3600	IN	SOA	v0n0.nic.guide. hostmaster.donuts.email. 1790433683 7200 900 1209600 3600

Both answers are empty except for an SOA. Under RFC 8659 a CA searches for CAA records from the requested name up toward the root, stopping before it, and is restricted only if it finds a record set. None exists at and.guide or guide, so any publicly trusted CA may issue for our apex or any name under it.

With two CAs already in use, a CAA policy has to authorize both. Cloudflare’s Pages documentation lists the CAs a custom domain needs (letsencrypt.org, pki.goog; cansignhttpexchanges=yes, and ssl.com), and its CAA documentation says Cloudflare automatically adds records for its own CAs when a zone using Universal SSL gets any CAA record. CAA Records and Let’s Encrypt walks through the inheritance rules.

What the HTML response carries

Live capture, 26 September 2026. Response headers for the home page, with the long report-to line trimmed:

$ curl -sI https://and.guide/
HTTP/2 200 
date: Sat, 26 Sep 2026 14:54:40 GMT
content-type: text/html; charset=utf-8
access-control-allow-origin: *
cache-control: public, max-age=0, must-revalidate
link: <https://and.guide/.well-known/api-catalog>; rel="api-catalog", <https://and.guide/docs/api/>; rel="service-doc", <https://and.guide/.well-known/openapi.json>; rel="service-desc"; type="application/vnd.oai.openapi+json;version=3.1", <https://and.guide/api/health>; rel="status"; type="application/json", <https://and.guide/.well-known/agent-skills/index.json>; rel="describedby"; type="application/json"
vary: Accept
referrer-policy: strict-origin-when-cross-origin
x-content-type-options: nosniff
...
nel: {"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}
server: cloudflare
cf-ray: a4131aed9d7fea24-ICN
alt-svc: h3=":443"; ma=86400

Reading top to bottom:

cache-control: public, max-age=0, must-revalidate makes browsers revalidate the HTML on every load.
access-control-allow-origin, referrer-policy, and x-content-type-options do not come from our code. Our Worker adds only link and vary, and our _headers file covers only /.well-known/ paths.
The link header advertises five machine-readable resources: an API catalog, API documentation, an OpenAPI description, a health endpoint, and an agent-skills index. All five returned 200 (capture below).
vary: Accept exists because the same URL also has a Markdown representation, covered below.
nel and the trimmed report-to configure network error reporting to a.nel.cloudflare.com.
cf-ray ends in ICN. Cloudflare documents that the Ray ID encodes the data center that handled the request; ICN is the airport code for Incheon, which serves Seoul.
alt-svc: h3=":443"; ma=86400 advertises HTTP/3 for 24 hours. We did not test an HTTP/3 connection, because this curl build has no HTTP/3 support.
Absent: strict-transport-security, content-security-policy, x-frame-options, and permissions-policy.

Live capture, 26 September 2026. The five Link targets, and the robots.txt line that states our content-use preferences:

$ for p in /.well-known/api-catalog /docs/api/ /.well-known/openapi.json /api/health /.well-known/agent-skills/index.json; do curl -s -o /dev/null -w "%{http_code} $p\n" "https://and.guide$p"; done
200 /.well-known/api-catalog
200 /docs/api/
200 /.well-known/openapi.json
200 /api/health
200 /.well-known/agent-skills/index.json
$ curl -s https://and.guide/robots.txt | grep -i '^content-signal'
Content-Signal: ai-train=no, search=yes, ai-input=no

Redirects: www, plain HTTP, and old URLs

Live capture, 26 September 2026. Plain HTTP on the apex, plain HTTP on www, and HTTPS on www, each with a path and query string:

$ curl -sI 'http://and.guide/about/?x=1' | grep -iE '^(HTTP|location)'
HTTP/1.1 301 Moved Permanently
Location: https://and.guide/about/?x=1
$ curl -sI 'http://www.and.guide/guides/?ref=test' | grep -iE '^(HTTP|location)'
HTTP/1.1 301 Moved Permanently
Location: https://and.guide/guides/?ref=test
$ curl -sI 'https://www.and.guide/guides/?ref=test' | grep -iE '^(HTTP|location|strict)'
HTTP/2 301 
location: https://and.guide/guides/?ref=test

Every non-canonical entry point reaches its final URL in one 301, with the path and query string intact. None of the redirects sends an HSTS header, matching the apex, which does not send one either. www or Apex? compares this single-hop pattern with how other large sites order their scheme and host redirects.

The www redirect is answered outside Korea

Live capture, 26 September 2026. Cloudflare’s trace endpoint on both hosts:

$ curl -s https://and.guide/cdn-cgi/trace | grep -E '^(h|colo|loc|http|tls|kex)='
h=and.guide
colo=ICN
http=http/2
loc=KR
tls=TLSv1.3
kex=X25519
$ curl -s https://www.and.guide/cdn-cgi/trace | grep -E '^(h|colo|loc|http|tls|kex)='
h=www.and.guide
colo=NRT
http=http/2
loc=KR
tls=TLSv1.3
kex=X25519

Live capture, 26 September 2026. Six Ray IDs from each host:

$ for i in 1 2 3 4 5 6; do curl -sI https://www.and.guide/ | grep -i '^cf-ray'; done
cf-ray: a4131a925af47231-HKG
cf-ray: a4131a936a72dd45-HKG
cf-ray: a4131a948c3f0705-HKG
cf-ray: a4131a959dca86e2-HKG
cf-ray: a4131a96ba458616-HKG
cf-ray: a4131a983c34259e-KIX
$ for i in 1 2 3 4 5 6; do curl -sI https://and.guide/ | grep -i '^cf-ray'; done
cf-ray: a4131a994a34ea14-ICN
cf-ray: a4131a99eca4ad77-ICN
cf-ray: a4131a9a9b17ea1d-ICN
cf-ray: a4131a9b3edf309d-ICN
cf-ray: a4131a9c0e6c7513-ICN
cf-ray: a4131a9cbc82d827-ICN

Across 13 samples per host between 14:40 and 14:55 UTC, the apex was answered from ICN every time. www was answered from HKG (Hong Kong) 11 times, NRT (Tokyo) once, and KIX (Osaka) once, and never from ICN. The two names resolve to different Cloudflare address sets, the most visible difference between them; we have not investigated Cloudflare’s routing beyond that.

Live capture, 26 September 2026. Timing three fresh requests to each host:

$ for u in https://and.guide/ https://www.and.guide/; do for i in 1 2 3; do curl -s -o /dev/null -w "$u %{http_code} connect=%{time_connect}s tls_done=%{time_appconnect}s total=%{time_total}s\n" $u; done; done
https://and.guide/ 200 connect=0.032660s tls_done=0.042922s total=0.071736s
https://and.guide/ 200 connect=0.010142s tls_done=0.028390s total=0.065388s
https://and.guide/ 200 connect=0.012296s tls_done=0.031574s total=0.065106s
https://www.and.guide/ 301 connect=0.051081s tls_done=0.109858s total=0.159238s
https://www.and.guide/ 301 connect=0.071642s tls_done=0.152492s total=0.220278s
https://www.and.guide/ 301 connect=0.041567s tls_done=0.095197s total=0.137479s

Across eight requests per host that day, the www redirect alone took 126–264 ms, while the complete apex home page took 61–76 ms. A reader who types www pays for a DNS lookup, TCP and TLS handshakes with a more distant data center, and a redirect before the real page starts loading. Keeping every link, sitemap entry, and canonical tag on the apex keeps that path rare.

Legacy URLs: 301 for moved posts, 410 for retired templates

Live capture, 26 September 2026. An old blog URL with and without its trailing slash, then a retired template path:

$ curl -sI https://and.guide/blog/posts/1/ | grep -iE '^(HTTP|location)'
HTTP/2 301 
location: /guides/subdomain-setup-guide/
$ curl -sI https://and.guide/blog/posts/1 | grep -iE '^(HTTP|location)'
HTTP/2 308 
location: /blog/posts/1/
$ curl -sI https://and.guide/system/ | grep -viE '^(report-to|nel):'
HTTP/2 410 
date: Sat, 26 Sep 2026 14:54:49 GMT
content-type: text/plain; charset=utf-8
cache-control: public, max-age=300
x-robots-tag: noindex, nofollow
server: cloudflare
cf-ray: a4131b249c0e74c5-ICN
alt-svc: h3=":443"; ma=86400

$ curl -s https://and.guide/system/
This retired template URL is gone.

/blog/posts/1/ returns a 301 with a relative Location pointing to the guide that replaced it, one line of our _redirects file. Cloudflare’s advanced-mode documentation says a _worker.js takes control of all incoming requests; ours has no rule for these paths and hands them to env.ASSETS.fetch(), so the 301 comes from the asset layer applying _redirects behind the Worker. Without the trailing slash, the same URL takes two hops: a 308 to the slashed path, which is not in our rules, and then our 301.

/system/ belongs to a retired template, and the Worker answers it with a 410, a five-minute cache lifetime, and X-Robots-Tag: noindex, nofollow. We use 301 where a page has a replacement and 410 where it has none.

The pages.dev hostname is a second copy

Live capture, 26 September 2026. The About page on the Pages project hostname:

$ curl -sI https://and-guide.pages.dev/about/ | grep -iE '^(HTTP|x-robots-tag)'
HTTP/2 200 
$ curl -s https://and-guide.pages.dev/about/ | grep -oE '<link[^>]*rel="canonical"[^>]*>'
<link rel="canonical" href="https://and.guide/about/">

and-guide.pages.dev served the home and About pages with a 200 and no x-robots-tag, a duplicate of the site whose Link headers even advertise pages.dev URLs. Only the rel="canonical" tag in each page ties it back to https://and.guide/.

One URL, two representations

Live capture, 26 September 2026. The About page requested as Markdown, its headers, the HTML headers for comparison, and a HEAD request:

$ curl -s -H 'Accept: text/markdown' https://and.guide/about/ | head -n 6
# About and.guide
> Learn who publishes and.guide, what the technical publication covers, and how its guides are sourced and corrected.
Original URL: https://and.guide/about/
Independent operator

# A focused publication about the infrastructure behind a public URL.
$ curl -s -D - -o /dev/null -H 'Accept: text/markdown' https://and.guide/about/ | grep -iE '^(HTTP|content-type|content-length|vary|content-signal|x-markdown-tokens)'
HTTP/2 200 
content-type: text/markdown; charset=utf-8
content-length: 2534
vary: Accept
content-signal: ai-train=no, search=yes, ai-input=no
x-markdown-tokens: 634
$ curl -s -D - -o /dev/null https://and.guide/about/ | grep -iE '^(HTTP|content-type|vary)'
HTTP/2 200 
content-type: text/html; charset=utf-8
vary: Accept
$ curl -sI -H 'Accept: text/markdown' https://and.guide/about/ | grep -iE '^(HTTP|content-type|x-markdown-tokens)'
HTTP/2 200 
content-type: text/markdown; charset=utf-8
x-markdown-tokens: 1

When the Accept header contains text/markdown, the Worker converts the page’s <main> element to Markdown, prepends the title, description, and original URL, and returns it with content-type: text/markdown, a token estimate (body length divided by four, rounded up: 2,534 becomes 634), and the same content-signal values our robots.txt carries. Both representations send vary: Accept. Under RFC 9110 that forbids a cache from reusing a stored response for a request with a different Accept value, so a cache that follows the rule will not hand the Markdown copy to a browser.

Two rough edges show. The converter is a set of regular expressions, so the output has two H1 headings and some stray spacing. And a HEAD request reports x-markdown-tokens: 1, because the Worker skips the conversion for HEAD and sends a placeholder.

The wildcard to our deployment server

Live capture, 26 September 2026. The wildcard record, two names nobody created, and what the server behind them returns over HTTP and HTTPS:

$ dig +nocmd +norec +noall +answer '*.and.guide' A @roan.ns.cloudflare.com
*.and.guide.		300	IN	A	115.68.101.36
$ dig +nocmd +noall +answer wwww.and.guide A @1.1.1.1
wwww.and.guide.		300	IN	A	115.68.101.36
$ dig +nocmd +noall +answer no-such-name-0926.and.guide A @1.1.1.1
no-such-name-0926.and.guide. 300 IN	A	115.68.101.36
$ dig +nocmd +noall +answer +authority no-such-name-0926.and.guide AAAA @1.1.1.1
and.guide.		1800	IN	SOA	frida.ns.cloudflare.com. dns.cloudflare.com. 2414193944 10000 2400 604800 1800
$ curl -sI http://no-such-name-0926.and.guide/ | head -n 1
HTTP/1.1 404 Not Found
$ curl -s http://no-such-name-0926.and.guide/
404 page not found
$ curl -sS -o /dev/null https://no-such-name-0926.and.guide/
curl: (60) SSL certificate problem: unable to get local issuer certificate
...
$ openssl s_client -connect no-such-name-0926.and.guide:443 -servername no-such-name-0926.and.guide </dev/null 2>/dev/null | grep -m1 'Verify return code'
Verify return code: 18 (self-signed certificate)
$ curl -skI https://no-such-name-0926.and.guide/ | head -n 1
HTTP/2 503 
$ curl -sk https://no-such-name-0926.and.guide/
no available server

*.and.guide is a deliberate DNS-only A record pointing to 115.68.101.36, our self-hosted deployment server for our own apps, which is separate from the Pages site. Because the record is a wildcard, a new app deployed there gets a working hostname without a DNS change. Names with records of their own, such as www, keep them; every other name resolves to the server, including the typo wwww.and.guide. The wildcard is IPv4-only: the AAAA query for the same name returns no data.

The server’s reverse proxy answers names it has no route for with a plain-text 404 page not found over HTTP. Over HTTPS it presents a self-signed default certificate (OpenSSL verify code 18), which curl refuses; with verification skipped, the response is a 503 reading no available server. The wildcard subdomains guide explains why DNS wildcards and certificate wildcards cover different sets of names.

What we would change, and what we learned

Nothing below had been changed when these captures were taken. They are conclusions from the captures above; the update note after the list records what has changed since.

Publish a CAA policy that matches reality. Authorize both issuers we observed, pki.goog for the apex and letsencrypt.org for www, plus ssl.com from the Pages list, after confirming which CA issues certificates for apps on the deployment server. We would list them explicitly rather than rely on Cloudflare’s automatic additions.
Add HSTS in stages. Start on the apex without includeSubDomains. Extending the policy to subdomains would also cover every name the wildcard answers, and unrouted names there present a self-signed certificate. HSTS preload and subdomains covers the trade-offs of each directive.
Look into the missing apex HTTPS record. Until the canonical host has one, ECH and DNS-based HTTP/3 discovery apply only to the redirect host.
Redirect and-guide.pages.dev, or decide not to. Cloudflare documents a Bulk Redirect that sends a project’s pages.dev hostname to its custom domain with path and query preserved. Today we rely on canonical tags alone.
Decide on DNSSEC deliberately. The TLD is signed and Cloudflare would sign our zone; the remaining step is a DS record at the registrar, plus a rollback plan.
Fix two small Worker details. Add slashless forms for legacy URLs that still receive links, and send a real token count on HEAD requests or omit the header.

Update, 27 September 2026. The site update that published this teardown addressed three items from point 4 and point 6. Every *.pages.dev hostname now receives X-Robots-Tag: noindex from the Worker; we chose that over a redirect so preview deployments keep working while search engines index only and.guide. The legacy blog URLs now have their own 301 rules without the trailing slash, and HEAD requests for Markdown no longer carry a placeholder token count. The other points stand as written.

The wildcard is a deliberate choice, and its trade-offs are known: every name under and.guide resolves, so a typo never produces NXDOMAIN, and a mistyped HTTPS URL meets a certificate warning instead of a clean error.

The broader lesson is that our canonical host and our redirect host run on different machinery. They resolve to different address sets, publish different DNS records, present certificates from different CAs, and were answered from data centers in different cities. A check that only looked at https://and.guide/ would have missed half of that.

How and.guide Is Served: A Teardown of Our Own Domain

In short

The request path at a glance

Delegation and DNSSEC: signed TLD, unsigned zone

The apex borrows the Pages project’s addresses

Two certificates from two CAs, and no CAA

What the HTML response carries

Redirects: www, plain HTTP, and old URLs

The www redirect is answered outside Korea

Legacy URLs: 301 for moved posts, 410 for retired templates

The pages.dev hostname is a second copy

One URL, two representations

The wildcard to our deployment server

What we would change, and what we learned

Sources

How this was tested

Spotted an error?

In short

The request path at a glance

Delegation and DNSSEC: signed TLD, unsigned zone

The apex borrows the Pages project’s addresses

Two certificates from two CAs, and no CAA

What the HTML response carries

Redirects: www, plain HTTP, and old URLs

The www redirect is answered outside Korea

Legacy URLs: 301 for moved posts, 410 for retired templates

The pages.dev hostname is a second copy

One URL, two representations

The wildcard to our deployment server

What we would change, and what we learned

Sources

How this was tested

Spotted an error?

Keep reading