Hi,
Just a quick question, will the DNS-ALG/DNS64 [0] or something similair be part of
the official release at some point ?
Because I think totd is pretty much not maintained anymore ?, if I'm not mistaken.
Maybe their isn't anything to maintain on totd, I don't know. 
Anayway having one daemon handle all things DNS is just keeping it simple as well.
* Leen Besselink:
Just a quick question, will the DNS-ALG/DNS64 [0] or something
similair be part of the official release at some point ?
I guess all systems on which Unbound runs are dual-stack, so this type
of translation appears to be unnecessary (at the DNS level). The
application can just use IPv4 sockets, and the kernel will treat this
traffic according to the configured routing policy.
Florian Weimer wrote:
* Leen Besselink:
Just a quick question, will the DNS-ALG/DNS64 [0] or something
similair be part of the official release at some point ?I guess all systems on which Unbound runs are dual-stack, so this type
of translation appears to be unnecessary (at the DNS level). The
application can just use IPv4 sockets, and the kernel will treat this
traffic according to the configured routing policy.
I think it depends, eventually less and less IPv4-addresses will be
available and thus we'll get a lot more different situations, where
unbound with it's IPv4-address might be further away from the hosts
that query it, more centralized.
Also what if people just want a simple modern network with just
IPv6-addresses for simple(r) management ?
If you use IPv4, most of the time, you're doing NAT anyway, might as
well (if it works well enough, for you, which it might not for a lot
of people) use NAT-PT or something similair.
I don't know what kind of things will develop.
I did see the project at [0] was/is also partly funded bij NLnet Labs
and it's a patch to Unbound so I thought it might merge eventually.
I did see the project at [0] was/is also partly funded bij NLnet Labs
and it's a patch to Unbound so I thought it might merge eventually.
Note, it was funded by NLnet. NLnet Labs is a separate entity also
funded by NLnet.
jaap
[1] www.NLnet.nl
[2] www.NLnetLabs.nl
I did see the project at [0] was/is also partly funded bij NLnet Labs
and it's a patch to Unbound so I thought it might merge eventually.
Note, it was funded by NLnet. NLnet Labs is a separate entity also
funded by NLnet.
OK, that's a mistake on my part.
This has nothing to do with the need for DNS64. See
http://tools.ietf.org/html/draft-ietf-behave-dns64-00 for details.
Simon
That's our goal. Currently the patch needs some work. We're working on it.
When it is ready we'll submit it for inclusion and see what happens.
Simon
* Simon Perreault:
Why does the presence of an IPv4 stack have anything to do with the need for
DNS64?
Simon
* Simon Perreault:
- Tunnel: the whole point of DNS64/NAT64 is to not assign IPv4 addresses to
the IPv6-only network.
- NAT: uh?
Simon
* Simon Perreault:
Why would you need DNS64 if you can make connections to IPv4 addresses
at the API level? The kernel can tunnel/NAT it, no matter what API
calls you use.- Tunnel: the whole point of DNS64/NAT64 is to not assign IPv4 addresses to
the IPv6-only network.- NAT: uh?
NAT is just a very lightweight tunnel.
What I expect to happen is that the kernel performs the address
translation at the socket layer. You send out an IPv4 UDP packet in
your application, and it gets send out as an IPv6 packet, with a
suitable IPv6 source address (whatever that is), destined to the NAT64
gateway (by apply a the DNS64 translation). No IPv4 addresses are
required (except for the original destination). The result is less
overall complexity, and perfect interoperability with DNSSEC. The
cost is a small IPv4 stack change (which could presumably be
implemented as a packet filter rule if necessary).
Thanks for this complete description. I wanted to make sure I understood you
well.
I think what you are describing is described here:
http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-01
One drawback is that it requires modifying the host.
There are many solutions for IPv6 migration. Depending on your requirements
you will choose one or another. It seems that for many people it is important
to not have to modify the host, hence the interest for DNS64/NAT64 (and NAT-PT
before it).
Thanks for your input,
Simon
a message of 16 lines which said:
That's our goal. Currently the patch needs some work. We're working
on it. When it is ready we'll submit it for inclusion and see what
happens.
So, what happened? Now that the RFC is in state AUTH48 (soon to be
published), will we have DNS64 in Unbound? (BIND 9.8, with DNS64
support, is in public beta.)
The first thing that would need to be done would be to re-read the draft
and identify what needs to be done (if anything). There may be some
things related to DNSSEC, but I would need to re-read the spec to be sure.
Simon