How to generate authoritative DNS64 reverse zone

[Aleksi Suhonen]

Hello,

Suppose that I have a NAT64 prefix 2001:67c:2b0:db32:0:1::/96 and a
couple of DNS64 resolvers that use it. The resolvers will also generate
nice CNAMEs that point to in-addr.arpa for that prefix. This is nice.

But other resolvers in the world won't do that, so I'd need to have a
real reverse zone for this fantastical NAT64 prefix for their benefit.
But if I configure a DNS64 prefix on an authoritative server, it will
start messing with my normal zones too, won't it?

So how do I configure Bind9 to generate one authoritative DNS64 reverse
zone that contains CNAMEs to in-addr.arpa, but otherwise not mess with
anything?

Yours,

--
Aleksi Suhonen / Axu TM Oy
Internetworking Consulting
Cellular: +358 44 975 6548
World Wide Web: www.axu.tm

[Alberto Colosi]

Hi, is hard an ISP give to you a reverse lookup zone

first of all , is needed you to "own" all zone (ipv4 , all C class) for example.

as second thing, is really hard to move definitions on TLD like ripe , arin, apnic or others ....

is more possible ISP give to you (if first line is true)  controll of reverse zone and ISP transfer from you reverse zone definitions without involving ripe/arin/apnic/...

I spoke as I was in the need with an ipv4 reverse zone and ISP only accepted on that way.

if you don't "own" entire zone , is no way to have this from your ISP.

Remember ipv6 or ipv4 reverse zones are queried only if right referenced on ripe/arin/apnic/... or your ISP transfer from you the ipv6 zone.

repeating if you not "own" entire zone , ISP never will accept to move to you or to transfer from you the zone as other IP don't belong to you

---

From: bind-users <bind-user...@lists.isc.org> on behalf of Aleksi Suhonen <bind-us...@ssd.axu.tm>
Sent: Friday, May 19, 2017 3:24 PM
To: bind-...@lists.isc.org
Subject: How to generate authoritative DNS64 reverse zone

 

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users Info Page - lists.isc.org Mailing Lists lists.isc.org To see the collection of prior postings to the list, visit the bind-users Archives. Using bind-users: To post a message to all the list members, send ...

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bind-users Info Page - lists.isc.org Mailing Lists lists.isc.org To see the collection of prior postings to the list, visit the bind-users Archives. Using bind-users: To post a message to all the list members, send ...

[Mark Andrews]

In message <57bf558b-f4eb-f2e4...@axu.tm>, Aleksi Suhonen writes:
> Hello,
>
> Suppose that I have a NAT64 prefix 2001:67c:2b0:db32:0:1::/96 and a
> couple of DNS64 resolvers that use it. The resolvers will also generate
> nice CNAMEs that point to in-addr.arpa for that prefix. This is nice.
>
> But other resolvers in the world won't do that, so I'd need to have a
> real reverse zone for this fantastical NAT64 prefix for their benefit.
> But if I configure a DNS64 prefix on an authoritative server, it will
> start messing with my normal zones too, won't it?
>
> So how do I configure Bind9 to generate one authoritative DNS64 reverse
> zone that contains CNAMEs to in-addr.arpa, but otherwise not mess with
> anything?
>
> Yours,

You should delegate
1.0.0.0.0.0.0.0.2.3.B.D.0.B.2.0.C.7.6.0.1.0.0.2.IP6.ARPA normally.
This will let everyone in the world find the CNAME records. This
should be done even if you are just doing it for your recursive
clients.

If you don't want A to AAAA mappings to happen then turn off the
DNS64 mapping for everyone on the server.

dns64 2001:67c:2b0:db32:0:1::/96 {
clients { none; }
};

Mark

> --
> Aleksi Suhonen / Axu TM Oy
> Internetworking Consulting
> Cellular: +358 44 975 6548
> World Wide Web: www.axu.tm
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>

> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Aleksi Suhonen]

Hi,

