Subject: Is this correct behavior?

From: Kare Presttun <[email-masked]>
Date: Tue, 26 Nov 2002 16:27:28 +0100

Dear list readers!

I decided to dig into a mail bouncing problem and found
some behavior of two of the .no ccTLD servers that made
me wonder what is correct. Otlined below:

 From time to time I get a notice that a mail to me has bounced with
a notice saying:
 > -----Opprinnelig melding-----
 > Fra: [email-masked]
[mailto:[email-masked]]
 > Sendt: 21. november 2002 00:26
 > Til: < address deleted by me>
 > Emne: Undeliverable Mail
 >
 > Unknown host: [email-masked]
 >

Or like this one from Securityfocus:

<[email-masked]>: Name service error for mail.securityfocus.com:
Host not    found, try again

\--45AD4A3131.1036699892/outgoing.securityfocus.com

So I decided to dig into it. Using the Squish service at:
http://www.squish.net/dnscheck/ I get error messages on
two of the .no nameservers (Outsourced to UltraDNS
who bought the customers from Nominum) namely
not.norid.no and njet.norid.no. Asking one of the gtld
servers for my domain I get:

; <<>> DiG 9.2.1 <<>> @i.gtld-SERVERS.NET presttun.org mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

;; QUESTION SECTION:
;presttun.org.                  IN      MX

;; AUTHORITY SECTION:
presttun.org.           172800  IN      NS      NS2.NEXTRA.NO.
presttun.org.           172800  IN      NS      SID.NIMROD.NO.
presttun.org.           172800  IN      NS      THREE.PSEUDOSPACE.COM.

;; ADDITIONAL SECTION:
THREE.PSEUDOSPACE.COM.  172800  IN      A       209.51.13.174

;; Query time: 406 msec
;; SERVER: 192.43.172.30#53(i.gtld-SERVERS.NET)
;; WHEN: Mon Nov 25 12:31:11 2002
;; MSG SIZE  rcvd: 133

So far everything looks fine. So asking one of the .no
servers to resolve the .no DNS servers for me I get:

; <<>> DiG 9.2.1 <<>> @nac.no sid.nimrod.no
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;sid.nimrod.no.                 IN      A

;; AUTHORITY SECTION:
nimrod.no.              86400   IN      NS      nn.uninett.no.
nimrod.no.              86400   IN      NS      sid.nimrod.no.
nimrod.no.              86400   IN      NS      desoto.nimrod.no.

;; ADDITIONAL SECTION:
nn.uninett.no.          3600    IN      A       158.38.0.181
sid.nimrod.no.          75029   IN      A       195.139.160.2
desoto.nimrod.no.       75029   IN      A       195.139.160.6

;; Query time: 515 msec
;; SERVER: 129.240.2.40#53(nac.no)
;; WHEN: Mon Nov 25 12:39:32 2002
;; MSG SIZE  rcvd: 139

Once again it looks fine. Asking the same question to ether not or
njet.norid.no I get:

; <<>> DiG 9.2.1 <<>> @njet.norid.no sid.nimrod.no
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;sid.nimrod.no.                 IN      A

;; ANSWER SECTION:
sid.nimrod.no.          86400   IN      A       195.139.160.2

;; AUTHORITY SECTION:
nimrod.no.              86400   IN      NS      sid.nimrod.no.
nimrod.no.              86400   IN      NS      nn.uninett.no.
nimrod.no.              86400   IN      NS      desoto.nimrod.no.

;; ADDITIONAL SECTION:
nn.uninett.no.          86400   IN      A       158.38.0.181
desoto.nimrod.no.       86400   IN      A       195.139.160.6

;; Query time: 390 msec
;; SERVER: 198.133.199.105#53(njet.norid.no)
;; WHEN: Mon Nov 25 12:46:18 2002
;; MSG SIZE  rcvd: 139

Where the the server I'm asking for is in the answer section
(without being AA) but not in the additional section.

Reading 1034, end of 4.2.1: "To fix this problem, a zone contains
"glue" RRs which are not part of the authoritative data, and are
address RRs for the servers. These RRs are only necessary if the
name server's name is "below" the cut, and are only used as part
of a referral response.". It seems to be correct but it also seems
to be the reason for dropped mail.

So is this correct behavior? Thanks in advance.

Med vennlig hilsen | Best regards,
Kåre Presttun
Tel.: +47 4100 4908
mailto:[email-masked]
http://www.presttun.org/kare/ 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 26 Nov 2002 17:17:19 -0500

> So is this correct behavior? Thanks in advance.

Yes, this is correct behavior. RFC 2181 Section 5.5 requires that RRsets
not be repeated in a response.

