Having Trouble with Reverse Map in Child Zone.

Martin McCormick martin at dc.cis.okstate.edu
Tue Apr 2 15:35:19 UTC 2002


	It is now working.  This is a case of looking for obscure
problems when the real reason was just bad typing.

Mark_Andrews at isc.org writes:
>	Which zone did you put this in?

	The IN-ADDR.ARPA. entries were placed in the tops of both
the forward and reverse maps for our class B network.

>	What was the $ORIGIN value?

	That's where I began to smell the rat.  I build our
forward and reverse zones using shell scripts and a C-based parser
which pieces the final zone together out of portions such as all
the A records, all the CNAME records and, of course, the SOA and
NS records.

	There were two major errors on my part that I just
didn't even think about.  After looking at Mark's example, I
looked more closely and made a shocking discovery.

>	I would normaly expect this to be 
>
>222.78.139.IN-ADDR.ARPA.    IN    ns  testdns1.testnet2.okstate.edu.
>222.78.139.IN-ADDR.ARPA.    IN    ns  testdns2.testnet2.okstate.edu.

	The C program I wrote that builds the reverse maps looks
for the NS not the ns records in order to carry them over to the
new reverse zone.  That meant that when I posted the original
message, I was leaving them out of the reverse map where they
really belonged.  The fact that they were in the forward map is
really meaningless.  It would have been better to have them in
the reverse map and leave them out of the forward map if they had
to be left out of anything.

	Also, the missing dot to fully qualify IN-ADDR.ARPA .
probably would have broken it anyway.

	Finally, one last question.  While my reverse map builder
looks for the NS records, does bind look at the case of the
record type?  Would ns have worked if not for my map builder?

	The $ORIGIN was what made me look at _EVERYTHING_ once
again.

	This makes me feel rather stupid to be honest.

Martin McCormick


More information about the bind-users mailing list