تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

واجهة برمجة التطبيقات Cloud DNS ResourceRecordSets

1. مقدمة

تاريخ آخر تعديل: 2021-01-06

ما هو Cloud DNS؟

ما الذي ستنشئه

في هذا الدرس التطبيقي حول الترميز، ستنشئ Cloud DNS ManagedZone وResourceRecordSets ذات الصلة باستخدام gcloud لإدارة دقة الاسم على مثيل جهاز افتراضي (VM).

المعلومات التي ستطّلع عليها

كيفية إنشاء وقراءة وحذف وتحديث ResourceRecordSets فردي.

المتطلبات

2. بدء الإعداد

إعداد مشروع Google Cloud Platform

تسجيل الدخول إلى gcloud

gcloud auth login

إنشاء مشروع

gcloud projects create my-codelab-project

تفعيل Cloud DNS API

gcloud services enable dns.googleapis.com

قد يستغرق تنفيذ هذا الإجراء بضع دقائق.

3- إنشاء منطقة مُدارة خاصة

تحتوي ManagedZone على ResourceRecordSets.

دوِّن اسم النطاق الذي تريد إضافة سجلّات نظام أسماء النطاقات له. في هذا المثال، سنستخدم "my-domain.com" ونفترض أن مثيل جهازك الافتراضي على الشبكة التلقائية.

gcloud dns managed-zones create my-zone \
    --description="ManagedZone for Cloud DNS ResourceRecordSets codelab." \
    --dns-name=my-domain.com. \
    --networks=default \
    --visibility=private

4. إدارة ResourceRecordSets

في نهاية هذا القسم، ستحل طلبات نظام أسماء النطاقات عبر الشبكة الافتراضية الخاصة لنطاقك إلى عنوان IP للجهاز الافتراضي.

على سبيل المثال، إذا كان عنوان IP لجهازك الافتراضي هو "1.2.3.4"، وكنت تريد "my-domain.com". لحله إلى عنوان IP هذا، يجب عليك إنشاء "سجل A".

إنشاء سجلّ A

gcloud dns record-sets create "my-domain.com." --type="A" --ttl="60" --rrdatas="1.2.3.4" --zone="my-zone"

وسيطة الموضع "my-domain.com". ، والمعروف أيضًا باسم dnsName، هو الاسم الذي نريد تعريف تحليل DNS له.
–type: تشير إلى نوع سجلّ نظام أسماء النطاقات الذي نحاول إنشاءه.
–ttl: تشير إلى الوقت المستغرَق في حفظ هذا السجلّ.
–rrdatas: تحتوي على الإجابة الفعلية لطلب البحث.
–zone: مطلوبة لتوجيه منطقة ManagedZone التي يجب إنشاء هذا السجلّ فيها.

يمكنك الاطّلاع على مزيد من المعلومات حول مفاهيم نظام أسماء النطاقات هنا.

والآن بعد أن أنشأت سجل A، من المفترض أن تتمكن من اختبار التحويل باستخدام نظام أسماء النطاقات (DNS).

بروتوكول النقل الآمن إلى جهازك. في هذا المثال، نستخدم مثيلاً للجهاز الافتراضي (VM) بالاسم "dns-codelab" في "us-central1-a"

gcloud compute ssh codelab --zone=us-central1-a

ثبِّت برامج dnsutils لتتمكّن من استخدام الزرّdig. Command

sudo apt install dnsutils

الاستعلام عن النطاق

dig my-domain.com.

يُفترض أن ينتج عن ذلك مخرجات مشابهة

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19979
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;my-domain.com.                        IN        A

;; ANSWER SECTION:
my-domain.com.                60        IN        A        1.2.3.4
...

إنشاء سجلّ CNAME وتصحيحه والحصول عليه

الآن بعد أن تم تعيين my-domain.com. إلى 1.2.3.4، فربما تريد التأكد من أن www.my-domain.com. إلى 1.2.3.4 أيضًا. سجلات لـ "www. " لا يتم إنشاء البادئات تلقائيًا.

في حالة طلب البحث عن www.my-domain.com.

dig www.my-domain.com.

ستحصل على مخرجات مشابهة

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61964
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...

الإشارة إلى عدم وجود سجل نظام أسماء نطاقات لهذا النطاق

وبدلاً من إنشاء سجلّ A آخر، يجب إنشاء سجلّ CNAME والذي يشير إلى سجلّ آخر. وسيمنعنا ذلك من الاضطرار إلى تغيير كلا السجلين في حال أردنا استخدام عنوان IP مختلف.

الخروج من جلسة تثبيت الجهاز الافتراضي

exit

إنشاء سجلّ CNAME

gcloud dns record-sets create "www.my-domain.com." --type="CNAME" --ttl="60" --rrdatas="my-domin.com." --zone="my-zone"

الآن بعد أن أنشأت سجل CNAME، من المفترض أن تتمكن من اختبار التحويل باستخدام نظام أسماء النطاقات (DNS).

بروتوكول النقل الآمن إلى جهازك مرة أخرى

gcloud compute ssh codelab --zone=us-central1-a

الاستعلام عن النطاق

dig www.my-domain.com.

يُفترض أن تكون قد تلقيت مخرجات مشابهة

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61964
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...

يا للهول! يبدو أنه كان هناك خطأ إملائي عند إنشاء سجل CNAME الخاص بنا على " –rrdatas" . وبدلاً من حذف السجل وإعادة إنشائه، يمكننا تصحيح التغيير الصحيح.

الخروج من مثيل الجهاز الافتراضي

exit

تصحيح سجلّ CNAME

gcloud dns record-sets update "www.my-domain.com." --type="CNAME" --rrdatas="my-domain.com." --zone="my-zone"

لاحظ أنه يمكننا حذف "–ttl" لأنّنا لن نغيّرها، ولكن يجب تضمين جميع العلامات الأخرى لأنّها جزء من المعرّف الفريد العام لـ ResourceRecordSet.

يمكننا أيضًا التحقق من أن السجل كما هو متوقع باستخدام gcloud

gcloud dns record-sets describe "www.my-domain.com." --type="CNAME" --zone="my-zone"

وهو ما يُفترض أن ينتج عنه مخرجات

NAME                    TYPE    TTL  DATA
www.my-domain.com.      CNAME   60  "my-domain.com."

التحقق من أن سجل CNAME يتم تحليله بشكل صحيح

gcloud compute ssh codelab --zone=us-central1-a

dig www.my-domain.com.

يُفترض أن تكون قد تلقيت مخرجات مشابهة

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7471
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;www.my-domain.com.                IN        A

;; ANSWER SECTION:
www.my-domain.com.        60        IN        CNAME         my-domain.com..
...

الحذف للحذف

قبل حذف منطقة مُدارة، يجب أولاً حذف جميع ResourceRecordSets داخل ManagedZone (باستثناء سجلّات NS وSOA التي يتم إنشاؤها تلقائيًا ويجب أن تكون موجودة دائمًا في ManagedZone).