rpc.bootparamd uses nameserver: single point failure?

[Manavendra K. Thakur]

Hi all,

After installing the new libc_resolv.so.sun3 library from uunet, we
noticed that in addition to programs like finger and telnet,
rpc.bootparamd was also using the nameserver to resolve hostnames.

How do other sites feel about this?  Are you worried about the fact that
you are dependent on an outside service in order to boot?  I know that
nameserver queries are quite fast and that the nameserver system in
general is fairly robust (what with secondary servers and stuff).

However, what if our link to the outside world (which is how we access our
domain's authoritative nameserver) goes down for a day or so?  Am I
correct in assuming that our diskless clients won't be able boot?  It
seems that we are putting ourselves at the mercy of a highly critical
point of single failure here, and I'm not sure how to best deal with it,
or even if it's an issue worth worrying about.

If it is worth worrying about, one possible way to approach the problem is
for Sun to rewrite the bootparamd code to provide some additional
protection and redundancy.  In particular, I think it would be good for
Sun to integrate some sort of hierarchical hostname resolution procedure
into the bootparamd and gethostby{name,addr} code.  For example, if the
nameserver times out, then try a YP call if ypbind is running.  Failing
that, the code should look in the local /etc/hosts as a last resort.

(Of course, there may already be some sort of hierarchical procedure set
up.  The SunOS 4.0.3 man page for gethostbyname doesn't mention anything
about this, and we don't have access to Sun source code.)

Comments and perspectives from other sites?

                                Manavendra K. Thakur
				System Manager, High Energy Division
				Harvard-Smithsonian Center for Astrophyics
                                thakur at cfa.harvard.edu
                                thakur%cfa201 at harvard.harvard.edu