On 01 Mar 2007, at 12:40, Robert Bailey wrote: > I see... nslookup fails because it looks up via IP first, but just > "using" the dns host entries like sftp myserver, works find.
nslookup fails because it tries to communicate directly with the DNS server, a connection it can't establish because that'd be a connection that crosses label-imposed boundaries. Using DNS entries from within an application via the nameservice works, but if you had an application that tried to contact the server directly (like nslookup does) it fails; what you can do is to setup the DNS server at the same label as where your queries originate from, or set up a DNS server that listens on a multi-level port, so that it can answer queries from any label. (If you do set it up to listen on an MLP you want to make sure that the information it distributes is not considered to be of a higher confidentiality level than the labels you're allowing access) > I wish sun offered a class on Sol10 TX. ... There is someone working on a TX class, but I don't know what the timeframe is for its arrival. On 01 Mar 2007, at 23:32, Darren J Moffat wrote: > Bart Blanquart wrote: >> The resolver in a zone doesn't contact the DNS-server itself: it >> makes a door-call to nscd in the global zone, which does the >> lookup on its behalf -- so there is no need for network >> connectivity between the labeled zone and the DNS-server (wherever >> it's running). > I thought it was just lookups done through the nsswitch that worked > like that. For direct use of libresolv there is no door to nscd so > I would expect that the /etc/resolv.conf in the labeled zone would > be used. Right, I may have used the wrong terminology: it's indeed only lookups done through the nsswitch that make use of the door to the nscd in the global zone. Applications that use libresolv directly will be able to get hostnames resolved only if the DNS server is at the same label as the application, or listens on an MLP. Bart
