WEBVTT 00:00.000 --> 00:08.800 I'd like to thank you very much for this album. 00:08.800 --> 00:09.800 This is Alexander. 00:09.800 --> 00:17.680 We'll be talking to us about the idea with somebody in the integration. 00:17.680 --> 00:22.000 Yeah, so thank you for taking this talk. 00:22.000 --> 00:34.240 I kind of feel that sometimes the traditional corporate environments, they don't get attention 00:34.240 --> 00:45.000 anymore, especially in the DNS, which supposed to be tangle in together public environments. 00:45.000 --> 00:51.000 We are talking now about the stuff that happens behind sometimes closed doors, like this 00:51.000 --> 01:01.040 room and in the enterprise environments, you traditionally have the set-up where you 01:01.040 --> 01:09.280 admins control everything, so they have full coverage of what they do there, including 01:09.280 --> 01:15.360 how the names result and so on, and more to that, most of those names have no reason to 01:15.360 --> 01:21.360 exist outside of that environment or be resolved outside that environment. 01:21.360 --> 01:33.160 So to be kind of projects that try to implement the enterprise, the main infrastructure 01:33.160 --> 01:45.640 in open source wall, the Samba AD, or Samba in general, for over 30 years, and VAPAs in 2007. 01:45.640 --> 01:50.440 So we exist for quite a long time. 01:50.440 --> 01:57.600 And I just happen to be in both of these projects for quite some time, so I started working 01:57.600 --> 02:07.960 with Samba in actually 1998, and to the point that got invited to the team in 2003. 02:07.960 --> 02:16.720 So it's quite time, and then I joined Red Hat in 2011, and I cannot get rid of this 02:16.720 --> 02:20.280 job anymore. 02:20.280 --> 02:26.400 As a part of it, I'm also contributing to MIT corporates, but Greg Hudson, heavily reverites 02:26.440 --> 02:33.280 my patches, so I'm only contributing, not a committer or anything, but yeah, we go there. 02:33.280 --> 02:38.120 So what is this DNS pointer price, the main? 02:38.120 --> 02:47.100 Really, when we talk about the enterprise domains, it's almost always equivalent of saying 02:47.100 --> 02:51.200 unspoken active-directive word, right? 02:51.200 --> 02:58.040 So Microsoft did a great job in 90s by looking at the Unix environments, taking Unix 02:58.040 --> 03:03.400 technologies, taking open source stuff and projects developed there, combining them in a 03:03.400 --> 03:12.800 good, and sometimes I'm not a doxel way, and bringing them, selling them, so successful 03:12.800 --> 03:21.280 is that maybe 95% of all enterprise environments in the world for past 30 years where 03:21.280 --> 03:23.160 active-directory. 03:23.160 --> 03:30.720 It's almost at that time, it was a given that you deal with active-directory. 03:30.720 --> 03:39.000 So a lot of projects had to start looking at the compatibility with that, and certainly 03:39.000 --> 03:46.240 the free-APE started as one of those original aim was to get a not compatible with 03:46.240 --> 03:52.960 active-directory, but as easy as active-directory for deployment, full-inux stuff. 03:52.960 --> 03:59.040 But later we came to the same point that we have to integrate way of active-directory, 03:59.040 --> 04:05.240 and we had to add an off-integration ways, which made us, I mean, free-APE looking as if 04:05.280 --> 04:10.000 it's active-directory from the point of view of active-directory, not the users. 04:10.000 --> 04:18.200 But the typical thing is the main controllers, the main members, the main controllers typically 04:18.200 --> 04:26.640 Windows machines and Linux for, in case of Microsoft Active-directory, and Samba AD, which 04:26.640 --> 04:34.080 kind of tried to implement the equivalent, based on the protocol compatibility. 04:34.080 --> 04:38.760 And the main members, the main members are clients that enrolled in these domains, and 04:38.760 --> 04:41.920 they are all whatever they are. 04:41.920 --> 04:48.960 But the whole thing is, literally, we take L-dap as the centralized store with the replication 04:48.960 --> 04:53.000 mechanism across multiple domain controllers. 04:53.000 --> 05:03.040 We take some control protocols based on DCRPC mechanism, which comes from alpha, deck, 05:03.040 --> 05:13.120 and goes back to, I think, 179s and 78, so pretty old one, and then the curbers to combine 05:13.120 --> 05:17.920 them all and do mutual authentication, and so on. 05:17.920 --> 05:25.280 In IPA, it's exactly the same, except that the management APIs are basically HTTPS, 05:25.320 --> 05:28.800 it's like thinking in itself. 05:28.800 --> 05:39.920 So, all of these things actually is heavily dependent on DNS resolution, and it's not just 05:39.920 --> 05:48.080 a record, so I'm in the curbers' extremely fragile, at least according to the popular 05:48.080 --> 06:00.760 opinion, because in order to map the curbers' service principles to a certain resources, 06:00.760 --> 06:06.960 you have to have unified view on those resources and on those names, and most of the curbers' 06:06.960 --> 06:15.960 principles they are, well, built from service name, slash, what we call a host name, a full host 06:15.960 --> 06:16.960 name. 06:17.040 --> 06:23.680 Immediately get this natural map into the DNS view of your domain, and if you're all of 06:23.680 --> 06:29.680 your machines in the same DNS domain, that's easy, that you can do expansion, so on, but 06:29.680 --> 06:36.560 in reality, your environment might have multiple DNS domains belonging to the same logical 06:36.560 --> 06:43.920 domain, and this thing that when we talk about domain, we have to specify, is it active directory 06:44.000 --> 06:50.160 domain, or logical domain, organizational domain, and then DNS domain is something that is 06:50.160 --> 06:55.920 kind of evasive for administrators, many administrators miss this point, they think about 06:55.920 --> 07:06.400 domain as organizational one, the DNS is a menu detail for them, which causes a lot of trouble, 07:06.400 --> 07:13.120 a lot of troubles, shouldn't problems as well, so both domain controllers and domain members, 07:13.200 --> 07:22.480 they rely on the DNS, on the auto discovery for curbers, so you have to find out which curbers 07:22.480 --> 07:31.200 realm you're in, you have to discover where your domain controllers are, and there are protocols 07:31.200 --> 07:37.440 within active directory, which all windows clients are actually following, how they find this, 07:37.440 --> 07:46.560 so they look into these details, they look, SRV records, they follow some lookups, and sometimes 07:46.560 --> 07:54.000 we cannot use anything other than that because they always do this, you cannot really say to Windows 07:54.000 --> 08:02.320 machine that, hey, my domain controller is there by AP address, because it needs to mutually 08:02.320 --> 08:09.120 authenticate it, so authenticate itself there and authenticate the controller that it's the 08:09.120 --> 08:14.800 one who it presents itself, and for doing that it needs to have this on the curbers level, 08:15.360 --> 08:20.640 as the service principle, and they are constructed of DNS names, not AP addresses, 08:21.200 --> 08:27.760 so it's kind of tied together but not really obvious to the administrators, and this is how it 08:27.840 --> 08:35.680 looks like for any domains, this is from Microsoft specification MSADTS, it's technical spec for 08:35.680 --> 08:43.680 active directory, so all non-read only domain controllers must register a bunch of 08:44.640 --> 08:50.640 SRV records of this type where dot axis domain and then there are a few 08:51.520 --> 09:02.720 different expansions there, and DNS people know that this one is against typical RFCs in this area, 09:03.520 --> 09:12.480 here they are, your client must allow this, okay, we already have most of these knowledge 09:12.480 --> 09:20.400 encoded in the resolver libraries in the DNS components and so on, but 20 years ago this was 09:20.400 --> 09:28.480 a big trouble if you wanted to combine all these things together, on the domain members we do 09:29.200 --> 09:37.200 auto-discovery home to talk to, then which server out of what we discovered we have to talk to, 09:37.200 --> 09:47.360 which is also SRV records out of this set, the first three of them, and they might not belong to 09:47.360 --> 09:53.200 our domain, they might belong to a domain with trust, and we have to find someone whom we talk 09:53.200 --> 10:01.920 from that domain that we trust or how we delegate that there's very weird situation in 10:01.920 --> 10:07.520 most cases, but they also have to tell where they are, so this is dynamic update, 10:07.520 --> 10:18.080 that is typically nowadays done with a lot of different protocols, most of the public DNS 10:18.880 --> 10:26.960 systems allow you to do some rest like API update, but this is enterprise domain, the only thing 10:26.960 --> 10:35.840 they trust is their mutual authentication, which is essentially Kerberus, right, so all of them support 10:36.800 --> 10:48.640 using the GSS to seek, and that's RFC 3645, but with a twist, so the spec is actually called 10:48.640 --> 10:57.920 GSSA, MSGSSA, it's public, it's implemented in most places, in most libraries, 10:58.800 --> 11:04.720 or traditional libraries, like say, bind has this implementation and buy and bootials 11:05.520 --> 11:12.240 therefore, but most of the new languages like GoRAS, the people re-implemental of this, and they 11:12.240 --> 11:21.520 have hard time finding out these things, they are all documented, so for example, HMAKMD5 from TK 11:22.480 --> 11:32.080 RFC is not used, actually banned, the MSGSSA spec says must not use this one, and the reason 11:32.080 --> 11:42.080 for that is a bit unobvious, because remember evolution of the active directory, it started with 11:42.320 --> 11:53.760 Windows NT domains structure, which used RC4 hash to encode password, so when active directory 11:53.760 --> 12:02.320 came in and they switched to use Kerberus, they actually used HMAKRC4 to encode passwords, which 12:02.320 --> 12:10.640 actually takes just that hash and gets it into the Kerberus hash, one to one, so if you take HMAKMD5 12:10.720 --> 12:18.560 here it's essentially that hash, so you disclose your machine account credential immediately, 12:19.280 --> 12:27.360 so it's not allowed to use that one, you have to use something better, in this case the Kerberus 12:27.360 --> 12:36.160 service ticket to sign of this, but in the end your result is something where the digest to sign 12:36.240 --> 12:44.400 the last message is not really fitting into the original RFC for GSSTC, so they extended the 12:44.400 --> 12:53.440 way how it's done, and if you just implemented the RFC you don't get this, again most of the code 12:53.440 --> 13:03.040 in stuff like bind supports it, the wildcard updates are not supported, and they are like 13:03.040 --> 13:10.160 this is a quick, you cannot do wildcard update, you have to specify the the correct one, 13:10.160 --> 13:19.360 this now bites, if you try to use NS update with GSSTC to sign updates like proof of 13:19.360 --> 13:28.160 possession of a DNS record for acne, and if you do the wildcard entry you cannot use that, 13:28.240 --> 13:33.200 against, again, against Windows DNS server, but you can do this with bind for example, 13:34.400 --> 13:44.720 I guess also power DNS does the same, and does support it, and on the, on bind site for example, 13:44.720 --> 13:50.880 the actual access control who can write is based on the fact that you can match 13:51.520 --> 13:58.880 a more generic, much more generic, echo system, access control system, in active directory, 13:58.880 --> 14:05.440 it's literally like an object and LDAP has a bunch of access controls associated with it, 14:05.440 --> 14:12.400 and DNS update comes in authenticates as that machine account, and that machine account has to 14:12.400 --> 14:19.840 have a mapping to what is allowed in this access control list, but because we're not doing it the same 14:20.480 --> 14:30.320 way, bind and playments like eight variants of matching kerbura's principle to what is happening 14:30.320 --> 14:38.000 to the zone, so yeah, four of them based on the machine account name, which is like real 14:38.000 --> 14:45.440 account name with the dollar, like machine dollar or something, and four of them rely on, because 14:45.520 --> 14:52.560 that's equivalent of host slash something in the normal kerbura's, for them rely on the 14:52.560 --> 14:59.280 kerbura's, that doesn't help administrators, because they don't understand what it is, and 14:59.280 --> 15:04.000 reading through the documentation it doesn't help either, because the documentation says, 15:04.000 --> 15:08.960 this is how it's done in active directory, it's not how it's done in active directory, it's the 15:09.920 --> 15:18.000 visual effect of what is being done underneath in the active directory, but if you automate this, 15:18.000 --> 15:25.280 if you hide this within the actual code implementation, then most of the users don't really care, 15:25.280 --> 15:33.360 except that you have to put this echo on the zone file, right? The other part of, you don't really 15:33.440 --> 15:43.040 run NS update manually, you run it as a part of a high-level activity, so for example, in a free 15:43.040 --> 15:54.480 APA we use SSSD to combine all of this, and SSSD looks for network changes and then fires up NS update 15:54.480 --> 16:03.200 with a file that contains all the details, and uses the machine account keypap, which may or may 16:03.200 --> 16:11.920 not be contained in the machine credential, so machine name with the dollar in the end, or it may 16:11.920 --> 16:18.960 contain the host principle, and so on, this is the same for users, this is the against pure 16:18.960 --> 16:27.120 active directory, stuff, Samba on its own has two different DNS update implementations historically, 16:27.120 --> 16:37.920 so there's NS update GSS, which nobody uses these days, I hope, it comes from the tool that is called 16:37.920 --> 16:48.640 NetOnePire, which was used to slurp data from Windows in T-domains and populate your Samba 16:48.640 --> 16:56.560 AD environment, and then the other one is Samba DNS update, which is similar to what SSSD does 16:56.560 --> 17:05.600 as a wrapper on top of NS update, it generates the update file, it verifies entries that should go 17:05.600 --> 17:13.040 there chooses to write credential to authenticate with and does all this thing, there was another one 17:14.480 --> 17:22.720 utility that was used internally to propagate this information over a DCRPC interfaces, and that's 17:22.720 --> 17:30.560 not visible to that instance, that's not configurable, then the domain controllers, if we come back, 17:30.560 --> 17:38.160 they really don't really depend on DNS themselves except being able to find each other or find 17:38.160 --> 17:48.240 the whoever they talk to, so once DNS own setup dynamic update is about the only issue that you get there, 17:48.800 --> 17:56.800 the changes for zones can come from other sources, and one of them, the big one, is replication, 17:56.800 --> 18:06.240 so one of them is this set of protocols built on DCRPC, in Active Directory that's DRCU, 18:06.240 --> 18:12.800 which is replication mechanism between all Active Directory things, in free API we use 18:14.000 --> 18:21.920 LDAP replication that our LDAP server implements, which is eventual consistency, so you get 18:21.920 --> 18:27.600 sometimes inconsistent situation, but eventually it gets consistent, but it's what's important, 18:27.600 --> 18:34.640 it's modification from outside of the DNS server, so you have to sync details between them, 18:35.600 --> 18:43.520 and on free API side, so we can work with the external one, somebody also can work with the external 18:43.520 --> 18:52.640 one, you don't get the dynamic updates, with that case, but if you do integrate, then we use 18:52.640 --> 19:03.520 bind, and we have a plugin that uses internal bind API, the dynamic database API, and it basically 19:04.320 --> 19:13.120 able to look up and LDAP and do updates over to the LDAP, so it kind of keeps the synchronization 19:13.920 --> 19:21.520 it works fairly well when it doesn't work, it's harder to debug, and that happens. 19:24.000 --> 19:30.240 You can manage again these through different things, there is support for DNSSEC, 19:30.240 --> 19:39.840 through the open DNSSEC because we need to deal with PKSS 11 tokens, and bind only has, like 19:40.400 --> 19:49.600 I think it's a file system based at DNSSEC store, and we need to kind of again transfer data 19:49.600 --> 19:58.480 between them, what's important, all free API servers, they replicate to each other, and they all 19:58.480 --> 20:06.160 become DNS authority DNS server, so there is not a one authority DNS server for a zone, 20:07.040 --> 20:13.520 a lot of them, and sometimes that creates problems for clients, thinking, doing something, 20:13.520 --> 20:20.400 but surprisingly all of this works relatively well with the large amount of zones to the point 20:20.400 --> 20:26.320 of we figure it out, that we have a lot of users that actually use our web UI, for API, a web UI 20:26.320 --> 20:37.680 to exclusively manage their DNS zones, and I got recently a note from one of the users that 20:37.680 --> 20:44.960 they actually write in their own management UI for that utility, because you can use this bind 20:44.960 --> 20:54.640 in the buildup outside of IP, just against normal LDAP server as well. In some of the case, 20:54.640 --> 21:01.360 they have obviously external one, but they also integrate with bind through a different API, 21:01.360 --> 21:11.120 this DLC API, which I know bind team kind of wants to deprecate, at least there are 21:11.120 --> 21:16.960 good reasons for doing that, and that means for somebody it's a big problem. 21:17.920 --> 21:24.720 It also has its own DNS implementation, but it's not scalable to the level that some 21:24.720 --> 21:33.440 by AD needs, and so we have an interesting problems, because of these APIs, they both internal, 21:33.440 --> 21:41.120 and they are not really stable, so bind team, refactor stem, and changes at will, 21:41.840 --> 21:48.560 and we find out that, especially in Debian, where the new thing is uploaded, you cannot really 21:48.560 --> 21:54.720 build or rebuild bind into buildup, because it's API completely changed it internally. 21:55.840 --> 22:04.880 In Fedore, in a rail, we kind of control how updates of bind happens, so we coordinate our 22:04.960 --> 22:16.240 activities, but this is typical problem. So 920.4, change log says, DLC API will be removed, 22:16.240 --> 22:26.480 or consider it removed in in future, so it's at least message to prepare to do something different. 22:26.480 --> 22:34.240 Again, when it was like 8 months ago, this issue was open saying that we don't really want to 22:34.240 --> 22:42.400 install developer headers anymore, so you wouldn't get the access to API publicly anymore. 22:42.400 --> 22:55.040 Well, it's not finished yet, but with the 920, the script that installs, that installs 22:55.040 --> 23:03.760 the information about how you compile against bind is not available already, and I'll just 23:03.760 --> 23:11.680 go maybe two minutes about where we are, so we are working on the rewrite of bind in the buildup 23:11.680 --> 23:20.080 to become compatible with the bind going forward. Ideally, maybe get to the point to discuss with 23:20.080 --> 23:28.640 bind team maybe merge this code eventually. We are working on the encrypted DNS setup 23:29.440 --> 23:37.200 from the ground like before you get machine started to the point where you have your infrastructure 23:37.200 --> 23:46.560 deployed with this. It's the PDF is available, you can look close to it, but it's a combination 23:46.560 --> 23:53.360 of bind and unbound because bind version we have currently doesn't have all support for features 23:53.360 --> 24:03.040 we need. And because we stock, we have complexity on backports in these things, that's fun, 24:03.040 --> 24:11.280 probably for beer stories, and we also have challenges because some of the unrelated changes that 24:11.280 --> 24:19.360 happened in other open source components for us to do some decisions. So, for example, 24:19.360 --> 24:28.240 open SSL deprecated one way of loading crypto primitives and say you have to do the other one. 24:28.240 --> 24:35.200 Well, 10 will completely remove that API, the old one, which is used in bind 24:35.360 --> 24:44.640 9, 16, 18, but not used in bind 9, 20, but we cannot use bind 9, 20. So, it's a circus that we have to 24:46.000 --> 24:52.800 enjoy probably. And the other challenge is that by the time we will solve all of this, 24:52.800 --> 25:00.400 there will be this deprecation of everything crypto wise. So, post quantum crypto is already being 25:00.400 --> 25:10.800 pushed by the governmental institutions, and by 2030 we will get done. So, that's actually all. 25:13.360 --> 25:14.000 Thank you. 25:16.400 --> 25:20.800 I wish the one person to be on matrix, if people here have questions, please find another journal 25:20.800 --> 25:23.440 later, and maybe you would always have a chat. 25:24.160 --> 25:24.720 Bye bye. 25:26.000 --> 25:26.720 Thank you.