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