[Feature Request] DNS64 Support

[TymanLS]

I would love to see support for DNS64 added to blocky. This feature, described in RFC 6147, would have blocky synthesize AAAA records for hosts where only A records are found, and thus allow IPv6-only hosts to resolve addresses for IPv4-only hosts and send traffic to them through a separate NAT64 gateway. Currently I am solving this problem by using upstream DNS providers that support DNS64, such as Cloudflare and Google DNS64 servers, but I would like to have more flexibility in my selection of upstream DNS providers and which DNS64/NAT64 prefix I can use; currently Cloudflare and Google only support the well-known DNS64 prefix (64:ff9b::/96), but it would be nice to have the option to select a different prefix if desired. Thank you!

[benbender]

Would also love to see this implemented as it would be a foundational building block of getting rid of legacy ip on many home networks!

[Bartosz-lab]

DNS64 support would be awesome

[p3lim]

I would love to see support for this as well, but I'd like to add that this should be configurable with group mappings, just like blocking and upstreams, because depending on how you access blocky you might not have NAT64 to support it.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[TymanLS]

I am still interested in this feature! I don't have much experience with Go, but let me know if there's any other information I can provide to help with this effort.

[0xERR0R]

@TymanLS This feature sounds interesting and can be implemented in blocky. I could start to implement it. Just for my understanding: DNS64 would be implemented in blocky, this is basically a translation layer which always returns AAAA record even if upstream DNS server returns only A. Where is the part with NAT64 gateway? Is it something you host in your local network or is it provided by your ISP?

My ISP (still) doesn't support ipv6, so I can't really test it

[TymanLS]

@0xERR0R Thank you for taking a look at this feature request!

Sorry about the confusion regarding the NAT64 gateway. The NAT64 gateway is a service hosted somewhere that translates between IPv6 and IPv4 addresses. DNS64 is not useful without a NAT64 gateway, but they are separate components; for blocky, we only need to worry about DNS64, not the NAT64 gateway.

For DNS64, I believe your understanding is correct. If a DNS query returns any AAAA records, then no action is required. However, if the DNS query only returns A records, then blocky will also return AAAA records that are calculated based on the DNS64 prefix and the A records.

For example, let's say we try to make a DNS request for an IPv4-only name like github.com. The reply contains no AAAA records:

$ nslookup github.com
Non-authoritative answer:
Name:   github.com
Address: 140.82.112.3

If we configure DNS64 using the well-known DNS64 prefix of 64:ff9b::/96, then the same DNS request will look like this:

$ nslookup github.com
Non-authoritative answer:
Name:   github.com
Address: 140.82.112.3
Name:   github.com
Address: 64:ff9b::8c52:7003

Let me know if there is any other information I can provide!

[0xERR0R]

@TymanLS Ok, I would start with the implementation. Would you volunteer to test the implementation if I provide a Docker image?

[TymanLS]

Yes, I can certainly help test the implementation, just let me know where/how to get the docker image once it is ready. Thank you!

[0xERR0R]

The image is tagged with "fb-dns64". I would greatly appreciate your feedback.

configuration:

dns64:
  enable: true
  # optional: DNS64 prefixes for IPv4-to-IPv6 address synthesis
  # Multiple prefixes allow for load balancing or redundancy across multiple
  # NAT64 gateways. DNS64 will synthesize one AAAA record per prefix per A record.
  #
  # Format: IPv6 prefix in CIDR notation
  # Valid prefix lengths (per RFC 6052): /32, /40, /48, /56, /64, /96
  # - /96 is most common (well-known prefix 64:ff9b::/96)
  # - Shorter prefixes (/32, /40, etc.) allow more flexibility in address assignment
  #
  # default: [64:ff9b::/96] (RFC 6052 well-known prefix)
  #
  # IMPORTANT: Prefixes must not overlap. Overlapping prefixes will be rejected.
  prefixes:
    - 64:ff9b::/96

[TymanLS]

Thank you, I have performed some very basic tests with the DNS64 feature using the spx01/blocky:fb-dns64 container from DockerHub, and so far it seems to work great! I have currently configured blocky to use Cloudflare's 1.1.1.1 and 2606:4700:4700::1111 as upstream resolvers. I am getting the following results as expected for some IPv4-only sites, including sites that return multiple A records:

$ nslookup github.com <blocky-ip>
Server:         <blocky-ip>
Address:        <blocky-ip>#53

Non-authoritative answer:
Name:   github.com
Address: 140.82.114.4
Name:   github.com
Address: 64:ff9b::8c52:7204

$ nslookup ipv4only.arpa <blocky-ip>
Server:         <blocky-ip>
Address:        <blocky-ip>#53

Non-authoritative answer:
Name:   ipv4only.arpa
Address: 192.0.0.171
Name:   ipv4only.arpa
Address: 192.0.0.170
Name:   ipv4only.arpa
Address: 64:ff9b::c000:aa
Name:   ipv4only.arpa
Address: 64:ff9b::c000:ab

Ad blocking appears to work as intended:

$ nslookup ads.google.com <blocky-ip>
Server:         <blocky-ip>
Address:        <blocky-ip>#53

Non-authoritative answer:
Name:   ads.google.com
Address: 0.0.0.0
Name:   ads.google.com
Address: ::

I also made sure to check some sites that support both IPv4 and IPv6 to make sure they do not synthesize records, and that seems to be working as well:

$ nslookup facebook.com <blocky-ip>
Server:         <blocky-ip>
Address:        <blocky-ip>#53

Non-authoritative answer:
Name:   facebook.com
Address: 31.13.70.36
Name:   facebook.com
Address: 2a03:2880:f10d:83:face:b00c:0:25de

However, I did notice a bug with the configuration file. When I set the enable key to false, the DNS64 feature is still enabled. I also tried to change the key to enabled, but that resulted in a config error. I know this is just for testing right now, but I wanted to make sure to mention that as well.

There are many more things I have not tested yet, such as the interaction with DNSSEC, how the DNS64 feature handles other record types such as PTR, and whether certain unusable IPv6 prefixes (such as ::ffff:0:0/96) can be excluded. These details are all described in RFC 6147, but I will need more time to get set up to test these more advanced features. So far though, it seems to work quite well for basic DNS64 use cases such as mine, and I'm very excited to see this feature come to blocky!

[0xERR0R]

Thanks for your feedback. I fixed the configuration bug and rebased on latest release (0.28.2). The image name remains, just pull it again. Let me know if you find something.

[0xERR0R]

Current implementation uses "Non-Validation mode" for DNSSEC. vDNS64 (validating mode) is optional part of RFC 6147, we can handle it on demand in a separate issue