Servfail When Resolving certain domains

[England, Robert (Robert)]

I'm trying to figure out why our DNS servers are having intermittent
problems getting to a hand full of domains on a consistent basis. Below is
one of the domain names we continually have issues with. We run a BIND 8.2.4
environment.

We have email being queued because of host name lookup failure.
When we perform a DIG for the MX record against our DNS servers responsible
for external DNS resolution, they come back with the below message.

$ /usr/sbin/dig zaiqtech.com mx

; <<>> DiG 8.3 <<>> zaiqtech.com mx
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; zaiqtech.com, type = MX, class = IN

;; Total query time: 14 msec
;; FROM: rootdns2 to SERVER: default -- 192.19.192.102
;; WHEN: Mon Dec 10 15:06:49 2001
;; MSG SIZE sent: 30 rcvd: 30



We then perform a DIG with the +norec option as noted below, and get the
following. The NS records of the name server for the domain we are looking
up.
Am I correct to say that the NS records that are returned below come from
the .com DNS servers as referrals? Are these the NS records registered with
Network Solutions?


$ /usr/sbin/dig zaiqtech.com mx +norec

; <<>> DiG 8.3 <<>> zaiqtech.com mx +norec
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65486
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; zaiqtech.com, type = MX, class = IN

;; AUTHORITY SECTION:
zaiqtech.com. 21h51m26s IN NS CONNACTIVITY.CONNACTIVITY.com.
zaiqtech.com. 21h51m26s IN NS NS2.CONNACTIVITY.com.

;; ADDITIONAL SECTION:
CONNACTIVITY.CONNACTIVITY.com. 22m28s IN A 206.34.200.2
NS2.CONNACTIVITY.com. 1d4h8m24s IN A 206.34.200.3

;; Total query time: 9 msec
;; FROM: rootdns2 to SERVER: default -- 192.19.192.102
;; WHEN: Mon Dec 10 15:10:46 2001
;; MSG SIZE sent: 30 rcvd: 120



The question I have is when our DNS servers try to find the MX records for
the zaiqtech.com domain name it is unsuccessful. How does that happen?
If the +norec allows DIG to perform a DNS query like our name servers,
doesn't our DNS servers get referred to the name servers listed above?

If I perform a dig against the name servers listed above with the +norec
option I get the following (below). I am able to find the MX records from
the name servers directly.

How come our name servers do not seem to find the answer when they (should
be) quering the name servers of the zaiqtech.com domain listed above? What
am I missing?

Doesn't our name servers follow the referral to the name servers for the
zaiqtech.com domain? If not then what is really happening? If someone can
help me figure this out, it should clear up things up, in my mind.

What I have been doing for now to get around this problem, is setting up
zone forwarding for the domains that continue to give us a problem.
Why does querying our DNS server with zone forwarding configured work and
querying our DNS server without zone forward does not work?

I really need to understand what zone forwarding is doing that a standard
DNS query with out zone forwarding is not doing.


Thanks for the help

-Bob



$ /usr/sbin/dig zaiqtech.com mx +norec @206.34.200.2

; <<>> DiG 8.3 <<>> zaiqtech.com mx +norec @206.34.200.2
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36418
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUERY SECTION:
;; zaiqtech.com, type = MX, class = IN

;; ANSWER SECTION:
zaiqtech.com. 10h40m IN MX 10 mail.zaiqtech.com.
zaiqtech.com. 10h40m IN MX 20 mail2.zaiqtech.com.

;; ADDITIONAL SECTION:
mail.zaiqtech.com. 10h40m IN A 216.141.126.195
mail2.zaiqtech.com. 10h40m IN A 216.141.125.243

;; Total query time: 41 msec
;; FROM: rootdns2 to SERVER: 206.34.200.2
;; WHEN: Mon Dec 10 15:16:48 2001
;; MSG SIZE sent: 30 rcvd: 105

$ /usr/sbin/dig zaiqtech.com mx +norec @206.34.200.3

; <<>> DiG 8.3 <<>> zaiqtech.com mx +norec @206.34.200.3
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38910
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUERY SECTION:
;; zaiqtech.com, type = MX, class = IN

