starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #98] [Server] Support DNS64 (RFC 6147) #347

New issue

Open

opened 2026-03-15 22:04:59 +03:00 by kerem · 10 comments

kerem commented

2026-03-15 22:04:59 +03:00

Owner

Originally created by @vi on GitHub (Feb 28, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/98

I struggle to find something for DNS64 that is not BIND.

Originally created by @vi on GitHub (Feb 28, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/98 I struggle to find something for DNS64 that is not BIND.

kerem added the

enhance

crate:server

labels

2026-03-15 22:04:59 +03:00

kerem commented

2026-03-15 22:05:10 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 28, 2017):

I'm happy to take feature requests. I haven't had plans to support something like this, as it's not in my own use cases. It looks like a fairly strait forward implementation.

Is your plan to use this to auto-populate AAAA records for a NAT64? If so, I would see this as a magic option that could as easily be implemented with a dynamic update where on registration of the A record, you would perform the auto translation to the AAAA and IPv6 address. Is there a reason that doesn't work that I'm missing?

@bluejekyll commented on GitHub (Feb 28, 2017): I'm happy to take feature requests. I haven't had plans to support something like this, as it's not in my own use cases. It looks like a fairly strait forward implementation. Is your plan to use this to auto-populate AAAA records for a NAT64? If so, I would see this as a magic option that could as easily be implemented with a dynamic update where on registration of the A record, you would perform the auto translation to the AAAA and IPv6 address. Is there a reason that doesn't work that I'm missing?

kerem commented

2026-03-15 22:05:16 +03:00

Author

Owner

@vi commented on GitHub (Feb 28, 2017):

I haven't tried to use trust-dns [yet]. Just saw that it is aimed to be BIND replacement, but also that RFC 6147 is not mentioned in README list of RFCs.

@vi commented on GitHub (Feb 28, 2017): I haven't tried to use trust-dns [yet]. Just saw that it is aimed to be BIND replacement, but also that RFC 6147 is not mentioned in README list of RFCs.

kerem commented

2026-03-15 22:05:21 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 1, 2017):

I am definitely aiming for the project to be able to be used in the place of BIND, but I very early on decided not to make it a drop-in replacement. So it will not be 100% compatible with the BIND feature set. In this particular case, it seems like an RFC which provides value for configurations where you want some type of server logic to kick in to auto response to AAAA for NAT64 setups.

If someone requires this, I'll consider adding it, but I still fail to see why it couldn't just be part of deployment/management scripts as opposed to baked into the DNS server itself. Thanks for your interest in the project!

@bluejekyll commented on GitHub (Mar 1, 2017): I am definitely aiming for the project to be able to be used in the place of BIND, but I very early on decided not to make it a drop-in replacement. So it will not be 100% compatible with the BIND feature set. In this particular case, it seems like an RFC which provides value for configurations where you want some type of server logic to kick in to auto response to AAAA for NAT64 setups. If someone requires this, I'll consider adding it, but I still fail to see why it couldn't just be part of deployment/management scripts as opposed to baked into the DNS server itself. Thanks for your interest in the project!

kerem commented

2026-03-15 22:05:26 +03:00

Author

Owner

@vi commented on GitHub (Mar 1, 2017):

Does trust-dns have executable configuration files (like in Lua or Python often have) and can be told to turn e.g. A 178.172.160.4 into AAAA fd11:1:1:ffff::b2ac:a004 where fd11:1:1:ffff:: is configurable prefix and b2ac:a004 is IPv4 address in disguise for all resolved addresses?

@vi commented on GitHub (Mar 1, 2017): Does trust-dns have executable configuration files (like in Lua or Python often have) and can be told to turn e.g. `A 178.172.160.4` into `AAAA fd11:1:1:ffff::b2ac:a004` where `fd11:1:1:ffff::` is configurable prefix and `b2ac:a004` is IPv4 address in disguise for all resolved addresses?

kerem commented

2026-03-15 22:05:31 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 1, 2017):

The server supports dynamic DNS with SIG0 authentication. I've always imagine tools would be build around that interface to perform updates of the server. In that context, you could use any scripting language you want to manage it. I haven't considered scripted configs before, but it would be feasible... not on my road-map right now.

For example, in this case I would imagine the tool that is being used to manage the zones would be responsible for the logic you describe... The TRust-DNS client and server support atomic update operations, on a per record-set basis, which should make scripting this pretty straightforward.

@bluejekyll commented on GitHub (Mar 1, 2017): The server supports dynamic DNS with SIG0 authentication. I've always imagine tools would be build around that interface to perform updates of the server. In that context, you could use any scripting language you want to manage it. I haven't considered scripted configs before, but it would be feasible... not on my road-map right now. For example, in this case I would imagine the tool that is being used to manage the zones would be responsible for the logic you describe... The TRust-DNS client and server support atomic update operations, on a per record-set basis, which should make scripting this pretty straightforward.

kerem commented

2026-03-15 22:05:36 +03:00

Author

Owner

@vi commented on GitHub (Mar 1, 2017):

DNS64 is mostly not about being authoritative DNS server for some zone, but more like a DNS proxy that also patches request on the fly, changing all IPv4 addresses into IPv6 ones for NAT64.

@vi commented on GitHub (Mar 1, 2017): DNS64 is mostly not about being authoritative DNS server for some zone, but more like a DNS proxy that also patches request on the fly, changing all IPv4 addresses into IPv6 ones for NAT64.

kerem commented

2026-03-15 22:05:41 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 1, 2017):

