الدرس 3.3: استعلامات DNS بأداة dig (DNS Enumeration with dig)

مقدمة: واش هو الـDNS وكيفاش يخدم

تخيّل كل مرة تحب تزور موقع لازم تكتب الـIP نتاعو : 142.250.185.206 بدل ما تكتب google.com. حاجة تعيِّي بزاف وماش واقعية. هنا يجي دور نظام أسماء النطاقات أو DNS (Domain Name System).

الـDNS هو “دفتر عناوين” تاع الإنترنت. أي دومين (مثال: doctorhou.com) يترجم أوتوماتيكياً لعنوان IP باش المتصفح ولا أي برنامج يعرف مع من يتواصل.

• كي تكتب دومين في المتصفح → يروح الطلب للـDNS resolver → يرجعلك بالـIP المناسب.
• العملية هذي تصرع في أجزاء من الثانية، وأنت غالباً ما تحس بيهاش.

في الأمن السيبراني، الـDNS نقطة حساسة بزاف. علاش؟

• لو نتحكّم فيه، نقدر نوجّه الضحية لمكان آخر.
• نقدر نخلي دومين معروف يفتح صفحة مزوّرة (Phishing).
• ونقدرو نغيّرو إعدادات الـDNS resolver باش نتحكم في الطريقة اللي يتم بها حل أسماء النطاقات، مثلاً باستعمال Google DNS أو Cloudflare DNS لزيادة السرعة والأمان.

علاش الـDNS مهم في الهجمات السيبرانية

الـDNS ظاهرلك حاجة بسيطة: يترجم أسماء المواقع لعناوين IP. بصح من منظور هاكر ولا مدافع أمني، راهو نقطة إستراتيجية.

• تحويل المسارات (Redirection): إذا نقدر نغيّر استجابة الـDNS، نقدر نوجّه الضحية لموقع مزوّر فيه phishing ولا malware.
• لمراقبة والتتبع: أي موقع تزورو يمر عبر DNS resolver، يعني اللي يتحكم فيه يقدر يعرف واش تشوف على النت.
• حجب الوصول (Censorship): بزاف حكومات وشركات تستعمل الـDNS block باش يمنعو مواقع معينة.
• الحماية: بعض خدمات DNS (ك Google DNS أو Cloudflare DNS) يقدمو protection ضد المواقع الخبيثة، فيصير اختيار الـresolver جزء من الأمن الشخصي.

بالتالي، فهم الـDNS مش غير للهاكرز، بل حتى للناس اللي يحبو يزيدو السرعة، الأمان، والخصوصية في التصفح.

أوامر عملية باش تستكشف الـDNS

nslookup

الأمر الكلاسيكي:

nslookup doctorhou.com

nslookup doctorhou.com

يعطيك الـIP المرتبط بالدومين. تقدر حتى تحدد سيرفر DNS مختلف:

nslookup doctorhou.com 8.8.8.8

nslookup doctorhou.com 8.8.8.8

هنا الاستعلام يروح مباشرة لـ Google DNS بدل السيرفر الافتراضي.

dig

أداة أقوى وأشهر وسط الأمنيين:

dig doctorhou.com

dig doctorhou.com

تعرض كامل التفاصيل:

• عنوان الـIP
• نوع الـrecord (A, AAAA, MX, TXT…)
• وقت الاستجابة (query time)

┌──(doctorhou㉿***************)-[~]
└─$ dig doctorou.com

; <<>> DiG 9.20.0-Debian <<>> doctorou.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39331
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;doctorou.com.                  IN      A

;; ANSWER SECTION:
doctorou.com.           3600    IN      A       15.197.225.128
doctorou.com.           3600    IN      A       3.33.251.168

;; Query time: 131 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Mon Sep 01 13:39:17 CET 2025
;; MSG SIZE  rcvd: 73

• status: NOERROR : هذا يعني الاستعلام كان صحيح وماكانش خطأ (الدومين doctorou.com موجود ويتحلّ).
• QUESTION SECTION : ;doctorou.com. IN A : طلبنا A record (العنوان IPv4) تاع doctorou.com.
• ANSWER SECTION : doctorou.com. 3600 IN A 15.197.225.128 ; doctorou.com. 3600 IN A 3.33.251.168 : doctorou.com مربوط بعنوانين IP مختلفين (multi-A records): هذا معناه الموقع يستعمل load balancing (تقسيم الحمل) غالبًا عبر خدمة استضافة سحابية (كيما AWS أو Cloudflare).
• ANSWER SECTION : 3600 = TTL (Time To Live) بالثواني → يعني DNS cache يقدر يحتفظ بالنتيجة لمدة ساعة وحدة قبل ما يعاود يسقصي.
• Query Time : السيرفر جاوب في 131 ملي ثانية.
• SERVER: 10.255.255.254#53 : هذا هو DNS resolver اللي جهازك يستعمله (IP داخلي للشبكة).

