1
00:00:01,340 --> 00:00:04,990
Now let's take these Windows Server DNS features and see

2
00:00:04,990 --> 00:00:07,430
how they translate into Microsoft Azure,

3
00:00:07,430 --> 00:00:10,320
specifically the Infrastructure as a Service, or

4
00:00:10,320 --> 00:00:13,940
IaaS, scenario with virtual networks.

5
00:00:13,940 --> 00:00:17,510
Here's a really nice diagram from Microsoft Learn. As always, when I

6
00:00:17,510 --> 00:00:20,290
show you nonoriginal art I provide a citation.

7
00:00:20,290 --> 00:00:22,980
You can see that in the lower left corner of the slide.

8
00:00:22,980 --> 00:00:27,010
So here we're seeing a hybrid cloud environment where we've got an on‑premises,

9
00:00:27,010 --> 00:00:30,940
let's say an Active Directory domain, and therefore we have DNS servers

10
00:00:30,940 --> 00:00:33,990
that are authoritative for that domain. It looks like we have an

11
00:00:33,990 --> 00:00:36,940
ExpressRoute link into a hub virtual network.

12
00:00:36,940 --> 00:00:40,470
This just as well could be a site‑to‑site virtual private network.

13
00:00:40,470 --> 00:00:44,320
It's just going to be a way to extend our on‑premises infrastructure at

14
00:00:44,320 --> 00:00:48,440
OSI layer 3 into our hub virtual network infrastructure.

15
00:00:48,440 --> 00:00:49,520
Now what's happening here?

16
00:00:49,520 --> 00:00:49,810
Well,

17
00:00:49,810 --> 00:00:52,350
in this case it looks like we have our local

18
00:00:52,350 --> 00:00:54,990
on‑premises DNS servers configured for,

19
00:00:54,990 --> 00:00:57,890
I would say, conditional forwarding to go out into

20
00:00:57,890 --> 00:00:59,910
the virtual network in the cloud.

21
00:00:59,910 --> 00:01:00,160
Now,

22
00:01:00,160 --> 00:01:04,220
you could do that if the DNS servers in the cloud were in another

23
00:01:04,220 --> 00:01:08,810
domain. You wouldn't necessarily need to do that if you are just setting

24
00:01:08,810 --> 00:01:11,480
up additional domain controllers in the cloud.

25
00:01:11,480 --> 00:01:15,140
See, so much of this branches in so many different ways.

26
00:01:15,140 --> 00:01:20,640
This example here is showing that on‑prem, if somebody runs a DNS query

27
00:01:20,640 --> 00:01:24,160
for a resource that's in Azure on its own DNS zone,

28
00:01:24,160 --> 00:01:27,120
we need some way locally without going over the

29
00:01:27,120 --> 00:01:29,530
internet to get into that virtual network.

30
00:01:29,530 --> 00:01:33,000
So again, that's what DNS conditional forwarding is all about.

31
00:01:33,000 --> 00:01:36,280
If we're looking for azureprivatenetwork.com,

32
00:01:36,280 --> 00:01:37,840
if that's our zone in Azure,

33
00:01:37,840 --> 00:01:41,030
we would do a conditional forwarding entry for that, and that would bring you

34
00:01:41,030 --> 00:01:45,700
into Azure where you've got an authoritative DNS server VM there that is

35
00:01:45,700 --> 00:01:50,120
resolving private IP addresses within your virtual network infrastructure. Now,

36
00:01:50,120 --> 00:01:53,400
I'll show you more about this in the demo, but this is where things can get more

37
00:01:53,400 --> 00:01:57,770
complicated. We have to remember that virtual networks are completely isolated

38
00:01:57,770 --> 00:01:59,240
from each other by default.

39
00:01:59,240 --> 00:02:03,120
So that means Azure‑provided DNS, or Azure‑provided name

40
00:02:03,120 --> 00:02:06,330
resolution, will not work across virtual networks.

41
00:02:06,330 --> 00:02:09,870
So the idea is that you can do your own DNS solution, but you'll have to

42
00:02:09,870 --> 00:02:15,780
configure forwarding across those VNet peerings. In this case this shows VNet1

43
00:02:15,780 --> 00:02:20,870
and VNet2 with a peering connecting them. And a peering is just a logical,

44
00:02:20,870 --> 00:02:24,280
back‑end routing path between two virtual networks.

45
00:02:24,280 --> 00:02:26,310
All right, it doesn't imply any encryption,

46
00:02:26,310 --> 00:02:30,200
you could also, if you wanted to, do a VNet‑to‑VNet VPN, but the

47
00:02:30,200 --> 00:02:34,080
normal pattern is to link those VNets via a peering and then you

48
00:02:34,080 --> 00:02:36,050
can configure conditional forwarding,

49
00:02:36,050 --> 00:02:39,380
let's say, if you have yet another domain running in VNet2.

50
00:02:39,380 --> 00:02:45,360
Now, what's this 168.63.129.16 stuff? That's a virtual IP

51
00:02:45,360 --> 00:02:46,580
that you should be aware of.

52
00:02:46,580 --> 00:02:51,340
It uses AnyCast, so it's available to all Azure public cloud customers

53
00:02:51,340 --> 00:02:55,920
and it represents the Azure‑provided services called the wire server,

54
00:02:55,920 --> 00:02:59,950
and this is what gives you your DHCP, or Dynamic Host Configuration

55
00:02:59,950 --> 00:03:01,820
Protocol, within your VNets.

56
00:03:01,820 --> 00:03:06,030
And also, very importantly, when you're doing Azure‑provided name resolution,

57
00:03:06,030 --> 00:03:10,630
it handles that within each VNet. Now, that wire server can also come into

58
00:03:10,630 --> 00:03:14,230
play big time when you're integrating with Azure DNS,

59
00:03:14,230 --> 00:03:20,000
particularly private zones and things like private endpoints that we'll get into next.