ڈومین نیم سسٹم (DNS) انٹرنیٹ کی ایڈریس بک ہے۔ جب کوئی شخص براؤزر میں example.sa لکھتا ہے یا you@example.sa پر ای میل بھیجتا ہے، تو DNS ہی وہ نظام ہے جو اس انسان دوست نام کو ان مشینی ہدایات میں ترجمہ کرتا ہے جو دراصل درخواست کو راہ دکھاتی ہیں۔ یہ ہدایات DNS ریکارڈز میں رہتی ہیں — چھوٹے، منظم اندراجات جو آپ کے ڈومین کے زون میں محفوظ ہوتے ہیں۔
ان ریکارڈز کو درست رکھنا ہی وہ فرق ہے جو ایک ایسی سائٹ کے درمیان ہوتا ہے جو لوڈ ہوتی ہے، ایسی ای میل جو پہنچتی ہے، اور ایسا SSL جو تصدیق پاتا ہے — اور دوسری طرف گھنٹوں کی الجھن بھری بندش کے۔ یہ رہنما ان ریکارڈز کی وضاحت کرتا ہے جنہیں آپ حقیقت میں چھوئیں گے، درست نحو اور حقیقی دنیا کی مثالوں کے ساتھ۔
ایک DNS ریکارڈ کی ساخت کیسی ہوتی ہے
ہر ریکارڈ کی بنیادی شکل ایک جیسی ہوتی ہے:
NAME TTL CLASS TYPE VALUE
www 3600 IN A 192.0.2.10
- NAME — وہ ہوسٹ نیم جس پر ریکارڈ لاگو ہوتا ہے (
www، روٹ ڈومین کے لیے@، یا وائلڈ کارڈ کے لیے*)۔ - TTL (Time To Live) — ریزولور جواب کو کتنے سیکنڈ تک کیش میں رکھ سکتے ہیں۔ کسی منصوبہ بند تبدیلی سے پہلے اسے کم کریں (مثلاً 300)، اور مستحکم ہونے کے بعد اسے بڑھا دیں (3600+)۔
- TYPE — ریکارڈ کی قسم، جس کی وضاحت نیچے کی گئی ہے۔
- VALUE — ڈیٹا: ایک IP ایڈریس، کوئی اور ہوسٹ نیم، یا متن۔
بنیادی ریکارڈز
A ریکارڈ — نام سے IPv4
A ریکارڈ ایک ہوسٹ نیم کو ایک IPv4 ایڈریس سے جوڑتا ہے۔ یہ انٹرنیٹ پر سب سے عام ریکارڈ ہے۔
@ 3600 IN A 192.0.2.10
www 3600 IN A 192.0.2.10
اسے اپنے ڈومین کو کسی ویب سرور، کلاؤڈ ہوسٹنگ انسٹنس، یا VPS کی طرف اشارہ کرنے کے لیے استعمال کریں۔
AAAA ریکارڈ — نام سے IPv6
AAAA ریکارڈ ("quad-A") یہی کام IPv6 ایڈریسز کے لیے کرتا ہے۔ اگر آپ کے سرور کا کوئی IPv6 ایڈریس ہے، تو A اور AAAA دونوں شائع کریں تاکہ ڈوئل اسٹیک کلائنٹس کسی بھی پروٹوکول کے ذریعے آپ تک پہنچ سکیں۔
@ 3600 IN AAAA 2001:db8::10
CNAME ریکارڈ — نام سے کسی دوسرے نام تک
ایک CNAME (Canonical Name) ایک ہوسٹ نیم کو دوسرے کے لیے عرف بنا دیتا ہے۔ یہ اس وقت بہترین ہے جب کئی نام ایک ہی ہدف کی پیروی کریں — مثلاً www اور shop کو ایک ہی جگہ کی طرف اشارہ کرنا، یا کسی سب ڈومین کو CDN یا SaaS اینڈ پوائنٹ کی طرف اشارہ کرنا۔
www 3600 IN CNAME example.sa.
blog 3600 IN CNAME hosting.provider.net.
دو اصول اہم ہیں:
- روٹ/apex پر کبھی CNAME نہ رکھیں (
@، مثلاًexample.sa) دیگر ریکارڈز جیسے MX یا NS کے ساتھ — یہ زون کو خراب کر دیتا ہے۔ اس کے بجائے apex پر ایک A ریکارڈ (یا اپنے DNS فراہم کنندہ کی ALIAS/ANAME flattening) استعمال کریں۔ - ایک CNAME کا ہدف خود A/AAAA کے ذریعے ریزولو ہونا چاہیے؛ کئی CNAMEs کی زنجیر بنانا تاخیر بڑھا دیتا ہے۔
MX ریکارڈ — ای میل کہاں جاتی ہے
MX (Mail Exchanger) ریکارڈز دنیا کو بتاتے ہیں کہ کون سے سرور آپ کے ڈومین کے لیے میل قبول کرتے ہیں۔ ہر ایک کی ایک priority ہوتی ہے (کم نمبر = ترجیحی)؛ ایک دوسرا، زیادہ priority والا بیک اپ لچک کا اضافہ کرتا ہے۔
@ 3600 IN MX 10 mail.example.sa.
@ 3600 IN MX 20 backup-mail.example.sa.
MX کی value ایک ہوسٹ نیم ہونی چاہیے (جس کا اپنا A/AAAA ریکارڈ ہو)، کبھی IP ایڈریس نہیں۔ اگر آپ بزنس ای میل ہوسٹنگ چلاتے ہیں، تو آپ کا فراہم کنندہ آپ کو شائع کرنے کے لیے درست MX اہداف دیتا ہے۔
TXT ریکارڈز — تصدیق، SPF، DKIM، DMARC
TXT ریکارڈز کسی بھی قسم کا متن رکھتے ہیں۔ عملی طور پر یہ وہ تین ریکارڈز رکھتے ہیں جو آپ کی ای میل کو قابلِ اعتماد اور اسپام فولڈرز سے باہر رکھتے ہیں:
| مقصد | ہوسٹ | مثال value |
|---|---|---|
| SPF (مجاز بھیجنے والے) | @ |
v=spf1 include:_spf.example.sa -all |
| DKIM (دستخطی کلید) | selector._domainkey |
v=DKIM1; k=rsa; p=MIGfMA0... |
| DMARC (پالیسی) | _dmarc |
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.sa |
TXT کے ذریعے ہی آپ Google Search Console جیسی سروسز کو ڈومین کی ملکیت ثابت کرتے ہیں (google-site-verification=...)۔
NS ریکارڈز — کون authoritative ہے
NS (Name Server) ریکارڈز آپ کے زون کے لیے authoritative سرورز کی فہرست دیتے ہیں۔ یہ آپ کے رجسٹرار پر (delegation) اور زون کے اندر دونوں جگہ مقرر کیے جاتے ہیں، اور ان کا آپس میں مطابقت رکھنا ضروری ہے۔
@ 86400 IN NS ns1.alskyline.com.
@ 86400 IN NS ns2.alskyline.com.
کم عام مگر مفید ریکارڈز
- SRV — کسی ہوسٹ اور پورٹ پر کوئی سروس تلاش کرتا ہے، جو SIP، XMPP، Microsoft autodiscover وغیرہ کے ذریعے استعمال ہوتا ہے:
_sip._tcp 3600 IN SRV 10 5 5060 sip.example.sa. - PTR — ریورس DNS، جو کسی IP کو واپس نام سے جوڑتا ہے۔ IP کے نیٹ ورک پر مقرر کیا جاتا ہے (اکثر آپ کے ہوسٹنگ فراہم کنندہ کی طرف سے)، یہ ای میل کی deliverability کے لیے ضروری ہے۔
- CAA — محدود کرتا ہے کہ کون سے Certificate Authorities آپ کے ڈومین کے لیے SSL سرٹیفکیٹ جاری کر سکتے ہیں:
@ 3600 IN CAA 0 issue "letsencrypt.org"۔
ایک عملی مثال: ایک مکمل چھوٹے کاروبار کا زون
@ 3600 IN A 192.0.2.10
www 3600 IN A 192.0.2.10
@ 3600 IN AAAA 2001:db8::10
shop 3600 IN CNAME example.sa.
@ 3600 IN MX 10 mail.example.sa.
mail 3600 IN A 192.0.2.20
@ 3600 IN TXT "v=spf1 include:_spf.example.sa -all"
_dmarc 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.sa"
@ 3600 IN CAA 0 issue "letsencrypt.org"
اپنے ریکارڈز کی تصدیق
تبدیلیوں کی تصدیق ہمیشہ کمانڈ لائن سے کریں نہ کہ براؤزر سے، جو جارحانہ انداز میں کیش کرتا ہے:
dig example.sa A +short
dig example.sa MX +short
dig _dmarc.example.sa TXT +short
# Windows equivalent:
nslookup -type=MX example.sa
یاد رکھیں کہ پھیلاؤ (propagation) آپ کے TTL کے زیرِ انتظام ہوتا ہے۔ اگر آپ ایک طویل TTL مقرر کرتے ہیں اور پھر کسی ریکارڈ کو تبدیل کرنا چاہتے ہیں، تو وہ ریزولور جنہوں نے پہلے ہی پرانا جواب کیش کر رکھا ہے، اس TTL کے ختم ہونے تک وہی فراہم کرتے رہیں گے۔
منظم DNS اور ڈیٹا ریزیڈنسی کیوں اہمیت رکھتے ہیں
اپنے DNS کو ایک تیز، قابلِ اعتماد، anycast سے مدد یافتہ پلیٹ فارم پر ہوسٹ کرنا زائرین کے لیے lookup تاخیر کو کم کرتا ہے اور آپ کو رجسٹرار سطح کی بندشوں سے بچاتا ہے۔ مملکت میں موجود اداروں کے لیے، DNS اور اس کے پیچھے کی سروسز کو مملکت کے اندر موجود انفراسٹرکچر پر چلانا PDPL، NCA اور SDAIA کی ڈیٹا ریزیڈنسی توقعات کی حمایت کرتا ہے، جبکہ عربی زبان کی مدد قریب رکھتا ہے۔
Skyline منظم DNS آپ کو اوپر بیان کردہ ہر ریکارڈ کی قسم کے لیے ایک صاف ستھرا ایڈیٹر، معقول ڈیفالٹ TTLs، اور SPF/DKIM/DMARC اور .sa ڈومینز کے لیے ٹیمپلیٹس فراہم کرتا ہے — اور یہ سب مقامی مدد کے ساتھ۔
Comments
0 total · 0 threads