4SODEEP TECH
FAENAR
اختر منتجًا
تدفّق 4SO GeoDNS: مراقبة الحركة، فهم الطوبولوجيا، الإجابة وفق السياسة، مراقبة السلامة، تحسين القرارات.

AUTHORITATIVE DNS / GLOBAL TRAFFIC

4SO GeoDNSمستوى تحكم لـ DNS مع مسار خدمة مستقل

تجتمع إدارة API-first للحالة المطلوبة في DNS وValidation وImmutable Revision وBlue/Green Delivery وHealth-aware Routing وDNSSEC ودورة حياة العقد في عملية واحدة، بينما يبقى Query Path مستقلاً عن Manager.

Authoritative DNSGlobal TrafficDNSSECBlue / Green
PDFتنزيل الكتيب التقنيكتيب تقني من 12 صفحة (بالفارسية)↓

مكوّنات 4SO GeoDNS: مسار الاستعلام مستقل عن مسار التحكم

  1. 1استعلام Resolverيصل الاستعلام من Resolver حاملًا شبكة ECS أو شبكة Resolver.
  2. 2عقدة DNSdnsdist ← Runtime نشط لـ PowerDNS (Blue/Green) ← حالة PostgreSQL محلية؛ دون Manager حيّ في مسار الاستعلام.
  3. 3سياسة Geo/ECSأولوية حتمية على ECS وCIDR وASN/المؤسسة والجغرافيا؛ ويُرفض Lua الاعتباطي.
  4. 4نقطة إقليمية سليمةيشير الجواب إلى النقطة السليمة التي اختارتها السياسة لهذا الاستعلام.
  5. 5نقطة غير سليمةتُحسب الصحة خارج مسار الاستعلام؛ وتقرأ العقدة لقطة محلية ذات إصدار فقط.
  6. 6ManagerProduct API مبني على FastAPI؛ وPostgreSQL مرجع الحالة المطلوبة والتدقيق وOutbox.
  7. 7مراجعات ثابتةيجهّز العامل ووكيل العقدة عبر mTLS اللون غير النشط ويقرآنه ثم يبدّلان ذريًا.
01PROBLEM & OUTCOME

مشكلة المنتج

قد يكون لتغيير صغير في DNS نطاق تأثير (Blast Radius) كبير.

يجب أن يكون Authoritative DNS سريعاً ومتاحاً دائماً، وأن تكون تغييراته في الوقت نفسه دقيقة وقابلة للتدقيق (Audit) والتراجع (Rollback). يفصل GeoDNS مسار الإعداد (Configuration) عن مسار الخدمة (Serving).

01SERVING

يجب ألا تعتمد الخدمة (Serving) على Manager

يبقى مسار الاستعلام (Query path) على عقدة DNS وآخر حالة تم التحقق منها.

02CHANGE CONTROL

لا تغيير مباشر في بيئة التشغيل

تتحول السجلات (Record) والسياسات (Policy) أولاً إلى Revision، ثم تمر بمرحلتي Stage وVerify.

03TRAFFIC

تحتاج Traffic Policy إلى بيانات موثوقة

تأتي صحة Endpoint وأهليته من Observation مقبولة، لا من حالة مصطنعة في المتصفح.

04SECURITY

لـ DNSSEC دورة حياة خاصة به

يجب أن تخضع المفاتيح (Key) والتوقيع (Sign) وRollover والاستعادة لتحكم لا يقل عن إدارة Zone.

02CAPABILITY SNAPSHOT

لمحة عن القدرات

Zone وTraffic وSecurity في Control Plane واحد.

إلى جانب Authoritative Records، يعدّ GeoDNS كلاً من Delivery وTraffic Management ودورة حياة العقد جزءاً من المنتج نفسه.

01ZONES & RRSETS

Zone وسجلات Type-safe

Forward/Reverse Zone، ومجموعات RRset من نوع Typed، وImport/Export مضبوط.

