On Sun, Dec 18, 2011 at 07:09:30PM +0100, Marco Pizzoli wrote: > Hi, > I started to look at the documentation of FreeIPA and SSSD. > Now I'm curious to know about the relationship between sssd and the dns > servers. > To be honest, I'm not sure I completely understand what are you trying to accomplish. I'll try to answer your questions, but feel free to clarify or steer me in the right direction. One thing to keep in mind is that SSSD does not perform name resolution through glibc, mostly because glibc's interface is synchronous. SSSD uses the "c-ares" library. c-ares does read /etc/hosts and /etc/resolv.conf so there is no separate config and the name resolution gives the same results as it would if performed via glibc, but the name resolution process itself is completely standalone. > As I can see, obviously, the deployment of all windows-style services are > led by a query/response by sssd to dns servers, possibly directly to the > FreeIPA dns server. There are two ways SSSD queries DNS when acting as a FreeIPA client, depending on your configuration: 1) name resolution to get the IP address corresponding to a hostname in the "ipa_server" parameter 2) if the IPA server is not set, query DNS using the SRV records to get the list of servers and then perform 1) > When deploying sssd I have to configure the resolv.conf file. Is hereafter > sssd the only service which is *required* to use that file? > I don't understand this part, sorry. /etc/resolv.conf is read prominently by the glibc resolver and affects library calls such as gethostbyname etc. In a centralized environment, the resolv.conf would typically be set by DHCP. > I'm thinking to the unix/linux farm of my office in which, by taking a > weighted choice, they decided to not use the dns servers, relying only on > /etc/hosts files. The order of the hosts databases (aka when to use resolv.conf and when to use /etc/hosts) is set in the /etc/nsswitch.conf config file with the hosts directive. The typical order is "files dns" which translates to "ask /etc/hosts first and if there's no answer, go ask the servers in /etc/resolv.conf" c-ares reads that order so it should work in sync with the rest of the system. c-ares allows overriding the list of servers it talks to, but currently SSSD does not expose or leverage this interface. > > If you confirm this, do you think it would be a good idea the filing of a > feature request asking to have an option for sssd to choose the > resolv.conf file to point to? > So I could use a file called, for example, "/etc/resolv.conf.FreeIPA". So > I can be sure that no other services will use that dns's. If we want to support this feature, I would much prefer adding a new config option directly to sssd.conf than a new resolv.conf style file. That said, can you explain why would you like to see this feature?

If it's just for overriding DNS config per-client, then I would suggest to do this using either some DHCP client override (such as dhcp-class) or distribute /etc/hosts to clients.

On Sun, Dec 18, 2011 at 11:00:12PM +0100, Marco Pizzoli wrote: > Hi Jakub, > first of all thanks for the complete response. You told me a lot of > things I didn't know. > Please, see my answer below. > > On Sun, Dec 18, 2011 at 10:36 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt;

