امنیت، هویت، استقرار و تاب‌آوری · فصل ۴ — Linux/Windows، Container، DNS، CDN و Storage · 98

DNS, TLS, Reverse Proxy و HSTS

می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «DNS, TLS, Reverse Proxy و HSTS». می‌تواند برای «DNS, TLS, Reverse Proxy و HSTS» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.

خلاصهٔ درس

می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «DNS, TLS, Reverse Proxy و HSTS».

می‌تواند برای «DNS, TLS, Reverse Proxy و HSTS» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.

خروجی این درس

می‌تواند برای «DNS, TLS, Reverse Proxy و HSTS» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.

پیش‌نیازها

OPS-001 OPS-004

1. مسئله: «HTTPS باز می‌شود» یک مدرک لایه‌ای نیست

در یک سرویس وب، نام دامنه، پاسخ DNS، endpoint، اتصال TLS، هویت گواهی، route پراکسی، upstream و سیاست HSTS هرکدام یک لایه مستقل‌اند. ممکن است یک درخواست 200 بگیرد ولی به upstream اشتباه رسیده باشد، یا DNS درست resolve شود اما گواهی برای نام دیگری باشد.

خروجی مالک این درس Edge Request Trust Path Record v1 است. این رکورد به‌جای یک verdict مبهم، برای هر لایه observation، inference، unknown و recovery check را جدا ثبت می‌کند.

2. DNS پاسخ «کجا» را می‌دهد، نه «چه کسی» را

DNS نام را به داده‌هایی مانند address record نگاشت می‌کند. resolver می‌تواند پاسخ را از cache یا name server بگیرد. موفقیت resolution فقط می‌گوید برای آن نام یک پاسخ DNS به‌دست آمده است؛ هویت TLS، سلامت برنامه یا مجوز application را ثابت نمی‌کند.

در رکورد ابتدا hostname، answer و resolved endpoint را ثبت کن. سپس مستقل از آن سراغ TLS برو.

3. TTL مرز زمانی cache است

TTL یک حد زمانی برای نگهداری RR در cache است، نه یک تضمین دائمی درباره endpoint. وقتی TTL منقضی شده یا fixture نشان می‌دهد authoritative answer تغییر کرده، نتیجه قبلی را نباید بدون re-resolution ادامه داد.

در Lab، یک case پاسخ cache قدیمی و authoritative answer جدید دارد. تشخیص درست این است که DNS evidence نیازمند re-query است؛ نه اینکه بلافاصله TLS یا proxy را مقصر بدانیم.

4. TLS 1.3 مرجع جاری خود را دارد

در زمان این درس، RFC 9846 مرجع جاری IETF برای TLS 1.3 است و RFC 8446 را obsolete کرده است. TLS یک کانال محافظت‌شده میان endpointها ایجاد می‌کند، اما خودش همه semantics مربوط به application authorization یا correctness را تعیین نمی‌کند.

در evidence record نسخه TLS و نتیجه transport را ثبت کن، اما از آن نتیجه application-level نساز.

5. transport success با server identity یکی نیست

ممکن است handshake در fixture از نظر transport کامل شود ولی نام مورد انتظار با certificate-name evidence جور نباشد. بنابراین TLS_CONNECTED و SERVER_IDENTITY_MATCH دو نتیجه متفاوت‌اند.

در case mismatch، DNS resolution درست است و TLS transport برقرار می‌شود، ولی identity state باید mismatch بماند. این case دقیقاً shortcut «DNS و TLS سبز است، پس endpoint درست است» را رد می‌کند.

6. SNI و نام مورد انتظار بخشی از context هستند

برای سرویس‌های چندنامی، نامی که client برای connection در نظر دارد بر certificate selection و بررسی هویت اثر دارد. در این درس SNI و certificate-name evidence به‌عنوان fixture facts ثبت می‌شوند؛ هدف ساخت PKI یا CA نیست.

