IPv6 reverse zone exports, but entries do not

Started by adam.dorsey, May 22, 2014, 10:43:08 AM

Previous topic - Next topic

adam.dorsey

I have created an IPv6 reverse zone in NicTool for one of our domains.  I had no issues creating it, or adding PTR entries to it.  However, when exporting to BIND, the zone file is created, but the PTR entries that I have added do not appear in the zone.

The zone is 1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa.

It contains the following entries:
3.0.0.0.2.5.1.0.0.0.0.0.0.0.0.0    PTR    gaea.princeton.rdhpcs.noaa.gov.    86400
4.0.0.0.2.5.1.0.0.0.0.0.0.0.0.0    PTR    analysis.princeton.rdhpcs.noaa.gov.    86400
7.0.0.0.2.5.1.0.0.0.0.0.0.0.0.0    PTR    mgmt.princeton.rdhpcs.noaa.gov.    86400
8.0.0.0.2.5.1.0.0.0.0.0.0.0.0.0    PTR    zeus.princeton.rdhpcs.noaa.gov.    86400

When the zone is exported, this is the content of the file:


$TTL    86400;
1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa. IN SOA ns-e.noaa.gov.    oar\.rdhpcs\.infra.noaa.gov. (
2014052210    ; serial
7200   ; refresh
3600     ; retry
604800    ; expiry
3600   ; minimum
)

1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa. 86400 IN NS ns-e.noaa.gov.
1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa. 86400 IN NS ns-mw.noaa.gov.
1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa. 86400 IN NS ns-nw.noaa.gov.


Have I done something stupid?  Is there any reason that these entries should not be exporting into the file?

Edit: This is NicTool 2.22, running on CentOS 5.10.

matt

I'm not sure why you're experiencing that, but I plan to look into it within a few days.

adam.dorsey

Excellent, thank you.  Please let me know if I can get you any more data.

I'll keep digging on my end and see what I can find out.

matt

I just finished doing a test of NicTool 2.23, which is slightly different but contains other fixes and changes unrelated to your issue. I set up a BIND export with identical zones and did an export:

/usr/local/nictool/ns1 # ./run
nsid 1 reading DB settings from ../server/lib/nictoolserver.conf
nsid 1 has 2 zones, 0 changed, forced, retrieved 2 zones, retrieved 0 zones, exported

/usr/local/nictool/ns1 # cat data-ns1.example.com/1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa
$TTL    86400;
$ORIGIN 1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa.
1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa. IN SOA ns1.example.com.    hostmaster.1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa.. (
2014052604    ; serial
16384   ; refresh
900     ; retry
1048576    ; expiry
2560   ; minimum
)

1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa. 86400 IN NS ns1.example.com.
1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa. 86400 IN NS ns2.example.com.
1.0.c.1.0.2.1.9.0.2.0.0.0.1.6.2.ip6.arpa. 86400 IN NS ns3.example.com.
3.0.0.0.2.5.1.0.0.0.0.0.0.0.0.0 86400 IN  PTR gaea.princeton.rdhpcs.noaa.gov.
4.0.0.0.2.5.1.0.0.0.0.0.0.0.0.0 86400 IN  PTR analysis.princeton.rdhpcs.noaa.gov.
7.0.0.0.2.5.1.0.0.0.0.0.0.0.0.0 86400 IN  PTR mgmt.princeton.rdhpcs.noaa.gov.
8.0.0.0.2.5.1.0.0.0.0.0.0.0.0.0 86400 IN  PTR zeus.princeton.rdhpcs.noaa.gov.


When you run an export, what type of feedback do you get on the command line?  What about in syslog (/var/log/messages on CentOS)?

matt

After reading through the git logs, there were some updates to BIND exports, so it's possible that simply upgrading to NicTool 2.23 (just released) will resolve the problem.

adam.dorsey

Thanks for taking a look.  We found a workaround by using a script to auto-populate the reverse zones based on the forward zones, then the IPv6 deployment got delayed.  When we're ready to move forward with this, I'll upgrade NicTool and see if that fixed the issue.