Maintained by: NLnet Labs

[Unbound-users] DNS64 patch for Unbound

lst_hoe02 at
Mon Jun 30 14:50:56 CEST 2014

Zitat von "W.C.A. Wijngaards" <wouter at>:

> Hash: SHA1
> Hi Bjoern,
> On 06/29/2014 11:21 PM, Bjoern A. Zeeb wrote:
>> Hi,
>> a few years back Viagenie[4] developed a DNS64 patch [5] for
>> unbound.  In the last couple of years I maintained it and forward
>> ported it privately.  Lately, with FreeBSD temporarily shipping
>> unbound in base, people have asked for that patch and I ended up
>> putting it into a user branch [1][2] and updated it again for a new
>> version [3].  I (or anyone) can easily extract an up-to-date patch
>> and a large junk of that is mainly the regeneration of files from
>> .l/.y.
>> However I am now facing the question:  is upstream willing to fully
>> integrate this change or should I just drop it into FreeBSD base?
>> I’d be happy to work with you guys on this.  Just let me know.
> Yes, we would be happy to integrate this.
> Previously, we had spoken (very cordially, at the IETF, even though
> the main author had had a soccer-related injury) with the folks from
> Viagenie.  Both NAT64 was not very important and also the license for
> the contribution needed to be sorted out.  These things seem to have
> changed (or I might remember our conversation about the license
> wrongly).  I see the patch has a very comfortable BSD license.
> Is NAT64 considered this important?  We would be happy to incorporate
> the patch if this is considered useful to many users.  NAT64 for DNS
> does involve allowing others to inject new addresses in a new netblock
> for arbitrary names, and as such carries a little bit of security
> considerations.  So, I would hesitate to enable this by default.  But
> the option could certainly be useful, as we would like to help the
> IPv4 to IPv6 transition.  What do other users think about this?

I doubt this is easy useable with DNSSEC as DNS records are created  
on-the-fly, no? I also don't like the idea of yet another workaround  
to delay the switch-over, after all we already have  
dual-stack(protocol) for the next decade i suspect.

> (if they can receive the email...)

Of course, SPF is evil and we therefore don't use it at all ;-)