Subject: Strange behavior from resolvers?

From: Mats Dufberg <[email-masked]>
Date: Tue, 3 Apr 2001 16:24:31 +0200 (CEST)

There is a zone, obol-net.net, that causes me some troubble. It is
delegated with the following information:

obol-net.net.      NS      ns1.obol-net.net.
obol-net.net.      NS      ns2.obol-net.net.
ns1.obol-net.net.  A       195.163.92.125
ns2.obol-net.net.  A       195.163.92.123

In the zone we have, among other data,

ns1.obol-net.net.  A       195.163.92.125
ns2.obol-net.net.  A       195.163.92.123

but there is no MX in the same nodes (ns1.obol-net.net, ns2.obol-net.net).
If I recursively through a resolver (bind 8.2.2, 8.2.3. or 9.1.0)  send
the request

ns1.obol-net.net. MX ?

the response is SERVFAIL. When I direct the request directly to the
servers I see no problem with the response.

Can anyone see what is wrong?

Mats

-----------------------------------------------------------------
Mats Dufberg                                     +46-8-545 857 06
[email-masked]                           fax: +46-8-545 857 29

---

From: Alex Kamantauskas <[email-masked]>
Date: Tue, 3 Apr 2001 10:49:00 -0400 (EDT)

> servers I see no problem with the response.

 I'm not sure I understand here.  Do you meant that if you send an MX
 query directly to ns1.obol-net.net for ns1.obol-net.net you are receiving
 a answer?  (Using "dig @ns1.obol-net.net ns1.obol-net.net mx")

-- 
/ak

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 3 Apr 2001 17:05:56 +0200 (CEST)

>  a answer?  (Using "dig @ns1.obol-net.net ns1.obol-net.net mx")

Yes, compare

dig @ns1.obol-net.net ns1.obol-net.net mx

with

dig ns1.obol-net.net mx

Mats

---

From: Kandra Nygårds <[email-masked]>
Date: Tue, 3 Apr 2001 17:27:09 +0200

Asking my own (local) nameserver at home, I get the following in /var/log/messages

Apr  3 17:28:46 devnull named[1075]: ns_resp: query(ns1.obol-net.net) All possible A RR's lame

Might have something to do with it? =)

But yes, I know. This confused the heck out of me for quite a while too.

-Kandra

----- Original Message ----- 
From: "Mats Dufberg" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 03, 2001 16:24
Subject: Strange behavior from resolvers?

ns1.obol-net.net. MX ?

Mats

---

From: Alex Kamantauskas <[email-masked]>
Date: Tue, 3 Apr 2001 11:45:09 -0400 (EDT)

On Tue, 3 Apr 2001, Matt Crawford wrote:

> I have a guess, but I haven't tested it yet.  Something between the
> internet and those two servers ns1/2.obol-net.net is refusing packets
> with UDP source port 53.

 If that were the case, than all queries would fail, but an SOA query
 still works:

  root/ns1:/ # dig obol-net.net soa
  ;; ANSWER SECTION:
  obol-net.net.           1D IN SOA       ns1.obol-net.net.

 My initial thought had to do with resolvers answering with the best
 answer they know.  ns1.obol-net.net doesn't have any info about an mx
 record for ns1.obol-net.net, so it replies back with the best answer it
 knows, which is no answer but provides the authoritative NS records for
 'obol-net.net'.  A standard resolver has no prior knowledge of
 'obol-net.net', so it just returns a SERVFAIL.

 However, looking back on that, I seem to think there is a hole in that
 logic.

-- 
/ak

---

From: Peter Koch <[email-masked]>
Date: Tue, 03 Apr 2001 18:11:39 +0200

> dig @ns1.obol-net.net ns1.obol-net.net mx

The NOERROR NODATA response from ns1.obol-net.net is accompanied by two NS RRs
in the authority section. From a rough scan of the debug output I think that
at least my nameserver/resolver running BIND 8.2.3 feels sent into an endless
loop by these references and thus generates the "SERVFAIL". Maybe it is more
appropriate to discuss this on a BIND related list.

There's no magic here with port 53 sourced queries.

-Peter

---

From: Alex Kamantauskas <[email-masked]>
Date: Tue, 3 Apr 2001 12:10:31 -0400 (EDT)

> No, no.  *source* address.  Of packets coming from the *outside*.
> It would be a goofy thing to do, but it fits the observations.
>

 Source packets generally wouldn't be coming from port 53, iirc.  The
 destination would be port 53, but the source would be a higher
 unpriveleged port.

-- 
/ak

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 3 Apr 2001 19:41:52 +0200 (CEST)

> appropriate to discuss this on a BIND related list.