;; ANSWER SECTION:
zaiqtech.com. 10h40m IN MX 10 mail.zaiqtech.com.
zaiqtech.com. 10h40m IN MX 20 mail2.zaiqtech.com.

;; ADDITIONAL SECTION:
mail.zaiqtech.com. 10h40m IN A 216.141.126.195
mail2.zaiqtech.com. 10h40m IN A 216.141.125.243

;; Total query time: 40 msec
;; FROM: rootdns2 to SERVER: 206.34.200.3
;; WHEN: Mon Dec 10 15:17:37 2001
;; MSG SIZE sent: 30 rcvd: 105

[James D Almand (Doug)]

We've experience the same. In most of the cases the domain is
registered m but
register.com or verisgn is holding it up, because the domains in
question have not
paid.

Post by England, Robert (Robert)
I'm trying to figure out why our DNS servers are having intermittent
problems getting to a hand full of domains on a consistent basis. Below is
one of the domain names we continually have issues with. We run a BIND 8.2.4
environment.
We have email being queued because of host name lookup failure.
When we perform a DIG for the MX record against our DNS servers responsible
for external DNS resolution, they come back with the below message.
$ /usr/sbin/dig zaiqtech.com mx
; <<>> DiG 8.3 <<>> zaiqtech.com mx
;; res options: init recurs defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; zaiqtech.com, type = MX, class = IN
;; Total query time: 14 msec
;; FROM: rootdns2 to SERVER: default -- 192.19.192.102
;; WHEN: Mon Dec 10 15:06:49 2001
;; MSG SIZE sent: 30 rcvd: 30
We then perform a DIG with the +norec option as noted below, and get the
following. The NS records of the name server for the domain we are looking
up.
Am I correct to say that the NS records that are returned below come from
the .com DNS servers as referrals? Are these the NS records registered with
Network Solutions?
$ /usr/sbin/dig zaiqtech.com mx +norec
; <<>> DiG 8.3 <<>> zaiqtech.com mx +norec
;; res options: init defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65486
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; zaiqtech.com, type = MX, class = IN
zaiqtech.com. 21h51m26s IN NS CONNACTIVITY.CONNACTIVITY.com.
zaiqtech.com. 21h51m26s IN NS NS2.CONNACTIVITY.com.
CONNACTIVITY.CONNACTIVITY.com. 22m28s IN A 206.34.200.2
NS2.CONNACTIVITY.com. 1d4h8m24s IN A 206.34.200.3
;; Total query time: 9 msec
;; FROM: rootdns2 to SERVER: default -- 192.19.192.102
;; WHEN: Mon Dec 10 15:10:46 2001
;; MSG SIZE sent: 30 rcvd: 120
The question I have is when our DNS servers try to find the MX records for
the zaiqtech.com domain name it is unsuccessful. How does that happen?
If the +norec allows DIG to perform a DNS query like our name servers,
doesn't our DNS servers get referred to the name servers listed above?
If I perform a dig against the name servers listed above with the +norec
option I get the following (below). I am able to find the MX records from
the name servers directly.
How come our name servers do not seem to find the answer when they (should
be) quering the name servers of the zaiqtech.com domain listed above? What
am I missing?
Doesn't our name servers follow the referral to the name servers for the
zaiqtech.com domain? If not then what is really happening? If someone can
help me figure this out, it should clear up things up, in my mind.
What I have been doing for now to get around this problem, is setting up
zone forwarding for the domains that continue to give us a problem.
Why does querying our DNS server with zone forwarding configured work and
querying our DNS server without zone forward does not work?
I really need to understand what zone forwarding is doing that a standard
DNS query with out zone forwarding is not doing.
Thanks for the help
-Bob
; (1 server found)
;; res options: init defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36418
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; zaiqtech.com, type = MX, class = IN
zaiqtech.com. 10h40m IN MX 10 mail.zaiqtech.com.
zaiqtech.com. 10h40m IN MX 20 mail2.zaiqtech.com.
mail.zaiqtech.com. 10h40m IN A 216.141.126.195
mail2.zaiqtech.com. 10h40m IN A 216.141.125.243
;; Total query time: 41 msec
;; FROM: rootdns2 to SERVER: 206.34.200.2
;; WHEN: Mon Dec 10 15:16:48 2001
;; MSG SIZE sent: 30 rcvd: 105
; (1 server found)
;; res options: init defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38910
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; zaiqtech.com, type = MX, class = IN
zaiqtech.com. 10h40m IN MX 10 mail.zaiqtech.com.
zaiqtech.com. 10h40m IN MX 20 mail2.zaiqtech.com.
mail.zaiqtech.com. 10h40m IN A 216.141.126.195
mail2.zaiqtech.com. 10h40m IN A 216.141.125.243
;; Total query time: 40 msec
;; FROM: rootdns2 to SERVER: 206.34.200.3
;; WHEN: Mon Dec 10 15:17:37 2001
;; MSG SIZE sent: 30 rcvd: 105

