קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
Cloud DNS משתמש בתהליך הבא כדי לענות על שאילתות ממכונות וירטואליות (VM) של Compute Engine ומצמתים של Google Kubernetes Engine (GKE).
במכונות וירטואליות של Compute Engine שאינן צמתים של GKE, Cloud DNS פועל לפי סדר הרזולוציה של רשתות VPC כדי לעבד את השאילתות שהוא מקבל. צריך להגדיר כל מכונה וירטואלית כך שתשתמש בכתובת ה-IP של שרת המטא-נתונים (169.254.169.254) כשרת השמות שלה.
התאמה באמצעות כללים בכללי התגובה ברמת האשכול של GKE. Cloud DNS סורק את כל כללי התגובה הרלוונטיים ברמת האשכולות של GKE כדי למצוא כלל שבו מאפיין השם של ה-DNS תואם לחלק הגדול ביותר האפשרי מהשאילתה. Cloud DNS משתמש בהתאמה של הסיומת הארוכה ביותר כדי לסרוק מדיניות תגובה ברמת האשכולות.
אם Cloud DNS מוצא כלל תואם של מדיניות תגובה וגם הכלל מספק נתונים מקומיים, Cloud DNS מחזיר את הנתונים המקומיים בתור התגובה שלו, וכך מסיים את תהליך פתרון השם.
אם Cloud DNS מוצא כלל תואם של מדיניות התגובה וגם ההתנהגות של הכלל עוקפת את מדיניות התגובה, Cloud DNS ממשיך לשלב הבא.
אם Cloud DNS לא מצליח למצוא מדיניות תגובה תואמת או אם אין מדיניות תגובה רלוונטית ברמת האשכולות עבור הצומת, Cloud DNS ממשיך לשלב הבא.
התאמת רשומות באזורים פרטיים ברמת האשכולות. מערכת Cloud DNS סורקת את כל התחומים הפרטיים המנוהלים ברמת האשכולות כדי למצוא רשומה שתתאים לחלק הגדול ביותר של השאילתה. ב-Cloud DNS נעשה שימוש בהתאמה של הסיומת הארוכה ביותר כדי למצוא רשומות בתחומים פרטיים ברמת האשכולות.
אם ההתאמה הספציפית ביותר לשאילתה היא שם תחום של תחום פרטי ברמת האשכולות, Cloud DNS משתמש בנתוני הרשומה של התחום הזה כדי לפתור את הבקשה.
אם קיימת רשומה בתחום שתואמת בדיוק לשאילתה, Cloud DNS מחזיר את הנתונים של הרשומה הזו.
אם התחום לא מכיל רשומה תואמת, Cloud DNS מחזיר את הערך NXDOMAIN.
אם ההתאמה הספציפית ביותר לשאילתה היא שם התחום של תחום העברה ברמת האשכולות, Cloud DNS מעביר את השאילתה לאחד מיעדי ההעברה של תחום ההעברה כדי להשלים את תהליך פתרון השמות. Cloud DNS מחזיר אחת מהתגובות הבאות.
התגובה שהתקבלה מיעד ההעברה.
תגובה מסוג SERVFAIL, אם יעד ההעברה לא מגיב ל-Cloud DNS.
אם השאילתה לא תואמת לאף תחום פרטי ברמת האשכולות, המערכת של Cloud DNS ממשיכה לסדר פתרון של רשתות VPC.
סדר פתרון של רשת VPC
התאמה באמצעות שרת שמות חלופי של רשת VPC. אם לרשת ה-VPC יש מדיניות שרת יוצאת, השאילתה מועברת על ידיGoogle Cloud לאחד משרתי השמות החלופיים שהוגדרו במדיניות הזו כדי להשלים את תהליך פתרון השמות.
אם יש שני שרתי שמות חלופיים או יותר במדיניות השרת של תעבורת הנתונים היוצאת, Cloud DNS מדרג את שרתי השמות החלופיים באמצעות אלגוריתם פנימי. כששרתי השמות החלופיים מתחילים באותה דרגה, הדירוג שלהם עולה בהתאם לשיעור גבוה יותר של תשובות מוצלחות (כולל תשובות NXDOMAIN) וגם בהתאם לזמן הנסיעה הלוך ושוב הקצר ביותר (זמן האחזור הנמוך ביותר לתגובה).
Cloud DNS שולח שאילתות לשרתי שמות חלופיים ומחזיר תשובות לפי התהליך הבא.
אם יש שני שרתי שמות חלופיים או יותר במדיניות השרתים היוצאים, Cloud DNS שולח את השאילתה קודם לשרת השמות החלופי בעל הדירוג הגבוה ביותר, ואז לשרת השמות החלופי בעל הדירוג הבא, אם Cloud DNS לא מקבל תגובה משרת השמות החלופי בעל הדירוג הגבוה ביותר. אם Cloud DNS לא מקבל תשובה משרת השמות החלופי במקום הבא בדירוג, הוא ממשיך לשלוח שאילתות לשרתי שמות חלופיים לפי דירוג יורד עד שהוא מגיע לסוף הרשימה של שרתי השמות החלופיים.
אם Cloud DNS מקבל תגובה משרת שמות חלופי, הוא מחזיר את התגובה הזו. התשובות כוללות NXDOMAIN תשובות.
אם Cloud DNS לא מקבל תגובה מכל שרתי השמות החלופיים במדיניות השרתים היוצאים, הוא יוצר תגובה מסוג SERVFAIL. במאמר דרישות הרשת של שרתי שמות חלופיים מוסבר איך לפתור בעיות שקשורות לקישוריות של שרתי שמות חלופיים.
אם לרשת ה-VPC אין מדיניות שרת של תעבורת נתונים יוצאת, Cloud DNS ממשיך לשלב הבא.
התאמה באמצעות כללים במדיניות התגובה ברמת הרשת של VPC. Cloud DNS סורק את כל כללי התגובה הרלוונטיים של רשתות VPC כדי למצוא כלל שבו מאפיין שם ה-DNS תואם לחלק הגדול ביותר האפשרי של השאילתה. Cloud DNS משתמש בהתאמה של הסיומת הארוכה ביותר כדי לסרוק את כללי מדיניות התגובה ברמת הרשת של VPC.
אם Cloud DNS מוצא כלל תואם של מדיניות תגובה וגם הכלל מציג נתונים מקומיים, Cloud DNS מחזיר את הנתונים המקומיים בתור התגובה שלו, וכך מסיים את תהליך פתרון השם.
אם Cloud DNS מוצא כלל תואם של מדיניות התגובה וגם ההתנהגות של הכלל עוקפת את מדיניות התגובה, Cloud DNS ממשיך לשלב הבא.
אם Cloud DNS לא מצליח למצוא מדיניות תגובה תואמת או אם אין מדיניות תגובה רלוונטית ברמת הרשת של VPC למכונה הווירטואלית או לצומת, Cloud DNS ממשיך לשלב הבא.
התאמת רשומות בתחומים פרטיים מנוהלים ברמת הרשת של VPC.
Cloud DNS סורק את כל התחומים הפרטיים המנוהלים שמוסמכים לרשת ה-VPC כדי למצוא רשומה שתתאים לחלק הגדול ביותר של השאילתה. כדי למצוא רשומות, Cloud DNS משתמש בהתאמה של הסיומת הארוכה ביותר.
אם ההתאמה הספציפית ביותר לשאילתה היא שם תחום של תחום פרטי ברמת הרשת של VPC, Cloud DNS משתמש בנתוני הרשומה של אותו תחום כדי לפתור את הבקשה.
אם הדומיין מכיל רשומה שתואמת בדיוק לשאילתה, Cloud DNS מחזיר את נתוני הרשומה.
אם התחום לא מכיל רשומה תואמת, Cloud DNS מחזיר את הערך NXDOMAIN.
אם ההתאמה הספציפית ביותר לשאילתה היא שם האזור של תחום העברה ברמת הרשת של VPC, Cloud DNS מעביר את השאילתה לאחד מיעדי ההעברה של תחום ההעברה כדי להשלים את תהליך פענוח השם. Cloud DNS מחזיר אחת מהתגובות הבאות.
התגובה שהתקבלה מיעד ההעברה.
תגובה מסוג SERVFAIL, אם יעד ההעברה לא מגיב ל-Cloud DNS.
אם ההתאמה הספציפית ביותר לשאילתה היא שם של תחום שיתוף ברמת הרשת של VPC, Cloud DNS מפסיק את תהליך פתרון השמות הנוכחי ומתחיל תהליך חדש של פתרון שמות מנקודת המבט של רשת ה-VPC היעד של תחום השיתוף.
אם השאילתה לא תואמת לתחום פרטי, לתחום העברה או לתחום שיתוף (peering), Cloud DNS ממשיך לשלב הבא.
התאמת רשומות בתחומים הפנימיים של Compute Engine.
Cloud DNS סורק את כל התחומים הפנימיים של DNS ב-Compute Engine כדי למצוא רשומה שתתאים לחלק הגדול ביותר של השאילתה. כדי למצוא רשומות, Cloud DNS משתמש בהתאמה של הסיומת הארוכה ביותר.
אם ההתאמה הספציפית ביותר לשאילתה היא שם DNS פנימי של Compute Engine, Cloud DNS מחזיר בתגובה את כתובת ה-IP הפנימית של ממשק הרשת של המכונה הווירטואלית או את הפונקציה להפניה לאחור (reverse lookup) שלה, וכך מסיים את תהליך פתרון השם.
התאמת רשומה באמצעות שאילתת DNS ציבורית. Google Cloud ממשיך אחרי רשומת התחלת הרשות (SOA) כדי לשלוח שאילתות לגבי תחומים שזמינים לכולם, כולל תחומים ציבוריים של Cloud DNS. Cloud DNS מחזיר אחת מהתגובות הבאות.
התגובה שהתקבלה משרת שמות מוסמך.
תגובה מסוג NXDOMAIN, אם הרשומה לא קיימת.
דוגמה
נניח שיש לכם שתי רשתות VPC, vpc-a ו-vpc-b, אשכול GKE, cluster-a, וגם את המשאבים הבאים ברמת ההיקף הבאה:
ל-vpc-a יש הרשאה לשלוח שאילתות לגבי האזורים הפרטיים הבאים. שימו לב לנקודה בסוף כל רשומה:
static.example.com.
10.internal.
peer.com. הוא תחום peering שיכול לשלוח שאילתה להזמנת פתרון השמות של VPC vpc-b.
vpc-a לא משויך לשרתים או למדיניות תגובה כלשהם של יציאה.
ל-cluster-a יש הרשאה לשלוח שאילתות לגבי תחום פרטי בשם example.com.
cluster-a לא משויך גם לשרתים של תעבורת נתונים יוצאת או למדיניות תגובה כלשהי.
מכונה וירטואלית ב-cluster-a יכולה לשלוח שאילתות:
example.com וילדים (כולל static.example.com), שעונים על ידי האזור הפרטי שנקרא example.com, עם הרשאה ל-cluster-a.
10.internal ב-vpc-a.
peer.com באמצעות תחום ה-peering.
מכונה וירטואלית שלא נמצאת ב-cluster-a יכולה להריץ שאילתות:
static.example.com וילדים, ותשובות יישלחו מהתחום הפרטי שנקרא static.example.com מורשה ל-vpc-a. שאילתות עבור example.com מחזירות תגובות מהאינטרנט.
10.internal ב-vpc-a.
peer.com באמצעות תחום ה-peering.
המאמרים הבאים
במאמר פתרון בעיות מפורטות פתרונות לבעיות נפוצות שעשויות להתרחש במהלך השימוש ב-Cloud DNS.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["התוכן קשה להבנה","hardToUnderstand","thumb-down"],["שגיאות בקוד לדוגמה או במידע","incorrectInformationOrSampleCode","thumb-down"],["חסרים לי פרטים או דוגמאות","missingTheInformationSamplesINeed","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-06-27 (שעון UTC)."],[[["\u003cp\u003eCloud DNS handles queries from Compute Engine VMs by following the VPC network resolution order, with each VM needing to use the metadata server IP address (169.254.169.254) as its name server.\u003c/p\u003e\n"],["\u003cp\u003eFor GKE nodes, Cloud DNS first attempts to match queries using cluster-scoped response policies and private zones before proceeding to the VPC network resolution order.\u003c/p\u003e\n"],["\u003cp\u003eThe VPC network resolution order involves matching queries against alternative name servers, VPC network-scoped response policies, managed private zones, Compute Engine internal zones, and finally, public DNS queries.\u003c/p\u003e\n"],["\u003cp\u003eLongest-suffix matching is utilized by Cloud DNS to scan cluster-scoped and VPC network-scoped resources for records or rules that match queries.\u003c/p\u003e\n"],["\u003cp\u003eOutbound server policies help reroute queries through alternative name servers, which are ranked based on response success rates and latency, for a faster resolution.\u003c/p\u003e\n"]]],[],null,["# Name resolution order\n\nCloud DNS uses the following procedure to answer queries from\nCompute Engine virtual machine (VM) instances and\nGoogle Kubernetes Engine (GKE) nodes.\n\nFor Compute Engine VMs other than GKE nodes,\nCloud DNS follows the [VPC network resolution\norder](#vpc_steps) to process queries it receives. Each VM must be configured to\nuse the metadata server IP address (`169.254.169.254`) as its name server.\n\nFor GKE nodes:\n\n1. Cloud DNS first attempts to match a query using [cluster-scoped\n response policies and private zones](#gke_steps).\n\n2. Cloud DNS continues by following the [VPC network\n resolution order](#vpc_steps).\n\nCluster-scoped response policies and private zones\n--------------------------------------------------\n\n1. **Match using rules in GKE cluster-scoped response\n policies**. Cloud DNS scans all applicable GKE\n cluster-scoped response policies for a rule where the DNS name attribute\n matches as much of the query as possible. Cloud DNS uses\n longest-suffix matching to scan cluster-scoped response policies.\n\n 1. If Cloud DNS finds a matching response policy rule *and* the\n rule serves local data, then Cloud DNS returns the local\n data as its response, completing the name resolution process.\n\n 2. If Cloud DNS finds a matching response policy rule *and* the\n rule's behavior bypasses the response policy, then Cloud DNS\n continues to the next step.\n\n 3. If Cloud DNS fails to find a matching response policy *or* if\n there isn't an applicable cluster-scoped response policy for the node,\n then Cloud DNS continues to the next step.\n\n2. **Match records in cluster-scoped private zones**. Cloud DNS scans\n all cluster-scoped managed private zones for a record that matches as much of\n the query as possible. Cloud DNS uses longest-suffix matching to\n find records in cluster-scoped private zones.\n\n 1. If the most specific match for the query is the zone name of a\n cluster-scoped private zone, Cloud DNS uses that zone's record\n data to resolve the request.\n\n - If the zone contains a record that exactly matches the query, Cloud DNS returns that record's data.\n - If the zone doesn't contain a matching record, Cloud DNS returns `NXDOMAIN`.\n 2. If the most specific match for the query is the zone name of a\n cluster-scoped forwarding zone, then Cloud DNS forwards the\n query to one of the forwarding zone's forwarding targets to complete the\n name resolution process. Cloud DNS returns one of the following\n responses.\n\n - The response received from the forwarding target.\n - A `SERVFAIL` response, if the forwarding target doesn't respond to Cloud DNS.\n 3. If the query doesn't match any cluster-scoped private zone,\n Cloud DNS continues to the [VPC network\n resolution order](#vpc_steps).\n\nVPC network resolution order\n----------------------------\n\n1. **Match using VPC network alternative name server** . If the\n VPC network has an [outbound server\n policy](/dns/docs/server-policies-overview#dns-server-policy-out),\n Google Cloud forwards the query to one of the [alternative name\n servers](/dns/docs/server-policies-overview#altns-targets) defined in that\n policy to complete the name resolution process.\n\n If two or more alternative name servers exist in the outbound server\n policy, Cloud DNS ranks the alternative name servers using an\n internal algorithm. Beginning with equal ranks, alternative name servers\n increase in rank based on higher rates of successful responses (including\n `NXDOMAIN` responses) *and* based on the shortest round-trip time (the lowest\n response latency).\n\n Cloud DNS sends queries to alternative name servers and returns\n responses using the following process.\n - If two or more alternative name servers exist in the outbound server\n policy, Cloud DNS first sends the query to the highest-ranked\n alternative name server, then to the next-ranked alternative name\n server if Cloud DNS does *not* receive *any* response from the\n highest-ranked alternative name server. If Cloud DNS doesn't\n receive any response from the next-ranked alternative name server,\n Cloud DNS continues to query alternative name servers by\n descending rank until it exhausts the list of alternative name servers.\n\n - If Cloud DNS receives a response from an alternative name\n server, Cloud DNS returns that response. Responses include\n `NXDOMAIN` responses.\n\n - If Cloud DNS does *not* receive a response from *all*\n alternative name servers in the outbound server policy,\n Cloud DNS synthesizes a `SERVFAIL` response. To troubleshoot\n alternative name server connectivity, see [Alternative name server\n network requirements](/dns/docs/server-policies-overview#altns-net-req).\n\n If the VPC network does *not* have an outbound server policy,\n Cloud DNS continues to the next step.\n2. **Match using rules in VPC network-scoped response\n policies**. Cloud DNS scans all applicable VPC\n network response policies for a rule where the DNS name attribute matches\n as much of the query as possible. Cloud DNS uses longest-suffix\n matching to scan VPC network-scoped response policies.\n\n 1. If Cloud DNS finds a matching response policy rule *and* the\n rule serves local data, then Cloud DNS returns the local data\n as its response, completing the name resolution process.\n\n 2. If Cloud DNS finds a matching response policy rule *and* the\n rule's behavior bypasses the response policy, then Cloud DNS\n continues to the next step.\n\n 3. If Cloud DNS fails to find a matching response policy *or* if\n there isn't an applicable VPC network-scoped response\n policy for the VM or node, then Cloud DNS continues to the next\n step.\n\n3. **Match records in VPC network-scoped managed private zones**.\n Cloud DNS scans all managed private zones authorized for the\n VPC network for a record that matches as much of the query as\n possible. Cloud DNS uses longest-suffix matching to find records.\n\n 1. If the most specific match for the query is the zone name of a\n VPC network-scoped private zone, Cloud DNS uses that\n zone's record data to resolve the request.\n\n - If the zone contains a record that exactly matches the query, Cloud DNS returns the record's data.\n - If the zone doesn't contain a matching record, Cloud DNS returns `NXDOMAIN`.\n 2. If the most specific match for the query is the zone name of a\n VPC network-scoped forwarding zone, then Cloud DNS\n forwards the query to one of the forwarding zone's forwarding targets to\n complete the name resolution process. Cloud DNS returns one of\n the following responses.\n\n - The response received from the forwarding target.\n - A `SERVFAIL` response, if the forwarding target doesn't respond to Cloud DNS.\n 3. If the most specific match for the query is the name of a VPC\n network-scoped peering zone, Cloud DNS stops the current name\n resolution process and begins a new name resolution process from the\n perspective of the peering zone's target VPC network.\n\n If the query doesn't match a private zone, forwarding zone, or peering zone,\n Cloud DNS continues to the next step.\n4. **Match records in Compute Engine internal zones** .\n Cloud DNS scans all applicable [Compute Engine\n internal DNS zones](/compute/docs/internal-dns) for a record that matches as\n much of the query as possible. Cloud DNS uses longest-suffix\n matching to find records.\n\n 1. If the most specific match for the query is a Compute Engine internal DNS name, Cloud DNS returns the internal IP address of the VM's network interface or its reverse lookup pointer as its response, completing the name resolution process.\n5. **Match record using public DNS query**. Google Cloud follows the\n start of authority (SOA) record to query publicly available zones, including\n Cloud DNS public zones. Cloud DNS returns one of the\n following responses.\n\n - The response received from an authoritative name server.\n - An `NXDOMAIN` response, if the record doesn't exist.\n\nExample\n-------\n\nSuppose that you have two VPC networks, `vpc-a` and `vpc-b`, and\na GKE cluster, `cluster-a`, along with the following scoped\nresources:\n\n1. `vpc-a` is authorized to query the following private zones. Note the trailing\n dot in each entry:\n\n - `static.example.com.`\n - `10.internal.`\n2. `peer.com.` is a peering zone that can query the VPC\n name resolution order of `vpc-b`.\n\n3. `vpc-a` is not associated with any outbound server or response policies.\n\n4. `cluster-a` is authorized to query a private zone called `example.com`.\n `cluster-a` is also not associated with any outbound server or response\n policies.\n\n5. A VM in `cluster-a` can query:\n\n - `example.com` and children (including `static.example.com`), answered by the private zone called `example.com`, authorized to `cluster-a`.\n - `10.internal` on `vpc-a`.\n - `peer.com` by using the peering zone.\n6. A VM that is *not* in `cluster-a` can query:\n\n - `static.example.com` and children, answered by the private zone called `static.example.com` authorized to `vpc-a`. Queries for `example.com` return internet responses.\n - `10.internal` on `vpc-a`.\n - `peer.com` by using the peering zone.\n\nWhat's next\n-----------\n\n- To find solutions for common issues that you might encounter when using Cloud DNS, see [Troubleshooting](/dns/docs/troubleshooting).\n- To get an overview of Cloud DNS, see [Cloud DNS overview](/dns/docs/overview).\n- To learn how to configure response policies, see [Manage response policies\n and rules](/dns/docs/zones/manage-response-policies)."]]
