[MUSIC PLAYING] STEPHANIE WONG: Hey, everyone. Welcome to Cloud OnAir, live
webinars from Google Cloud. You are watching Cloud
101, where we dive deep into cloud solutions and
learning for cloud developers. Today, we're going to be talking
about how to use GCP DNS. You can ask
questions at any time by submitting them in
the box below the screen. We'll have Googlers on
standby to answer them. So let's go ahead
and get started. So here again, we
have Ryan Przybyl back for another session
of networking. He is a Cloud Customer Engineer
and Networking Specialist, and I'm Stephanie Wong,
Developer Advocate. I'll pass it off to you,
Ryan, so we can get started. RYAN PRZYBYL: Thanks, Stephanie. So what we're going
to cover today is, really quick, a
general overview of DNS. I assume the audience doesn't
have any experience with DNS, so I'm to cover some basics. Then we'll jump into, sort
of, our products and features. Then I'll go through
some DNS architectures, and then we'll
jump into the Q&A. So let's start with just
a general overview of DNS. DNS uses a lot of
terminology that can be somewhat unique to
people that deal with DNS. Here's a few
things, but the ones I really want to get across
are knowing what records are. So we call A or quad A records. These are really the
file that contains the IP address for something. So whether it's
www.ryanprzybyl.com when you want to get to
that, you need to know what is the IP address
for that, right? So the record is what
actually contains, hey, this is your domain
and this is the IP address that you're trying to get to. The other one is the zone file. The zone file actually
is the zone construct that contains all
of the records, OK? So there are some
other things in here, but those are really
the ones that I want people to
understand because we're going be talking about those as
we talk about DNS as it relates to GCP. So real quick, if you've
never sort of gotten into DNS, this is the very,
very high-level primer of how DNS works. So when you're at your
PC or you're at a client and your client needs
to access something, it's going to talk
to a resolver. In this case I'm trying
a recursive resolver. That recursive resolver
is going to say, hey either I have the
IP address for what you're trying to get to-- right,
so I've cached it, that record, or I need to go out and find
it somewhere in the world. So one way that can
work is the client talks to the resolver
or the resolver responds back to the client. You have the IP
address and you can go to whatever you're
trying to reach. In the other case, if the
resolver doesn't have it, the resolver is going to reach
out to somebody else, right? So in this case, I'm showing
an authoritative server that's going to get the
information it needs, cache it in the resolver, and then
pass it back to the client. So that's sort of at a
very, very high level. If you've never dealt
with DNS, that's kind of the process that's
happening behind the scenes. STEPHANIE WONG: Yeah. Is there any kind of
noticeable latency if the recursive resolver has
to redirect to another server? RYAN PRZYBYL: Yeah, I
mean, there's a little bit. So, like, if you're ever,
like, browsing the web and you see things are
taking a little bit longer, it could be the resolver's
trying to figure out something. STEPHANIE WONG: Right. RYAN PRZYBYL: Typically, if
it's something you go to a lot, it's cached in the resolver
and it's instantaneous. STEPHANIE WONG: OK. Yeah. RYAN PRZYBYL: When
it comes to Cloud, not so much because
a lot of times you're telling it
specifically where all those authoritative
servers live. So it's not trying to go
and say, does it live here? Does it live there or
does it live there? It knows exactly
where it's going. STEPHANIE WONG:
Is there some sort of a dynamic routing
mechanism, where it's, like, trying to choose
the closest server possible? RYAN PRZYBYL: It
sort of depends. Generally speaking,
yes, it's going to go to something that's close. Like, if you're using
Google DNS, when I talk about Google DNS,
you want public DNS, right? It's going to route
it to the closest, sort of, DNS server
that we have, based on where your
request is coming from. STEPHANIE WONG: Gotcha, OK. RYAN PRZYBYL: OK, so let's talk
about GCP and our DNS product and features. So I'm going to go through
a few of these things and then at the
end or farther on, I'm going to talk about
the architectures that support all of them. So back to zones. We talked about zones. These are where the
records actually live. When you're dealing
with DNS in GCP, there's two types of zones. You either have private zones
or you have public zones. A private zone
would be something if you're running a
hybrid environment, and so you're running
something on-prem and you're extending
that on-prem environment into the cloud. So maybe you're running a
dev environment in the cloud. So for example, my domain,
ryanprzybyl.com-- maybe I'm running dev.ryanprzybyl.com
in the cloud. So I might say
dev.ryanprzybyl.com is a private zone in the
cloud that only I can access. Alternatively, you can
have a public zone. So a good example
of this is, say, I wanted to run a business where
I was going to do retail sales and I want to have a web server
that was facing the internet. In that case, I would
have a public zone because it's public. It's internet-facing,
and I would have a different set
of records to access those resources and cloud
that were publicly-facing. So a good example might be
if I was a retailer running a bunch of websites, I might
say Google's public load balancer is going to be
the IP address I use. So the record would actually
point to the IP address and would fan out to my
website on the back side, but that IP address
is public and it's accessible over the internet. STEPHANIE WONG:
OK, so for private, you're using private RFC1918
zone ranges, IP ranges. RYAN PRZYBYL: Yes. You could, in theory, use
non-RFC1918 in there, right? There's nothing saying it
only has to be RFC1918, but when you're
using public zones, it all has to be
public IP addresses, whether it's yours or
Google's or somebody else's. STEPHANIE WONG: OK. Yep, that makes sense. RYAN PRZYBYL: OK, so there's
this concept of split horizon. So take those two
concepts we just talked about, private and public,
and combine them together, and that's really
what split horizon is when you hear that term. So a good example might be I'm
running a VM in Google Cloud, and that VM has two
interfaces on it-- one with a public IP,
one with a private IP. So if I'm coming from
my corp environment, maybe I want to access the
private IP address on that VM, so I would use a private zone
to do that, while somebody coming in from the
internet to access that VM would use the public zone. When you combine
those two, we call it split horizon because you
have something where you have a private zone and a
public zone both accessing the same sort of resource. STEPHANIE WONG:
And you can-- you do this because your VM might
be able to have two network interfaces. RYAN PRZYBYL: Exactly. You could have a
network interface with an RFC1918 address
that's not publicly routable, and you could have an IP
address on another NIC that is actually
publicly addressable-- STEPHANIE WONG: Right. RYAN PRZYBYL: --so it's
reachable from the internet. STEPHANIE WONG: Does it matter
whether the client is also in the private IP space or just
the destination needs to be? RYAN PRZYBYL: So typically,
if you're coming from say, like, your corp
environment, you're going to be in private IP space. And when you hit your
resolvers, your resolvers are going to know that they're
trying to resolve internally to that private
space, so they're going to resolve to
authoritative servers or zones that are in that private space. If you're coming from
a public IP address, you're going to have a
different set of DNS servers that are typically
responding to your query. STEPHANIE WONG: Yeah. RYAN PRZYBYL: Right. So it kind of depends on
what sort of infrastructure you're coming from--
whether you're coming from the
public infrastructure or whether you're coming from
your private infrastructure. STEPHANIE WONG: Yeah. And you might answer this
later, but do firewall rules and that sort of
thing still apply here in terms of protecting from? RYAN PRZYBYL: They do, but
more so on the private side, not too much on the public side. I mean, you can have firewall
rules on the public side, but if you're wanting
public access to it, then you want to open things up. STEPHANIE WONG: Oh, yeah. Yeah, that makes sense. RYAN PRZYBYL: OK, so let's
talk about DNS forwarding real quick. So DNS forwarding really
comes in two types. There's outbound forwarding
and there's inbound forwarding. So outbound forwarding is
where you have a subdomain. So let's use
dev.ryanprzybyl.com again. That's my subdomain
under ryanprzybyl.com. If I'm doing
outbound forwarding, I'm basically saying
for dev.ryanprzybyl.com, I don't want it to
resolve within the cloud. I want it to resolve,
say, on-prem. So I'm telling the DNS in
the private environment, go to on-prem to resolve
the IP address for, you know, machinelearning.
dev.ryanprzybyl.com That's outbound forwarding. I'm forwarding the request
out of GCP to, say, an on-prem environment. Inbound forwarding is the
exact opposite of that. So that's where you
go on-prem and you say maybe I'm running
dev.ryanprzybyl.com in GCP. So in your on-prem
environment, you're saying, I don't want to resolve that in
my on-prem DNS infrastructure. I want to actually forward
that request to GCP. So from a GCP
perspective, that request is coming inbound, right? STEPHANIE WONG: Right. RYAN PRZYBYL: So
same scenario, right? It's just are you forwarding
the request out of GCP? That's outbound forwarding. Or are you sending your
on-prem to forward the request into GCP? And that's what we call
inbound forwarding. STEPHANIE WONG: And this
is when the DNS server is sitting outside
of the network that you're currently using. RYAN PRZYBYL: Yeah, that's
where you have-- maybe you have a BIND server on-prem in
your corporate environment, and you say I want that to
resolve DNS for this subdomain. So you tell the
cloud environment go to that BIND server
to resolve things, to try to resolve it internally. STEPHANIE WONG: Right. And what are some kind of
company use cases that would use this sort of architecture? I'm trying to imagine,
like, hybrid would be one. But why would a company
want to be doing forwarding outside of that? They're either on-prem or
they're GCP environment. RYAN PRZYBYL: That's usually
the main use case, right? So you're running-- maybe your
dev environment is on-prem and you're running
your production environment in the cloud,
or maybe it's vice-versa. So you have authoritative
servers for that and you have the zones created. You're on-prem,
so you're like, I don't want to go and create
a whole bunch more stuff. I just want to tell GCP
to come to the on-prem DNS server or the DNS resolvers to
get the information that they need. STEPHANIE WONG: Yeah. RYAN PRZYBYL: But that's
the most common use case. STEPHANIE WONG:
OK, hybrid, yeah. RYAN PRZYBYL: Yep. The big thing to
know about forwarding is we talked about your
forwarding in and out of GCP. If you're trying to forward
to another VPC, which we'll talk about
in a second, you don't use forwarding to do that. You use something
called peering. So that's the big,
sort of, caveat that I want you to sort
of take away from this is think about forwarding,
inbound or outbound, is into or out of GCP,
not sort of forwarding within the GCP environment. STEPHANIE WONG: I imagine that
if you do go with peering, too, which would be the more
efficient way of doing that or maybe performance
would be better? RYAN PRZYBYL: It's
just different. And I'll talk about
peering in just a second. But really, sort of
think of if you're trying to forward something
across two different VPCs, then you're going to
use peering to do it. If you're trying to say, send
it out of GCP or into GCP, then you're going
to use forwarding for this because you're
inbound or outbound. STEPHANIE WONG: Different
use cases, there, yeah. RYAN PRZYBYL: Yep. The other thing to keep in
mind is when we do forwarding, we use proxies. So there is an IP range that
we use for our DNS proxies that's that 35-block
that I've put there. So that'll come into play when
I talk about the architectures and making sure that you have
this set up right so that when the request is coming
in from that 35-block, you're not sort of blocking
it on-prem and saying, hey, I have this-- I have this tight
firewall rule set that's blocking that 35 block. STEPHANIE WONG: Gotcha. So you definitely
need to check for that and make sure that
that's allowed. RYAN PRZYBYL: And
I'll talk to that when I talk about the
actual architectures and how we would really set
this up in a little more detail. So, DNS peering-- we just
sort of talked about this. This is really where
you want to, say, have a zone somewhere else in GCP. So you can think of two VPCs. So VPC A, I'm telling
it I don't want to resolve this in VPC
A. I have a zone in VPC B and I want you to forward
the request to VPC B. But you're doing it from VPC to
VPC, not like VPC to on-prem. STEPHANIE WONG: Right. RYAN PRZYBYL: Right. So, again, that's that
subtle difference. So sometimes people get
a little confused with, like, when do I use peering? When do I use forwarding? Because it seems like I'm
just forwarding the request. In essence, you
are right, but it's from one VPC to another VPC. STEPHANIE WONG:
And those two VPCs have to already be peered VPCs? RYAN PRZYBYL: No,
you actually don't have to peer the VPCs together. DNS peering is completely
separate than VPC peering. STEPHANIE WONG: That's a good
distinction to make, yeah. RYAN PRZYBYL: Yeah. So most people get
confused, right, because we use the term peering. We use it in a lot
of different ways. In this case, you
don't actually have to have the VPCs peered
together to run DNS peering. STEPHANIE WONG: Gotcha. RYAN PRZYBYL: So let's talk
about alternative name servers real quick. So an alternative
name server is sort of a version of forwarding. So we talked about
forwarding where you're forwarding outside of GCP. An alternative
name server is just saying I want to
forward all requests, so I don't want to use any
sort of Cloud DNS for serving, I want to basically use
something like maybe Infoblox. Maybe you have a BIND
server on-prem that's going to do all of your DNS. So in this case, what you're
doing is you're saying, I have a complete
alternative name server. You're going to put the IP
address of that server in, and it's going to
forward everything there. So when we talk
about forwarding, forwarding can be
specific subdomains. So like I was saying,
dev.ryanprzybyl.com. If you use an
alternative name server, no matter what you're
trying to resolve, it's going to
forward it outside. STEPHANIE WONG: OK. RYAN PRZYBYL: So think of
this as it's very binary. You're either not using
alternative name server and you're sort
of differentiating where you want to
forward different zones or you're using
alternative name server and you're forwarding
everything. STEPHANIE WONG: Gotcha. RYAN PRZYBYL: OK, so that
was a really high-level sort of overview of the
products themselves. So let's go through each of them
and talk about the architecture and how you actually
set it up and give you more of a visual
of how this works. So we'll talk about
alternative name servers first. So in this case, I
have some subnets and I'm running in the VPC
network and I have a policy. And I'll talk about
policies and zones when I actually show
you how to set these up. There's other
infrastructure that has to come into play here. So in this case, I'm using
either a dedicated interconnect or VPN. I also have a Cloud Router. There's a router
on-prem and then there's a subnet on-prem
where I have the actual name servers living in this example. So the first thing
I need to set up is I need to set
the policy to say I'm going to use an
alternative name server policy and forward everything
outside of GCP. And when you do that-- I'll show you how to
do that-- you specify the IP address of what
is the name server that's sitting on-prem. The other thing you have to
do is the Google Cloud router has to have a route to it. So for example, if you say
10.0.1.1 is the name server, you have to be telling the
cloud environment, hey, I have this subnet
10.0.1.0/24, in this case, that lives on-prem. STEPHANIE WONG: Right. RYAN PRZYBYL: So you
need to be advertising that from the router
on-prem to the Cloud Router. That way when the policy
looks to forward it, it actually has a route right. The other thing you've
got to do is verify that no firewall rules are
blocking this up, specifically on-prem. So I talked about the
proxies that we use. So in this case, when
the request happens, it's actually going to go
through our DNS proxies. So the request on-prem is going
to come from an IP address in that 35.199/19 block. So if you've got
firewall rules on-prem, you have to open up
those firewall rules to allow those proxies to talk
to your on-prem environment, right? Even though you
may say, well, I'm not running any of those
in my cloud environment. We use that for
all DNS proxying. STEPHANIE WONG: So just
to clarify a little bit-- so you have to allow the route
from on-premise to GCP coming from your internal IP space,
which would be the 10.0 IP range there. But on the flip
side, you also have to make sure that our DNS
proxy range, which is 35.199, is also being not
blocked coming from GCP to the on-prem environment. RYAN PRZYBYL: Exactly. STEPHANIE WONG: OK. So there's two ways that you
actually have to enforce. RYAN PRZYBYL: So
one is routing, one is more just firewall rules. STEPHANIE WONG:
Firewall rules, yeah. RYAN PRZYBYL: Yep. And the last piece of it
too is, how do you get the-- how do you basically
tell the on-prem about that 35-dot range,
right, because you've basically done routing one way. You've told GCP about
the 10.0.1.0 range and you've told it to route
it over the interconnect. But remember, the request is
coming from the 35-dot range, so the on-prem needs to
understand how do I actually route that back. STEPHANIE WONG: Right. RYAN PRZYBYL: So what you do
is you set up the Cloud Router to actually advertise
that 35-dot block. So now you've got routing
both ways because routing is very unidirectional. So now we figure out how to
route from 10.0.1/24 to the 35 block, and we've also figured
out how to route from the 35 block back to 10.0.1. STEPHANIE WONG: So
the Cloud Router is ultimately
advertising the 35.199 range as opposed to the actual
VMs that you have running. RYAN PRZYBYL: Correct. Well, it's advertising all
the subnets that you have. In a normal case, it would
advertise all of the subnets that you have in GCP, as well. STEPHANIE WONG: OK. RYAN PRZYBYL: You're just adding
an additional route in here to say I need my on-prem
to know about this 35 block because if the on-prem receives
a request from the 35 block proxies and when
it goes to respond to that if it doesn't
know, it's going to say, well, I don't know where
this 35 block lives. So what the Cloud
Router is doing is you're basically telling
it the 35 block lives here in the VPC. STEPHANIE WONG: Yeah. RYAN PRZYBYL: So
one thing to note, something that comes
up a lot with customers in terms of questions
is, we use that 35 block. It's a public IP block. It's a Google public
IP but isn't something that's routable on the internet. So you might have,
for example, if you have just a default
route on-prem and it doesn't know-- if you
haven't done the Cloud Router piece, told it that this block
is going to exist in the Cloud, it might try to route
to that 35 block through just your
internet gateway to go out on the internet,
and it's going to say, well, I know Google
owns that 35 block. It's going to try
to route to Google. The challenge is we
don't advertise that 35 block on the internet. So even though we're
using public IPs to do it, they're not reachable
via the internet. STEPHANIE WONG: Yeah. RYAN PRZYBYL: They're only
reachable via the Cloud environment. STEPHANIE WONG: So
it's not necessarily going to know that it needs
to route to your specific GCP environment. RYAN PRZYBYL: Well, it'll know
that the 35 block that we're using is coming across your
dedicated interconnect or VLAN, so it knows it needs to go back
to your private environment to access that. STEPHANIE WONG: I guess
the main thing here is that you explicitly need
to set up those routes. RYAN PRZYBYL: Exactly. If you don't set up those
routes and you're on-prem, when it tries to
respond to the request-- because the request is
coming from a 35 block and you're, on-prem right? STEPHANIE WONG: Right. RYAN PRZYBYL: So
when the on-prem is trying to talk back to it,
it needs to have a route to it. And if you don't
set up the route, it's probably going
to think, hey, that's just an internet route. It's going to go out to the
internet and the internet's going to go, I-- I don't know what this 35
block is, even though it's a public IP because
Google owns it and we're not advertising
it, it doesn't exist on the public internet. It only exists in your
private environment. STEPHANIE WONG: That's
interesting, yeah. RYAN PRZYBYL: Yeah, so
when you set up DNS, there's more than just
setting up the zones and setting up the files. You've got to make sure
the routing and all-- STEPHANIE WONG: Yeah, there
are a couple of pre-reqs there. RYAN PRZYBYL: --these firewall
rules and so-- so, you know, we've had other videos talking
about a lot of that stuff, but it is very critical
to making this stuff work. STEPHANIE WONG: Yeah. It's a good thing we have you. [LAUGHS] RYAN PRZYBYL: Yeah. OK, so let's talk about
inbound forwarding now. So in this case,
we're going to set up an inbound policy, which
I'll show you guys how to do for inbound forwarding. You're also going to
use an IP address. You're going to assign an IP
address in-- in this case, it's the 10.148
range that you want to use for inbound forwarding. In this case, we have to do some
similar sort of routing stuff. So since the 10.0.1
is on-prem, it needs to be advertised
the Cloud Router, like we just talked about. In addition, you
have to make sure that you have no
firewall rules that block that coming into GCP this time. So instead of talking
about firewall rules on-prem blocking it, now we're
talking about firewall rules that you're running in GCP. So if you have a firewall
rule that says 10.0.1.0/24 can't talk to GCP, then it's
never going to be able to do the inbound forwarding requests
because that's where your DNS stuff is coming from on-prem. STEPHANIE WONG: Again,
explicitly specifying in a firewall rule that
you're allowing inbound access from these ranges. RYAN PRZYBYL: Yes. And then the same
thing-- so in this case, if you since you're using
10.148 in the cloud, you don't really have to set up
the Cloud Router to do anything special because it's going
to pick up that subnet because it's something you
just configure in the Cloud and it's going to advertise
it to the on-prem router. But it's good to
always make sure that you're actually
seeing that subnet be advertised on your router. Same thing if you can route--
you route to the inbound server that's living in that 10.148,
but if 10.148 doesn't how to get to 10.1 because you
haven't been advertising 10.1, you're going to have a problem. So, again, can't
highlight this enough, DNS has a lot of-- even though
we're talking about DNS, there's a lot of routing
constructs that have to be set up in here to make this work. STEPHANIE WONG: So one
thing I was thinking was we just came out with
Network Intelligence Center pretty recently last year. Is this something that you can
use to verify my firewall rules are working, I have routes-- I don't know if it measures
routes, but the way. RYAN PRZYBYL: You could-- yeah, so Network Intelligence
Center is going to look at do the routes exist? Do the firewall rules allow it? Now, in this case, it's--
you can set this up to sort of mimic this scenario in
Network Intelligence Center, right? So the way that you
might do it is maybe you create the 10.0.1 block in
GCP and then what you try to do is you try to route
from a VM in that 10.0.1 block to the IP address
in the 10.148 block. So you're setting
up a little test case where you're basically
taking that on-prem subnet and just creating it in
GCP to see if it can route through the GCP infrastructure. And then you would go
and delete that and then just run the stuff on-prem. STEPHANIE WONG: Yeah, and then
you'd do the full setup stuff. RYAN PRZYBYL: Yeah, you could
use Network Intelligence Center to make sure you
have the routing in place and to make sure the
firewalls are OK, but you have to just trick
it a little bit by creating that subnet in the
GCP environment and then tracing all the
routing and the firewall rules there and just make
sure you delete it. STEPHANIE WONG: Yeah. And just to provide
context, this is a-- Network Intelligence Center has
a module for connectivity tests where you can set up
these tests and make sure that things are actually
working properly, so it's really useful for
things like that, yeah. RYAN PRZYBYL: Yeah, it's great
to check do the routes exist? Do the firewall rules,
and all those things, so you're spot-on. It's a good test pattern
if you aren't sure if you have it correct
or maybe you set this up and it's not working and you
want to try to troubleshoot it, Network Intelligence Center
is a good way to go in there and try to troubleshoot. And it'll tell you a
route doesn't exist, a firewall rule
is blocking this, and then it allows you
to go and make the tweaks that you need to make. STEPHANIE WONG:
Yeah, that's perfect. RYAN PRZYBYL: OK, so now
we're going to reverse it. Instead of the
inbound architecture, we're going to talk about
where I'm forwarding outbound to something on-prem. So in this case,
same general setup. In this case, you're
going to create a zone. So when you're doing
inbound, remember I said we're creating a policy. In this one, we're
actually creating a zone. It's an outbound zone-- which
I'll show you how to create-- and it's pointing to
the on-prem DNS server. So same sort of
similar situation with the Cloud Router. We have to be learning
the block from on-prem and we have to be
advertising the proxy range because in this case, we're
doing outbound forwarding, so something in GCP is
going to talk to our proxies and the proxy is going
to push it outbound. And then lastly, same thing
we talked about before, you have to have a custom
route advertisement set up so that the Cloud
Router advertises the 35 block outbound. Because if that part
does not happen natively, you have to manually
go and configure that. STEPHANIE WONG: Yeah. Anything that's going
outwards-- this and the ANS is requiring this proxy. RYAN PRZYBYL: Yeah,
it's going to use-- the ANS doesn't really use
it because you're basically just telling it, I'm going to
forward everything outbound. STEPHANIE WONG: Oh, so it's not
necessary in that case as much. Yeah. RYAN PRZYBYL: So let's
talk about peering now. So this is what I was
talking about before. If you noticed the
previous things, everything had an on-premise
in this case, right? So in this case, I'm doing
everything wholly within GCP. So in this case, I'm basically
building a peering set up where I'm telling the VPC
Network A that hey, to resolve to-- let's use
dev.ryanprzybyl.com again-- go to VPC B to resolve that. Now, once you get
into VPC B, you still have to have something set up. So for example, you
would have the zone file for dev.ryanprzybyl.com
with the records in there. Or you could have a
forwarding rule set up. So you're basically
saying, OK I'm going to go from VPC Network A
is going to talk to VPC Network B, and then once it
gets to VPC Network B, it's going to see that there's
a forwarding zone set up, and then it's going
to forward on-prem. So you can sort of
daisy-chain these together. So when we talk
about peering, all we're doing is
basically saying, how do I get something in Network
A to talk to Network B to resolve some stuff? Now, what happens when
it's in Network B? It could resolve in Network
B. It could forward out of Network B. There's
lots of other things that can happen in
Network B. So I'm just talking about setting up
the peering relationship. So think of the Network
B be in this example. It could be set up like this. So Project A to
VPC Network that's on the left side,
that could be-- that would be sort of VPC Network
B in the next example. Or you could have an
alternative name server setup. So the stuff that's on the left
in that one and that one, just think of it as being on the
right in Network B here. STEPHANIE WONG: Yeah,
that makes sense. You can just expand. But can you kind of go--
is there a typical use case that you would want to separate
the zone and the record in a separate network? RYAN PRZYBYL: Yeah, so let me
talk about the next use case and I'll show you exactly
where this comes into play. STEPHANIE WONG: Sounds good. RYAN PRZYBYL: So now we're going
to lay a whole bunch of stuff on top of each, other
make this more complex. OK, so to answer
your direct question, so in this case, Network
H that I've shown here, that's where the
zone file exists or that's where the policy
exists to forward things. So, in this case, I want to
take the information that's living in Network H and I want
to cascade it to Networks A, B, and C in here. So in this case, I use peering. So I set up peering from A
to H, peering from B to H, and peering from C to H. STEPHANIE WONG: Gotcha, yeah. RYAN PRZYBYL: And
then H is going to handle whatever
the request is. One of the common challenges
that customers will run into is, let's say I'm forwarding
a bunch of stuff to on-prem. So let's take H. Let's
say H, in this case, is a forwarding zone,
like I've got shown here. So all the peering requests come
in to H in the forwarding zone and then it forwards
those requests to on-prem for resolution and
then comes back to H and then H will fan it back out. What some customers
will try to do is they'll try to build
a forwarding zone from A, a forwarding zone from B,
a forwarding zone from C, forward all of that
stuff to on-prem. It doesn't work, and the
reason it doesn't work is because we use
those proxies in there. We use the same proxy
range in every VPC. STEPHANIE WONG: Yup. RYAN PRZYBYL: So
you can think of-- VPC A, B, and C all
use the 35-dot range. STEPHANIE WONG: Oh, yes. RYAN PRZYBYL: When it goes
to on-prem, on-prem's like, I don't know which
one of these ranges-- which one of these
to route back to. So when it goes
back, the proxy is like, I don't know if that
request came from A or B or C. So you always want to have
one single forwarding zone forwarding out of
GCP to your on-prem. That way the proxy-- everything stays very
clean, like it always knows it's going back
to, in this case, Network H. That's where that
35-dot proxy set up lives, so any request
coming from on-prem is always going
back to H and then H is fanning everything out. STEPHANIE WONG: And
there's something that will identify the
actual request destination. So if it does need to go
back to VPC A, B, or C, there's something,
some sort of indication that will tell it, right? RYAN PRZYBYL: Yeah,
because you've got the peering stuff set up,
it's going to basically say, the response is
going to come back-- it's going to come back into
H and then H is going to say, OK, I know A needs
it, so A is setup in this peering arrangement to
grab the, effectively, the IP address of whatever it's
trying to resolve too. STEPHANIE WONG: Right. OK. RYAN PRZYBYL: So let me
thinly go through this. So you still have
the same things we talked about
the Cloud Router. In this case, the
Cloud Router is living in H. None of
the Cloud Routers-- you may have Cloud Routers
running in A, B, and C. You don't have to do anything
with those in this case. You can only configure the Cloud
Router in H to do all the stuff we talked about-- learn the 10.0.1
route from on-prem, advertise the 35-dot range
proxy to the on-prem. So all of the routing
stuff only exists in H because H is the
only forwarding zone. STEPHANIE WONG: It
also seems like this would create more
of a dynamic setup anyway because if you wanted to
add additional projects sitting in additional VPCs, you would be
able to peer to your forwarding zone. RYAN PRZYBYL: Exactly. So you have all of
your forwarding zones and you have all of
your constructs set up in H. You could just
stamp out more VPCs and just peer them and get
the information you need. STEPHANIE WONG: If there
was an issue to occur, it'd be easier to
identify the root cause if you can look to the VPC H. RYAN PRZYBYL: Yeah, if
something isn't working here, chances are pretty good
it's probably in Network H. STEPHANIE WONG: Right, right. RYAN PRZYBYL: If you have--
if you scaled the Project A VPCs to be 20 VPCs,
you don't want to be troubleshooting
every single one of those. STEPHANIE WONG: Exactly, right. RYAN PRZYBYL: I would start
your troubleshooting in H. Does H have all the right routes? Does H have all
the firewall rules? Because H is just-- H is really the-- you can
think of it as kind of a hub and spoke architecture. STEPHANIE WONG: Exactly. RYAN PRZYBYL: There's
a lot of stuff in here. It sort of-- if you don't
have your hands on it, and it's kind of like
well, how do I actually configure the policy? STEPHANIE WONG: Exactly. RYAN PRZYBYL: You talk
about configure a policy or you configure zone. I'm going to show you how
to actually configure those. STEPHANIE WONG: Yeah,
that would be great. RYAN PRZYBYL: OK,
so let's go in. So all the Cloud DNS is
under Network services. So I'm going to go to Cloud DNS. When you go to Cloud DNS, you
sort of see these two things. You see zones and server
policies, as we talked about. So I'm going to show you how
to create the zones first. Everything that is
zone related, I'll show you how to create that. So you create a new zone. So first, let's go back
we talked about public versus private zones. So this is the first thing
you're going to choose. Is this a private zone
you're trying to create or is this a public zone
that you're trying to create? And you're just going
to check whichever one. So I'm going to
create a private zone. I'm going to call this dev-- I'll just call this ryanprzybyl. Spell my name. So in this case,
I'm going to say I'm running the dev
environment in GCP. So I'm going to
say anything that's dev.ryanprzybyl.com
I want to resolve in this private
zone I'm creating. You can give it a description. And in this case,
so the options-- this is where you're going
to do a few different things. If I'm just creating
the private zone that I'm going to
put the records in, I just leave it as
Default private. And then this is telling
me which of the VPCs I want to put it in. So I will put it in the
load balancing demo network that we went through last
time, and I just click Create. So it's going to
create that policy. Er, it's going to
create that zone. I'm sorry. So the next thing you do
is you add a record set. So remember we
talked about zones and we talked about
the records that live. So here's where I would go
and add the actual records. So if I had VM1 or whatever
I wanted to call it that's dev.ryanprzybyl.com,
and then it's going to be an A record
if we're using IPv4. We will support IPv6 and then
we'll be running quad A records in here. So I'm going to say
it's an A record. I can set the time to live. And then I'm going to
give an IP address. So what is that VM's IP address? So maybe it's 10.0.1.5. So remember, this is the thing-- when something is trying to
get to vm1.dev.ryanprzybyl.com, it's ultimately trying
to get to the IP address. It's trying to say what IP
address does this belong to? So this is that
actual record and when I talk about the record actually
contains the IP address, this is what I'm creating. I'm creating that record
for this particular VM and I'm pointing to that
particular IP address. STEPHANIE WONG: So
the zone is more like, this is an
instantiation of what's housing the records that I
could tell the translate-- RYAN PRZYBYL: The
zone is just like-- you can think of it as
a folder that you're sticking all the records in. Think about a Manila folder
and each of the records is a piece of paper. That's a really easy
way to think about it. And then you can
have a file drawer that had a whole bunch
of folders in it. That's a really good analogy
for how this works, right? Each one of those
folders is going to be-- maybe it's dev.ryanprzybyl.com
and prod.ryanprzybyl.com is a separate manila folder
and staging.ryanprzybyl.com is a separate folder. And then, again,
each of the records has a piece of paper in there. STEPHANIE WONG: Yep,
that makes sense. RYAN PRZYBYL: OK, so I'm
going to cancel out of this. I'm going to go and I'm
going to delete the zone. And I'll show you how to
create something else. OK, so I was just
creating the private zone. Now, let's go ahead and create-- so in this case, I'll put-- oops-- so let's
in this case, I'm going to say this
lives outside of GCP. So I'm going to set
up a forwarding zone. Remember, a forwarding zone is
for forwarding outside of GCP. So I'm going to say for
dev.ryanprzybyl.com, I don't want you to
resolve it in GCP, I want you to go someplace
else to resolve it. STEPHANIE WONG: Yep, outbound. RYAN PRZYBYL: Yep. So, I applied it to the
particular network or the VPC that I want. And now I have to give it
a server because, remember, I'm forwarding to your
on-prem, so you're running a BIND server on-prem. Maybe the address is 10.0.1.1,
I think we talked about earlier. STEPHANIE WONG: Yeah. RYAN PRZYBYL: So I
would put that in there, and say for this particular
zone, dev.ryanprzybyl.com, don't resolve in GCP, go to
10.0.1.1 that lives on-prem. Again, all the routing works. All the firewall rules
are working, everything. Then whenever something in
GCP tries to resolve something for dev.ryanprzybyl.com, it's
going to route to on-prem. It's going to route to 10.0.1.1,
where the records live, to get the IP address. STEPHANIE WONG: But even if
you create a forwarding rule, you still have to
create the zone first as a way to house that. RYAN PRZYBYL: You'd still
have that-- you'd have the zone file would be on-prem. So think of your manila folders. Your manila folder
that you created would just be on-prem
for dev.ryanprzybyl.com. STEPHANIE WONG: Right. And this is more than
just the forwarding rule to let your GCP resources
know to go there. RYAN PRZYBYL: All
you're telling it is for this subdomain,
forward it outside of GCP to this IP address. That's all you're doing. STEPHANIE WONG:
That makes sense. And you could have
interconnect or something that's extending it? RYAN PRZYBYL: Yeah,
you're going to need some interconnect or VPN
or some sort of connection to your on-prem that this stuff
is actually going to route to. STEPHANIE WONG: Especially
a private IP range, right? RYAN PRZYBYL: Mm-hm. OK, so that is that. So let's talk about DNS peering
while we're in the zone. So DNS peering, you create
in the zone file piece of it. So in this case,
I just changed it. So I've got the set to private
for dev.ryanprzybyl.com. I want it to go to
another VPC now, not on prem, but
another GCP VPC. So now I'm writing the
peering relationship and I'm going to apply
it to the same network. And then I have to
tell it what project that network is in because
remember, I'm in GCP now. So I basically said
I'm going to apply it to this particular VPC, but
what's the other project that I want to do-- that the other VPC lives in,
so I selected that project, and then I would select
a VPC in that project. STEPHANIE WONG: Yeah,
that makes sense. So it's like that
architecture we were just kind of going over. RYAN PRZYBYL: Yeah,
let me show you how to sort of configure
the actual peerings. So in this case, you select
Private, give it a name, tell it what subdomain you
want to peer to somebody else. That's what I did when
I selected the peering. And then you're applying
it, like I said, this is the VPC you're
applying this policy to and then you're telling it
what is the project in VPC that you want me to peer
with on the other side. STEPHANIE WONG: Yeah. RYAN PRZYBYL: So those are
pretty much the main things you're going to do. You're going to create the
zone, create a forwarding zone, or create a peering
relationship. All that is done under
creating the zone. STEPHANIE WONG: OK. RYAN PRZYBYL: OK. The next part, we talk about
alternative name servers and inbound. Those are not done
in the zone area. They're done in DNS
server policies, which is the other option
we have right here. So if I want to write
a DNS server policy, I'm going to create the policy. The policy has to have a name. Give it a description. Logs for this-- whether you
want logging turned on or off. Caveat, because DNS should
be constantly hitting things, it can create a lot of
data for a lot of logs. STEPHANIE WONG:
OK, good to know. RYAN PRZYBYL: Just an FYI,
you get a whole ton of logs if you enable logging. STEPHANIE WONG: Yeah. RYAN PRZYBYL: And then, really,
these bottom two pieces right here are where
you're going to say, is this an inbound forwarding
policy that I'm writing? So if it's an inbound forwarding
policy, you just say On, and then you tell it where do
you want to apply this policy? So in this case, I'm
applying it to that network. And I would hit Create. It would create
the inbound policy that's going to allow inbound
requests into that VPC. STEPHANIE WONG: Gotcha. OK. RYAN PRZYBYL: Now, if I'm doing
the alternative name servers-- so this is the binary
relationship where I said, I don't want use any
sort of Cloud DNS. I am using a BIND server
on-prem, as an example. I want to forward every single
request to that on-prem. I don't want to deal with
any sort of Cloud DNS, so everything's
getting forwarded out. Then, what I would do
is, I would add the-- I would change the inbound
query forwarding to off, and I would just come down here
under Alternative DNS servers, give it an address. So in the example used
before, I'm basically saying any DNS
request that comes, go ahead and forward it to this. Don't try to do any resolution
in Cloud whatsoever. STEPHANIE WONG: Yeah. RYAN PRZYBYL: So if you're
using Infoblox, if you're using, like I said, a BIND
server on-prem-- these are very common things--
if you're using another service and you said, I want to use
that service for all DNS, this is how you would
sort of direct that to. STEPHANIE WONG: So you
mentioned you're using policies for inbound forwarding rule-- RYAN PRZYBYL: Yes. STEPHANIE WONG: --or ANS. So how do you kind of
bucket that because there's a distinction between using
policies versus the zones which we just set up. RYAN PRZYBYL: Yep. So it's just-- it's
just sort of the policy is, I mean, it's more
like semantics, right? It's just one is a policy
for inbound forwarding or alternate name servers. The other actually do what
the actual zone creation. STEPHANIE WONG: Yeah,
so you're actually creating this actual
resource, the record. RYAN PRZYBYL: Yeah, but
you're creating a forwarding zone or a peering relationship
between two zones, or you're creating the
private zone itself. In this case, you're not
creating zones, right? You're just writing a
high-level policy that says, I'm not dealing with a zone. I'm just saying for this
thing, I want to forward it-- I want to basically forward
from on-prem into GCP. STEPHANIE WONG: Yeah. RYAN PRZYBYL: Or I want to
forward from GCP to something completely external. STEPHANIE WONG: OK,
that makes sense. Yeah. RYAN PRZYBYL: So it's-- don't think too much
about it, right? It's just-- if you're
configuring those things, we call them policies. For the other stuff,
you're actually doing it in the zone files
and the zone kind of concept. STEPHANIE WONG: Right. No, I think that's helpful
just to try to mentally wrap my mind around it. But that makes sense, yeah. RYAN PRZYBYL: OK. So it's pretty easy, right? That's when you
go into Cloud DNS, you're either creating zones
or creating server policies. We showed you pretty much how
to create inbound forwarding, outbound forwarding,
alternative name servers, the private zones,
how to create the records. STEPHANIE WONG: We
just did so much. [LAUGHS] RYAN PRZYBYL: We packed a
lot into 40 minutes so far. If there's questions, definitely
reach out to us and ask us. We're happy to address. Or if you're running
into any issues, let us know if we can
help troubleshoot. STEPHANIE WONG: Yeah. RYAN PRZYBYL: But that is
pretty much DNS in a nutshell. STEPHANIE WONG: In a nutshell,
somewhat of a nutshell. RYAN PRZYBYL: It's
a lot, I know. STEPHANIE WONG: Yeah, no
that was really great. I learned a lot. Thank you for
explaining all of that. I know it can be
a little confusing because there are different
various architectures, as you said. But that was super-helpful. That's it for the
presentation portion, right? RYAN PRZYBYL: Yep,
that's everything I have. I can't show how to
configure anything else because that's pretty much it. STEPHANIE WONG:
OK, so we're going to come back in just a moment
to actually go over some frequently asked questions. So we're going to
be back in a minute and just stay tuned for that. OK, welcome back. We're now ready for our
frequently asked questions. So Ryan, the first
question that I hear a lot is how does DNSSEC work
in this environment. RYAN PRZYBYL: Sure. So when you create
the zones, you can enable them to
be set up for DNSSEC. So you just-- it's simple. You click the button, and
DNSSEC is enabled, right? The pitfall-- the thing
I will warn you about-- is where it gets a
little more difficult is when you're
trying to, let's say you're running something
outside of GCP and using DNSSEC and you want to migrate it to
GCP and you want to use DNSSEC. There are some pitfalls
in there because if you're trying to do the migration and
you have it in the wrong state and you get key rotation, that
can really hose things up. So what I would
recommend if you're trying to do a DNSSEC
migration is disabled DNSSEC in your current provider. Let everything time out based
on the records and the time to live. Let everything expire so
now you're no longer using DNSSEC over here. Transfer it, so move all of
the records into the zone that you have DNSSEC enabled
and then do it that way. That way you're
not trying to move a secure zone to a secure zone
and mess with the transfer states and risk some
key getting rotated and it will hose
things up pretty badly. STEPHANIE WONG: Yeah. RYAN PRZYBYL: That's the
big caveat with DNSSEC. But DNSSEC is supported
in the environment. If you're trying to
do FedRAMP, if you're trying to do a bunch
of different things that require DNSSEC,
it's good that we have that feature capability. STEPHANIE WONG: OK,
that makes sense. Yeah, so I just
want to make sure that you are
disabling momentarily and then transfer over
because it will give you a cleaner transfer. RYAN PRZYBYL: Yeah,
the other thing to know about DNSSEC really is-- know that, really, DNSSEC
is used to authorize and make sure that
you're getting-- where you're getting
the records from is the authorized
place you're supposed to be getting the records from. It is not-- people
think sometimes it's kind of like IPsec, it's
encrypting things in transit. It is not doing that. So when the actual information
comes down, it's in the clear. It's not encrypted. Sometimes people think it is. It's just DNSSEC is
really there to make sure that where you're getting
the information from is where you're supposed to be
getting the information from. STEPHANIE WONG: So it's
a way of verifying, like, the BIND server and the
zone and the record set. RYAN PRZYBYL: Yeah,
it's verifying that that what's
providing information is actually supposed to
be providing information. STEPHANIE WONG: Right, right. OK, so the next question-- how do you migrate an
existing zone into GCP DNS? Like, similar, but
for the actual zone. RYAN PRZYBYL: Sure. So what you could do is you
go in and create the zone. You can then move-- you
can migrate your records. And I believe we
support various formats for migrating, like JSON
and various other things that you can just sort of
migrate all of your records in. There's going to be roughly
a little bit of downtime because as your
records are moving, things are trying to
go over here to resolve and you're moving things. So I would say,
in my experience, you're talking
maybe 10, 15 minutes of downtime while you're
migrating everything over. But you can basically
just wholly import all of your records once
you create the zone. Remember, where
there's a section where I created the zone,
it said the record piece? You can sort of import all
of your records in there. STEPHANIE WONG: OK. But the 15 minutes
is really just so that things can roll out and
update records and make sure because they're
pointing to the right-- RYAN PRZYBYL: Yeah, exactly. There's a whole bunch of things,
like your registrar and things are pointing to different
things and you're in a sort of migration
state where things may not resolve correctly. And like I said, usually
it takes 10 or 15 minutes for things to flush out. It's, I would say, a
good sort of benchmark. STEPHANIE WONG: Right. But I mean, presumably
companies would be doing it over the
weekend or at night or-- RYAN PRZYBYL: Correct. It's not something you want to
do at, like, noon on Monday. This is something you would
do like a scheduled migration to migrate the zone into GCP. STEPHANIE WONG: Yeah, OK. Other question-- what was the
most common pitfall that you see our customers fall into? RYAN PRZYBYL: So
I talked about one of them, which is creating the
multiple forwarding zones where they have the individual
VPCs and they're trying to create forwarding
zones out of each of them. So we talked about
this, where you've got, say, four forwarding zones
all using the same 35 proxy range. Things go to on-prem,
on-prem responds back and the proxies don't know, do
I hand this to VPC A, B, or C? That's the whole reason you
have the peering architecture to the one forwarding zone
but all the peering zones. STEPHANIE WONG: Mm-hm. RYAN PRZYBYL: So that's
a common thing sometimes customers get tripped
up because what will happen if you configure
multiple-- let's say you have two forwarding zone set up. And you make requests from Zone
A and Zone A goes to on-prem. It might land back in Zone A.
So it might just work just fine. But then the next request
might go to on-prem, it comes back and then end up
in Zone B or something like that where it doesn't
resolve correctly. And the more of those
you have, the more places the proxy can think, OK,
I might have to push it to one other thing things. So generally speaking,
if you have two, you might think it's
working, but if you have 10 it'll be very
obvious that it's not working very quickly. STEPHANIE WONG:
Yeah, I mean it's kind of taking a chance
because the resolver is not going to know where exactly
to send the response to. RYAN PRZYBYL: Exactly. And if you've got
two, your chances are smaller that's going
to route correctly. If you have 10, there's more
places for it to route to, so you're going to see the
problem manifest much quicker. STEPHANIE WONG: Right, right. RYAN PRZYBYL: So that's
a very common problem that people will run into. Because again, they don't
really understand the construct and how it's being
routed internally. And logically, you think
it should work just fine, but it doesn't. STEPHANIE WONG: Yeah. No, that's a great insight. Awesome, well that pretty
much wraps up the FAQ. I do want to cover
some next steps. I really encourage everyone
to actually go check out cloud.google.com/free and you
can log into the GCP Console there, try out some of the DNS
products that we just talked about. You actually get a
12-month $300 free trial that automatically starts when
you set up your first billing account. And if you do want to
look for more information, any conditions and
restrictions, you can check out the
documentation in this slide. But besides that thank,
you so much Ryan. RYAN PRZYBYL: Yeah. I can't stress that
getting your hands dirty on this stuff enough. All the stuff we've covered
in the series of five things, we're setting up the VPC,
setting up the routing, the DNS stuff we
talked about, right? We can talk about this
all day, but really, once you get your
hands dirty and you start touching it
and manipulating it, that's when you get really
good learning of how to set this stuff up and you get
comfortable with how it works. And as you said,
the pitfalls-- like, you'll find something
that doesn't work and you can
troubleshoot it and use, like you said,
Network Intelligence Center to troubleshoot
it, things like that. STEPHANIE WONG: Exactly, yeah. Well, that was excellent. Thank you so much for
showing us all of that. RYAN PRZYBYL: Yep. Happy to help. STEPHANIE WONG: All
right, take care and we'll see you next time. [MUSIC PLAYING]