--
| "Wisdom begins when you discover the difference between
| 'That doesn't make sense' and "I don't understand.' "
| Children of God, by Mary Doria Russell

.__.__ Tech. & Zone Contact (-_-) for domain 'State.Ga.US.' __.__
(_____)------------------------ 'o' --------------------------( ___ )
.| / | James D. Almand (Doug) - (JDA-ARIN) (AJ829-ORG) | \ |
.| / | EMail: ***@state.ga.us | \ |
.| / | or : ***@state.ga.us | \ |
.| / | State of Ga. - GTA/IT Data Networking (unix systems) | \ |
.| / | 330 Capitol Ave. - 1st Bsmt. Office: [phone] | \ |
.|_/_| Atlanta, GA. 30334-9002 |_\_|
(_____)-------------------------------------------------------(_____)

[Jim Reid]

Robert> I'm trying to figure out why our DNS servers are having
Robert> intermittent problems getting to a hand full of domains on
Robert> a consistent basis. Below is one of the domain names we
Robert> continually have issues with. We run a BIND 8.2.4
Robert> environment.

Robert> $ /usr/sbin/dig zaiqtech.com mx

The delegation for zaiqtech.com is messed up. The servers for .com say
it is served by ns2.connactivity.com and connactivity.connactivity.com.
However neither of these servers is authoritative for this zone. Both
of them claim the zone is served by a different set of name servers,
only one of which -- connactivity.connactivity.com -- is listed in the
parent zone. And that server isn't authoritative for it. Complain to
the administrators of both zones. How you do this is left as an
exercise to the reader. :-)

[England, Robert (Robert)]

Isn't there a way around this? If I do a

zone "zaiqtech.com" in {
type forward;
forwarders { 206.34.200.2; 206.34.200.3; };
};

in our named.conf the mail gets sent and everybody is happy. But I don't
want to have to do this for every domain that I find an error for. I have
tried sending the domain admin in the SOA an email, but I don't have the
time to track down every admin to tell them they have DNS issues.

Why does the zone forward work? I saw the NS record issues but I still need
to understand why the zone forward works and not the straight DNS query that
follows the top down approach (db.cache) that for 99% of the domains we
email daily.

-Bob

-----Original Message-----
From: Jim Reid [mailto:***@rfc1035.com]
Sent: Monday, December 10, 2001 4:37 PM
To: England, Robert (Robert)
Cc: 'Bind-Users-Group'
Subject: Re: Servfail When Resolving certain domains

"Robert" == England, Robert (Robert)

<***@northamerica.exchange.agere.com> writes:

Robert> I'm trying to figure out why our DNS servers are having
Robert> intermittent problems getting to a hand full of domains on
Robert> a consistent basis. Below is one of the domain names we
Robert> continually have issues with. We run a BIND 8.2.4
Robert> environment.

Robert> $ /usr/sbin/dig zaiqtech.com mx

The delegation for zaiqtech.com is messed up. The servers for .com say
it is served by ns2.connactivity.com and connactivity.connactivity.com.
However neither of these servers is authoritative for this zone. Both
of them claim the zone is served by a different set of name servers,
only one of which -- connactivity.connactivity.com -- is listed in the
parent zone. And that server isn't authoritative for it. Complain to
the administrators of both zones. How you do this is left as an
exercise to the reader. :-)