02REVISIONS

Immutable Revisions

Changeset وSnapshot Hash وRevision لأغراض Audit وRollback.

03BLUE / GREEN

Blue/Green Delivery

Stage على Color غير النشط، ثم قراءة الحالة، ثم Cutover ذرّي.

04TRAFFIC

Global Traffic Management

Endpoint وPool وRegion وHealth Perspective وسياسة الإجابة (Policy).

05DNSSEC

دورة حياة DNSSEC

Signing وأدلة DS وRollover وRestore/Reconcile.

06TRANSFERS

Secondary / Transfer

TSIG وAXFR/IXFR وCatalog Zone ودورة حياة Secondary Provider.

07NODE LIFECYCLE

عمليات عقد DNS

Onboard وDrain وReplace وRemove وFleet rollout.

08OBSERVABILITY

DNS Observability

Health وMetrics وAlert وIncident وSynthetic DNS Probe.

4SO

يبقى مسار Query المعتاد قصيراً: Resolver → عقدة DNS → بيئة التشغيل النشطة → الحالة المحلية. ولا يعتمد أي Query عادي في الإجابة على Manager أو على Database عابرة للمناطق.

03DEPLOYMENT PROFILES

نموذج النشر

من Manager واحد وعقدة DNS واحدة إلى مناطق (Region) متعددة.

الحد الأدنى من طوبولوجيا المنتج بسيط، وليس HA أو Multi-region شرطاً للبدء؛ إذ تُضاف العقد والمناطق (Region) تدريجياً.

الملفControl PlaneServing Planeالاستخدام
أساسيManager واحدعقدة DNS واحدةإعداد بسيط ومتكامل لـ Authoritative DNS
متعدد العقدManager مركزيعدة عقد DNSتكرار Serving وRollout مضبوط
مواقع (Site) متعددةControl Plane واحدعقد في مواقع (Site) متعددةفصل نطاقات الأعطال والقرب من Resolver
Multi-regionإدارة مركزية مع عمليات إقليميةServing مستقل في مناطق (Region) متعددةGlobal Traffic ومرونة واسعة النطاق
04ARCHITECTURE

المعمارية

مسار Configuration أطول، أما مسار Serving فقصير عمداً.

يجب أن يمر تغيير DNS عبر Validation وRevision وDelivery، أما إجابة DNS فتُقدَّم مباشرةً من بيئة التشغيل المُتحقَّق منها على العقدة.

CONTROLPanel / Product APIAuthentication والنطاقات وRBAC وTyped Validation.
↓
AUTHORITYالحالة المطلوبة / Revision / Jobحالة معاملاتية وRevision غير قابلة للتغيير وAudit وأدلة.
↓
DELIVERYWorker + Node Agent عبر mTLSStage وقراءة الحالة وVerify وAtomic Cutover.
↓
SERVINGعقدة Authoritative DNSdnsdist وبيئة تشغيل PowerDNS النشطة مع حالة محلية مُتحقَّق منها.
الطبقةComponentالمسؤوليةFail-safe behavior
Product APIFastAPI + scoped RBACZone/RRset وtraffic policy وnode lifecycle وtyped validationلا يعدّل Browser بيئة runtime الخاصة بـ DNS مباشرةً
AuthorityPostgreSQL + transactional outboxDesired state وaudit وحالة job/revisionMutation وevent publication ضمن حدّ معاملاتي واحد
DeliveryWorker + mTLS Node AgentStage inactive color وread-back وverify وatomic cutoverيتوقف Failed delivery قبل الوصول إلى serving
DNS EdgednsdistStable serving entry واختيار active PowerDNS colorلا يعتمد Query path على Manager
Authoritative RuntimePowerDNS blue/green + local PostgreSQLتقديم آخر revision مُتحقَّق منهاعند Control-plane outage تستمر إجابات DNS من آخر state سليمة
SecurityDNSSEC · TSIG · transfer policySigning وrollover وzone-transfer trustلا تدخل Secret material إلى Panel/Audit/Evidence
TECH