ماكانش NS section هنا لأنه طلبنا غير الـ A record.

استعمال dig للاستعلام على الـ Nameserver

الـDNS مش غير يحوّل دومين لـ IP. فيه بزاف أنواع Records نقدر نستعلم عليهم. مثلاً:

• A record: يعطينا الـIP.
• NS record: يبيّن أسماء سيرفرات الـDNS اللي يخدمو مع الدومين.
• MX record: يوضح سيرفرات البريد المرتبطة بالدومين.

dig doctorhou.com ns 

dig doctorhou.com ns 

┌──(doctorhou㉿XXXXXXXXXXXX)-[~]
└─$ dig doctorhou.com ns

; <<>> DiG 9.20.0-Debian <<>> doctorhou.com ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57057
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;doctorhou.com.                 IN      NS

;; ANSWER SECTION:
doctorhou.com.          86400   IN      NS      ns3.octenium.net.
doctorhou.com.          86400   IN      NS      ns1.octenium.net.
doctorhou.com.          86400   IN      NS      ns4.octenium.net.
doctorhou.com.          86400   IN      NS      ns2.octenium.net.

;; Query time: 187 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Mon Sep 01 15:05:54 CET 2025
;; MSG SIZE  rcvd: 126

تحليل النتيجة:

يبين واش طلبنا: doctorhou.com من نوع NS (يعني أسماء الخوادم).

ANSWER SECTION:
لقينا أربع خوادم أسماء:

• ns1.octenium.net.
• ns2.octenium.net.
• ns3.octenium.net.
• ns4.octenium.net.

هذو تابعين لشركة Octenium (هي اللي توفر خدمة الـ DNS Hosting للدومين).

AUTHORITY & ADDITIONAL SECTION:
ماكانش تفاصيل إضافية بزاف (غير OPT pseudo-section)، بصح مرات dig يمد حتى عناوين الـ IP نتاع الـ Nameservers.

علاش يهمنا نعرف الـ NS؟

• الهاكر يقدر يستعمل هاد المعلومة باش يعرف وين مربوط الدومين ومن يدير خوادمو.
• لو يلقى Misconfiguration في Nameserver (مثلاً مفتوح للـ zone transfer) يقدر يستغلو.
• بالنسبة للمسؤولين على المواقع، المعلومة تهم باش يتأكدو باللي الدومين مربوط صح مع مزود الخدمة الصحيح وماهوش غالط.

لاستعلام عن خوادم البريد (Mail Servers) باستعمال dig MX

dig doctorhou.com mx 

dig doctorhou.com mx 

راح يمدلنا أسماء الخوادم (NS) اللي يحتضنو سجلات DNS الخاصة بالدومين. هذو هما “المراجع الرسمية” وين كل طلب على doctorou.com يتوجه باش يلقى العنوان الصحيح.

; <<>> DiG 9.20.0-Debian <<>> doctorou.com mx
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26035
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;doctorou.com.                  IN      MX

;; AUTHORITY SECTION:
doctorou.com.           600     IN      SOA     ns17.domaincontrol.com. dns.jomax.net. 2025071503 28800 7200 604800 600

;; Query time: 203 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Mon Sep 01 14:46:03 CET 2025
;; MSG SIZE  rcvd: 98

سقصينا: “وين البريد الإلكتروني تاع doctorou.com يتوجّه؟”

doctorou.com. 600 IN SOA ns17.domaincontrol.com. dns.jomax.net. 2025071503 28800 7200 604800 600

بما أنه ماكانش MX records، السيرفر عطانا SOA (Start of Authority) record:

• ns17.domaincontrol.com → أول nameserver مسؤول.
• dns.jomax.net → البريد الإلكتروني للمسؤول (مكتوب هكذا بدل @).
• الأرقام الباقية = بيانات خاصة بالـ DNS zone:
  • 2025071503 → Serial number (تاريخ + إصدار).
  • 28800 → Refresh.
  • 7200 → Retry.
  • 604800 → Expire.
  • 600 → Minimum TTL.

الخلاصة

• doctorou.com ماعندوش MX records → يعني الدومين مايستقبلش إيميلات رسمية.
• غالبًا البريد الإلكتروني مربوط بسيرفر آخر (مثلاً Gmail Workspace أو Outlook)، لكن ما تمش ضبطه لهذا الدومين.
• وجود SOA record فقط يبيّن أن المسؤولية عند GoDaddy (domaincontrol.com).