On 05/20/2017 01:48 AM, Mark Andrews wrote:
> In message <57bf558b-f4eb-f2e4...@axu.tm>, Aleksi Suhonen writes:
>> So how do I configure Bind9 to generate one authoritative DNS64 reverse
>> zone that contains CNAMEs to in-addr.arpa, but otherwise not mess with
>> anything?

> You should delegate
> 1.0.0.0.0.0.0.0.2.3.B.D.0.B.2.0.C.7.6.0.1.0.0.2.IP6.ARPA normally.
> This will let everyone in the world find the CNAME records. This
> should be done even if you are just doing it for your recursive
> clients.

I created the delegation, tried the below config and created an empty
zone file for the above delegation. Rndc reconfig gave the following error:

22-May-2017 07:58:13.534 general: error: reloading configuration failed:
already exists

This was the entirety of the error message.

> If you don't want A to AAAA mappings to happen then turn off the
> DNS64 mapping for everyone on the server.

> dns64 2001:67c:2b0:db32:0:1::/96 {
> clients { none; }
> };

When I removed the empty master zone, the error message went away. So it
seems that the dns64 declaration implicitly creates a new zone in Bind.
Makes sense. This could be added to documentation?

I think the above error message should also be improved, as it gave no
indication as to *what* exists already. I could have saved about an hour
of wondering what the hell is wrong with my config change, if the error
message was a bit more wordy. :-)

In hind sight, I guess I could have turned on debugging and seen what
messages would be generated then, but I suspect there would have been
too many messages for me to process.

Anyway, thanks for the help.

[Mark Andrews]

In message <396e2fc9-3151-aad6...@axu.tm>, Aleksi Suhonen writes:
> Hi,
>
> On 05/20/2017 01:48 AM, Mark Andrews wrote:
> > In message <57bf558b-f4eb-f2e4...@axu.tm>, Aleksi Suhonen writes:
> >> So how do I configure Bind9 to generate one authoritative DNS64 reverse
> >> zone that contains CNAMEs to in-addr.arpa, but otherwise not mess with
> >> anything?
>
> > You should delegate
> > 1.0.0.0.0.0.0.0.2.3.B.D.0.B.2.0.C.7.6.0.1.0.0.2.IP6.ARPA normally.
> > This will let everyone in the world find the CNAME records. This
> > should be done even if you are just doing it for your recursive
> > clients.
>
> I created the delegation, tried the below config and created an empty
> zone file for the above delegation. Rndc reconfig gave the following error:
>
> 22-May-2017 07:58:13.534 general: error: reloading configuration failed:
> already exists
>
> This was the entirety of the error message.
>
> > If you don't want A to AAAA mappings to happen then turn off the
> > DNS64 mapping for everyone on the server.
>
> > dns64 2001:67c:2b0:db32:0:1::/96 {
> > clients { none; }
> > };
>
> When I removed the empty master zone, the error message went away. So it
> seems that the dns64 declaration implicitly creates a new zone in Bind.
> Makes sense. This could be added to documentation?

The ARM already has this in the description for dns64.

<para>
Additionally a reverse IP6.ARPA zone will be created for
the prefix to provide a mapping from the IP6.ARPA names
to the corresponding IN-ADDR.ARPA names using synthesized
CNAMEs. <command>dns64-server</command> and
<command>dns64-contact</command> can be used to specify
the name of the server and contact for the zones. These
are settable at the view / options level. These are
not settable on a per-prefix basis.
</para>

> I think the above error message should also be improved, as it gave no
> indication as to *what* exists already. I could have saved about an hour
> of wondering what the hell is wrong with my config change, if the error
> message was a bit more wordy. :-)

Ticket opened.

> In hind sight, I guess I could have turned on debugging and seen what
> messages would be generated then, but I suspect there would have been
> too many messages for me to process.
>
> Anyway, thanks for the help.
>
> --
> Aleksi Suhonen / Axu TM Oy
> Internetworking Consulting
> Cellular: +358 44 975 6548
> World Wide Web: www.axu.tm