Name Services

1Naming: ทำไมต้องมีชั้นของ "ชื่อ" คั่นระหว่างผู้ใช้กับที่อยู่จริง

ถ้าไม่มีชั้นนี้ ทุกครั้งที่ server ย้าย IP โปรแกรมทุกตัวที่อ้างอิงถึง server นั้นต้องแก้โค้ดใหม่ทั้งหมด — Name Service ทำให้การเปลี่ยนแปลงที่อยู่จริงไม่กระทบผู้ใช้ปลายทาง

2DNS: Domain Name System

Zone และ Resource Record

Zone คือส่วนของ namespace ที่ name server กลุ่มหนึ่งรับผิดชอบดูแลข้อมูลโดยตรง แต่ละ zone เก็บข้อมูลเป็น resource record:

กระบวนการ Resolve ชื่อ (Name Resolution)

Client ถาม: dns0.dcs.qmul.ac.uk คือ IP อะไร?

1. Local resolver ถาม root name server
   root -> "ไม่รู้ แต่ .uk ให้ไปถามที่ ns.uk"
2. ถาม name server ของ .uk
   .uk -> "ไม่รู้ แต่ ac.uk ให้ไปถามที่ ns.ac.uk"
3. ถาม name server ของ ac.uk
   ac.uk -> "ไม่รู้ แต่ qmul.ac.uk ให้ไปถามที่ dns0.dcs.qmul.ac.uk"
4. ถาม name server ของ qmul.ac.uk
   qmul.ac.uk -> "dns0.dcs.qmul.ac.uk = 138.37.88.249"

3Directory Service: X.500 และ LDAP

LDAP (Lightweight Directory Access Protocol) เป็น protocol ที่ใช้เข้าถึง directory service แบบ X.500 ได้ง่ายกว่าเดิม — ปัจจุบันเป็นฐานของระบบ authentication องค์กรจำนวนมาก เช่น Microsoft Active Directory

4ทันสมัย: จาก DNS สู่ Service Discovery ยุค Microservices

DNS แก้ปัญหา "หา server ที่อยู่ตำแหน่งค่อนข้างคงที่" ได้ดี แต่ในระบบ microservices ที่ container ถูกสร้าง/ทำลาย/ย้ายตำแหน่งตลอดเวลา (scale in/out บ่อยเป็นวินาที) ต้องการ name service ที่อัปเดตเร็วกว่าและผูกกับ health check โดยตรง

5Name, Identifier, Address และ Attribute ไม่ใช่คำเดียวกัน

เรามักพูดว่า “ชื่อเครื่อง” แล้วรวมหลายแนวคิดไว้ด้วยกัน Naming ที่ดีเริ่มจากแยกสิ่งที่คงตัวออกจากสิ่งที่เปลี่ยนตามตำแหน่ง Name ใช้อ้างถึง entity ตามกติกาหนึ่ง Identifier มีเป้าหมายให้ชี้ entity เดียวและไม่ถูกนำกลับใช้สับสน Address บอกวิธี/ตำแหน่งเข้าถึง ณ ช่วงหนึ่ง ส่วน Attribute บรรยายคุณสมบัติให้ค้นหา

Pure name และ Impure name

Pure name ไม่ฝัง location เช่น UUID ต้อง resolve ผ่านบริการอื่น ส่วน impure name มีข้อมูลตำแหน่งอยู่ในชื่อ เช่น URL ที่มี host/path ทำให้ route ง่ายแต่ย้ายแล้วต้องรักษา redirect/compatibility ไม่มีแบบใดดีที่สุดเสมอ Pure name เพิ่ม indirection ส่วน impure name ลด lookup แต่ coupling กับ topology สูงขึ้น

Binding และ Binding Lifetime

Binding คือความสัมพันธ์ name→entity/address และมี lifetime ต่างกัน DNS record อาจอยู่หลายชั่วโมง service instance อาจอยู่ไม่กี่นาที session binding อาจอยู่ตลอด connection การเลือก TTL/lease ต้องสัมพันธ์กับอายุจริง ถ้า cache นานกว่า entity มาก stale mapping จะสูง ถ้าสั้นเกิน lookup load เพิ่มและระบบพึ่ง naming service มากขึ้น