هر conclusion درباره identity باید به نام مورد انتظار و evidence همان connection متصل باشد.

7. Reverse proxy یک مرز route است

در NGINX، proxy_pass یک مکانیزم مشخص برای فرستادن request به upstream است و رفتار path/URI و headerها به configuration وابسته است. بنابراین موفقیت TLS هیچ اطلاعی درباره اینکه /api به upstream درست route شده یا نه نمی‌دهد.

رکورد باید Host/Path ورودی و upstream انتخاب‌شده را کنار هم نگه دارد.

8. 200 از upstream اشتباه هنوز failure است

فرض کن /api/orders باید به orders-service برسد اما rule اشتباه آن را به admin-service می‌فرستد و آن سرویس هم 200 پاسخ می‌دهد. اگر فقط status code را ببینی، failure پنهان می‌ماند.

در Lab، یک fixture دقیقاً همین وضعیت را دارد. proxy route state باید mismatch ثبت شود، حتی اگر transport و response status ظاهراً موفق باشند.

9. Forwarded context را با route evidence قاطی نکن

پراکسی ممکن است Host یا headerهای forwarding را تغییر یا اضافه کند. وجود یک header خاص به‌تنهایی proof route نیست؛ باید config intent و observed upstream را با هم مقایسه کرد.

این درس از headerها فقط به‌عنوان bounded fixture evidence استفاده می‌کند و ادعای universal reverse-proxy policy ندارد.

10. HSTS یک سیاست UA/server روی secure transport است

RFC 6797 سیاست HSTS را با Strict-Transport-Security تعریف می‌کند؛ header باید از پاسخ روی secure transport پردازش شود تا UA آن host را به‌عنوان HSTS host بشناسد.

پس دیدن همان header روی HTTP ناامن معادل ایجاد HSTS policy نیست. این تفاوت یک failure probe مستقل در Lab است.

11. HSTS جای TLS validation یا application security را نمی‌گیرد

HSTS می‌تواند user agent را برای host شناخته‌شده به secure transport محدود کند، اما phishing، malware، route اشتباه، گواهی نامعتبر یا authorization برنامه را به‌طور کلی حل نمی‌کند.

در رکورد، HSTS فقط یک layer state است؛ نه verdict نهایی امنیت.

12. Observation، inference و unknown را جدا نگه دار

DNS answer = 192.0.2.10 observation است. این endpoint سرویس درست است ممکن است inference باشد. TLS identity هنوز بررسی نشده یک unknown معتبر است.

Edge Request Trust Path Record برای هر لایه این سه دسته را جدا می‌کند تا یک موفقیت محلی به ادعای بیش‌ازحد تبدیل نشود.

13. Recovery باید دقیقاً همان لایه را دوباره اثبات کند

اگر TTL منقضی شده، re-query و مقایسه answer recovery evidence است. اگر certificate-name mismatch داری، اصلاح fixture identity و re-run همان check لازم است. اگر proxy route اشتباه است، route mapping را اصلاح کن و observed upstream را دوباره ببین.

Restart عمومی، پاک‌کردن بی‌دلیل cache یا تغییر همزمان چند لایه recovery proof قابل‌اعتماد نیست.

14. Lab و Transfer

Lab کاملاً offline و synthetic است. هشت fixture محلی شامل hostname، DNS answer/TTL، TLS version، certificate-name evidence، path/upstream mapping، response و HSTS transport هستند. هیچ public DNS، CA، production host یا network request خارجی لمس نمی‌شود.

Transfer hostname، TTL، TLS name، proxy path و upstream mapping را عوض می‌کند. همه هشت state باید از evidence جدید دوباره محاسبه شوند؛ هیچ verdict از baseline قابل کپی نیست.

15. منابع، freshness و مرز ادعا

