FORMERR from bind9 for reverse map for Ottawa dialup
Greg A. Woods
woods at weird.com
Mon Aug 18 21:59:57 UTC 2003
[ On Sunday, August 17, 2003 at 17:51:30 (-0400), Michael Richardson wrote: ]
> Subject: FORMERR from bind9 for reverse map for Ottawa dialup
>
> Is this among issues with djdns? Or another? I will complain to the ISP
> who has hired this service as soon as I have the right ammunition.
FYI ns.uunet.ca and ns2.uunet.ca are/were, IIRC, running BIND-8.x
(though they may have more recently been upgraded to BIND-9), and
auth01.ns.uu.net is, IIRC, running BIND-9.x. The latter is an
authoritative-only server, while the former are _STILL_ also recursive
caching servers.
I believe the ultimate problem is that there are no NS records in the
zone for the record in question (i.e. in 157.10.64.in-addr.arpa) even
though there are NS RRs in the parent zone (i.e. in 10.64.in-addr.arpa):
$ host -C 157.10.64.in-addr.arpa
No nameservers for 157.10.64.in-addr.arpa found
$ host -t ns 157.10.64.in-addr.arpa
157.10.64.in-addr.arpa ANY record not found, server failure
$ host -d -t ns 157.10.64.in-addr.arpa dialdns1.uu.net
;; res_mkquery(0, 157.10.64.in-addr.arpa, 1, 2)
;; res_send(query, 40, answer, 65536) called:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15511
;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0
;; QUESTIONS:
;; 157.10.64.in-addr.arpa, type = NS, class = IN
;; Querying server (# 1) udp address = 153.39.194.10, accepting up to 65536 answer bytes
;; got answer, 102 bytes:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15511
;; flags: qr aa rd; Ques: 1, Ans: 0, Auth: 1, Addit: 0
;; QUESTIONS:
;; 157.10.64.in-addr.arpa, type = NS, class = IN
;; AUTHORITY RECORDS:
10.64.in-addr.arpa. 3600 IN SOA DIALDNS1.UU.NET. hostmaster.UU.NET. (
18 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 mins)
604800 ; expire (7 days)
3600 ) ; minimum (1 hour)
;; Query for NS records done, 1 answer, authoritative, status: no error
Refer to the following authoritative servers:
10.64.in-addr.arpa SOA DIALDNS1.UU.NET hostmaster.UU.NET (
18 ;serial number (version)
3600 ;slave refresh period (1 hour)
900 ;slave retry interval (15 minutes)
604800 ;slave expire time (1 week)
3600 ;negative response TTL (1 hour)
)
(dialdns2.uu.net answers identically)
I don't know what dialdns1 and dialdns2 are running, though I suspect
it's BIND-9 as well.
Everything in the parent zone is OK though (except for the fact that
ns.uunet.ca and ns2.uunet.ca are _STILL_ also running as recursive cache
servers!):
$ host -a 10.64.in-addr.arpa
10.64.in-addr.arpa SOA ns.uunet.ca hostmaster.uunet.ca (
2001032001 ;serial number (version)
43200 ;slave refresh period (12 hours)
300 ;slave retry interval (5 minutes)
604800 ;slave expire time (1 week)
43200 ;negative response TTL (12 hours)
)
10.64.in-addr.arpa NS ns.uunet.ca
10.64.in-addr.arpa NS ns2.uunet.ca
10.64.in-addr.arpa NS auth01.ns.uu.net
$ host -C 10.64.in-addr.arpa
10.64.in-addr.arpa NS auth01.ns.uu.net
ns.uunet.ca hostmaster.uunet.ca (2001032001 43200 300 604800 43200)
10.64.in-addr.arpa NS ns.uunet.ca
ns.uunet.ca hostmaster.uunet.ca (2001032001 43200 300 604800 43200)
10.64.in-addr.arpa NS ns2.uunet.ca
ns.uunet.ca hostmaster.uunet.ca (2001032001 43200 300 604800 43200)
$ host -t ns 157.10.64.in-addr.arpa ns.uunet.ca
157.10.64.in-addr.arpa NS dialdns2.uu.net
157.10.64.in-addr.arpa NS dialdns1.uu.net
$ host -t ns 157.10.64.in-addr.arpa ns2.uunet.ca
157.10.64.in-addr.arpa NS dialdns1.uu.net
157.10.64.in-addr.arpa NS dialdns2.uu.net
$ host -t ns 157.10.64.in-addr.arpa auth01.ns.uu.net
157.10.64.in-addr.arpa NS dialdns1.uu.net
157.10.64.in-addr.arpa NS dialdns2.uu.net
Note though that ns.uunet.ca and ns2.uunet.ca are also authorities for
the parent zone in question, _and_ since they are operating recursively
they will looking up and return the answer you want:
$ host -a 155.157.10.64.in-addr.arpa ns.uunet.ca
155.157.10.64.in-addr.arpa PTR 1Cust155.tnt4.ottawa.on.da.uu.net
$ host -a 155.157.10.64.in-addr.arpa ns2.uunet.ca
155.157.10.64.in-addr.arpa PTR 1Cust155.tnt4.ottawa.on.da.uu.net
However since auth01.ns.uunet, which is also an authority for the parent
zone, is not operating recursively it can do nothing but send a referral:
$ host -a 155.157.10.64.in-addr.arpa auth01.ns.uu.net
155.157.10.64.in-addr.arpa ANY record currently not present at auth01.ns.uu.net
$ host -t ptr 155.157.10.64.in-addr.arpa auth01.ns.uu.net
155.157.10.64.in-addr.arpa PTR record currently not present at auth01.ns.uu.net
$ host -t txt 155.157.10.64.in-addr.arpa auth01.ns.uu.net
155.157.10.64.in-addr.arpa TXT record currently not present at auth01.ns.uu.net
> running as a local recursive name server, I have a process doing TXT
> lookups on my reverse IP (a dialup from uu.net) and my local named9 is logging:
Why TXT records? What do you expect to find? There are no TXT records
along with the PTRs at the authoritative servers.
> I.e. I am getting a referral from a server that is supposed to be
> authoritative. Note that it is authoritative for other record types!
If your nameserver chose to query auth01.ns.uu.net then that's the
answer it must return. It is only authoritative for the parent zone,
not the zone you want to query.
I'm not sure why your recursive BIND-9 server is logging a FORMERR
instead of chasing down the authoritative servers (though at this time
of the day I'm not sure it's supposed to either :-). Maybe it's because
it sees the SOA in the AUTHORITY section. I don't have any problem with
my test BIND-9.2.1 server, but then again I can't tell where it got its
cached records from either.
BTW, HOSTMASTER at UUNET.CA: You have some contacts pointing at
hostmaster at ns.uunet.ca, which bounces!!!! Please fix your mailer!!!
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com> Secrets of the Weird <woods at weird.com>
More information about the bind-workers
mailing list