1
00:00:01,020 --> 00:00:03,870
Now Azure DNS has two forms.

2
00:00:03,870 --> 00:00:08,490
There's Azure DNS for public zones and Azure DNS private zones.

3
00:00:08,490 --> 00:00:12,370
The public zone is where you can delegate your domain into Azure.

4
00:00:12,370 --> 00:00:14,700
You can't yet buy a domain in Azure,

5
00:00:14,700 --> 00:00:18,500
but you can delegate your domain from where it's hosted into Azure

6
00:00:18,500 --> 00:00:22,550
and then manage that domain with its internet‑accessible resource

7
00:00:22,550 --> 00:00:24,680
records within your Azure subscription.

8
00:00:24,680 --> 00:00:25,530
It's very convenient.

9
00:00:25,530 --> 00:00:26,820
Now on the other hand,

10
00:00:26,820 --> 00:00:32,040
an Azure DNS private zone uses RFC 1918 non‑internet routable IPs,

11
00:00:32,040 --> 00:00:33,970
and it has some nice conveniences.

12
00:00:33,970 --> 00:00:36,350
For example, as you can see in this diagram,

13
00:00:36,350 --> 00:00:41,140
being able to do fully qualified names with your virtual machines across VNets,

14
00:00:41,140 --> 00:00:42,760
whether they have a peering or not.

15
00:00:42,760 --> 00:00:44,960
On best cases they do have a peering.

16
00:00:44,960 --> 00:00:49,460
But this gives you that ability using all private IPs and staying on the

17
00:00:49,460 --> 00:00:54,150
Azure backbone network to do that fully‑qualified domain name resolution

18
00:00:54,150 --> 00:00:57,050
without relying on that Azure wire server.

19
00:00:57,050 --> 00:00:59,400
Which as I said, I just want to keep repeating,

20
00:00:59,400 --> 00:01:01,650
and I'll show you again yet in the demo,

21
00:01:01,650 --> 00:01:06,230
the wire server can only handle name resolution within a single VNet.

22
00:01:06,230 --> 00:01:09,980
And even at that frankly, it's single label name resolution.

23
00:01:09,980 --> 00:01:11,240
It's nothing special.

24
00:01:11,240 --> 00:01:12,940
Going a bit further yet again,

25
00:01:12,940 --> 00:01:15,680
I want to be careful to not get too far in the weeds here,

26
00:01:15,680 --> 00:01:21,720
the private endpoint is a way to create a back channel that uses private IP

27
00:01:21,720 --> 00:01:26,220
addresses to Azure services that are in the internet by default.

28
00:01:26,220 --> 00:01:27,420
So in this example,

29
00:01:27,420 --> 00:01:30,530
let's say we created a private endpoint connection for

30
00:01:30,530 --> 00:01:32,880
an Azure SQL Database virtual server,

31
00:01:32,880 --> 00:01:36,280
and those always have internet‑resolvable DNS,

32
00:01:36,280 --> 00:01:38,630
like azsql1.database.windows.net.

33
00:01:38,630 --> 00:01:42,780
When you create a private link or a private endpoint,

34
00:01:42,780 --> 00:01:47,370
notice that Azure gives a private IP address to that resource within your

35
00:01:47,370 --> 00:01:49,950
virtual network space wherever you want to create it.

36
00:01:49,950 --> 00:01:52,870
In this case, it's in the snet‑consumer subnet.

37
00:01:52,870 --> 00:01:56,880
And that means that that DNS forwarder is on the same subnet and,

38
00:01:56,880 --> 00:02:00,640
therefore, can communicate with that database server using

39
00:02:00,640 --> 00:02:03,470
private non‑internet routable addresses.

40
00:02:03,470 --> 00:02:03,690
Well,

41
00:02:03,690 --> 00:02:08,170
the name resolution here is where things get interesting because under the hood,

42
00:02:08,170 --> 00:02:11,700
private endpoint is where Azure creates basically a split

43
00:02:11,700 --> 00:02:15,840
horizon scenario where you're always referencing that private

44
00:02:15,840 --> 00:02:17,900
link resource on its public DNS.

45
00:02:17,900 --> 00:02:20,460
But depending upon where the query originates,

46
00:02:20,460 --> 00:02:24,180
it's either going to connect over the internet or on the private link.

47
00:02:24,180 --> 00:02:26,970
So in this example, we've got a Client VM.

48
00:02:26,970 --> 00:02:30,220
Now if Client VM is trying to make a connection to