6Namespace คือโครงสร้าง ไม่ใช่เพียงรายการชื่อ

Flat namespace เช่น UUID กระจายการสร้างง่ายและไม่ต้องรู้ hierarchy แต่ค้นด้วยมนุษย์ยาก Hierarchical namespace เช่น DNS/path แบ่ง authority และ resolution ตามส่วนของชื่อได้ ช่วย scale การบริหาร แต่ rename/move ข้าม subtree มีความหมายและ policy ตามมา

Context และ Relative Name

ชื่อ printer มีความหมายเมื่อรู้ context ว่าอยู่ office/domain ใด เช่นเดียวกับ relative file path หรือ Kubernetes short service name Context ลดความยาวแต่สร้าง ambiguity และ portability problem การ debug ควรบันทึก fully qualified/canonical name เพราะชื่อสั้นเดียวกัน resolve ต่างกันตาม namespace/search path

Alias, Canonical Name และ Symbolic Link

หลายชื่อชี้ entity เดียวได้เพื่อ migration, brand หรือ convenience แต่ alias chain ยาวทำ resolution ช้าและเกิด loop ได้ Name service ต้องตรวจ cycle/limit depth และกำหนดว่า metadata/permission ติดที่ alias หรือ target การลบ target อาจทำ dangling reference

7Resolution: การตามชื่อทีละช่วง

Resolution แปลง name ไปเป็น object/address บางระบบ iterative คือ resolver ถาม server ทีละระดับ บางระบบ recursive คือ server รับภาระถามต่อแล้วคืนผลสุดท้าย ความต่างมีผลต่อ load, cache, privacy และ failure path

Client → Recursive Resolver → Root → TLD → Authoritative Server
                    ↘ cache answer / negative answer

Client-side, Server-side และ Proxy-based Discovery

Client-side discovery ให้ client ถาม registry และเลือก instanceเอง ประสิทธิภาพดีแต่ library หลายภาษาต้องรองรับ policy Server-side discovery ให้ load balancer/router resolve แทน client ง่ายแต่เพิ่ม hop/ศูนย์กลาง Proxy/sidecar ทำ discovery ใกล้ process และใช้ policyร่วม แต่เพิ่ม operational complexity

8DNS แบบลงลึก: ระบบชื่อที่เป็น Distributed System ด้วยตัวเอง

DNS scale ได้เพราะ hierarchy, delegation, caching และ replication Root ไม่เก็บทุก hostname แต่ชี้ authority ของ TLD จากนั้น authoritative server ของ zone ให้ record จริง การแบ่ง authority ทำให้องค์กรดูแล subtree ของตนโดยไม่ต้องมีฐานกลางตัวเดียว

TTL คือข้อตกลงเรื่องความเก่า

TTL ไม่ได้บอกว่า record จะถูกลบพร้อมกันทั่วโลกเมื่อครบเวลา มันบอก cache ว่าเก็บ answer ได้นานเท่าใด Resolver ที่ถามคนละเวลาจึงหมดอายุคนละเวลา ระหว่างเปลี่ยน record โลกจะเห็นทั้งค่าเก่าและใหม่พร้อมกันตามธรรมชาติ

ก่อน migration มักลด TTL ล่วงหน้าอย่างน้อยหนึ่ง TTL เดิม รอ cache เก่าหมด แล้วจึงเปลี่ยน address หลังระบบใหม่เสถียรค่อยเพิ่ม TTL หากลดตอนเปลี่ยนทันที cache ที่ถือค่าเก่าไม่เห็น TTL ใหม่และยังเก็บต่อจนหมดของเดิม

Negative Caching

NXDOMAIN และผลไม่พบก็ถูก cache ได้ ถ้าถามชื่อก่อนสร้าง record แล้วรีบทดสอบใหม่ อาจยังเห็นไม่พบจาก negative cache การตั้งค่า SOA และ resolver policy มีผล จึงต้องแยก “authoritative ไม่มี record” จาก “resolver cache คำตอบเก่า”

DNS Consistency และ Failover