[Barry Margolin]

Post by England, Robert (Robert)
I'm trying to figure out why our DNS servers are having intermittent
problems getting to a hand full of domains on a consistent basis. Below is
one of the domain names we continually have issues with. We run a BIND 8.2.4
environment.
We have email being queued because of host name lookup failure.
When we perform a DIG for the MX record against our DNS servers responsible
for external DNS resolution, they come back with the below message.
$ /usr/sbin/dig zaiqtech.com mx
; <<>> DiG 8.3 <<>> zaiqtech.com mx
;; res options: init recurs defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; zaiqtech.com, type = MX, class = IN
;; Total query time: 14 msec
;; FROM: rootdns2 to SERVER: default -- 192.19.192.102
;; WHEN: Mon Dec 10 15:06:49 2001
;; MSG SIZE sent: 30 rcvd: 30
We then perform a DIG with the +norec option as noted below, and get the
following. The NS records of the name server for the domain we are looking
up.
Am I correct to say that the NS records that are returned below come from
the .com DNS servers as referrals? Are these the NS records registered with
Network Solutions?
$ /usr/sbin/dig zaiqtech.com mx +norec
; <<>> DiG 8.3 <<>> zaiqtech.com mx +norec
;; res options: init defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65486
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; zaiqtech.com, type = MX, class = IN
zaiqtech.com. 21h51m26s IN NS CONNACTIVITY.CONNACTIVITY.com.
zaiqtech.com. 21h51m26s IN NS NS2.CONNACTIVITY.com.
CONNACTIVITY.CONNACTIVITY.com. 22m28s IN A 206.34.200.2
NS2.CONNACTIVITY.com. 1d4h8m24s IN A 206.34.200.3
;; Total query time: 9 msec
;; FROM: rootdns2 to SERVER: default -- 192.19.192.102
;; WHEN: Mon Dec 10 15:10:46 2001
;; MSG SIZE sent: 30 rcvd: 120
The question I have is when our DNS servers try to find the MX records for
the zaiqtech.com domain name it is unsuccessful. How does that happen?
If the +norec allows DIG to perform a DNS query like our name servers,
doesn't our DNS servers get referred to the name servers listed above?

You should not use +norec when querying your local caching server. You
should use it when querying the connactivity.com servers, i.e. when you're
trying to simulate what your caching server will do.

When you use +norec with your caching server, you're explicitly telling it
*not* to go to the servers that it's referred to.

Post by England, Robert (Robert)
If I perform a dig against the name servers listed above with the +norec
option I get the following (below). I am able to find the MX records from
the name servers directly.

But notice that they are not authoritative answers, i.e. "aa" doesn't show
up in the "flags:" section of the output. The servers that a domain is
delegated to should always be authoritative.

[England, Robert (Robert)]

Do caching DNS server have to receive a authoritative answer before it will
cache it? Is that why a zone forward works?

-Bob

-----Original Message-----
From: Barry Margolin [mailto:***@genuity.net]
Sent: Monday, December 10, 2001 5:26 PM
To: comp-protocols-dns-***@moderators.isc.org
Subject: Re: Servfail When Resolving certain domains

Post by England, Robert (Robert)
I'm trying to figure out why our DNS servers are having intermittent
problems getting to a hand full of domains on a consistent basis. Below is
one of the domain names we continually have issues with. We run a BIND

8.2.4