49
00:02:30,220 --> 00:02:35,290
azsql1.database.windows.net using that name in the absence of forwarding,

50
00:02:35,290 --> 00:02:38,140
then the private endpoint would not be used and the

51
00:02:38,140 --> 00:02:39,920
connection would happen over the internet.

52
00:02:39,920 --> 00:02:43,400
In order to ensure that Client VM uses the private link,

53
00:02:43,400 --> 00:02:46,960
we need a way for that Client VM on‑prem to resolve

54
00:02:46,960 --> 00:02:49,120
the private link private IP address.

55
00:02:49,120 --> 00:02:51,340
So this is a rather complicated example.

56
00:02:51,340 --> 00:02:55,670
You would have to configure conditional forwarding on‑prem in your DNS

57
00:02:55,670 --> 00:03:00,450
such that calls to database.windows.net go to a VM that you've

58
00:03:00,450 --> 00:03:03,950
configured as a DNS server in your virtual network.

59
00:03:03,950 --> 00:03:07,900
That DNS server would be forwarding all of its traffic that it

60
00:03:07,900 --> 00:03:10,870
can't resolve itself to the Azure wire server.

61
00:03:10,870 --> 00:03:12,880
Why do you need that second hop?

62
00:03:12,880 --> 00:03:15,290
Well, you don't if you don't have a hybrid cloud.

63
00:03:15,290 --> 00:03:20,670
If you have an environment that would stop here at the snet‑consumer subnet,

64
00:03:20,670 --> 00:03:24,160
those VMs can go directly to that resource.

65
00:03:24,160 --> 00:03:27,680
Again, they would attempt to resolve the public DNS name.

66
00:03:27,680 --> 00:03:31,510
And the Azure‑provided DNS endpoint knows about the mapping,

67
00:03:31,510 --> 00:03:33,070
that split horizon mapping,

68
00:03:33,070 --> 00:03:36,450
that when you're connecting to that name over the internet,

69
00:03:36,450 --> 00:03:37,800
you go to the public endpoint,

70
00:03:37,800 --> 00:03:40,740
but if you're connecting to the Privatelink endpoint,

71
00:03:40,740 --> 00:03:42,030
you can fetch that,

72
00:03:42,030 --> 00:03:46,950
or Azure‑provided DNS can fetch that mapping in a private DNS zone.

73
00:03:46,950 --> 00:03:50,910
Now, you can create your own mappings with DNS.

74
00:03:50,910 --> 00:03:53,950
I strongly recommend if you're going to do private endpoints,

75
00:03:53,950 --> 00:03:57,090
go ahead and create the private DNS zone so you

76
00:03:57,090 --> 00:03:59,200
have that alias record available.

77
00:03:59,200 --> 00:04:00,990
Long story short, in summary,

78
00:04:00,990 --> 00:04:05,370
to do private endpoint you always connect using its public name.

79
00:04:05,370 --> 00:04:06,890
And in a hybrid cloud,

80
00:04:06,890 --> 00:04:10,910
you need to take a little extra work in terms of conditional forwarding

81
00:04:10,910 --> 00:04:14,150
because your on‑premises environment is not going to be able to

82
00:04:14,150 --> 00:04:17,850
directly use the Azure‑provided DNS endpoint,

83
00:04:17,850 --> 00:04:22,490
and you need that wire server to handle that split horizon translation.

84
00:04:22,490 --> 00:04:23,860
I hope that makes sense.

85
00:04:23,860 --> 00:04:25,740
I know it's super complicated.

86
00:04:25,740 --> 00:04:31,070
Our lab topology here consists of two VNets that are connected with a peering.

87
00:04:31,070 --> 00:04:32,570
I have dc10.

88
00:04:32,570 --> 00:04:36,380
This is a domain controller for the contoso.com zone.

89
00:04:36,380 --> 00:04:38,130
These private IPs are valid.

90
00:04:38,130 --> 00:04:42,120
I have another domain controller in the same zone across the peering.

91
00:04:42,120 --> 00:04:47,610
I also have another machine, a workgroup server, that's hosting its own domain.

92
00:04:47,610 --> 00:04:53,100
And then, lastly, I have a storage account with a private endpoint in the hub.

93
00:04:53,100 --> 00:04:56,120
So we're just going to look at various combinations and

94
00:04:56,120 --> 00:05:04,000
permutations here of how we can get name resolution to work in this peer‑to‑peer virtual network environment.