DNS เหมาะกับ mapping ที่เปลี่ยนไม่ถี่มาก ไม่ใช่ health checker ระดับ request DNS failover มี propagation/cache และ client อาจ reuse connection เก่า แม้ resolver ได้ IP ใหม่ การเปลี่ยน record จึงไม่เท่ากับ traffic ย้ายทันที ระบบมักใช้ load balancer/anycast/application retry ร่วม

9ความปลอดภัยของ Naming

ถ้าผู้โจมตีเปลี่ยน binding ได้ เขาไม่ต้องเจาะ service จริง เพียงพาผู้ใช้ไป service ปลอม Threat ได้แก่ spoofing, cache poisoning, registrar/account takeover, malicious registry entry และ stale certificate

Naming กับ authentication จึงเชื่อมกัน ชื่อพาไป endpoint แต่ TLS/identity บอกว่า endpoint ที่พบเป็นฝ่ายที่ตั้งใจหรือไม่ การใช้ IP ตรงอาจ bypass name แต่สร้างปัญหา SNI/certificate และทำลาย location transparency

10Directory Service: ค้นจาก Attribute ไม่ใช่รู้ชื่อก่อน

Name service ตอบจากชื่อไป object ส่วน directory service ช่วยค้น object ที่มี attribute ตรงเงื่อนไข เช่นพนักงานแผนกหนึ่ง เครื่องพิมพ์ชั้นหนึ่ง หรือ service ที่มี version/region เฉพาะ LDAP จัด entry เป็น tree มี Distinguished Name และ attribute ตาม schema

Index และ Query Cost

การค้น attribute ต้องมี index หากเปิด query กว้างหรือ filter ซับซ้อน directory อาจกลายเป็นคอขวด ต้องกำหนด schema/index, pagination, limit และ authorization เพราะ attribute บางชนิดเป็นข้อมูลส่วนตัว Search result ที่ cache ได้ต้องมี invalidation/TTL เช่นกัน

11Service Discovery ในโลก Container

Container/instance เกิดและหายบ่อย IP เป็น ephemeral จึงเรียกผ่าน service identity แล้ว resolve ไป endpoint set Control plane รับ registration/health แล้ว data plane เลือกปลายทาง Kubernetes ใช้ Service/DNS และ endpoint abstraction ขณะที่ Consul/etcd/ZooKeeper ใช้แนวคิด registry/coordinationต่างกัน

Health Check ไม่ใช่ Truth Oracle

Probe ผ่านบอกว่าเส้นทาง probe ทำงาน ไม่ได้พิสูจน์ทุก operation; probe ไม่ผ่านอาจเกิดจาก overload ชั่วคราว ถ้าถอด endpoint พร้อมกันมากเกิน traffic ไปกองที่เหลือจนล้มต่อ ระบบต้องตั้ง threshold, consecutive failure, passive signal และ load shedding อย่างระวัง

Stale Endpoint และ Connection Pool

แม้ registry อัปเดตแล้ว client อาจ cache endpoint หรือมี connection pool ค้าง ต้องมี TTL/watch, connection max age, retry ที่ปลอดภัย และ server draining Naming update เป็นเพียงส่วนหนึ่งของ lifecycle ไม่ใช่ปุ่มย้าย traffic ทันที

12Consistent Hashing และ Naming ของ Data Partition

เมื่อต้อง map key ไป node การใช้ hash(key) % N ทำให้ key ส่วนใหญ่ย้ายเมื่อ N เปลี่ยน Consistent hashing จัด node/key บนวงแหวน เมื่อเพิ่ม node จะย้ายเฉพาะช่วงใกล้เคียง ใช้ virtual node เพื่อกระจาย load และรองรับ capacity ต่างกัน

นี่คือนามบัญญัติอีกรูปแบบ: key ถูก resolve ไป owner/replica set แต่ membership เปลี่ยนได้ ต้องมี version ของ ring, handoff และวิธีจัด request ที่ใช้ topology เก่า หาก client-side routing cache stale ต้อง redirect หรือ proxy ไป owner ใหม่

13Content Addressing: เมื่อชื่อมาจากข้อมูล