Post by England, Robert (Robert)
environment.
We have email being queued because of host name lookup failure.
When we perform a DIG for the MX record against our DNS servers responsible
for external DNS resolution, they come back with the below message.
$ /usr/sbin/dig zaiqtech.com mx
; <<>> DiG 8.3 <<>> zaiqtech.com mx
;; res options: init recurs defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; zaiqtech.com, type = MX, class = IN
;; Total query time: 14 msec
;; FROM: rootdns2 to SERVER: default -- 192.19.192.102
;; WHEN: Mon Dec 10 15:06:49 2001
;; MSG SIZE sent: 30 rcvd: 30
We then perform a DIG with the +norec option as noted below, and get the
following. The NS records of the name server for the domain we are looking
up.
Am I correct to say that the NS records that are returned below come from
the .com DNS servers as referrals? Are these the NS records registered with
Network Solutions?
$ /usr/sbin/dig zaiqtech.com mx +norec
; <<>> DiG 8.3 <<>> zaiqtech.com mx +norec
;; res options: init defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65486
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; zaiqtech.com, type = MX, class = IN
zaiqtech.com. 21h51m26s IN NS CONNACTIVITY.CONNACTIVITY.com.
zaiqtech.com. 21h51m26s IN NS NS2.CONNACTIVITY.com.
CONNACTIVITY.CONNACTIVITY.com. 22m28s IN A 206.34.200.2
NS2.CONNACTIVITY.com. 1d4h8m24s IN A 206.34.200.3
;; Total query time: 9 msec
;; FROM: rootdns2 to SERVER: default -- 192.19.192.102
;; WHEN: Mon Dec 10 15:10:46 2001
;; MSG SIZE sent: 30 rcvd: 120
The question I have is when our DNS servers try to find the MX records for
the zaiqtech.com domain name it is unsuccessful. How does that happen?
If the +norec allows DIG to perform a DNS query like our name servers,
doesn't our DNS servers get referred to the name servers listed above?

You should not use +norec when querying your local caching server. You
should use it when querying the connactivity.com servers, i.e. when you're
trying to simulate what your caching server will do.

When you use +norec with your caching server, you're explicitly telling it
*not* to go to the servers that it's referred to.

Post by England, Robert (Robert)
If I perform a dig against the name servers listed above with the +norec
option I get the following (below). I am able to find the MX records from
the name servers directly.

But notice that they are not authoritative answers, i.e. "aa" doesn't show
up in the "flags:" section of the output. The servers that a domain is
delegated to should always be authoritative.

[Barry Margolin]

Post by England, Robert (Robert)
Isn't there a way around this? If I do a
zone "zaiqtech.com" in {
type forward;
forwarders { 206.34.200.2; 206.34.200.3; };
};
in our named.conf the mail gets sent and everybody is happy. But I don't
want to have to do this for every domain that I find an error for. I have
tried sending the domain admin in the SOA an email, but I don't have the
time to track down every admin to tell them they have DNS issues.
Why does the zone forward work? I saw the NS record issues but I still need
to understand why the zone forward works and not the straight DNS query that
follows the top down approach (db.cache) that for 99% of the domains we
email daily.

Probably because the zone forward prevents your server from trying to query the
servers listed in the NS records:

zaiqtech.com. IN NS riker.zaiqtech.com.
zaiqtech.com. IN NS data.zaiqtech.com.

[Jim Reid]

Robert> Isn't there a way around this?

Yes. Get the people responsible for the broken delegation to fix it.
That's the only sensible solution. The other approach is to ignore the
lame delegation. They'll soon get the message that something is broken
-- and hopefully fix it! -- whenever they find that nobody is sending
them email or visiting their web site. Think of people with broken
name server setups to be a bit like people with substance abuse
problems: they have to recognise they have a problem before they can
begin to fix it.

Robert> If I do a
Robert> zone "zaiqtech.com" in {
Robert> type forward;
Robert> forwarders { 206.34.200.2; 206.34.200.3; };
Robert> };

Robert> in our named.conf the mail gets sent and everybody is
Robert> happy. But I don't want to have to do this for every
Robert> domain that I find an error for.

... Which is precisely why the above kludge is not a sensible
approach. It's not an acceptable long-term solution. This ugly hack
won't even work if zaiqtech.com renumber their name servers because
your name server would then be forwarding queries for this domain to
the old (and presumably) wrong server addresses. [In fact this is one
of the reasons why a "solution" that involves forwarding is in general
a very bad idea IMO.] OTOH, if they fixed the delegation (as they
should have done inthe first place), you wouldn't need to resort to
ad-hoc unscalable kludges.

[England, Robert (Robert)]