Geo-routing & Health Contract. يُقرأ قرار DNS من policy مُجمَّعة وsnapshot محلية؛ ولا ينفّذ Query Path أي health-check شبكي لحظة الإجابة.

المجالالمُدخل / Mechanismالعقد التقني
Client localityECS أو Recursive Resolver IPيُستخدم ECS الصالح عندما يكون مسموحاً به؛ وإلا يكون Resolver IP أساس الاختيار.
Geo / network matchCIDR، ASN/Organization، Country/Subdivision/Continent/Cityتُقيَّم Overrides الدقيقة وgeography وفق priority رقمية وترتيب deterministic.
Native GeoIPPowerDNS geoip backend + Country/ASN MMDBيعمل GeoIP إلى جانب gpgsql؛ ولا تُنقل Zone data من authority الأساسية إلى YAML/GeoIP backend.
HealthTCP/UDP/HTTP/HTTPS/TLS/DNS/gRPC/ICMP probesتُحسب Health خارج Query Path، وتُسجَّل حالات مثل HEALTHY/DEGRADED/SUSPECT/UNHEALTHY في snapshot ذات إصدار.
Policy compilerStructured policy → trusted runtime materialلا يُقبل Arbitrary Lua؛ ويُنتج compiler مخرجات reproducible مع hash مرتبط بـ Revision.
SimulationResolver/ECS/time/health/dataset inputsيمكن محاكاة Rule match وselected pool/endpoint وfallback path وanswer وTTL قبل publish.
ECS cache isolationPolicy-aware cache keyingيجب ألا تتسرّب الإجابات المعتمدة على client network عبر cache بين سياقات ECS غير المرتبطة.
05LIFECYCLE

دورة الحياة

لكل تغيير في DNS مسار قابل للمراقبة.

الانتقال من Edit إلى Publish ليس مجرد بضع نقرات؛ فلكلٍّ من Validation وRevision وStage وقراءة الحالة والاستعادة حالة محددة.

01التحريرEdit
02التحققValidate
03بناء RevisionSeal
04التجهيزStage
05قراءة الحالةVerify
06الإطلاقCutover
07المراقبةObserve
08Rollback / الاستعادةRecover
06DNS PROFILES

ملفات القدرات

Authoritative DNS ليس مجرد Zone Editor.

لكل طبقة، من Authoritative Data إلى Global Traffic وSecurity، Profile تشغيلي مستقل.

Authoritative DNSZONES

إدارة Zone وRRset عبر Revision.

  • Forward / Reverse
  • Typed RRsets
  • Scheduled / templated changes
Traffic ManagementGTM

إجابة مبنية على Endpoint وPolicy.

  • Pools / Endpoints
  • Geo / health policy
  • Maintenance windows
DNS SecurityDNSSEC / TSIG

Trust وTransfer security داخل المنتج.

  • DNSSEC signing / rollover
  • TSIG
  • Transfer policy
أسطول عقد DNSDNS NODES

دورة حياة عقد Serving.

  • Enroll / mTLS
  • Drain / Replace
  • Fleet rollout
DeliveryBLUE / GREEN

إطلاق آمن وقابل للتراجع.

  • Inactive staging
  • التحقق عبر قراءة الحالة
  • Atomic cutover
الاستعادةCONTROL PLANE

حماية حالة الإدارة.

  • Backup / Restore
  • Release rollback
  • عملية التعافي من الكوارث
07ACTION & WORKFLOW CONTRACT

تدفق Job وCutover وRecovery

لا يُعاد تشغيل Job إلا عندما يكون side-effect boundary الخاص به معروفاً.

عمليات Mutation هي idempotent وproject-scoped؛ ولا تبقى node mutation وfleet rollout وcertificate rotation مفتوحة في وقت واحد على العقدة نفسها. ويُحصَّن Worker ownership عبر lease وexecution epoch.

