• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Reverse Zones via AXFR

Started by beewoolie, July 21, 2010, 07:26:04 PM

Previous topic - Next topic

beewoolie

While the reverse DNA lookup support provided by HE is sufficient, it does require us to manually enter each of our hosts into the zone via the web interface.  I'd like to see a zone transfer mechanism supported as well.  SixXS supports this sort of delegation.  It allows me to use a script to generate my reverse zones.

gshaver


We are looking into this (or a similar method) of adding bulk records for a future release.

Gary

snarked

I've noticed this too and after some expermentation, I've noted a flaw and a temporary solution:

For a SLAVE reverse zone hosted at the HE servers, configure as follows:

1) The first name server:  Declare it as your hidden master primary (which should be the name server in the SOA record).  With this entry as a NON he.net name server, there is no automatic master zone created in the DNS manager.

2) The other 4 name servers:  ns2-5.he.net.  (I excluded ns1.he.net as it's IPv4 only).

3) In the zone:  The NS records name ns1-ns5.he.net.  There is no NS record for the hidden master; only the SOA record.

4) In the DNS interface, declare it as a slave zone with transfers from the hidden master (Delete the zone's other entry as a reverse first if necessary).  Permit ns1.he.net for AXFR access at the master as usual for a slaved zone.

-------------
There should be no direct queries from the outside to one's hidden master.  In fact, since HE's DNS servers cover the parent, a delegation record will never be handed out.  When an external name server is referred to HE (per the /32 delegation for "0.7.4.0.1.0.0.2.ip6.arpa"), that referral will name only ns1-5.he.net (as it should).  When those servers receive the referred query, since they host both the parent and child zones, a step is skipped and the child zone answer is delivered directly (even though the query has descended the DNS tree only to the parent zone).  That answer will include only ns1-5 as the authoritative NS's in the query, so one's hidden master is never revealed as a valid resolution server.

The hidden master may still receive queries from HE's servers to determine whether the SOA record has updated (supposedly, ONLY from ns1.he.net as the AXFR point), but not queries from elsewhere (i.e. other than HE's servers and itself or the network local to it - if so configured by you).

The only way any of us will even know that there's a hidden master is from the SOA record.  Note that it is technically a RFC violation to list "ns1.he.net" as the primary in the SOA record (to further hide the hidden master), and depending on HE's DNS software, might even break the slave status of the reverse zone.  I know HE uses software other than BIND.  With BIND, the notify subsystem does use the SOA declared master server for its operation, and HE's DNS package may do similarly.

I don't like this and feel that we should be able to have a reverse zone as a SLAVE in the DNS manager and list ns1-ns5.he.net in the tunnel server, but that combination doesn't currently work.  When all 5 name servers are HE's in the tunnel server, the DNS server creates a MASTER zone, not a slave, for the IPv6 reverse.

gshaver

That's an interesting solution and technically will work.  afaik, the authoritative server does not check the soa
for the actual physical origin of the zone so having it list ns1.he.net to hide your master should be feasible.

There really shouldn't be a problem with setting up one of your assigned 48s  or 64s as a slave zone.  While the delegation
would actually be ns1-ns5, the slave could be a different nameserver altogether.  Because you'd be listed as the master, we'd
even honor NOTIFYs if you sent them.

Let me know if you experienced different behavior.
Gary

snarked

Gary:  If you want, take a look at what my account has set up.  I have my reverse zone as a slave with a hidden master precisely as I described above.  I noted that whenever I substituted ns1.he.net for my master in the tunnelbroker, that automatically changed my reverse zone from slave to master in the DNS interface (Argh!).  Therefore, what I have was what my experments came up with as a result that works.

realdreams

Have you tried going to the advanced tab and delete the automatically generated reverse zone? I am not sure if it will be regenerated when you edit tunnel settings. I changed the first rDNS to my own DNS.