الاستعلام عن السجلات النصية (TXT records)

dig doctorhou.com txt

dig doctorhou.com txt

└─$ dig doctorhou.com txt

; <<>> DiG 9.20.0-Debian <<>> doctorhou.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44870
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;doctorhou.com.                 IN      TXT

;; ANSWER SECTION:
doctorhou.com.          14400   IN      TXT     "v=spf1 +a +mx +ip4:57.128.97.32 ~all"

;; Query time: 91 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Mon Sep 01 16:24:05 CET 2025
;; MSG SIZE  rcvd: 91

واش يدير هذا؟

يجيبلك السجلات النصية المرتبطة بالدومين.

• أغلب الاستعمالات:
  • SPF records (يحدد شكون يقدر يبعث إيميلات باسم الدومين).
  • Google site verification أو Microsoft verification.
  • DKIM keys للتحقق من توقيع الرسائل.
  • معلومات عامة يحطها مدير النظام.

علاش مهم للهجوم والدفاع؟

• للمهاجم: يكشف معلومات عن مزود البريد المستعمل، وكيما كانو مفاتيح DKIM يقدر يتأكد إذا الإيميلات ممكن تكون ضعيفة أو ناقصة حماية.
• للمدافع: لازم يتأكد بلي TXT records معمولة مليح، خاصةً SPF + DKIM + DMARC.

لاستعلام العكسي بالـ dig -x (Reverse DNS)

الأمر:

dig -x 57.128.97.32n

dig -x 57.128.97.32n

; <<>> DiG 9.20.0-Debian <<>> -x 57.128.97.32
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64818
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;32.97.128.57.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
32.97.128.57.in-addr.arpa. 86400 IN     PTR     srv60.octenium.net.

;; Query time: 255 msec
;; SERVER: 10.255.255.254#53(10.255.255.254) (UDP)
;; WHEN: Mon Sep 01 15:15:48 CET 2025
;; MSG SIZE  rcvd: 86

QUESTION SECTION:

طلبنا PTR Record: تحويل الـ IP 57.128.97.32 لاسم دومين.

ANSWER SECTION:

لقينا:

srv60.octenium.net.

واش يعني هذا؟

• الهكر: يعرف مزود الخدمة أو نوع السيرفر (Octenium هنا).
• المسيرين: PTR record مهم بزاف خصوصاً للسيرفرات نتاع البريد الإلكتروني. لو ماكانش مضبوط، الرسائل تقدر تروح للـ spam.

ملخص أوامر dig اللي شفناهم

1. A Record
   يبين عنوان الـ IP الرئيسي للدومين.
   مثال: doctorhou.com → 57.128.97.32
2. MX Record
   يكشف خوادم البريد الخاصة بالدومين.
   مهم باش نعرف وين يوصل الإيميل.
3. NS Record
   يعرض أسماء الخوادم اللي تدير الدومين.
   مثال: ns1.octenium.net, ns2.octenium.net...
4. TXT Record
   يعطينا نصوص خاصة مثل SPF, DKIM، أو إعدادات أمان.
   مثال: v=spf1 +a +mx +ip4:57.128.97.32 ~all
5. CNAME Record
   يربط دومين بدومين آخر.
   (في حالتنا ماكانش CNAME للدومين الرئيسي).
6. SOA Record
   يعطينا معلومات على “السلطة” (Start of Authority):
   السيرفر الرئيسي، المسؤول التقني، و بارامترات التحديث.
7. PTR Record (Reverse DNS)
   يربط IP باسم سيرفر (مثال: 57.128.97.32 → srv60.octenium.net).

ملخص استعلامات dig على doctorhou.com

الخلاصة
من خلال الاستعلامات اللي درناهم بـ dig قدرنا نفهم البنية تاع دومين doctorhou.com:

• الدومين مربوط بعنوان IPv4 واحد (57.128.97.32) ومايستعملش IPv6.
• البريد الإلكتروني يمر عبر mail.doctorhou.com، يعني السيرفر عندو خدمة مهيأة للبريد.
• الـ Nameservers تابعين لـ GoDaddy (ns17 و ns18)، بينما الـ SOA يبيّن أنو الإدارة التقنية مربوطة بشركة octenium.net.
• ماكانش CNAME، يعني الدومين يخدم كـ root domain مباشر.
• عكس الاستعلام (PTR) ورّانا أن الـ IP مربوط بالسيرفر srv60.octenium.net.