I totally agree, but I am still trying to understand why the forwarding
works and the standard config. does not? Trust me I don't want to have to
worry about zone forwarders, and the admin involved. But as a stop gap that
was the only way to get it to work until I fully understand the problem.
Again this is not the only domain I am experiencing problems with. But this
one just so happens to be a visible problem. Some of the others are not as
visible. So understanding why one way work and not the other will help me in
understanding, so that I may send an email off to the admin responsible for
the domains in question.

-Bob

-----Original Message-----
From: Jim Reid [mailto:***@rfc1035.com]
Sent: Monday, December 10, 2001 10:35 PM
To: England, Robert (Robert)
Cc: bind-***@isc.org
Subject: Re: Servfail When Resolving certain domains

"Robert" == England, Robert (Robert)

<***@northamerica.exchange.agere.com> writes:

Robert> Isn't there a way around this?

Yes. Get the people responsible for the broken delegation to fix it.
That's the only sensible solution. The other approach is to ignore the
lame delegation. They'll soon get the message that something is broken
-- and hopefully fix it! -- whenever they find that nobody is sending
them email or visiting their web site. Think of people with broken
name server setups to be a bit like people with substance abuse
problems: they have to recognise they have a problem before they can
begin to fix it.

Robert> If I do a
Robert> zone "zaiqtech.com" in {
Robert> type forward;
Robert> forwarders { 206.34.200.2; 206.34.200.3; };
Robert> };

Robert> in our named.conf the mail gets sent and everybody is
Robert> happy. But I don't want to have to do this for every
Robert> domain that I find an error for.

... Which is precisely why the above kludge is not a sensible
approach. It's not an acceptable long-term solution. This ugly hack
won't even work if zaiqtech.com renumber their name servers because
your name server would then be forwarding queries for this domain to
the old (and presumably) wrong server addresses. [In fact this is one
of the reasons why a "solution" that involves forwarding is in general
a very bad idea IMO.] OTOH, if they fixed the delegation (as they
should have done inthe first place), you wouldn't need to resort to
ad-hoc unscalable kludges.

[Barry Margolin]

Post by England, Robert (Robert)
I totally agree, but I am still trying to understand why the forwarding
works and the standard config. does not?

The standard config doesn't work because your server trusts the NS records,
but they're wrong.

Post by England, Robert (Robert)
Trust me I don't want to have to
worry about zone forwarders, and the admin involved. But as a stop gap that
was the only way to get it to work until I fully understand the problem.

Why do you feel it's your responsibility to make it work? If it were their
mail server that were down, would anyone expect you to arrange a workaround
for that? If they can't get their DNS right, that's their problem. It
would be nice if you forwarded the messages in this thread to them to let
them know they're screwed up, but I don't think you should be expected to
do anything else.

[England, Robert (Robert)]

I have forwarded these messages as well as my findings to a bunch of the
email addresses in the SOA and the WHOIS database, for some of the domains
we are having issues with.

The reason I need to make it work is that we have people in Singapore and
other areas that can send to them with their hotmail account etc. They want
to know why our corporate DNS server can't resolve the domains for email to
send, but hotmail can. I don't have an answer for them.

If I tell our users that DNS is incorrect for the domains they are sending
to, they ask me why hotmail can get mail to them and ours can't. They then
ask why their mail servers can resolve them correctly, but our can not.

That is why if understand why a zone forward work and a standard config.
does not then I can with confidence tell them why there is a problem.

-----Original Message-----
From: Barry Margolin [mailto:***@genuity.net]
Sent: Tuesday, December 11, 2001 11:11 AM
To: comp-protocols-dns-***@moderators.isc.org
Subject: Re: Servfail When Resolving certain domains

Post by England, Robert (Robert)
I totally agree, but I am still trying to understand why the forwarding
works and the standard config. does not?

The standard config doesn't work because your server trusts the NS records,
but they're wrong.

Post by England, Robert (Robert)
Trust me I don't want to have to
worry about zone forwarders, and the admin involved. But as a stop gap that
was the only way to get it to work until I fully understand the problem.

