dns

Name: dns
Author: proyecto26

46installs1forks

How to install dns?

proyecto26/system-design-skills/dns

$npx -y skills add proyecto26/system-design-skills --skill dns

Installs into the current project.

Summary

This skill should be used when the user asks about "DNS", "domain resolution", "GeoDNS / geo routing", "latency-based routing", "weighted / failover routing", "Route 53 / Cloud DNS", an "A/CNAME/ALIAS record", "anycast", or "DNS TTL / propagation". It gives the global front door

Files · 1

View on GitHub

SKILL.md

1	# DNS
2
3	DNS is the global front door: it turns a name (`api.example.com`) into an address
4	before any request reaches your servers. It is also a routing layer — the same
5	lookup can hand different clients different answers (by region, latency, health,
6	or weight). Get it wrong and clients reach a dead region, fail over in minutes
7	instead of seconds, or cache a bad answer for hours. It is not a load balancer
8	and not a CDN; it decides which endpoint a client is told to use, not how bytes
9	are balanced inside that endpoint.
10
11	## When to reach for this
12	A service is reachable by a stable hostname; traffic must be steered to the
13	closest or healthiest region/data center; or an endpoint's IP can change (a new
14	load balancer, a failover site) and clients must follow without code changes.
15	Multi-region or multi-data-center designs need DNS to pick the entry point;
16	single-region designs still need it for a stable, movable name.
17
18	## When NOT to
19	Routing inside one region — that is a load balancer's job (→ `load-balancing`),
20	which reacts in milliseconds, not TTL-bound minutes. Fine-grained per-request or
21	session-aware steering — DNS answers per lookup, then the client caches it. Fast
22	failover with sub-second recovery — DNS failover is gated by TTL and resolver
23	caching; do not promise instant cutover from the name layer. And do not reach for
24	exotic routing policies before a number shows users are spread across regions
25	(YAGNI) — a single `A`/`ALIAS` record is the right default for one region.
26
27	## Clarify first
28	- Geographic spread — one region or many? Where are the users? (→ `requirements-scoping`)
29	- Failover target — recovery time objective for losing a region: seconds, or "a few minutes is fine"?
30	- How dynamic is the endpoint — fixed IPs, or an LB hostname that changes? (drives `A` vs `CNAME`/`ALIAS`)
31	- Steering goal — closest by latency, by user geography, by weight (canary/A-B), or just round-robin?
32	- Staleness tolerance for the mapping — how long can a client keep a stale answer? (sets the TTL → `back-of-the-envelope`)
33
34	## The options
35
36	Record type (what the name returns)
37	- `A` / `AAAA` — name → IPv4 / IPv6. Use when the endpoint has a stable IP.
38	- `CNAME` — name → another name. Use to alias onto a provider hostname; never at the zone apex (`example.com`).
39	- `ALIAS` / `ANAME` (provider-specific) — apex alias to a hostname. Use to point `example.com` at an LB/CDN hostname.
40	- `NS` / `MX` / `TXT` — delegation, mail, verification. Use as the domain requires; not traffic steering.
41
42	Routing policy (which answer a client gets)
43	- Simple — one answer for everyone. Use for a single endpoint.
44	- Weighted — split by percentage. Use for canary, A/B, or shifting between clusters.
45	- Latency-based — answer the region with lowest measured latency to the resolver. Use to minimize round-trip.
46	- Geolocation / GeoDNS — answer by the client's location (data residency, localized content). Use when geography, not latency, must decide.
47	- Failover — primary while healthy, else secondary. Use for active-passive DR.
48	- Multivalue — return several healthy IPs; client picks. Use for cheap client-side spread with health pruning.
49
50	Reachability
51	- Anycast — one IP advertised from many sites; the network routes to the nearest. Use for resolver/CDN front ends and DDoS resilience (concept lives in `content-delivery`).
52
53	## Trade-offs
54
55	\| Option \| What it solves \| What it worsens \| Change it when \|
56	\|---\|---\|---\|---\|
57	\| Simple `A`/`ALIAS` \| Trivial; one stable name \| No steering, no failover; SPOF if the IP dies \| Traffic spans regions or needs DR → weighted/latency/failover \|
58	\| Weighted \| Gradual shifts, canary, cluster balancing \| Manual/slow; not health-aware unless paired with checks \| You need automatic closeness → latency; or automatic cutover → failover \|
59	\| Latency-based \| Lowest RTT per user automatically \| Routes to resolver location, not user; needs per-region endpoints \| Data residency matters more than speed → geolocation \|
60	\| Geolocation \| Compliance, localized answers \| Misroutes via VPN/forwarding resolvers; coarse map \| Speed matters more than geography → latency-based \|
61	\| Failover \| Automatic active-passive cutover \| Recovery bounded by TTL + caching; cold standby risk \| RTO must be sub-second → in-region LB, not DNS \|
62	\| Anycast \| Nearest entry + absorbs DDoS \| Operationally heavy (BGP); flap on route