الخلاصة: نقدر نستنتج أن الموقع مستضاف عند مزود خدمة (Octenium) لكن مسجل عند GoDaddy. هاد النوع من المعلومات يهم مسؤولي الأنظمة للتأكد من الإعدادات، وفي نفس الوقت يمد صورة واضحة للهاكر حول البنية التحتية المستعملة.

تغيير سيرفر الـ DNS (Changing Your DNS Server)

بالمفهوم البسيط: كل مرة تكتب doctorhou.com في المتصفح، نظامك يبعث طلب لسيرفر DNS باش يترجم الدومين لـ IP. لكن مش دايماً لازم تستعمل السيرفر اللي يجيك تلقائياً من DHCP (الراوتر أو الـ ISP). تقدر تبدلو بأي سيرفر آخر (مثلاً جوجل أو كلاودفلير) باش يكون عندك:

• سرعة أحسن
• استقرار أكثر
• أو حتى تجاوز بعض القيود

ملف /etc/resolv.conf

• هذا الملف هو المسؤول على تعريف سيرفرات الـ DNS.
• تقدر تفتحو بأي محرر نصوص:

sudogedit/etc/resolv.conf

sudogedit/etc/resolv.conf

(تقدر تعوض gedit بأي محرر: nano, vim, leafpad…)
المحتوى يكون كيف كيف:

# Generated by NetworkManager
search localdomain
nameserver 192.168.1.1

هنا النظام يستعمل السيرفر المحلي تاع الراوتر.

2 : تغييره إلى Google DNS

بكل بساطة، نقدر نبدل المحتوى ونكتب:

nameserver 8.8.8.8

أو نزيدو سطر ثاني باش يكون عندنا fallback:

nameserver 192.168.1.1
nameserver 8.8.8.8

النظام يجرب الأول، إذا ما جاوبش يروح للثاني.

من الكوماند لاين مباشرة

من غير ما تفتح محرر، تقدر تدير:

echo u0022nameserver 8.8.8.8u0022 u003e /etc/resolv.conf

echo u0022nameserver 8.8.8.8u0022 u003e /etc/resolv.conf

هاد الكوماند تمسح المحتوى القديم وتبدلو بجديد.

ملاحظة: إذا تستعمل DHCP، ممكن النظام يرجع يكتب فوق الملف أوتوماتيكياً.

ملف /etc/hosts

ثاني أداة مهمة: hosts file.
هذا ملف بسيط فيه ترجمات دومين → IP يدير override على DNS.
تفتحو هكذا:

leafpad /etc/hosts

leafpad /etc/hosts

افتراضياً تلقى:

127.0.0.1   localhost
127.0.1.1   kali

تقدر تضيف أي حاجة تحب، مثلاً:

192.168.1.150   doctorhou.com

ومن بعد أي واحد يحاول يدخل doctorhou.com من جهازك، يروح مباشرة لـ 192.168.1.150 بلا ما يدير استعلام DNS.

هذا مهم في الاختبارات (CTF, pentest) ولا كي تستعمل أدوات كيما dnsspoof أو Ettercap باش توجه الترافيك.

127.0.0.1	localhost
127.0.1.1	kali
::1		localhost ip6-localhost ip6-loopback
ff02::1		ip6-allnodes
ff02::2		ip6-allrouters
10.10.11.70     puppy.htb  DC.PUPPY.HTB PUPPY.HTB
10.10.11.69     DC01.fluffy.htb fluffy.htb
10.10.11.71     certificate.htb DC01.certificate.htb
10.129.63.225   tombwatcher.htb DC01.tombwatcher.htb
10.129.136.88 	sorcery.htb git.sorcery.htb dc01.sorcery.htb main.sorcery.htb
10.129.64.39    artificial.htb
10.129.177.82   rustykey.htb dc.rustykey.htb DC
10.129.96.64    voleur.htb dc.voleur.htb DC
10.129.83.105   outbound.htb mail.outbound.htb
10.129.99.235	mirage.htb dc01.mirage.htb dc01 _ldap._tcp.dc01.mirage.htb
10.129.75.22	era.htb file.era.htb
10.129.88.238	editor.htb wiki.editor.htb
10.10.120.89    vulnnet.thm broadcast.vulnnet.thm
10.10.11.68	planning.htb grafana.planning.htb
10.10.11.67 	environment.htb
10.10.11.64	nocturnal.htb
10.13.37.10     securewebinc.jet www.securewebinc.jet
10.10.11.54     drip.htb mail.drip.htb dev-a3f1-01.drip.htb
10.10.27.44	escape.thm