Cloud OnAir: Networking 105: How to use GCP DNS

In this 5th and final installment of our series on networking on Google Cloud Platform, you'll learn about Domain Name Service best practices and how to use GCP DNS.

[@paulinemorare5509]

❤ Thanks. You've poured your heart off. I now have an idea on how to organize my GCP.

[@kirylxs172]

Easy to understand and covers all basics. Great

[@anushavengsarkar6299]

Thanks alot Ryan. was waiting for this one for long.

[@Suresh_Kannan]

Another awesome presentation from both of you.... Keep doing 👍👍 and we can learn more

[@mohantyicm]

Amazing session. One I was looking out for before GCP PCNE cert.

[@psengupta21]

Awesome Video!!

[@ravichanderkt326]

Thanks lord, finally completed the full playlist and its one of my favorite 🙌❤. Thanks Stephanie and Ryan you guys Rocking:)

[@hugobarcinilla6414]

Xx

[@spookymv]

I can't understand the pricing. I would appreciate it if someone could do a cloud dns vs route 53 price comparison video

[@maharajap6690]

couldnt find any document related ANS on google cloud platform. Please share if have any

[@mithung30]

We want to connect grom GCP machine to on-prem Domain Controller server to join the GCP virtaul machine with that domain. Irrespective of the VMs reside in On-prem or in GCP, the domain should be same as defined in the Domain Controller. How to do that? Just a cloud DNS forwarding zone in GCP is sufficient? or we need something also to on-prem domain controller so that it can accept the DNS request from GCP?

[@shashantpanwar4711]

Are you able to resolve it?

[@mthangav]

The explanation of Google DNS overview is good; however, Google's architecture/implementation of DNS Proxy to point to the on-premise DNS is a flawed design for the following reasons:
It masks the source of the original VM IP that makes the DNS query, leaving the on-premise DNS unaware of the real DNS querier.
GCP subnets spread across different regions need to peer to one central subnet for DNS proxy to avoid self-generated routing issues created due to the poor architecture.
This hub-and-spoke DNS peering would add significant latency for name resolution across regions.
There is definitely a lot of scope for Google to improve on this. Google should learn from the way Azure simplifies operations without generating caveats and operational overhead.

[@arifulislamleeton]

Hi I'm Ariful Islam Leeton I'm software engineer

[@nguyenchicuong885]

Galaxy A20s của Cuong

[@KenSherman]

I know Ryan knows his stuff & is eager but my only complaint is that Ryan keeps cutting Stephanie off A LOT before she gets the chance to finish. It's as if she is forced to ineffectively rush out her thoughts before being interjected. Allowing others the chance to finish shows many positive & healthy traits too many for me to list.
However 2, in particular, out of many are wisdom and patience. I hate for it to be a situation where I would miss something valuable, especially from her DevOps point of view, that she would have said because she wasn't allowed the chance to finish despite any time constraints. If there were any time constraints, then discussing these topics should've been in a different format.
Take it from their CEO, Sundar, who allow others to finish before he speaks. I guess that's 1 reason why he's the CEO.
Effective communication reduces confusion. Allowing others to completely finish their talking points shows a more concise and clear discussion as well as respect among others.
8:00
Glad someone is clearly explaining this (without assumptions).
9:18-10:04
Another GOOD question!