Thanks very much for your reply.

> For NS records, "dnswalk" compares the RDATA of the record with the
> results of a gethostbyname() on the same name, and assumes that if the
> two are different, that the NS record is pointed at an alias (which is
> illegal).
> However, gethostbyname() can return a different name if another source
> of naming information has precedence over DNS, e.g. one has "hosts:
> files dns" in /etc/nsswitch.conf on Solaris, and that other source of
> naming information has a different form of the same name, e.g. the short
> form.

My nsswitch.conf has that very line in it.

> I think that's what's happening to you. gethostbyname() is finding the
> name "mail" in (probably) /etc/hosts, and since it doesn't match the
> FQDN "", it assumes your NS is pointed at an alias.

Again, I think you hit the nail on the head. I do have that server's
short name in my /etc/hosts file.

> I consider this a bug in dnswalk. The same faulty logic also appears in
> the MX-record check. At the very least, it should check the "aliases"
> variable which is returned by gethostbyname() to see if the name
> resolved via and alias or not.

OK, that's very useful to know. When I saw the word "BAD" in the dnswalk
results, I assumed I had a more basic error, but I couldn't work out what.

> Does this crude logic make the utility "unreliable"? Can't really say,
> since I haven't played around with it enough to see if there are other
> bugs. It drew my attention to some "problem spots" in the one zone I ran
> it on, so I'd say it still, despite its imperfections, has some value...

I'm sure with a more complicated zone file, it could prove its worth.
It's useful to know under what conditions it might be throwing red herrings.

Thanks very much for your help. Much appreciated.

Ian Masters