1 00:00:01,440 --> 00:00:03,910 Last thing I want to review with you briefly is the 2 00:00:03,910 --> 00:00:07,090 concept of DNSSEC and how that works just, 3 00:00:07,090 --> 00:00:09,120 again, from a relatively high point of view. 4 00:00:09,120 --> 00:00:09,760 Though, boom, 5 00:00:09,760 --> 00:00:12,840 you probably noticed a couple things change on screen just a 6 00:00:12,840 --> 00:00:15,060 moment through the magic of video editing. 7 00:00:15,060 --> 00:00:18,300 I've created another zone here that I can work with 8 00:00:18,300 --> 00:00:22,060 called signed.lan. By the way, in terms of just architecture, 9 00:00:22,060 --> 00:00:25,600 you notice that I'm using a .com even though this is a private 10 00:00:25,600 --> 00:00:28,970 internal DNS domain. Again, that brings up questions. 11 00:00:28,970 --> 00:00:33,540 Some businesses will always use a non‑internet routable TLD, or top‑level 12 00:00:33,540 --> 00:00:37,860 domain, to make sure that internal resources have no possibility of 13 00:00:37,860 --> 00:00:42,030 resolving on the internet. To that point, or as a nod to that, I've created 14 00:00:42,030 --> 00:00:46,920 a new zone here called signed.lan, and I'm going to create a new host record 15 00:00:46,920 --> 00:00:53,450 for my machine, dc10, where the IP address is 10.10.10.10, add that host in 16 00:00:53,450 --> 00:00:57,280 there. And then let me show you just a bit about DNSSEC. So, let's 17 00:00:57,280 --> 00:01:00,290 right‑click the zone, DNSSEC will sign the zone. 18 00:01:00,290 --> 00:01:04,040 This launches the DNSSEC signing wizard. I'm going to leave the 19 00:01:04,040 --> 00:01:06,870 default customized zone signing parameters. 20 00:01:06,870 --> 00:01:09,110 We create a key master. 21 00:01:09,110 --> 00:01:10,940 That's going to be this server. 22 00:01:10,940 --> 00:01:11,420 However, 23 00:01:11,420 --> 00:01:16,020 if we've already got a key master and we're signing a zone on another server, 24 00:01:16,020 --> 00:01:19,240 we would browse to that server using the second radio button. 25 00:01:19,240 --> 00:01:23,750 Let's create our key signing key. It says that the private key corresponding 26 00:01:23,750 --> 00:01:27,340 to our KSK will sign other keys used for signing the zone. 27 00:01:27,340 --> 00:01:30,340 So this is like a database key or a master key. 28 00:01:30,340 --> 00:01:33,870 I'm going to click Add, and I'm going to accept all of the defaults here 29 00:01:33,870 --> 00:01:37,500 in terms of cryptographic algorithm and key rollover. 30 00:01:37,500 --> 00:01:39,380 So, let me click Next. 31 00:01:39,380 --> 00:01:43,290 Next we have our zone‑specific private key. Click Next. Again, 32 00:01:43,290 --> 00:01:45,390 we're going to add a key pair here as well. 33 00:01:45,390 --> 00:01:45,730 And again, 34 00:01:45,730 --> 00:01:48,710 the notion of trust anchors is we're going to need to distribute 35 00:01:48,710 --> 00:01:52,010 the public key to other servers. In order to support 36 00:01:52,010 --> 00:01:56,060 authenticated denial of existence, we'll use NSEC3, and again 37 00:01:56,060 --> 00:01:57,670 I'm going to use the defaults here. 38 00:01:57,670 --> 00:02:01,870 We definitely want to enable the distribution of trust anchors for the zone. 39 00:02:01,870 --> 00:02:04,960 It says if this machine is also a domain controller, 40 00:02:04,960 --> 00:02:09,070 all of those DCs in the forest will receive the trust anchor and 41 00:02:09,070 --> 00:02:12,640 we want to automatically update those trust anchors when we roll 42 00:02:12,640 --> 00:02:14,500 over or regenerate our private key. 43 00:02:14,500 --> 00:02:17,920 Again, I'm going to use defaults here and then click Next. 44 00:02:17,920 --> 00:02:19,170 The zone has been signed. 45 00:02:19,170 --> 00:02:19,660 Good deal. 46 00:02:19,660 --> 00:02:23,950 So now we have a node here for Trust Points. Now, because I told 47 00:02:23,950 --> 00:02:27,790 DNS Manager to make the trust point available, 48 00:02:27,790 --> 00:02:32,060 it's already brought those DNS key entries in. The way that you can 49 00:02:32,060 --> 00:02:36,730 manually import your trust point is you can right‑click and do an Import, 50 00:02:36,730 --> 00:02:41,490 DNSKEY, and you'll want to go to the server that has the trust point in 51 00:02:41,490 --> 00:02:48,300 C\Windows\System32, and the trust anchor file has the name keyset‑, and 52 00:02:48,300 --> 00:02:49,750 then the name of the zone. 53 00:02:49,750 --> 00:02:51,020 All right. So that's that. 54 00:02:51,020 --> 00:02:56,140 And then lastly, we can establish our DNSSEC policy in Group Policy. 55 00:02:56,140 --> 00:03:00,190 I've created a separate GPO called DNSSec Policy, and if we 56 00:03:00,190 --> 00:03:02,860 go under Computer Configuration, Policies, 57 00:03:02,860 --> 00:03:05,330 Windows Settings, Name Resolution Policy, 58 00:03:05,330 --> 00:03:09,820 we can create our Name Resolution Policy Table, which you see I have one 59 00:03:09,820 --> 00:03:12,980 entry in here already. And basically to create a rule, 60 00:03:12,980 --> 00:03:16,850 you specify which part of your namespace the rule applies to. And I 61 00:03:16,850 --> 00:03:20,220 created one for the whole domain, that's pretty broad. Notice that you 62 00:03:20,220 --> 00:03:26,360 can specify FQDNs, subnets, any, so you can be as specific or as broad 63 00:03:26,360 --> 00:03:28,170 as you want for that domain. 64 00:03:28,170 --> 00:03:33,150 So I might call this signed.lan. And then lastly, we're concerned 65 00:03:33,150 --> 00:03:36,980 with the DNSSEC tab. Notice that you can do some things over here 66 00:03:36,980 --> 00:03:39,040 regarding direct access and so on. 67 00:03:39,040 --> 00:03:43,750 But the option is Enable DNS sec in this rule, and then you can specify 68 00:03:43,750 --> 00:03:48,750 required DNS clients to check that name and address data has been validated by 69 00:03:48,750 --> 00:03:54,300 the DNS server. And then optionally, you can layer in IPSec encryption. So you 70 00:03:54,300 --> 00:03:58,650 can really get pretty heavy handed with your both verification, your 71 00:03:58,650 --> 00:04:02,470 validation, as well as your confidentiality. 72 00:04:02,470 --> 00:04:03,640 IPSec, as you know, 73 00:04:03,640 --> 00:04:07,690 can cover not just confidentiality, but it can do mutual authentication 74 00:04:07,690 --> 00:04:12,080 itself. And then when you're ready, you can create that record in your 75 00:04:12,080 --> 00:04:15,190 Name Resolution Policy Table and then apply, 76 00:04:15,190 --> 00:04:17,490 don't forget to hit Apply, and then it's just a 77 00:04:17,490 --> 00:04:20,580 question of updating your Group Policy, 78 00:04:20,580 --> 00:04:23,360 doing a GP update, to put that into effect. 79 00:04:23,360 --> 00:04:27,650 And lastly, in terms of testing this, let me open up an elevated 80 00:04:27,650 --> 00:04:32,230 PowerShell session, and we can use the Resolve‑DnsName cmdlet, and 81 00:04:32,230 --> 00:04:35,490 notice what I'm doing here. I'm saying ResolveDnsName 82 00:04:35,490 --> 00:04:40,450 dc10.signed.lan, the server that I'm querying is dc10, and I want to 83 00:04:40,450 --> 00:04:44,770 see the DNS security records, ‑dnssecok. 84 00:04:44,770 --> 00:04:49,790 And this gives us the A record which maps correctly to our 10.10.10.10 85 00:04:49,790 --> 00:04:54,400 IP address, but what we want to see here is that RRSIG, that signed 86 00:04:54,400 --> 00:04:58,910 resource record that verifies that that record did in fact come from 87 00:04:58,910 --> 00:05:00,820 the server and it's a valid record. 88 00:05:00,820 --> 00:05:03,630 There's another cmdlet that you might want to look at in terms 89 00:05:03,630 --> 00:05:08,000 of validating your DNSSEC Name Resolution Policy Table, and 90 00:05:08,000 --> 00:05:11,940 that's Get‑DnsClientNrptPolicy. 91 00:05:11,940 --> 00:05:13,560 Now there's nothing on this machine. 92 00:05:13,560 --> 00:05:16,950 I haven't yet updated my Group Policy on this machine, but this 93 00:05:16,950 --> 00:05:26,000 is a nice way to verify that a machine is set up to require validation of responses from your DNS.