FORMERR from bind9 for reverse map for Ottawa dialup

Greg A. Woods woods at weird.com
Wed Aug 20 23:39:41 UTC 2003


[ On Monday, August 18, 2003 at 20:09:33 (-0400), Michael Richardson wrote: ]
> Subject: Re: FORMERR from bind9 for reverse map for Ottawa dialup 
>
>   That sounds like a reasonable explanation, but, I get answers for PTR.
> 
> marajade-[~] mcr 1005 %dig +norecurse 165.157.10.64.in-addr.arpa. ptr @dialdns1.uu.net.

Well, yes, of course you do if you ask either of the authoritative
servers directly (i.e. dialdns1.uu.net or dialdns2.uu.net).

However if you ask a caching recursive server then the result will
depend on whether it queries (or has recently queried) auth01.ns.uu.net
or either of ns.uunet.ca or ns2.uunet.ca to find the answer for you.

One more thing I didn't think about the other day was the possibility
that the lack of NS records in the zone files at the authoritative
servers may result in what is effectively (though perhaps not in
reality) an NXDOMAIN result being cached for those NS records.
I.e. perhaps the real problem is that once your local caching recursive
nameserver has queried an authoritative server then it will remember for
some time that the set of NS records for the zone in question is the
empty set and thus it will fail subsequent query attemps until it
forgets that there are no NS records for that zone.  There may even be
some difference in behaviour in this scenario between BIND-8 and BIND-9.
That may not quite explain the FORMERR though.....

In any case it's bad enough if a zone contains different NS records for
itself than the parent zone, but it's totally non-functional for there
to be no NS records for the zone inside of the zone itself, which is
exactly the case for 157.10.64.in-addr.arpa (and no doubt other related
zones as well).  I see UUNET have failed to do anything to fix this yet.

>   btw, who said anything about ns.uunet.ca?

The DNS did.  ;-)

The parent zone of the zone you're querying is served by ns.uunet.ca,
amongst others.  If I remember the zone search algorithm properly that
nameserver could be one of those queried during a recursive lookup for
any record in the zone you are querying.

>   see draft-richardson-ipsec-opportunistic-12.txt.
>   The lack of them is okay - it just tells my system that I must not use
>   my IP address as my IPsec identity.

Ah yes of course!  Sorry, but I forgot about that!  ;-)

>     Greg> If your nameserver chose to query auth01.ns.uu.net then that's the
>     Greg> answer it must return.  It is only authoritative for the parent
>     Greg> zone, not the zone you want to query.
> 
>   I did not.

If your local recursive caching nameserver is running BIND-9 then you
cannot tell what nameserver it queried on your behalf after the fact --
you can only tell by tracing its outbound traffic at the time it makes
the query or queries necessary to answer your query.

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