I'd like to thank you very much for this album.
This is Alexander.
We'll be talking to us about the idea with somebody in the integration.
Yeah, so thank you for taking this talk.
I kind of feel that sometimes the traditional corporate environments, they don't get attention
anymore, especially in the DNS, which supposed to be tangle in together public environments.
We are talking now about the stuff that happens behind sometimes closed doors, like this
room and in the enterprise environments, you traditionally have the set-up where you
admins control everything, so they have full coverage of what they do there, including
how the names result and so on, and more to that, most of those names have no reason to
exist outside of that environment or be resolved outside that environment.
So to be kind of projects that try to implement the enterprise, the main infrastructure
in open source wall, the Samba AD, or Samba in general, for over 30 years, and VAPAs in 2007.
So we exist for quite a long time.
And I just happen to be in both of these projects for quite some time, so I started working
with Samba in actually 1998, and to the point that got invited to the team in 2003.
So it's quite time, and then I joined Red Hat in 2011, and I cannot get rid of this
job anymore.
As a part of it, I'm also contributing to MIT corporates, but Greg Hudson, heavily reverites
my patches, so I'm only contributing, not a committer or anything, but yeah, we go there.
So what is this DNS pointer price, the main?
Really, when we talk about the enterprise domains, it's almost always equivalent of saying
unspoken active-directive word, right?
So Microsoft did a great job in 90s by looking at the Unix environments, taking Unix
technologies, taking open source stuff and projects developed there, combining them in a
good, and sometimes I'm not a doxel way, and bringing them, selling them, so successful
is that maybe 95% of all enterprise environments in the world for past 30 years where
active-directory.
It's almost at that time, it was a given that you deal with active-directory.
So a lot of projects had to start looking at the compatibility with that, and certainly
the free-APE started as one of those original aim was to get a not compatible with
active-directory, but as easy as active-directory for deployment, full-inux stuff.
But later we came to the same point that we have to integrate way of active-directory,
and we had to add an off-integration ways, which made us, I mean, free-APE looking as if
it's active-directory from the point of view of active-directory, not the users.
But the typical thing is the main controllers, the main members, the main controllers typically
Windows machines and Linux for, in case of Microsoft Active-directory, and Samba AD, which
kind of tried to implement the equivalent, based on the protocol compatibility.
And the main members, the main members are clients that enrolled in these domains, and
they are all whatever they are.
But the whole thing is, literally, we take L-dap as the centralized store with the replication
mechanism across multiple domain controllers.
We take some control protocols based on DCRPC mechanism, which comes from alpha, deck,
and goes back to, I think, 179s and 78, so pretty old one, and then the curbers to combine
them all and do mutual authentication, and so on.
In IPA, it's exactly the same, except that the management APIs are basically HTTPS,
it's like thinking in itself.
So, all of these things actually is heavily dependent on DNS resolution, and it's not just
a record, so I'm in the curbers' extremely fragile, at least according to the popular
opinion, because in order to map the curbers' service principles to a certain resources,
you have to have unified view on those resources and on those names, and most of the curbers'
principles they are, well, built from service name, slash, what we call a host name, a full host
name.
Immediately get this natural map into the DNS view of your domain, and if you're all of
your machines in the same DNS domain, that's easy, that you can do expansion, so on, but
in reality, your environment might have multiple DNS domains belonging to the same logical
domain, and this thing that when we talk about domain, we have to specify, is it active directory
domain, or logical domain, organizational domain, and then DNS domain is something that is
kind of evasive for administrators, many administrators miss this point, they think about
domain as organizational one, the DNS is a menu detail for them, which causes a lot of trouble,
a lot of troubles, shouldn't problems as well, so both domain controllers and domain members,
they rely on the DNS, on the auto discovery for curbers, so you have to find out which curbers
realm you're in, you have to discover where your domain controllers are, and there are protocols
within active directory, which all windows clients are actually following, how they find this,
so they look into these details, they look, SRV records, they follow some lookups, and sometimes
we cannot use anything other than that because they always do this, you cannot really say to Windows
machine that, hey, my domain controller is there by AP address, because it needs to mutually
authenticate it, so authenticate itself there and authenticate the controller that it's the
one who it presents itself, and for doing that it needs to have this on the curbers level,
as the service principle, and they are constructed of DNS names, not AP addresses,
so it's kind of tied together but not really obvious to the administrators, and this is how it
looks like for any domains, this is from Microsoft specification MSADTS, it's technical spec for
active directory, so all non-read only domain controllers must register a bunch of
SRV records of this type where dot axis domain and then there are a few
different expansions there, and DNS people know that this one is against typical RFCs in this area,
here they are, your client must allow this, okay, we already have most of these knowledge
encoded in the resolver libraries in the DNS components and so on, but 20 years ago this was
a big trouble if you wanted to combine all these things together, on the domain members we do
auto-discovery home to talk to, then which server out of what we discovered we have to talk to,
which is also SRV records out of this set, the first three of them, and they might not belong to
our domain, they might belong to a domain with trust, and we have to find someone whom we talk
from that domain that we trust or how we delegate that there's very weird situation in
most cases, but they also have to tell where they are, so this is dynamic update,
that is typically nowadays done with a lot of different protocols, most of the public DNS
systems allow you to do some rest like API update, but this is enterprise domain, the only thing
they trust is their mutual authentication, which is essentially Kerberus, right, so all of them support
using the GSS to seek, and that's RFC 3645, but with a twist, so the spec is actually called
GSSA, MSGSSA, it's public, it's implemented in most places, in most libraries,
or traditional libraries, like say, bind has this implementation and buy and bootials
therefore, but most of the new languages like GoRAS, the people re-implemental of this, and they
have hard time finding out these things, they are all documented, so for example, HMAKMD5 from TK
RFC is not used, actually banned, the MSGSSA spec says must not use this one, and the reason
for that is a bit unobvious, because remember evolution of the active directory, it started with
Windows NT domains structure, which used RC4 hash to encode password, so when active directory
came in and they switched to use Kerberus, they actually used HMAKRC4 to encode passwords, which
actually takes just that hash and gets it into the Kerberus hash, one to one, so if you take HMAKMD5
here it's essentially that hash, so you disclose your machine account credential immediately,
so it's not allowed to use that one, you have to use something better, in this case the Kerberus
service ticket to sign of this, but in the end your result is something where the digest to sign
the last message is not really fitting into the original RFC for GSSTC, so they extended the
way how it's done, and if you just implemented the RFC you don't get this, again most of the code
in stuff like bind supports it, the wildcard updates are not supported, and they are like
this is a quick, you cannot do wildcard update, you have to specify the the correct one,
this now bites, if you try to use NS update with GSSTC to sign updates like proof of
possession of a DNS record for acne, and if you do the wildcard entry you cannot use that,
against, again, against Windows DNS server, but you can do this with bind for example,
I guess also power DNS does the same, and does support it, and on the, on bind site for example,
the actual access control who can write is based on the fact that you can match
a more generic, much more generic, echo system, access control system, in active directory,
it's literally like an object and LDAP has a bunch of access controls associated with it,
and DNS update comes in authenticates as that machine account, and that machine account has to
have a mapping to what is allowed in this access control list, but because we're not doing it the same
way, bind and playments like eight variants of matching kerbura's principle to what is happening
to the zone, so yeah, four of them based on the machine account name, which is like real
account name with the dollar, like machine dollar or something, and four of them rely on, because
that's equivalent of host slash something in the normal kerbura's, for them rely on the
kerbura's, that doesn't help administrators, because they don't understand what it is, and
reading through the documentation it doesn't help either, because the documentation says,
this is how it's done in active directory, it's not how it's done in active directory, it's the
visual effect of what is being done underneath in the active directory, but if you automate this,
if you hide this within the actual code implementation, then most of the users don't really care,
except that you have to put this echo on the zone file, right? The other part of, you don't really
run NS update manually, you run it as a part of a high-level activity, so for example, in a free
APA we use SSSD to combine all of this, and SSSD looks for network changes and then fires up NS update
with a file that contains all the details, and uses the machine account keypap, which may or may
not be contained in the machine credential, so machine name with the dollar in the end, or it may
contain the host principle, and so on, this is the same for users, this is the against pure
active directory, stuff, Samba on its own has two different DNS update implementations historically,
so there's NS update GSS, which nobody uses these days, I hope, it comes from the tool that is called
NetOnePire, which was used to slurp data from Windows in T-domains and populate your Samba
AD environment, and then the other one is Samba DNS update, which is similar to what SSSD does
as a wrapper on top of NS update, it generates the update file, it verifies entries that should go
there chooses to write credential to authenticate with and does all this thing, there was another one
utility that was used internally to propagate this information over a DCRPC interfaces, and that's
not visible to that instance, that's not configurable, then the domain controllers, if we come back,
they really don't really depend on DNS themselves except being able to find each other or find
the whoever they talk to, so once DNS own setup dynamic update is about the only issue that you get there,
the changes for zones can come from other sources, and one of them, the big one, is replication,
so one of them is this set of protocols built on DCRPC, in Active Directory that's DRCU,
which is replication mechanism between all Active Directory things, in free API we use
LDAP replication that our LDAP server implements, which is eventual consistency, so you get
sometimes inconsistent situation, but eventually it gets consistent, but it's what's important,
it's modification from outside of the DNS server, so you have to sync details between them,
and on free API side, so we can work with the external one, somebody also can work with the external
one, you don't get the dynamic updates, with that case, but if you do integrate, then we use
bind, and we have a plugin that uses internal bind API, the dynamic database API, and it basically
able to look up and LDAP and do updates over to the LDAP, so it kind of keeps the synchronization
it works fairly well when it doesn't work, it's harder to debug, and that happens.
You can manage again these through different things, there is support for DNSSEC,
through the open DNSSEC because we need to deal with PKSS 11 tokens, and bind only has, like
I think it's a file system based at DNSSEC store, and we need to kind of again transfer data
between them, what's important, all free API servers, they replicate to each other, and they all
become DNS authority DNS server, so there is not a one authority DNS server for a zone,
a lot of them, and sometimes that creates problems for clients, thinking, doing something,
but surprisingly all of this works relatively well with the large amount of zones to the point
of we figure it out, that we have a lot of users that actually use our web UI, for API, a web UI
to exclusively manage their DNS zones, and I got recently a note from one of the users that
they actually write in their own management UI for that utility, because you can use this bind
in the buildup outside of IP, just against normal LDAP server as well. In some of the case,
they have obviously external one, but they also integrate with bind through a different API,
this DLC API, which I know bind team kind of wants to deprecate, at least there are
good reasons for doing that, and that means for somebody it's a big problem.
It also has its own DNS implementation, but it's not scalable to the level that some
by AD needs, and so we have an interesting problems, because of these APIs, they both internal,
and they are not really stable, so bind team, refactor stem, and changes at will,
and we find out that, especially in Debian, where the new thing is uploaded, you cannot really
build or rebuild bind into buildup, because it's API completely changed it internally.
In Fedore, in a rail, we kind of control how updates of bind happens, so we coordinate our
activities, but this is typical problem. So 920.4, change log says, DLC API will be removed,
or consider it removed in in future, so it's at least message to prepare to do something different.
Again, when it was like 8 months ago, this issue was open saying that we don't really want to
install developer headers anymore, so you wouldn't get the access to API publicly anymore.
Well, it's not finished yet, but with the 920, the script that installs, that installs
the information about how you compile against bind is not available already, and I'll just
go maybe two minutes about where we are, so we are working on the rewrite of bind in the buildup
to become compatible with the bind going forward. Ideally, maybe get to the point to discuss with
bind team maybe merge this code eventually. We are working on the encrypted DNS setup
from the ground like before you get machine started to the point where you have your infrastructure
deployed with this. It's the PDF is available, you can look close to it, but it's a combination
of bind and unbound because bind version we have currently doesn't have all support for features
we need. And because we stock, we have complexity on backports in these things, that's fun,
probably for beer stories, and we also have challenges because some of the unrelated changes that
happened in other open source components for us to do some decisions. So, for example,
open SSL deprecated one way of loading crypto primitives and say you have to do the other one.
Well, 10 will completely remove that API, the old one, which is used in bind
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
enjoy probably. And the other challenge is that by the time we will solve all of this,
there will be this deprecation of everything crypto wise. So, post quantum crypto is already being
pushed by the governmental institutions, and by 2030 we will get done. So, that's actually all.
Thank you.
I wish the one person to be on matrix, if people here have questions, please find another journal
later, and maybe you would always have a chat.
Bye bye.
Thank you.