> On Sun, Dec 18, 2011 at 07:09:30PM +0100, Marco Pizzoli wrote: > > Hi, > > I started to look at the documentation of FreeIPA and SSSD. > > Now I'm curious to know about the relationship between sssd and > > the > > dns > > > servers. > > To be honest, I'm not sure I completely understand what are you > trying to accomplish. I'll try to answer your questions, but feel > free to clarify or steer me in the right direction. > > One thing to keep in mind is that SSSD does not perform name > resolution through glibc, mostly because glibc's interface is > synchronous. SSSD uses > the "c-ares" library. c-ares does read /etc/hosts and > /etc/resolv.conf so > there is no separate config and the name resolution gives the same > results > as it would if performed via glibc, but the name resolution process > itself > is completely standalone. > > > As I can see, obviously, the deployment of all windows-style > > services are > > > led by a query/response by sssd to dns servers, possibly > > directly > > to the > > > FreeIPA dns server. > > There are two ways SSSD queries DNS when acting as a FreeIPA client, > > depending on your configuration: > 1) name resolution to get the IP address corresponding to a > hostname in > > the "ipa_server" parameter > > 2) if the IPA server is not set, query DNS using the SRV records to > get > > the list of servers and then perform 1) > > > When deploying sssd I have to configure the resolv.conf file. > > Is > > hereafter > > > sssd the only service which is *required* to use that file? > > I don't understand this part, sorry. /etc/resolv.conf is read > prominently > by the glibc resolver and affects library calls such as > gethostbyname etc. > > In a centralized environment, the resolv.conf would typically be set > by DHCP. > > > I'm thinking to the unix/linux farm of my office in which, by > > taking a > > > weighted choice, they decided to not use the dns servers, > > relying > > only on > > > /etc/hosts files. > > The order of the hosts databases (aka when to use resolv.conf and > when to use /etc/hosts) is set in the /etc/nsswitch.conf config > file with the hosts directive. The typical order is "files dns" > which translates to "ask /etc/hosts first and if there's no answer, > go ask the servers in /etc/resolv.conf" > > c-ares reads that order so it should work in sync with the rest of > the system. c-ares allows overriding the list of servers it talks > to, but currently SSSD does not expose or leverage this interface. > > > If you confirm this, do you think it would be a good idea the > > filing of a > > > feature request asking to have an option for sssd to choose the > > resolv.conf file to point to? > > So I could use a file called, for example, > > "/etc/resolv.conf.FreeIPA". So > > > I can be sure that no other services will use that dns's. > > If we want to support this feature, I would much prefer adding a new > config > option directly to sssd.conf than a new resolv.conf style file. > > That said, can you explain why would you like to see this feature? > > My wish is to use sssd on a Linux system joined to a FreeIPA domain, > but being able to do this still *not* enabling the dns resolution for > the rest of that Linux system -> not populating the /etc/resolv.conf > file. So you would like to use DNS resolution only for sssd and let the rest of the system rely only on data in /etc/hosts? That seems like a recipe for trouble, keep in mind that libraries that SSSD uses might still want to perform name resolution themselves. For instance, Kerberos might need to canonicalize hostname in some cases.

What is the problem you are trying to solve with this separation? > If I correctly understand, you are telling me that I could achieve > this result by withdrawing the "dns" keyword from the > /etc/nsswitch.conf file. Is this right? Not quite. Even though c-ares is a standalone resolver, it still reads /etc/nsswitch.conf and resolves in same order as specified there. > If it's just for overriding DNS config per-client, then I would > suggest to > do this using either some DHCP client override (such as dhcp-class) > or distribute /etc/hosts to clients. > > I understand these suggestions but we don't use dhcp and centralizing > the /etc/hosts distribution has not been considered so far. > > Thanks again, I very appreciated > Marco

> > My wish is to use sssd on a Linux system joined to a FreeIPA domain, > > but > > > being able to do this still *not* enabling the dns resolution for > > the > > rest > > > of that Linux system -> not populating the /etc/resolv.conf file. > > So you would like to use DNS resolution only for sssd and let the rest > of the system rely only on data in /etc/hosts? That seems like a recipe > for trouble, keep in mind that libraries that SSSD uses might still want > to perform name resolution themselves. For instance, Kerberos might need > to canonicalize hostname in some cases. > > What is the problem you are trying to solve with this separation? You caught the point. In the past we used to have all Linux production systems use the dns server. In our business dns servers are managed by a different office. During normal operations we faced occasional problems that prevented us to guarantee our service level agreement: - the dns server having a bad configuration following a configuration upgrade: his forwarding policies went messes and we had a lot of delay in serving requests - the dns server solves every system in the network: when network isolation is not achievable, we limited the "visibility" of system by not enable them to be found in searching by names. This helped a lot also when some colleagues make a mistake by forgetting to change the configuration of web applications from test to production (db connection strings, and so on...). We decided to not use the dns server and put in the /etc/hosts file only the hosts we were aware that particular system had need to communicate to.

> > If I correctly understand, you are telling me that I could achieve > > this > > > result by withdrawing the "dns" keyword from the /etc/nsswitch.conf > > file. > > > Is this right? > > Not quite. Even though c-ares is a standalone resolver, it still reads > /etc/nsswitch.conf and resolves in same order as specified there. Ok, I understand. Thanks again Marco

You caught the point. In the past we used to have all Linux production systems use the dns server. In our business dns servers are managed by a different office. During normal operations we faced occasional problems that prevented us to guarantee our service level agreement: - the dns server having a bad configuration following a configuration upgrade: his forwarding policies went messes and we had a lot of delay in serving requests - the dns server solves every system in the network: when network isolation is not achievable, we limited the "visibility" of system by not enable them to be found in searching by names. This helped a lot also when some colleagues make a mistake by forgetting to change the configuration of web applications from test to production (db connection strings, and so on...). We decided to not use the dns server and put in the /etc/hosts file only the hosts we were aware that particular system had need to communicate to.