Content-addressed name เป็น hash ของ content เช่น blob store หรือ Merkle DAG ถ้าข้อมูลเปลี่ยน hash เปลี่ยน ข้อดีคือ deduplication และตรวจ integrity ได้ แต่ mutable “ไฟล์ล่าสุด” ต้องมี pointer/name อีกชั้นที่เปลี่ยนไป hash ใหม่ ดังนั้น content addressing ไม่ลบ naming problem มันแยก immutable identity ออกจาก mutable reference ชัดขึ้น

การ deploy ด้วย mutable tag อาจทำให้เครื่องคนละตัวได้ content ต่างกันแม้ชื่อเดียวกัน งานที่ต้อง reproducible ควร pin digest แล้วใช้ tag เพื่อ discovery/ความสะดวกเท่านั้น

14Failure Modes ของ Name Service

คำว่า “DNS มีปัญหา” ควรใช้เมื่อมีหลักฐานที่ naming/resolution ไม่ใช่เมื่อเรียกเว็บไม่ได้ทุกชนิด DNS เป็นขั้นหนึ่งของเส้นทาง ถ้า resolve สำเร็จแต่ TCP timeout การแก้ record อาจไม่ตรงชั้น

15Workshop: ติดตามชื่อหนึ่งชื่อจนถึง Instance

1. เลือก domain/service ในระบบทดลอง บันทึก canonical name, record, TTL และ authoritative server
2. ใช้ dig/nslookup เปรียบเทียบ recursive resolver สองตัวและ authoritative answer
3. เปลี่ยน record หลังลด TTL ตามขั้นตอน สังเกตช่วงที่ค่าเก่า/ใหม่อยู่พร้อมกัน
4. สร้าง negative cache โดยถามชื่อก่อนสร้าง record แล้ววัดเวลาที่เห็นชื่อใหม่
5. ใน container cluster scale service จาก 1 เป็น 3 instance ดู endpoint set และ connection reuse
6. ทำ instance ไม่ ready แล้ววัดเวลาจาก probe fail ถึงหยุดรับ traffic
7. ใช้ TLS ตรวจว่า hostname, SNI และ certificateสัมพันธ์กันอย่างไร
8. เขียน resolution timeline ตั้งแต่ application cache, OS, recursive resolver, authoritative, LB จนถึง instance

16แนวทางออกแบบ Naming อย่างมีขอบเขต

1. แยก logical identity จาก locator ที่เปลี่ยนได้
2. กำหนด owner/authority ของ namespace และสิทธิ์เปลี่ยน binding
3. เลือก TTL/lease จาก change rate, failure goal และ lookup capacity
4. รองรับ version เก่า–ใหม่และช่วง rollout ไม่สมมุติ update พร้อมกัน
5. ออกแบบ stale mapping: retry, redirect, drain หรือ reject แบบใด
6. ผูก naming กับ authentication ไม่เชื่อ endpoint เพราะ resolve ได้อย่างเดียว
7. เก็บ metric ของ lookup latency, cache hit, stale endpoint และ registration churn
8. มี emergency process ที่ปลอดภัย ไม่ให้การแก้ DNS เร่งด่วนกลายเป็น outage ซ้ำ

17ทบทวนแกนสำคัญก่อนกรณีศึกษา

Name Services สร้าง indirection ระหว่างสิ่งที่เราอยากอ้างถึงกับตำแหน่งที่ติดต่อได้ ทำให้ service ย้าย ทำสำเนา และ failover โดย client ไม่ผูก IP แต่ indirection นี้มี cache, TTL, authority และ security เป็น distributed consistency problem ของตัวเอง

หลักสำคัญคือชื่อไม่เท่ากับ identity และ identity ไม่เท่ากับ address DNS scale ด้วย hierarchy/delegation/caching จึงยอมให้คำตอบเก่า–ใหม่อยู่พร้อมกันชั่วคราว Service discovery เพิ่ม health และ membership แต่ health check ไม่ใช่ความจริงสมบูรณ์ และ registry update ไม่ได้ยกเลิก connection เก่าทันที

