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.
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?
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 also would not like to see it enabled by default as you need a NAT64 router, too
more careful it could be a compiletime option.
Zitat von "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Bjoern,
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
I doubt this is easy useable with DNSSEC as DNS records are created
on-the-fly, no?
it is possible to do the DNS64 synthesizing of records after doing the
DNSSEC validation. As long as the client application does not do DNSSEC
validation, the scheme works. But sure, DNS64 and DNSSEC do not play
well together.
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.
DNS64 enables a network to go IPv6 native all the way, and switch off
legacy IPv4. I see that DNS64 *helps* with the switch over, it *helps*
sun-setting IPv4. It reduces complexity by removing the need to run full
dual-stack in order to access legacy IPv4 resources on the Internet.
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 see DNS64/NAT64 as a tool to reduce complexity in the IPv4->IPv6
transition phase by removing the need to run full dual stack in order to
reach legacy IPv4 resources in the Internet.
With DNS64 networks can go IPv6 native and use DNS64/NAT64 to access old
IPv4 stuff.
Deployments of DNS64 at larger conferences such as FOSDEM, RIPE and
Cisco Live have shown that the techology is mature and works for most
protocols.
DNS64 should not be enabled by default in Unbound (it requires local
configuration anyway), but it should be either a configuration switch or
a compile-time option (I would vote for a configuration switch. If it is
a compile-time option, the distributions will enable it anyway).
The DNS64 configuration options in BIND 9 work fine and could be a
template for Unbound.
I would be happy to see DNS64 support in Unbound and would be willing to
test.
I do think this will become more important over time. I support
inclusion of the code, compiled in but disabled per default.
I have pondered in the past whether or not to patch it into the fedora
or rhel version of unbound. The only reason I did not was because it
was an external patch and would require a lot of maintanance. I was
hoping upstream would merge it in themselves.
I am just throwing another mail in support of integrating DNS64
patch into Unbound.
O.
P.S.: I am writing this from NAT64 network we have setup at CZ.NIC.
And I fully agree with Carsten that NAT64 actually help the transition
and not hinder it.
There are some apps that are still broken without legacy IP, but I am
even considering to enable this as a default setup at my home.
OK, just replying to the last email; I’ll cleanup the patch (without the regenerated files, etc.) and post it here the next hours or if that fails days, so people can review, test, integrate it.
OK, just replying to the last email; I’ll cleanup the patch (without the regenerated files, etc.) and post it here the next hours or if that fails days, so people can review, test, integrate it.
Hello,
I'm not sure if it's valid in current version of patches, but I would
like to point out that the DNS64-patched Unbound operated on public
NAT64 test [1] (apparently offline ATM) fails to conform with RFC 6147
in the way it handles queries with DO and CD flags set. For these
queries, the synthesis MUST NOT be performed in order to preserve valid
DNSSEC data for further validation at endpoint [2]. I think this should
be fixed before the patch reaches the upstream.
I do think this will become more important over time. I support
inclusion of the code, compiled in but disabled per default.
+1
We do use it and only enabled the module when required.
DNS64 allows to do smooth transition and it is a feature that would be nice to have in mainstream because it would simplify maintenance. Like probably a few users on the mailing-list, we were updating the patch to be able to compile with the version we were using. I did ask a year ago if this could be added in maintream because it was tedious to maintain/hack our own patch version from the original 1.4.7 patch IIRC
OK, just replying to the last email; I’ll cleanup the patch (without the regenerated files, etc.) and post it here the next hours or if that fails days, so people can review, test, integrate it.
I extracted the patch from my FreeBSD user branch and manually cleaned it up and applied it to a clean unbound SVN checkout:
I have not tested this patch, and yes, there might be further standardisation changes that might need addressing. I would suggest to review this one and make sure it works, and given the module is not enabled by default commit it, then put additional changes on top. It’ll also keep the various contributors separate.
My thanks go to Viagenie for this patch; it’s been their work, not mine!
