SERVFAIL errors with omniairintl.com

[Jim Reid]

>>>>> "Jim" == Jim Warren <jim at coam.net> writes:

    Jim> yes, i noticed that it seems to return good information with
    Jim> the dig...any argument, but if you use the "a" or"mx" or
    Jim> "hinfo" it still fails, and nslookup fails, and then the root
    Jim> of the problem, sendmail fails with a "transient parse error
    Jim> -- nameserver timeout" ....which is the real reason i've got
    Jim> a problem.. we cant send mail to them....

Indeed. As you say, lookups for MX or A records for omniairintl.com on
your servers fail with SERVFAIL. However my name server looks up these
records OK and the servers for omniairintl.com seem to be OK too. This
would tend to suggest there's something wrong with your name servers
or the local configuration.

    Jim> actually dig with any reports the ns records only....
    Jim> and with "soa", i get the servfail,

A successful lookup of the NS records is to be expected. The NS
records will come from a query to one of the .com servers. However
when you ask for some other record type in the omniairintl.com zone,
the query ends up at one of the omniairintl.com name servers. This is
where the SERVFAIL comes in somehow. It doesn't appear to be the
omniairintl.com servers. They answer my queries OK: either when I get
my name server to lookup that zone or if I query their servers
directly with dig.

Could it be possible that the omniairintl.com servers think that your
servers are supposed to be authoritative for this zone? Maybe it used
to be hosted on your name servers? What if you turned up the debugging
on your server and traced the queries to/from their servers? What's in
your name server's cache for omniairintl.com? Are there any other
error reports in your name server logs or OS, especially about failed
memory allocation or lack of network buffers? Do your name servers
have some form of (zone-specific?) query forwarding enabled?

If the undelivered mail is causing a problem, set up a caching-only
name server (no forwarding!!!) on another box. Check that it answers
OK for omniairintl.com. And if so, get the mail system to use that
server for resolving. This will get the mail flowing again. However
it's just a workaround to buy you some time to get to the source of
the problem.

    Jim> but ns.utah.edu gets the
    Jim> root-servers returned...the root servers shouldnt come back
    Jim> as soa, should they?

I don't understand what you said. What query did you send to
ns.utah.edu and what reply did it give? Please show exactly what you
typed and what dig printed. If ns.utah.edu returned a referral to the
root servers when it was asked to lookup omniairintl.com, that's a bit
of a mystery. That server answers quite happily ANY, A, MX, etc
queries for omniairintl.com. I just tried it.

Queries to Internet root servers return referrals to top-level domain
servers. Root servers don't handle recursive queries. When they get a
request for a non-existent name, they return a reply code of NXDOMAIN,
an empty Answer Section and the root zone's SOA record in the
Authority Section of a reply. This is how things are meant to be.