ขั้นตอนถัดไปคือ Time & Global States เมื่อ resolve จนพบ process หลายตัวแล้ว เรายังต้องตอบว่าเหตุการณ์ใดเกิดก่อนกัน และจะสร้างภาพรวมของระบบอย่างไรทั้งที่ไม่มีนาฬิกากลาง Naming ช่วยบอกว่า “ใคร” ส่วน logical time จะช่วยอธิบายว่า “อะไรมีเหตุเป็นผลต่ออะไร”

18กรณีศึกษา: ย้าย API โดยไม่หยุดบริการ

ระบบเดิมชี้ api.example.com ไป Load Balancer A ต้องย้ายไป B หากเปลี่ยน A record ทันที client บางส่วนยัง cache A ตาม TTL เดิม บางส่วน resolve B แล้ว และบางส่วนใช้ connection keep-alive ไป A ต่อ การ migration จึงต้องรองรับ coexistence ไม่ใช่คิดว่าคำสั่งแก้ DNS เป็นเส้นแบ่งเวลาเดียวทั่วโลก

1. เตรียม B ให้รับ contract เดิมและตรวจ health/TLS ก่อนรับ traffic
2. ลด TTL ล่วงหน้าหนึ่งช่วง TTL เดิม ไม่ใช่ลดตอนเปลี่ยน
3. route traffic ส่วนน้อยด้วย LB/weight ถ้ามี แล้วเปรียบเทียบ metric
4. เปลี่ยน DNS และรักษา A ให้ทำงานตลอด stale window
5. drain A: หยุด connection ใหม่แต่รอ in-flight/keep-alive
6. ตรวจ resolver หลายจุด, traffic จริง และ certificate/SNI
7. ยกเลิก A หลังไม่มี traffic ตามเกณฑ์ ไม่ใช่เพียง TTL ผ่านหนึ่งรอบ

19กรณีศึกษา: Service Discovery ระหว่าง Rolling Deployment

Service v1 และ v2 ทำงานพร้อมกัน Registry อาจมี endpoint ทั้งสอง หาก contract เปลี่ยนแบบ incompatible client เก่าอาจถูกส่งไป v2 แล้วพัง การมีชื่อ service เดียวจึงต้องรักษา backward compatibility หรือแยก version identity/route ชัด

Readiness ควรเป็น false ก่อนรับ traffic และก่อน shutdown แต่ propagation ไม่ทันที Client cache กับ sidecar watch มี delay จึงต้องมี grace period ระบบใหม่ควรทน request ที่เริ่มก่อนถอด endpoint และระบบเก่าควรอยู่จน traffic จริงหมด

20Split-Horizon DNS และชื่อเดียวที่ตอบไม่เหมือนกัน

องค์กรอาจให้ชื่อเดียว resolve private IP ภายในและ public IP ภายนอก เรียก split-horizon/split DNS ช่วย route/security แต่ debug ยาก เพราะคำตอบขึ้นกับ resolver, VPN และ location ผู้ใช้สองคนพิมพ์คำสั่งเดียวกันได้ผลต่างกันโดยทั้งคู่ถูกตาม policy

ควรบันทึก resolver ที่ใช้, source network, full response และ search suffix ไม่ส่งเพียงภาพว่า “เครื่องฉันได้ IP นี้” Container อาจใช้ DNS config ต่างจาก host และ browser อาจใช้ DoH ต่าง resolver ของ OS ทำให้ nslookup กับ browserเห็นไม่เหมือนกัน

Search Domain กับชื่อสั้น

ชื่อ db อาจถูกลองเป็น db.team.svc, db.svc ตาม search list การใช้ชื่อสั้นข้าม namespace เสี่ยงชนและ query leak ออก public resolver ควรใช้ FQDN ใน config ที่ต้องแน่นอน และเข้าใจ ndots/resolver behavior ใน cluster

21Naming กับ Multi-Tenancy

Namespace ต้องกัน tenant ไม่ให้เดาหรือชนชื่อกัน ชื่อที่ unique ภายใน tenant อาจไม่ unique ทั้งระบบ ต้องใส่ scope ใน canonical ID, authorization และ cache key มิฉะนั้นข้อมูล tenant A อาจถูกคืนให้ B จาก cache ที่ key ขาด tenant

22การนำชื่อกลับมาใช้ใหม่และ ABA Problem

