[Top] [All Lists]

Re: BCP for handling DNS SERVFAIL results

2005-11-26 21:25:55


I got the hotfix from Microsoft (a per request item, not part of the service
packs), apply it and the SERVFAIL issue is now resolved. :-)

I think what this all says that many of the legacy servers, including NT,
Windows 2000, and BIND had SERVFAIL related issues, and the idea or (bad)
consideration to view SERVFAIL as a NXDOMAIN in order to fallback to the A
record reflected the fact that this issue did exist in the past for many of
the DNS servers.

I don't agree with this SMTP outgoing DNS logic consideration, but I can
certainly see why it was discussed in some of the net research I did on the

Thanks for your comments.

Hector Santos, Santronics Software, Inc.

----- Original Message -----
From: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
To: <ned+ietf-smtp(_at_)mrochek(_dot_)com>
Cc: "IETF-SMTP" <ietf-smtp(_at_)imc(_dot_)org>
Sent: Saturday, November 26, 2005 3:08 AM
Subject: Re: BCP for handling DNS SERVFAIL results

Well Ned! I did some detailed searching, and found this for Windows NT 4.0
and 2000 DNS.EXE server.;en-us;295933

Here its description (For Windows):


The resolution of e-mail names and other names may not work if a Windows
2000-based or Windows NT 4.0-based Domain Name System (DNS) server
a non-authoritative response from a root hint or forwarder. The Windows
2000-based or Windows NT 4.0-based DNS server sends a "Server Failure"
message to the client when it receives a Start of Authority (SOA) record
from a non-authoritative resource.

Some non-Microsoft DNS servers (for example, some BIND versions) cache
authoritative responses, which Windows 2000-based and Windows NT 4.0-based
DNS servers consider to be referrals. When a Windows 2000-based or Windows
NT 4.0-based DNS server receives such a response, the response is ignored
and a "Server Failure" message is sent to the client instead of the SOA

I am trying to get this update now which I thought SP6 already covered
Apparently not.  Hopefully, this will clear the server issue.

BTW, I found SERVFAIL related issues too with BIND too.

I downloaded the BIND source to learn about DNS server logic.

Hector Santos, Santronics Software, Inc.

----- Original Message -----
From: <ned+ietf-smtp(_at_)mrochek(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: <ned+ietf-smtp(_at_)mrochek(_dot_)com>; "IETF-SMTP" 
Sent: Friday, November 25, 2005 11:39 PM
Subject: Re: BCP for handling DNS SERVFAIL results

Thanks Ned. Excellent info and insight.

I do have a few follow-up questions related this:

2) Use Multiple DNS server.

   An IBM solution was to suggest to make sure you have
   additional DNS servers to query.

Well, sure. Having at least one secondary DNS server is pretty much
and they need to be geographically separate. I note in passing that has two servers and they appear to be on separate
networks. [] [TTL=86400] [] [TTL=86400]

One of the confusing issues about this, and no doubt probably a
misunderstanding on my part, is related to having multiple DNS servers
Primary DNS recursion lookups.

First a disclaimer: DNS operations are not exactly my primary area of
either. Hopefully what I say here will be correct and if it isn't
someone else will chime in and correct me.

With that said...

Be very careful here with your terminology. In the DNS world a "primary"
is one that provides authoritative information for one or more domains.
"secondary" is a slave that periodically transfers information from the
primary and makes it available for queries.

The servers for a given domain are specified by NS records in the
domain. So the way this works is that a resolver starts at the top of
and walks down using NS records at each level to find the servers below.
there are multiple NS records I believe the approach is to pick one  at
and if that doesn't work try another. This may also depend on the

Caching of course eliminates the need for many of these queries and
load at the upper levels manageable. There's also a bunch of tricky
at the very top to make things sufficiently performant while allowing
providers - I know very little about all this magic.

How do I best ask this because again, I am not a DNS admin or a server

Well, I guess I qualify as an admin since I handle a bunch of primary
secondary domains. But again, I'm no expert.

I guess the question is, can the same results be expected with:

  1) A server with multiple uplinks, versus

I'm afraid this exceeds my level of expertise. I use bind but I don't
multihomed environment so I don't know how it or any other server
implementation handles being multihomed.

  2) Multiple Server list

Applications typically don't have a full resolver built in that's
walking the DNS tree. Rather, they have a so-called "stub" resolver that
given a list of full resolvers to send queries to. The stub resolver
builds a
query and sends it to one of the resolvers, gets back a result and

I guess your statement above about having geographically separate
makes all this work better to increase the odds of getting result.

Right. Of course geographic separation doesn't matter when the problem
a server is down, but it can save you when a link is down.

But it was my impression that when you query a primary server, if the
is not available in the zone and not currently cached, that the server
query its uplinks. No?

Your terminology is confusing here. I think by "primary server" you mean
resolver" and by "uplink" you mean "servers for uplevel domains". If so,
yes, this is more or less how it works, but it works its way down from
lowest uplevel entry that the resolver has cached.

You see, for my company SMTP server, I have: is where I have my primary DNS

OK, but that has nothing to do with whether or not you're using that
machine as
your full resolver. For example, the primary server for is, but DNS queries on that machine are actually
to a
completely different system for resolution. I believe it's considered
practice not to have your DNS primaries or secondaries performing
resolution services.

and I have as forwarders the UUNET servers:

I had the impression this provided the uplink queries when the primary
not have the information.

Maybe. It would depend on how you have things configured. Forwarders are
basiclaly used to offload DNS processing from one machine to another.

I just happen to see this SERVFAIL fail when I was testing this
customer's MX record against via Window's

I was assisting him remotely from home and didn't see this SERVFAIL
the server:

   NSLOOKUP -query=mx -debug
   NSLOOKUP -query=mx -debug

First one returns SERVFAIL, second one NOERROR.

You might consider clearing the cache on your home server and see if

I was able to send him a test message because the SMTP server was
able to get to the second unnet server, and thus fallback to a
successful A
record result.

But the situation got me wondering what was wrong or different between
two, and also what if I or other customers didn't have a second DNS
setup for SMTP, if its something to worry about.

4) Ignore SERVFAIL?

Some just said that the SMTP client should be looking at SERVFAIL

Bad idea IMO. Configuration glitches happen, and when they do you
don't want to bounce mail to the domain unnecessarily. Most of the
time these problems get fixed and the mail goes on through with
only a small delay.

I agree.  I was wondering, and now realize that its probably wrong to
the gun with this, if it would make sense to do a A record lookup for

I've actually seen cases where MX record queries got a SERVFAIL but an A
query got a successful result. (I've always believed this is due to the
being down or misconfigured and having one record type cached but not
other, but I've never been able to track down the specific cause.) This
gets very complex because DNS servers do tricky stuff like piggyback A
information on MX queries, making problems hard to isolate.

But this doesn't mean that you should do this: Nothing prevents someone
having an MX for pointing to a completely separate while having a SMTP server running on
silently eats everything sent to it. And yes, such a setup would be
dangerous, but people do stupid and dangerous things all the time.