[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is this correct behavior?
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: postmaster@imail.oslonett.no
> [mailto:postmaster@imail.oslonett.no]
> > Sendt: 21. november 2002 00:26
> > Til: < address deleted by me>
> > Emne: Undeliverable Mail
> >
> > Unknown host: Kare@Presttun.org
> >
>
> Or like this one from Securityfocus:
>
> <Kare@presttun.org>: 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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>