Why do you feel it's your responsibility to make it work? If it were their
mail server that were down, would anyone expect you to arrange a workaround
for that? If they can't get their DNS right, that's their problem. It
would be nice if you forwarded the messages in this thread to them to let
them know they're screwed up, but I don't think you should be expected to
do anything else.

[Barry Margolin]

Post by England, Robert (Robert)
If I tell our users that DNS is incorrect for the domains they are sending
to, they ask me why hotmail can get mail to them and ours can't. They then
ask why their mail servers can resolve them correctly, but our can not.

The answer is that these kinds of problems result in transient errors.
Sometimes you can resolve the names, other times you can't. It may also be
dependent on the version of nameserver you're running -- different
nameservers behave differently when running into these types of problems
(since Hotmail is a Microsoft service, maybe they're using Microsoft DNS
server rather than BIND, but I shudder when I contemplate such a
configuration).

[M***@isc.org]

Post by England, Robert (Robert)
That is why if understand why a zone forward work and a standard config.
does not then I can with confidence tell them why there is a problem.

Because the standard config is expecting to be talking to servers
that are authoritative. When you are using a forward zone the
server is *not* expecting to be talking to a authoritative server
but rather a caching server and caching servers don't set 'aa'
whereas authoritative servers do. The servers in question are
not setting 'aa' in the answers (indicating that they detected
a error on load) and named is rejecting their answers as bad.

Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone] INTERNET: ***@isc.org

[England, Robert (Robert)]

Post by England, Robert (Robert)
-----Original Message-----
Sent: Tuesday, December 11, 2001 1:49 PM
To: England, Robert (Robert)
Subject: Re: Servfail When Resolving certain domains

Post by England, Robert (Robert)
That is why if understand why a zone forward work and a standard config.
does not then I can with confidence tell them why there is a problem.

Because the standard config is expecting to be talking to servers
that are authoritative.

If it does not will it just return a SERFAIL message?

Post by England, Robert (Robert)
When you are using a forward zone the
server is *not* expecting to be talking to a authoritative server
but rather a caching server and caching servers don't set 'aa'
whereas authoritative servers do.

This does seem to be the case, but I was not sure that the name server HAD
to receive an authoritative answer all the time, in order to be able to
resolve a name. I see non authoritative answers allot, are you telling me
that there are that many DNS server out there not configured correctly?

Post by England, Robert (Robert)
The servers in question are
not setting 'aa' in the answers (indicating that they detected
a error on load) and named is rejecting their answers as bad.

Is their a way for the name server to accept a non authoritative answer with
a standard configuration that uses the db.cache file?

Post by England, Robert (Robert)
Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia

Thanks for the help!!
-Bob

[M***@isc.org]

Post by England, Robert (Robert)

Post by M***@isc.org

Post by England, Robert (Robert)
That is why if understand why a zone forward work and a standard config.
does not then I can with confidence tell them why there is a problem.

Because the standard config is expecting to be talking to servers
that are authoritative.

If it does not will it just return a SERFAIL message?

If *all* the servers for the zone are broken.

Post by England, Robert (Robert)

Post by M***@isc.org
When you are using a forward zone the
server is *not* expecting to be talking to a authoritative server
but rather a caching server and caching servers don't set 'aa'
whereas authoritative servers do.

This does seem to be the case, but I was not sure that the name server HAD
to receive an authoritative answer all the time, in order to be able to
resolve a name. I see non authoritative answers allot, are you telling me
that there are that many DNS server out there not configured correctly?

Yes. People don't look at the logs or ignore the error messages.
Answers from a cache don't have 'aa' set. Answers from a
authoritative server should have 'aa' set. The lack of 'aa'
means that a error was detected when the zone was loaded.
As a client we only know that there was a error and as such
the answers we are getting back from this server may be incomplete
therefore we should not accept them.

Post by England, Robert (Robert)

Post by M***@isc.org
The servers in question are
not setting 'aa' in the answers (indicating that they detected
a error on load) and named is rejecting their answers as bad.

Is their a way for the name server to accept a non authoritative answer with
a standard configuration that uses the db.cache file?

No. Why would you accept known *bad* answers.

Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone] INTERNET: ***@isc.org