On Sat, Nov 6, 2010 at 4:19 AM, Milan Jurik <milan.ju...@oracle.com> wrote: > Hi Mike, > > Mike Gerdts píše v pá 05. 11. 2010 v 13:06 -0500: >> On Fri, Nov 5, 2010 at 12:22 PM, Milan Jurik <milan.ju...@oracle.com> wrote: >> > >> > Hi, >> > >> > Mike Gerdts píše v pá 05. 11. 2010 v 12:10 -0500: >> > > It is trying to do an IPv6 lookup (via ipnodes) before trying an IPv4 >> > > lookup (via hosts). Since you probably aren't using IPv6, you can get >> > > the desired behavior with: >> > > >> > > hosts: files nis dns >> > > ipnodes: files >> > > >> > >> > such config is really baaaad idea. Keep them in sync from Solaris 10 >> > releases. >> >> Can you elaborate? > > E.g. double parsing of flat file before going to DNS?
Before PSARC/2006/299 most people that would find this configuration desirable would have a very small ipnodes file. That is, it would likely only have the entries added by the installer. > >> If IPv6 is not in use, having ipnodes go to DNS >> does little other than cause unnecessary DNS requests that will always >> fail. My observation is that the times that you notice it is failing >> are those times where it causes a really long timeout to be invoked. >> > > In correctly set environment DNS server will not timeout for AAAA > records requests. Not everyone is so lucky to have a properly working DNS server. In particular, if you are having network problems that prevent you from reaching the DNS server(s) then it can be quite frustrating. > > There are cases where such config will bring something good but only in > rare cases it is not hiding some real setup problem. There is still not > clear why with common setup of hosts/ipnodes he does not see effect of > nscd cache and queries going to DNS even if needed data are in files. Perhaps cached negative lookups (misses for IPv6) are timing out before positive lookups? That is, it forgets that ipnodes doesn't provide the answer before it forgets that hosts has the answer. As a result, it has to go look to ipnodes since it is always searched before hosts. > > Still, ipnodes are not obsolete because if you query only hosts > database, DNS backend will generate only query only fo A record, in case > of ipnodes, it will generate both (so your workaround will work). My words were not chosen carefully... Turning /etc/inet/ipnodes into a symbolic link to /etc/inet/hosts "for backward compatibility", as was done with the implementation PSARC/2006/299 makes ipnodes(4) obsolete in my mind. Solaris considers it a "stable" (not obsolete) interface. The effect of PSARC/2006/299 is that the non-existence of the ipnodes file a completely workable configuration aside from those users that would actually modify /etc/inet/ipnodes and expect it to have some effect. I did not intend to say that the existence of ipnodes in nsswitch.conf was obsolete. Sorry for the confusion. http://arc.opensolaris.org/caselog/PSARC/2006/299/materials/spec.txt http://hg.genunix.org/onnv-gate.hg/rev/318aeb1049d9 How does one force software that they did not write to use only hosts lookups? I've observed this problematic behavior on systems that do not have and have never had an IPv6 address configured. I'm not aware of applications that first look to see if it is possible to speak IPv6 before asking the name service switch for an IPv6 address. Initially I was thinking it would be a useful enhancement to make the name service switch fail fast if IPv6 was not configured and someone was doing an ipnodes lookup that would hit DNS. However, it is quite reasonable to expect that an IPv4-only host would be able to ask about the IPv6 world. What I would really like is to say: ipnodes: none For the case where IPv6 is not used. My first attempt at solving this problem was to remove/comment the ipnodes nsswitch.conf entry. However, this seemed to have the effect of ipnodes choosing the same name services as hosts. My initial debugging of these unwanted IPv6 lookups dates back many years (Solaris 8 or 9?) so things may have changed. > > Best regards, > > Milan Likewise, Mike -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
