Subject: Re: Is this correct behavior?

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

Kare Presttun wrote:

> 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.

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

--
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: 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?

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