The ns1.obol-net.net is certainly not running bind, so the question
remains which nameserver is doing wrong. As far as I can see, bind would
return SOA in auhority section for an equevalent request.

; <<>> DiG 2.2 <<>> @dns.nic-se.se dns.nic-se.se mx
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0
;; QUESTIONS:
;;      dns.nic-se.se, type = MX, class = IN

;; AUTHORITY RECORDS:
nic-se.se.      3600    SOA     dns.nic-se.se. host\.master.nic-se.se. (

; <<>> DiG 2.2 <<>> @ns1.obol-net.net ns1.obol-net.net mx
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 2, Addit: 2
;; QUESTIONS:
;;      ns1.obol-net.net, type = MX, class = IN

;; AUTHORITY RECORDS:
obol-net.net.   86400   NS      ns2.obol-net.net.
obol-net.net.   86400   NS      ns1.obol-net.net.

Mats

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 03 Apr 2001 11:30:40 -0700

> remains which nameserver is doing wrong. As far as I can see, bind
> would return SOA in auhority section for an equevalent request.

This is a malformed NODATA response, and is being treated as a referral.

RFC 2308, 2.2 - No Data

  NODATA is indicated by an answer with the RCODE set to NOERROR and no
  relevant answers in the answer section.  The authority section will
  contain an SOA record, or there will be no NS records there.

You are returning NS RRs in the auth section. BIND sees this response
format as a referral and tries to query the listed servers. When all of
the servers respond with "referrals" then they are treated as lame and
BIND returns SERVFAIL.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Sematimba Noah K <[email-masked]>
Date: Tue, 03 Apr 2001 21:35:52 +0300 (EAT)

>  destination would be port 53, but the source would be a higher

many admins out there have query-source port 53 in their configs. It is usually 
a result of firewall configurations that block high ports and the like.

 Noah

---

From: "David St. Germain" <[email-masked]>
Date: Tue, 3 Apr 2001 14:27:11 -0400

Might the answer be as simple as the server is running SMTP?

Dave.

---

From: Alex Kamantauskas <[email-masked]>
Date: Tue, 3 Apr 2001 14:50:24 -0400 (EDT)

> many admins out there have query-source port 53 in their configs. It is
> usually a result of firewall configurations that block high ports and the
> like.
>

 Aah.  I actually knew that.  I need more Diet Coke

-- 
/ak

---

From: <[email-masked]>
Date: Tue, 3 Apr 2001 11:47:59 -0700 (PDT)

> return SOA in auhority section for an equevalent request.

I believe the DNS server they are running is Novell's DNS server.  I know
that their web server is running "NetWare-Enterprise-Web-Server/5.1".

The code the remote nameserver seems to be running seems to be based
somewhat on BIND, though.  It handles the unusual case of asking a
question with a QDCOUNT of two the same way BIND does (giving a "Format
error" instead of what I conider the correct "Not implemented" )  For
whatever reason, however, it handles queries to non-existant domains
incorrectly.

BIND (and DJBDNS) handle queries to completely non-existant domains
(NXDOMAINs) thusly:

* They return a RCODE of three (RFC1035 calls this "Name error", RFC1034
  calls this a "NXDOMAIN"), as described in RFC1035 section 4.1.1.

* No records are in the answer section

* They return, in the "Authority" section of the reply (the section where
  name server records are usually placed), the SOA for the domain in
  question.  Note that RFC1034 section 4.3.4 explcitly asks for this
  info to be placed in the "Additional" section.  However, since
  Bind placed this info in the "Authority" section, the de facto standard
  differs from the RFC.

* No other records are in the authority section.

* No records are in the additional section.

BIND and DJBDNS handle domains that exist, but not for the record type
requested by the client (resolver) thusly:

* They return a RCODE of 0.

* In all other aspects, the reply is the same as for a NXDOMAIN reply
  above.

My DNS server, MaraDNS, currently handles NXDOMAINS as BIND and DJBDNS do,
with the exception that she gives a RCODE of 0 in both cases.

The presumably Novell name server, however, handles completely nonexistant
domains thusly:

* It returns a RCODE of 3, "Name error".  However, there is no data after
  the header: No answer records, no authority records, and no additional
  records.

This DNS server handles the case of the domain existing, but not for the
type of record the client asks for, thusly:

* It returns a RCODE of 0

* It then returns nothing in the answer section, NS records in the
  authority section, and the IPs for the NS records in the additional
  section.

As Eric has just pointed out (as I was writing this), this tells BIND (and
DJBDNS) "I do not have this answer, but the answer can be found at my
nameserver".

- Sam

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 03 Apr 2001 11:54:17 -0700

Sorry, responded to the wrong message before.

> servers I see no problem with the response.

The stub resolver is just displaying the answer that it gets back from
whatever server it queried.

When the resolver queries a BIND (8.1->?) server, it displays the answer
that BIND returns. BIND sees this particular response as a malformed
NODATA response, which it treats as a referral. When the referrals fail
the proper response is to return SERVFAIL, since none of the auth servers
were able to answer the query.

RFC 2308, 2.2 - No Data

Your auth servers are returning NS RRs in the auth section. BIND sees this
response format as a referral and tries to query the listed servers. 

When your resolver queries the original auth servers, they are just
returning NODATA/NOERROR, but the resover doesn't have the smarts from
RFC-2308 to parse the response and restart the query (iteratively). It's
just a dumb stub so it just prints the answer it got.

You will have to fix your auth servers so that they return properly
formatted NODATA response if you want them to interoperate with
2308-compliant DNS servers in the query path.

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 3 Apr 2001 21:07:58 +0200 (CEST)

> that their web server is running "NetWare-Enterprise-Web-Server/5.1".

Yes, we have been informed that the the servers, ns{1,2}.obol-net.net are
running Novell 5.0 and 5.1, respectively (or the other way around).

> DJBDNS) "I do not have this answer, but the answer can be found at my

I tested a server which I think is an NT (non-bind) server, which permits
recursion. It accepts the respons from the Novell server without SERVFAIL:

; <<>> DiG 2.2 <<>> @ns1.ballou.se ns1.obol-net.net mx
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa ra; Ques: 1, Ans: 0, Auth: 2, Addit: 2
;; QUESTIONS:
;;      ns1.obol-net.net, type = MX, class = IN

;; AUTHORITY RECORDS:

Mats

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 3 Apr 2001 21:13:58 +0200 (CEST)

> 2308-compliant DNS servers in the query path.

Well, they are not ours. :-) On the contrary, they are annoying to my
script for verifying delagations. They cause the script to report the
delegation to be totally broken even though it probably works...

