تنظیم GeoDNS با API

در پایان این راهنما، برای یک نام در Zone ستون دو آدرس IPv4 می‌گذاریم تا Resolver داخل ایران 1.2.3.3 بگیرد و بقیه 5.6.7.7.

GeoDNS پاسخ DNS را بر اساس کشور (یا قاره) مبدا Resolver عوض می‌کند. این تنظیم در حال حاضر فقط از API نسخه ۲.۱ در دسترس است و در پنل اوشن فرم ندارد. اگر لازم باشد، همین پیکربندی را از طریق پشتیبانی ستون انجام می‌دهیم.

برای ترافیک وب، راه ساده‌تر قانون آپ‌استریم با شرط کشور است؛ بازدیدکننده به لبه می‌رسد و لبه مبدا را عوض می‌کند. GeoDNS وقتی معنا دارد که خود پاسخ DNS باید متفاوت باشد.

مرجع مسیرها: CDN and DNS (v2.1). ساخت توکن و WorkspaceUUID در مدیریت دامنه خود را با API خودکار کنید است.

ناسازگار با دکمه ابر (quickcdn)

GeoDNS با دکمه ابر قابل استفاده نیست. اگر در فهرست آپ‌استریم نامی با پیشوند quickcdn- داریم، اول ابر را با API خاموش می‌کنیم و CDN را به‌صورت دستی — آپ‌استریم و قانون مسیر جدا از DNS — می‌سازیم. تا وقتی پاسخ عمومی DNS آدرس Anycast باشد، تفکیک جغرافیایی روی IPهای رکورد دیده نمی‌شود.

پیش‌نیازها

دامنه با مدیریت DNS در ستون — اولین دامنه را به DNS ستون منتقل کنید
توکن Bearer با نقش dns-editor
شناسه‌ی فضای کاری (workspaceUUID) از فضاهای کاری
ابر همان نام خاموش باشد؛ آپ‌استریم quickcdn-… برای آن نام نباشد

مراحل

توکن و workspaceUUID را آماده می‌کنیم.
فهرست Zoneها را می‌گیریم و Zone دامنه را از spec.origin پیدا می‌کنیم. مقدار metadata.name همان <NAME> است:

curl -sS -X GET \
  "https://api.sotoon.ir/delivery/v2.1/global/workspaces/<workspaceUUID>/domainzones" \
  -H "Authorization: Bearer <TOKEN>"

در صورت نیاز همان Zone را جدا می‌خوانیم تا رکوردهای فعلی از بین نروند:

curl -sS -X GET \
  "https://api.sotoon.ir/delivery/v2.1/global/workspaces/<workspaceUUID>/domainzones/<NAME>" \
  -H "Authorization: Bearer <TOKEN>"

پارامتر <NAME>

<NAME> همان metadata.name آبجکت DomainZone است، نه لزوما نام دامنه.

آرایه opts باید با آرایه آدرس‌ها هم‌طول باشد. عنصر اول برای رکورد اول است و عنصر دوم برای رکورد دوم. آنچه باید منطبق شود را با geo می‌سازیم؛ اینجا یک کشور است و می‌تواند چند کشور باشد. برای بقیه، blockedGeo همان کشور را از رکورد دوم کنار می‌گذارد.

نمونه: زیردامنه testir روی example.com؛ ایران 1.2.3.3 و بقیه 5.6.7.7:

curl -sS -X PATCH \
  "https://api.sotoon.ir/delivery/v2.1/global/workspaces/<workspaceUUID>/domainzones/<NAME>" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/merge-patch+json" \
  -d '{
    "spec": {
      "records": {
        "testir": [
          {
            "type": "A",
            "ttl": 10,
            "A": ["1.2.3.3", "5.6.7.7"],
            "opts": [
              {
                "geo": [
                  { "country": "IR" }
                ]
              },
              {
                "blockedGeo": [
                  { "country": "IR" }
                ]
              }
            ]
          }
        ]
      }
    }
  }'

testir را با پیشوند واقعی عوض می‌کنیم. برای ریشه دامنه کلید @ است.

ایندکس	آدرس	شرط	رفتار
`0`	`1.2.3.3`	`geo`: کشور `IR`	فقط وقتی مبدا Resolver ایران باشد
`1`	`5.6.7.7`	`blockedGeo`: کشور `IR`	برای همه جز ایران

کد کشور دو حرفی ISO 3166-1 alpha-2 است. چند کشور در همان geo مجاز است. به‌جای کشور می‌توان continent گذاشت؛ هر دو را هم‌زمان روی یک عنصر نمی‌گذاریم.

merge-patch

برای PATCH جزیی از Content-Type: application/merge-patch+json استفاده می‌کنیم. این نمونه فقط کلید testir را عوض می‌کند و بقیه نام‌های spec.records می‌مانند. اگر روی همان نام رکورد دیگری مثل TXT هست، آن را هم در همین آرایه نگه می‌داریم؛ وگرنه با جایگزینی آرایه حذف می‌شود.

بررسی صحت

دوباره همان Zone را با GET می‌خوانیم. در spec.records.testir باید دو آدرس و دو عنصر opts دیده شود.
کد پاسخ PATCH و GET نباید 401 / 403 باشد؛ در غیر این صورت توکن و نقش dns-editor را بررسی می‌کنیم. اگر 404 است، <NAME> را با metadata.name مقایسه می‌کنیم.
چند دقیقه — دست‌کم به اندازه TTL رکورد — صبر می‌کنیم.
از نام‌سرورهای ستون در spec.nameserversV4 کویری می‌زنیم تا کش Resolver محلی را دور بزنیم:

dig @a.ns.sotoon53.com testir.example.com A

نام‌سرور را با یکی از مقادیر nameserversV4 و نام را با زیردامنه واقعی جایگزین می‌کنیم.

از داخل ایران پاسخ باید 1.2.3.3 باشد و از خارج 5.6.7.7. کشور را Resolver می‌بیند، نه لزوما دستگاه کاربر؛ اگر Resolver در ایران باشد، حتی با کلاینت خارج همان پاسخ ایران را می‌گیریم.

جایگزین ساده‌تر: قانون آپ‌استریم

اگر هدف فقط رساندن کاربر ایرانی و خارجی به مبدا متفاوت است و ترافیک از CDN می‌گذرد، GeoDNS لازم نیست. دو آپ‌استریم می‌سازیم و در قوانین آپ‌استریم شرط کشور می‌گذاریم. بازدیدکننده همان Anycast را می‌گیرد و لبه مبدا را عوض می‌کند.

تفاوت قانون مسیر و قانون آپ‌استریم در قوانین آپ‌استریم است. مراحل پنل در مسیریابی ترافیک بین‌الملل با قوانین آپ‌استریم آمده است.

مستندات

📄 تنظیم GeoDNS با API

پیش‌نیازها

مراحل

بررسی صحت

جایگزین ساده‌تر: قانون آپ‌استریم

ادامه مسیر

فهرست

بک‌لینک‌ها