Ah, thanks for the explanation. That makes sense to me. If your look at TRust-DNS as something you want to use and this is a blocker to that, I can try and fit it into my development at a future date. I'm also happy to accept PRs.

@bluejekyll commented on GitHub (Mar 1, 2017): Ah, thanks for the explanation. That makes sense to me. If your look at TRust-DNS as something you want to use and this is a blocker to that, I can try and fit it into my development at a future date. I'm also happy to accept PRs.

kerem commented

2026-03-15 22:05:46 +03:00

Author

Owner

@briansmith commented on GitHub (Jan 1, 2018):

Is your plan to use this to auto-populate AAAA records for a NAT64?

I'm not the OP, but this is my plan.

If so, I would see this as a magic option that could as easily be implemented with a dynamic update where on registration of the A record, you would perform the auto translation to the AAAA and IPv6 address. Is there a reason that doesn't work that I'm missing?

Imagine that you want to NAT64/DNS64 for the entire internet: IPv6-only LAN (not dual stack) that can access IPv4-only websites. In this case we need to give every IPv4-only-site on the internet an IPv6 address. That means that ideally the recursive resolver, not the server, would implement DNS64, and it would happen on-the-fly; i.e. require no disk/memory storage. That is, the recursive resolver would cache the AAAA records and throw away the A records from which it synthesized the AAAA records.

@briansmith commented on GitHub (Jan 1, 2018): > Is your plan to use this to auto-populate AAAA records for a NAT64? I'm not the OP, but this is my plan. > If so, I would see this as a magic option that could as easily be implemented with a dynamic update where on registration of the A record, you would perform the auto translation to the AAAA and IPv6 address. Is there a reason that doesn't work that I'm missing? Imagine that you want to NAT64/DNS64 for the entire internet: IPv6-only LAN (not dual stack) that can access IPv4-only websites. In this case we need to give every IPv4-only-site on the internet an IPv6 address. That means that ideally the recursive resolver, not the server, would implement DNS64, and it would happen on-the-fly; i.e. require no disk/memory storage. That is, the recursive resolver would cache the AAAA records and throw away the A records from which it synthesized the AAAA records.

kerem commented

2026-03-15 22:05:51 +03:00

Author

Owner

@briansmith commented on GitHub (Jan 2, 2018):

In particular, see https://tools.ietf.org/html/rfc6144#section-3.1.4:

Static records: One could literally populate DNS with corresponding A and AAAA records. This mechanism works for scenarios 2, 3, 5, and 6.

In particular, It doesn't work for Scenerio 1 (IPv6 network to IPv4 internet), which is the scenerio I described above.

Dynamic Translation of static records: In more general operation, the preferred behavior is an A record to be (retrieved and) translated to a AAAA record by the DNS64 if and only if no reachable AAAA record exists

@briansmith commented on GitHub (Jan 2, 2018): In particular, see https://tools.ietf.org/html/rfc6144#section-3.1.4: > Static records: One could literally populate DNS with corresponding A and AAAA records. This mechanism works for scenarios 2, 3, 5, and 6. In particular, It doesn't work for Scenerio 1 (IPv6 network to IPv4 internet), which is the scenerio I described above. > Dynamic Translation of static records: In more general operation, the preferred behavior is an A record to be (retrieved and) translated to a AAAA record by the DNS64 if and only if no reachable AAAA record exists

kerem commented

2026-03-15 22:05:56 +03:00

Author

Owner

@briansmith commented on GitHub (Jan 2, 2018):

It may be useful to add some knobs to this to control the behavior w.r.t. DNSSEC:

Add an option to disable A -> AAAA conversion for DNSSEC-signed A records, since the AAAA records are forged. This would prevent DNSSEC-enforcing applications from breaking.
Add an option to require DNSSEC-secured A records and/or secured proof of a lack of AAAA records for translation to happen.
Add an option to sign synthesized AAAA records using a given key that chains to a provided root. Then a DNSSEC-enforcing application can trust the additional root to keep DNSSEC working.

#2 and #3 are complementary. I would suggest splitting out this kind of DNSSEC-stuff into a separate issue; I'm recording it here just to draw attention to the issue.

@briansmith commented on GitHub (Jan 2, 2018): It may be useful to add some knobs to this to control the behavior w.r.t. DNSSEC: 1. Add an option to disable A -> AAAA conversion for DNSSEC-signed A records, since the AAAA records are forged. This would prevent DNSSEC-enforcing applications from breaking. 2. Add an option to require DNSSEC-secured A records and/or secured proof of a lack of AAAA records for translation to happen. 3. Add an option to sign synthesized AAAA records using a given key that chains to a provided root. Then a DNSSEC-enforcing application can trust the additional root to keep DNSSEC working. #2 and #3 are complementary. I would suggest splitting out this kind of DNSSEC-stuff into a separate issue; I'm recording it here just to draw attention to the issue.

kerem referenced this issue

2026-03-15 22:33:45 +03:00

[GH-ISSUE #347] Do not resolve publically-routable DNS names to private/loopback IP addresses #454

kerem referenced this issue

2026-03-16 01:26:15 +03:00

[GH-ISSUE #2725] Tracking issue for Let's Encrypt deployment requirements #1051

kerem referenced this issue

2026-03-16 02:03:30 +03:00

[PR #354] [CLOSED] (waiting) filter returned IPs by network scope #1385

kerem referenced this issue

2026-03-16 11:59:08 +03:00

[PR #3298] [MERGED] Do not resolve private/reserved addresses on public zones #3720