FABRIC Nat64 solution obviates the need for custom DNS in IPv6 sites

[Ilya Baldin]

Dear experimenters,

We are happy to announce the deployment FABRIC’s own native Nat64 solution which obviates the need to create custom DNS configurations on IPv6 sites as e.g. shown in this notebook.

Now all VMs started on all sites regardless of their addressing scheme will have a correct DNS configuration that allows them to resolve IPv4 and IPv6 sites and also take advantage of FABRIC-deployed Nat64 gateway to reach IPv4-only websites from IPv6 FABRIC sites.

If you have slices you already created and you want to take advantage of this new capability, please update your /etc/resolv.conf to have the following servers:

nameserver 0.0.0.0 nameserver 2600:2701:5000:a902::5 nameserver 2600:2701:5000:a902::6

Note: the above is not recommended as DNS setups vary from site to site. For all new slices reachability of IPv4 sites like github.com from IPv6 FABRIC sites should ‘just work’.

• This topic was modified 8 months, 1 week ago by Ilya Baldin.

[yoursunny]

I found an unintended consequence of enabling NAT64:

1. I sometimes want multiple slices to communicate with each other, while each slice can be re-deployed independently.
2. To do so, I’m using FABNetv4 network service, paired with an external domain name that supports dynamic updates.
3. When a “server” slice is re-deployed, it updates the domain name to point to its new FABNetv4 IP address.
4. Previously, this works well: the “client” slice can find the “server” slice by resolving the domain name.
5. Since NAT64 is deployed, the “client” slice would resolve both A and AAAA records on the domain name.
6. If the “client” software tries to connect to the IPv6 address in the AAAA records, it cannot reach the FABNetv4 destination.

My suggestion is to configure the DNS64 server so that it does not return AAAA records if the domain name resolves to an IPv4 address that is part of FABNetv4 or other RFC1918 address.

[Ilya Baldin]

Thank you for the suggestion. Let us look into it.

[Hussam Nasir]

Please try your test again and let us know if this works. We have applied a fix to the FABRIC DNS servers so that it no longer provides AAAA records  for FABNETv4 addresses and RFC 1918 addresses

1 user thanked author for this post.

yoursunny

[yoursunny]

I’m seeing “Unable to establish SSL connection” error when trying to download from GitHub releases:

ubuntu@N0:~$ wget --timeout=10s -v https://github.com/TomWright/dasel/releases/download/v2.3.4/dasel_linux_amd64
--2023-09-06 17:24:18-- https://github.com/TomWright/dasel/releases/download/v2.3.4/dasel_linux_amd64
Resolving github.com (github.com)... 2600:2701:5000:5001::8c52:7104, 140.82.113.4
Connecting to github.com (github.com)|2600:2701:5000:5001::8c52:7104|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/297615696/dfe35302-5ee7-42cf-939d-345b67a2091d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230906%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230906T172418Z&X-Amz-Expires=300&X-Amz-Signature=cdb822adb0af2026b86b8fae886e28358b27bb48551182c5ee95e03a946b4353&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=297615696&response-content-disposition=attachment%3B%20filename%3Ddasel_linux_amd64&response-content-type=application%2Foctet-stream [following]
--2023-09-06 17:24:18-- https://objects.githubusercontent.com/github-production-release-asset-2e65be/297615696/dfe35302-5ee7-42cf-939d-345b67a2091d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230906%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230906T172418Z&X-Amz-Expires=300&X-Amz-Signature=cdb822adb0af2026b86b8fae886e28358b27bb48551182c5ee95e03a946b4353&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=297615696&response-content-disposition=attachment%3B%20filename%3Ddasel_linux_amd64&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 2600:2701:5000:5001::b9c7:6d85, 2600:2701:5000:5001::b9c7:6e85, 2600:2701:5000:5001::b9c7:6c85, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|2600:2701:5000:5001::b9c7:6d85|:443... connected.
Unable to establish SSL connection.

Is the NAT64 gateway being blocked by GitHub releases download server?

tcpdump of the transaction: https://cdn1.frocdn.ch/JTeh94VJIxkXv6P.pcap

• This reply was modified 7 months, 4 weeks ago by yoursunny.

[Hussam Nasir]

We are seeing issues related to the site objects.githubusercontent.com when used with FABRIC NAT64. For now a workaround that is being used for this is to add

2a01:4f9:c010:3f02:64:0:b9c7:6e85 objects.githubusercontent.com

in your /etc/hosts file. This line forces this one site to route through one of the nat64 servers offered by the NAT64.net site while using FABRIC NAT64 for all others.

[yoursunny]

Instead of having users add hosts entry (which would require changes in every level including inside containers), can the DNS64 server be configured to return this IP?

• This reply was modified 7 months, 4 weeks ago by yoursunny.

[Hussam Nasir]

Unfortunately not at this moment since it’s a policy decision affecting the whole Testbed.  If you are unable to use this workaround, I would suggest using nat64.net since that seems to work fine.

Based on the decision taken by the FABRIC Dev and Security team, we have deployed a temporary fix for this issue. The fix should be transparent and work for the site you mentioned without any workarounds on your part. Please let us know if you still have issues.

• This reply was modified 7 months, 3 weeks ago by Hussam Nasir.

[Author]

Posts