This "squish" tool seems to be rather misguided. It seems to assume that
referrals will *always* contain *all* glue records in the Additional
Section, but this is not guaranteed. Note that the RFC verbiage you quoted
says that glue is "necessary when the name server's name is 'below' the
cut"; since "sid.nimrod.no" is not below the "presttun.org" zone cut,
there is no requirement for glue to be provided. To simplify matters, each
gTLD nameserver tends to have glue for all the gTLD domains, which
explains why "THREE.PSEUDOSPACE.COM" glue is available on a .org
nameserver; however, the same simplification doesn't hold true for
ccTLD glue -- ns2.nextra.no and sid.nimrod.no -- and that's why no glue is
provided for those names and they need to be looked up separately.

It's possible that the mail originators in this case are running BIND 4,
BIND 8 or some other DNS package which lacks "query restart", and
therefore may fail to perform all of these extra lookups automatically.
This would cause the query to fail initially, and if the client resolver
reached its retry threshold, to fail fatally.

- Kevin

---

From: Kare Presttun <[email-masked]>
Date: Wed, 27 Nov 2002 00:55:05 +0100

Thanks Kevin!

 >not be repeated in a response.

So this is what not.norid.no and njet.norid.no follows, but not
the rest of the .no ccTLD servers as we could see from the nac.no
responce (the others all the glue as well).
 >referrals will *always* contain *all* glue records in the Additional

That was my suspicion. The response from Squish is actually:
"198.133.199.105 (NJET.NORID.NO) with failed to resolve SID.NIMROD.NO
  due to 198.133.199.105 - no answers". Well the answer was there but
without the aa bit.

 >there is no requirement for glue to be provided. To simplify matters, each

That is why I said that it looked correct.

 >provided for those names and they need to be looked up separately.

If you look up a zone like nextra.no or nimrod.no there is no problem,
you get the answer with all (.no) glue. It is only when I look up the
nameservers directly because I got them refered from .org (or
somewhere not .no) the problem arrises. Since these servers are registered
for .no domains all the .no servers know them. While nac.no did not
provide answer, only glue, not and njet.norid.no provided partly both:
answer without glue for the question, and glue without answer for the
other server(s).
 >reached its retry threshold, to fail fatally.
BIND8 is widely used so this lack of backward compatibility cause
a big problem. This is not new or?? Is it the resolvers that has the
problem?

---

From: [email-masked]
Date: Wed, 27 Nov 2002 12:23:55 +1100

Squish has case sensitivity bugs.  sid.nimrod.no and
	SID.NIMROD.NO produce different results.

	Query restart should not a issue here.  The question should be
	answered on the second query and UDP clients should be making
	more than one request.

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

---

From: Kare Presttun <[email-masked]>
Date: Wed, 27 Nov 2002 15:42:24 +0100

>       SID.NIMROD.NO produce different results.

You are very correct in observing this (I did a test, and included
James in the CC).
At 27.11.2002 04:58 +0000, Paul Vixie wrote:
 >
 >second, i've seen comments here to the effect that a name node's ownership
 >was zone-independent, and that's just plain wrong.  again, early bind got
 >this horribly wrong and caused a lot of pain and confusion, and we need to
 >retain what's been learned (which is foundational to rfc2181 and rfc2308),
 >which is that a delegation point is owned by the child zone and the parent
 >can at best send delegations, never answers and never authoritative, when
 >queried for things at a child zone's delegation point.  bind9 does this
 >correctly.  an apparently common misunderstanding as to the contents of a
 >zone is that data can be copied from a child without changing the identity
 >of the parent.  this is just false, and is indicative of other conceptual
 >errors.

 From the statement of Mr. Vixie I draw the following conclusion about
the .no ccTLD servers (please correct me if I'm wrong):

nn.uninett.no.  Correct (authority for nimrod.no)
ifi.uio.no.   Correct (recursive)
nac.no.   Correct
not.norid.no.   Wrong (gives answer and partly glue)
njet.norid.no.   Wrong (gives answer and partly glue)
slave1.sth.netnod.se.   Correct

All diged below for completeness (using sid.nimrod.no as example):

; <<>> DiG 9.2.1 <<>> @nn.uninett.no sid.nimrod.no
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;sid.nimrod.no.                 IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

; <<>> DiG 9.2.1 <<>> @ifi.uio.no sid.nimrod.no
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;sid.nimrod.no.                 IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; QUESTION SECTION:
;sid.nimrod.no.                 IN      A

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

; <<>> DiG 9.2.1 <<>> @not.norid.no sid.nimrod.no
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;sid.nimrod.no.                 IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; QUESTION SECTION:
;sid.nimrod.no.                 IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

; <<>> DiG 9.2.1 <<>> @slave1.sth.netnod.se sid.nimrod.no
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;sid.nimrod.no.                 IN      A

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

Thanks a lot for clarifications and observations.

---

From: James Ponder <[email-masked]>
Date: Sat, 30 Nov 2002 14:36:50 +0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> You are very correct in observing this (I did a test, and included

Thank you both for notifying me about this, I have hopefully fixed the bugs.

Best wishes, James
-- 
James Ponder; www.squish.net; London, UK