ถ้าลบ object ID 7 แล้วสร้าง object ใหม่ใช้ ID 7 client ที่ cache reference เก่าอาจเข้าถึงของใหม่โดยเข้าใจว่าเป็นของเดิม เรียกปัญหาแบบ ABA: ค่าเหมือนกลับมา A แต่ identity เปลี่ยน Generation/epoch หรือ globally unique ID ป้องกัน stale reference สับสน

ชื่อมนุษย์อาจ reuse ได้ เช่น username/domain แต่ต้องมี quarantine, ownership verification และ invalidate credential/session/reference เก่า ไม่ควรใช้ display name เป็น immutable identity ใน foreign key/audit

23Workshop เพิ่มเติม: สร้าง Name Service ขนาดเล็ก

สร้าง registry API ที่มี register(name, endpoint, lease), renew, resolve, deregister และ watch change จากนั้นทดลอง:

1. endpoint สองตัว register ชื่อเดียวและ resolve เป็นชุด
2. หยุด renew หนึ่งตัว ตรวจ lease expiry และ stale window
3. ทำ watcher disconnect แล้ว reconnect ด้วย revision เก่า
4. compact history แล้วบังคับ client full resync
5. ใส่ epoch ป้องกัน instance เก่ากลับ renew หลัง replacement
6. ทำ registry leader failover และตรวจ binding durability
7. cache ฝั่ง client แล้ววัด lookup load เทียบ staleness
8. เพิ่ม mTLS/credential ป้องกัน service ปลอมลงทะเบียน

24Checklist และคำถามทบทวน

• ชื่อมี scope และ canonical form ชัดหรือไม่
• logical identity แยกจาก endpoint/address หรือยัง
• authority ของแต่ละ subtree/binding คือใคร
• TTL/lease สัมพันธ์กับ change rate และ failover goal หรือไม่
• client ทำอย่างไรเมื่อ mapping stale หรือมี endpoint หลายตัว
• มี generation ป้องกัน ID reuse/stale handle หรือไม่
• rename/delete/reuse มีผลต่อ cache, permission และ audit อย่างไร
• ชื่อ resolve ได้แล้วตรวจ identity ของ endpoint ต่ออย่างไร
• rolling version อยู่ร่วมกันโดยชื่อเดียวได้หรือควรแยก
• monitor NXDOMAIN, SERVFAIL, latency, cache hit และ registration churn หรือไม่

1. เหตุใด TTL ต่ำไม่ได้ทำให้ failover ทันทีเสมอ
2. name service กับ directory service ต่างกันตรง input/output อย่างไร
3. content hash เป็น identifier ที่ดี แต่เหตุใดยังต้อง mutable name อีกชั้น
4. service registry ที่ health check ผ่านรับประกันอะไรและไม่รับประกันอะไร
5. DNSSEC, DoH และ TLS แก้คนละ threat อย่างไร
6. client-side discovery กับ server-side discovery ย้าย complexity ไปที่ใคร

25คำศัพท์ Naming ที่มักใช้แทนกันจนระบบสับสน

คำถามสถานการณ์

1. ถ้า service name resolve เป็น endpoint สามตัว แต่หนึ่งตัว overload ระบบเลือกจาก naming หรือ load signal ที่ไหน
2. ถ้า registry partition instance ยังต่อได้กับ client บางส่วน ควรถอดเมื่อ lease หมดหรือคง availability แล้วเสี่ยง stale membership
3. ถ้าชื่อเดิมถูก reuse ให้ tenant ใหม่ token/link เก่าจะเข้าถึงผิด tenant หรือไม่
4. ถ้า DNS ตอบสอง IP แต่ certificate รองรับชื่อเดียว เหตุใดการใช้ IP ตรงเพื่อ debug จึงอาจได้ผลต่าง
5. ถ้า authoritative record ใหม่แต่ผู้ใช้ยังเห็นเก่า ต้องตรวจ cache/connection ชั้นใดก่อนกล่าวว่า propagation ผิด