Mats

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 03 Apr 2001 12:47:32 -0700

> > As Eric has just pointed out (as I was writing this), this tells
> > BIND (and DJBDNS) "I do not have this answer, but the answer can
> > be found at my nameserver".
> 
> I tested a server which I think is an NT (non-bind) server, which
> permits recursion. It accepts the respons from the Novell server
> without SERVFAIL:

Yeah I have an NT4 server here and it passed my tests as well. It doesn't
cache the data either, which would also seem to be a valid position in
this scenario. *BUT* it doesn't treat the answer like a referral (it
doesn't query the other server), and that's the wrong behavior. My guess
(without having the code, and turning up no hits on "2308" in MS KB) would
be that NT4's DNS server doesn't know about 2308 NODATA and that it's just
returning the referral for the stub to deal with.

Win2k's DNS server returns NO ERROR -- and even caches it -- after it asks
both auth servers. It appears to understand 2308 but just hands off the
referral data rather than falling into SERVFAIL.

NetWare 5.1 DNS server returns SERVFAIL after trying both auth servers. It
doesn't cache the data. This is all expected since NW5 DNS server is based
on BIND 8.

There may be an argument to be made that BIND shouldn't fall into SERVFAIL
if it gets into referral mode through authoritative NO ERROR responses.
Perhaps it should return the referral to the client for additional
processing or local failure (depending on the client's resolver). I will
leave that to the BIND people.

---

From: [email-masked]
Date: Wed, 04 Apr 2001 10:15:41 +1000

RFC 2308 enumerates the negative response types.  It did not
	invent new ones (AA=0 aside).  They all existed in RFC 103[45]
	as did referral.  RFC 2308 just pointed out easy mistakes to
	make.

	If a nameserver does not understand these response enumerated
	in RFC 2308 it is not RFC 103[45] compliant.  If a nameserver
	generates the wrong response, as in this case when it generated
	a referral rather than one of the possible NODATA responses,
	it is not RFC 103[45] compliant.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 03 Apr 2001 11:02:28 -0500

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 03 Apr 2001 10:22:41 -0500

---

From: Lars-Johan Liman <[email-masked]>
Date: Wed, 04 Apr 2001 14:00:02 +0200

Yow!

Even though this _is_ an interesting case, it is just that - a
case. This list is primarily for discussions of principles.

Please take the discussion to [email-masked] or similar.

				Cheers,
				  /Liman
				  Chair and list admin.

---

From: Sam Trenholme <[email-masked]>
Date: Wed, 4 Apr 2001 11:14:49 -0700 (PDT)

> This list is primarily for discussions of principles.

What is the appropriate mailing list to discuss unusual behavior of
various DNS servers "in the wild"?  As someone who is implementing a DNS
server, knowledge of the kinds of buggy and non-complient behavior some
DNS servers have is of great interest to me, so my code can have
workarounds for the DNS servers in question.

- Sam