برای این نسخه، RFC 1034/1035 فقط برای مدل پایه DNS و cache/TTL، RFC 9846 برای وضعیت جاری TLS 1.3، RFC 6797 برای HSTS و مستندات رسمی NGINX برای proxy_pass استفاده شده‌اند. NGINX به‌عنوان تنها reverse proxy معرفی نمی‌شود و RFCهای DNS به‌عنوان پوشش کامل همه extensionهای جدید DNS ارائه نمی‌شوند.

مرور بعدی منبع volatile مربوط به NGINX برای 2026-10-17 ثبت شده است. هر ادعای tool-specific زودتر از آن هم در صورت تغییر material مستندات باید requalify شود.

ارزیابی

پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.

OPS-005-S1 retrieval

State the bounded trust-path model and one non-goal.

lesson ✗AI ✗notes ✗

OPS-005-S2 application

Complete Edge Request Trust Path Record v1 for a supplied synthetic request using only direct fixture evidence.

lesson ✗AI ✗notes ✗

OPS-005-S3 diagnosis

Diagnose one changed DNS, certificate-name, proxy-route, or HSTS-transport fixture without blaming an unchanged layer.

lesson ✗AI ✗notes ✗

OPS-005-S4 decision

Choose a bounded recovery check for the failed layer and identify the shortcut you rejected.

lesson ✗AI ✗notes ✗

OPS-005-S5 transfer

Rebuild the record for a changed hostname, TTL, TLS name, path/upstream mapping and HSTS transport without copying baseline conclusions.

lesson ✗AI ✗notes ✗

ملاک‌های ارزیابی (rubric)

A sufficient submission must satisfy all critical dimensions:

Layer-model correctness — DNS, TTL/cache, TLS transport, server identity, proxy route, upstream response, and HSTS remain distinct.
Evidence quality — direct observations are traceable; inference and unknowns are labeled.
Scope discipline — no claim turns reverse proxy into CDN/WAF, TLS into application authorization, or HSTS into universal security.
Recovery proof — the selected failed layer is re-observed after a bounded repair.
Transfer independence — the changed-context case is recomputed from its own evidence.

Blocking failure occurs when a critical layer is collapsed into another, the final conclusion depends only on happy-path output, or transfer copies a baseline verdict.

منابع و تازگی

RFC 1034 — Domain Names: Concepts and Facilities

RFC 1035 — Domain Names: Implementation and Specification

RFC 9846 — The Transport Layer Security (TLS) Protocol Version 1.3

RFC 6797 — HTTP Strict Transport Security (HSTS)

NGINX ngx_http_proxy_module

MAKNOW instructional evidence design

مطالعهٔ موارد (case studies)

SIMPLE

DNS resolves expected endpoint, TLS 1.3 transport succeeds, certificate-name evidence matches, proxy routes the path to the intended upstream, and HSTS is observed on secure transport.

WRONG_APPROACH

Treat DNS success as proof of server identity; the certificate-name mismatch fixture falsifies the shortcut.

EDGE_OR_FAILURE

TLS and HTTP status succeed while proxy mapping selects the wrong upstream; route remains failed.

TRANSFER_NEAR

A second hostname, TTL, TLS name and path/upstream mapping requires a fresh evidence record.

تصاویر درس

OPS005-V1

فایل‌های آزمایشگاه

lab/OPS005-LAB1/learner/README.md

lab/OPS005-LAB1/learner/fixtures/cases.json

lab/OPS005-LAB1/learner/run_checks.py

lab/OPS005-LAB1/learner/starter.py

This lab is offline and synthetic. It does not modify public DNS, contact a certificate authority, probe a production host, or use credentials.

Inspect fixtures/cases.json.
Run python run_checks.py to verify fixture structure.
Implement analyze(case) in starter.py using only supplied evidence.
For each case, fill Edge Request Trust Path Record v1.
Keep DNS, TTL/cache, TLS transport, server identity, proxy route, upstream response, and HSTS policy separate.
For the transfer case, recompute every conclusion from changed evidence.

Do not infer a layer from another layer's success. A 200 response, DNS resolution, or TLS connection is never a universal proof token.