01QueueQUEUED
02RetryRETRY
03LeaseRUNNING + EPOCH
04StageVERIFY / CUTOVER
05SuccessSUCCEEDED
06FailureFAILED / CANCELLED
07RollbackROLLED_BACK
BLUE / GREEN CUTOVER

Stage على Color غير النشط

يتم DNS read-back قبل تبديل Active Color.

DNS QUERY ENTRY
↓
ACTIVE
BLUE
⇄
STAGED
GREEN
↓
DNS
VERIFY
revision → stage inactive → authoritative read-back → atomic cutover
لا يغيّر Stage الفاشل Active Serving.
HEALTH BRANCH

Primary أو Fallback وفق Snapshot

لا ينفّذ Query path أي probe شبكي في لحظة الطلب.

CLIENT CONTEXT
ECS / RESOLVER
↓
POLICY + HEALTH SNAPSHOT
↓
PRIMARY
HEALTHY?
PRIMARY
↙ ↘
FALLBACK
حالة Health ذات إصدار؛ ويمكن لـ snapshot قديمة أن تمنع (block) تطبيق policy.
DR LOOP

Readiness → Failover → Failback

يرتبط DR action بـ readiness hash وtopology freeze.

PRIMARY
SITE
→
READINESS
GATE
↓
FENCE
+ HASH
↑
DR
SITE
←
FAILBACK
VERIFY
backup ready → approval → failover → serving verify → controlled failback
تنتقل Stale readiness أو unknown external state إلى Reconcile.
FLOW 01

Publish Zone Revision

يُجهَّز التغيير (stage) أولاً على color غير النشط.

01Validate02Build Revision03Compile Policy04Stage Inactive05DNS Read-back06Atomic Cutover
Failure / Recoveryلا يغيّر Stage الفاشل Query Path النشط.
FLOW 02

Traffic Policy

تُحاكى Geo/Network policy قبل publish.

01Policy Input02Priority Order03ECS / Resolver Context04Simulate05Compile06Publish
Failure / Recoveryيُرفض Arbitrary Lua وpriority conflict قبل serving.
FLOW 03

Node Onboarding

لا تنضم Node إلى fleet إلا بعد trust وserving verification.

01Identity / mTLS02Preflight03Bootstrap04Register05Health06Rollout Eligible
Failure / Recoveryلا يتحول Bootstrap failure إلى retry أعمى.
FLOW 04

DNSSEC Rotation

تجري Key lifecycle مع overlap وserving acknowledgement.

01Key Intent02Generate / Import03Stage04Overlap05Observe Signing06Retire Old
Failure / Recoveryلا تدخل Secret material إلى Panel/Audit/Evidence العامة.
FLOW 05

Restore / DR

يرتبط Restore وsite failover بـ readiness evidence.

01Backup Ready02Preflight03Approval04Restore / Failover05Serving Verify06Commit / Failback
Failure / RecoveryUnknown external state → RECONCILE_REQUIRED، لا replay أعمى.
ADDITIONAL OPERATIONAL FLOWS

تدفقات تشغيلية إضافية

تؤثر Health وNode replacement مباشرةً في جودة Serving، ولذلك يجب أن يكون لكل منهما Flow مستقل.

FLOW 06

Health Snapshot → Routing

تُجمع Health خارج Query hot path وتتحول إلى snapshot ذات إصدار.

01Probe Policy02Schedule03Out-of-band Probe04Publish Snapshot05Compile Traffic Policy06Node Sync07DNS Verify
Failure / Recoveryلا تُعدّ Health القديمة أو Unknown تلقائياً Healthy، ويجب ألا تنقل Traffic دون سبب.
FLOW 07

Drain / Replace DNS Node

لا تخرج Node القديمة إلا بعد جاهزية Replacement وServing verification.