บทเรียนของ naming คือ indirection ให้ความยืดหยุ่น แต่ทุก indirection ต้องมี authority, consistency และ expiry การเพิ่มชื่ออีกชั้นไม่ได้ลบตำแหน่ง มันย้ายการตัดสินว่าตำแหน่งปัจจุบันคืออะไรไปไว้ใน resolver/registry ซึ่งเองก็เป็น distributed system ที่ล้มและมีข้อมูลเก่าได้

26Design Review: ตาม Binding ตั้งแต่สร้างจนหมดอายุ

เลือกชื่อหนึ่งชื่อแล้วเขียน lifecycle: ใครสร้าง ใครอนุมัติ เก็บที่ authoritative source ใด cache ที่ไหน เปลี่ยนอย่างไร revoke/expire เมื่อใด และ reuse ได้หรือไม่ หากตอบไม่ได้ การมี DNS/registry ที่ availability สูงก็ยังไม่ทำให้ naming ถูกต้อง

ควรแยก control-plane availability จาก data-plane continuity ถ้า registry ล่ม client ที่มี cache อาจคุย endpoint เดิมต่อได้ จึงไม่ควรทำ cache หมดพร้อมกันทั้งหมด แต่ถ้า endpoint ถูก revoke ด้วยเหตุ security cache ยาวกลับอันตราย งานแต่ละชนิดอาจต้อง TTL และ revocation channel ต่างกัน

อีกคำถามคือชื่อเปิดเผย topology/ข้อมูลลับหรือไม่ Hostname ที่ฝัง customer, environment หรือ internal role อาจรั่วผ่าน certificate/log DNS ชื่อที่อ่านง่ายมีประโยชน์ต่อ operations แต่ควรกำหนดข้อมูลที่อนุญาตและใช้ opaque ID เมื่อ identity ถูกเผยแพร่กว้าง

เกณฑ์ว่าระบบ Naming พร้อมหรือยัง

ต้องซ้อม authoritative/registry unavailable, stale cache, endpoint ตาย, certificate mismatch และการ reuse identity ไม่ใช่ทดสอบเพียง resolve ปกติ Dashboard ควรแยก lookup failure จาก connect/TLS/application failure เพื่อไม่ให้ทุก outage ถูกเรียกว่า DNS

Runbook ต้องบอก authority ที่แก้ได้ วิธีลด TTL ล่วงหน้า วิธี rollback และระยะที่ต้องรักษาปลายทางเก่า หากการแก้ฉุกเฉินต้องให้คนหนึ่งใช้ credential ส่วนตัวเปลี่ยน production record โดยไม่มี audit นั่นคือ naming governance failure แม้ DNS server จะ uptime 100% ก็ตาม

ชื่อที่ดีจึงต้องมีทั้งความหมาย ขอบเขต เจ้าของ และอายุ ไม่ใช่เพียงสะกดได้ถูกต้อง

27สรุปและขั้นตอนถัดไป

Naming สร้าง indirection ระหว่าง identity กับ locator ทำให้ entity ย้าย ทำสำเนา และเปลี่ยน endpoint โดยผู้ใช้ยังอ้างชื่อเดิมได้ แต่ binding มี authority, version, cache และ lifetime จึงไม่มีการเปลี่ยนชื่อที่ทุกคนเห็นพร้อมกันโดยธรรมชาติ

DNS แสดงว่า hierarchy, delegation และ caching ทำให้ระบบชื่อระดับโลก scale ได้ โดยแลกกับ stale answer และการเปลี่ยนแบบค่อยเป็นค่อยไป Service discovery เพิ่ม membership/health/lease แต่ไม่ได้ควบคุม connection เก่าหรือพิสูจน์ว่า process ตาย ส่วน content addressing ให้ immutable identity ของข้อมูล แต่ยังต้องมี mutable reference สำหรับคำว่า “รุ่นล่าสุด”

ขั้นตอนถัดไปคือ Time & Global States หลังรู้ว่า entity ใดอยู่ที่ไหน เรายังต้องอธิบายว่าเหตุการณ์ใดเกิดก่อนและ process แต่ละตัวรู้ถึงไหน Physical timestamp เพียงอย่างเดียวไม่พอ จึงต้องใช้ logical clock, causality และ snapshot สร้างภาพรวมที่สอดคล้อง