People who liked this also viewed

6 picks

Type

dns

46installs1forks

View on GitHub

How to install dns?

proyecto26/system-design-skills/dns

$npx -y skills add proyecto26/system-design-skills --skill dns

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# DNS
2
3	DNS is the global front door: it turns a name (`api.example.com`) into an address
4	before any request reaches your servers. It is also a routing layer — the same
5	lookup can hand different clients different answers (by region, latency, health,
6	or weight). Get it wrong and clients reach a dead region, fail over in minutes
7	instead of seconds, or cache a bad answer for hours. It is not a load balancer
8	and not a CDN; it decides which endpoint a client is told to use, not how bytes
9	are balanced inside that endpoint.
10
11	## When to reach for this
12	A service is reachable by a stable hostname; traffic must be steered to the
13	closest or healthiest region/data center; or an endpoint's IP can change (a new
14	load balancer, a failover site) and clients must follow without code changes.
15	Multi-region or multi-data-center designs need DNS to pick the entry point;
16	single-region designs still need it for a stable, movable name.
17
18	## When NOT to
19	Routing inside one region — that is a load balancer's job (→ `load-balancing`),
20	which reacts in milliseconds, not TTL-bound minutes. Fine-grained per-request or
21	session-aware steering — DNS answers per lookup, then the client caches it. Fast
22	failover with sub-second recovery — DNS failover is gated by TTL and resolver
23	caching; do not promise instant cutover from the name layer. And do not reach for
24	exotic routing policies before a number shows users are spread across regions
25	(YAGNI) — a single `A`/`ALIAS` record is the right default for one region.
26
27	## Clarify first
28	- Geographic spread — one region or many? Where are the users? (→ `requirements-scoping`)
29	- Failover target — recovery time objective for losing a region: seconds, or "a few minutes is fine"?
30	- How dynamic is the endpoint — fixed IPs, or an LB hostname that changes? (drives `A` vs `CNAME`/`ALIAS`)
31	- Steering goal — closest by latency, by user geography, by weight (canary/A-B), or just round-robin?
32	- Staleness tolerance for the mapping — how long can a client keep a stale answer? (sets the TTL → `back-of-the-envelope`)
33
34	## The options
35
36	Record type (what the name returns)
37	- `A` / `AAAA` — name → IPv4 / IPv6. Use when the endpoint has a stable IP.
38	- `CNAME` — name → another name. Use to alias onto a provider hostname; never at the zone apex (`example.com`).
39	- `ALIAS` / `ANAME` (provider-specific) — apex alias to a hostname. Use to point `example.com` at an LB/CDN hostname.
40	- `NS` / `MX` / `TXT` — delegation, mail, verification. Use as the domain requires; not traffic steering.
41
42	Routing policy (which answer a client gets)
43	- Simple — one answer for everyone. Use for a single endpoint.
44	- Weighted — split by percentage. Use for canary, A/B, or shifting between clusters.
45	- Latency-based — answer the region with lowest measured latency to the resolver. Use to minimize round-trip.
46	- Geolocation / GeoDNS — answer by the client's location (data residency, localized content). Use when geography, not latency, must decide.
47	- Failover — primary while healthy, else secondary. Use for active-passive DR.
48	- Multivalue — return several healthy IPs; client picks. Use for cheap client-side spread with health pruning.
49
50	Reachability
51	- Anycast — one IP advertised from many sites; the network routes to the nearest. Use for resolver/CDN front ends and DDoS resilience (concept lives in `content-delivery`).
52
53	## Trade-offs
54
55	\| Option \| What it solves \| What it worsens \| Change it when \|
56	\|---\|---\|---\|---\|
57	\| Simple `A`/`ALIAS` \| Trivial; one stable name \| No steering, no failover; SPOF if the IP dies \| Traffic spans regions or needs DR → weighted/latency/failover \|
58	\| Weighted \| Gradual shifts, canary, cluster balancing \| Manual/slow; not health-aware unless paired with checks \| You need automatic closeness → latency; or automatic cutover → failover \|
59	\| Latency-based \| Lowest RTT per user automatically \| Routes to resolver location, not user; needs per-region endpoints \| Data residency matters more than speed → geolocation \|
60	\| Geolocation \| Compliance, localized answers \| Misroutes via VPN/forwarding resolvers; coarse map \| Speed matters more than geography → latency-based \|
61	\| Failover \| Automatic active-passive cutover \| Recovery bounded by TTL + caching; cold standby risk \| RTO must be sub-second → in-region LB, not DNS \|
62	\| Anycast \| Nearest entry + absorbs DDoS \| Operationally heavy (BGP); flap on route

People who liked this also viewed

6 picks

Type