01Fleet Intent02Serving Capacity03Stop Eligibility04Bootstrap Replacement05Stage Active Revision06Serving Read-back07Remove Old Node
Failure / Recoveryما لم تُقدّم Replacement إجابات Authoritative صحيحة، لا تصل إزالة Node القديمة إلى مرحلتها النهائية.
Action / FlowAdmission / PreconditionsExecution / LockSuccess CriterionFailure / Recovery
Publish Zone / RRsetTyped validation وrevision وpolicy compile قبل deliveryStage على inactive color → node read-back → atomic cutoverتأكيد Authoritative answer/TTL وactive revision من serving pathلا يغيّر Failed stage حالة serving؛ وrollback إلى color السليم المحفوظ
Traffic PolicyStructured policy وpriority وsimulation دون conflictCompiler material ذات إصدار؛ وتُستهلك health snapshot خارج query pathتطابق Matched rule/pool/endpoint وsynthetic DNS behavior مع revisionيُرفض Arbitrary Lua؛ ويفشل policy conflict قبل publish
Node Onboarding / ReplaceIdentity/mTLS وpreflight وتوفّر node mutationDurable job مع node lock؛ ويُرفض تداخل onboarding/day-2/fleet/cert-rotationNode مرصودة بحالة healthy وrollout eligibility واضحةلا يتحول Node onboarding failure إلى generic retry؛ وقد يلزم fresh bootstrap
DNSSEC / CertificateKey/identity lifecycle وapproval في العمليات الحساسةStage/overlap/ack وrotation workflow خاص بالمالك (owner-specific)تطابق Signing/serving أو certificate observation مع generation المتوقعةرفض Stale rotation/fleet mutation المتزامنة؛ وحذف secret material من public job projection
Control-plane Restoreيجب أن تكون Backup بحالة READY وrepository-verified ومعها snapshot/hash evidencePreflight → approval → execution → cutoverRESTORED فقط بعد preflight binding وruntime verificationWorker interruption/unknown external state → RECONCILE_REQUIRED؛ ويُمنع blind retry
DR Failover / Failbackيلزم Readiness job وtopology freeze وfencing وrollback وRPO acknowledgementيرتبط Action بـ readiness state/hash وprofile revisionوصول Active site/traffic/database state إلى phase المتوقعةرفض Stale readiness أو topology mismatch؛ ولا يُسمح بـ failback إلا من FAILED_OVER
FLOW

تصنيف إعادة المحاولة صريح للمشغّل: SAFE_TO_RETRY، RECONCILE_REQUIRED، FRESH_BOOTSTRAP_REQUIRED أو FRESH_HEALTH_REQUEST_REQUIRED. وفقدان Lease في workflows المُخِلّة بالخدمة (disruptive) لا يُعدّ أبداً إذناً بـ replay أعمى.

08OPERATIONS CATALOG

كتالوج العمليات

تُضبط عمليات DNS بما يتناسب مع Blast Radius الخاص بها.

يستخدم المشغّل العملية نفسها في المنتج وAudit trail ذاته لتغيير Record أو Rollout العقد أو DNSSEC.

Create / Edit Zoneإدارة Zone وRRset مع Validation وRevision.
PublishStage وقراءة الحالة وAtomic Cutover إلى الإصدار الجديد.
Rollbackالعودة إلى Color السليم المحفوظ.
Traffic Policyإدارة Endpoint وPool وHealth-aware response policy.
DNSSECSigning وRollover وRestore/Reconcile.
Onboarding العقدEnroll عقد DNS وتجهيزها مع Identity مضبوطة.
Drain / Replaceإخراج العقد أو استبدالها دون تغيير مباشر في بيئة تشغيل Zone.
ObserveHealth وMetrics وAlert وSynthetic DNS behavior.

أدِر DNS بسرعة Serving ودقة نظام موزَّع.

يتحكّم 4SO GeoDNS في التغييرات من دون إدخال Control Plane في مسار إجابة DNS.

كل منتجات 4SO ←