lix-project/lix

Fork 57

Pasta address family detection relies on /etc/resolv.conf's address families #1014

New issue

Closed

opened 2025-10-13 18:47:27 +00:00 by raito · 3 comments

raito commented

2025-10-13 18:47:27 +00:00

Owner

Describe the bug

Our pasta address family detection relies on /etc/resolv.conf's address families.

So if you are running an IPv4-only resolver on an IPv6-only WAN system, you will run into troubles (and vice versa).

Workarounds exist to fix that, but are fragile and makes things more complicated for an end user to debug.

Steps To Reproduce

Use systemd-resolved vanilla, e.g. 127.0.0.53
Use Pasta with Lix.
Try to build a FOD that does connect to Internet with a DNS resolution.
See DNS resolution error.

Expected behavior

Success.

`nix --version` output

Since pasta is enabled.

Additional context

Discovered in AFNix infrastructure and workarounded in https://git.afnix.fr/afnix/infra/src/branch/main/services/resolver/default.nix#L38-L41.

## Describe the bug Our pasta address family detection relies on `/etc/resolv.conf`'s address families. So if you are running an IPv4-only resolver on an IPv6-only WAN system, you will run into troubles (and vice versa). Workarounds exist to fix that, but are fragile and makes things more complicated for an end user to debug. ## Steps To Reproduce 1. Use systemd-resolved vanilla, e.g. `127.0.0.53` 2. Use Pasta with Lix. 3. Try to build a FOD that does connect to Internet with a DNS resolution. 4. See DNS resolution error. ## Expected behavior Success. ## `nix --version` output Since pasta is enabled. ## Additional context Discovered in AFNix infrastructure and workarounded in https://git.afnix.fr/afnix/infra/src/branch/main/services/resolver/default.nix#L38-L41.

raito added the

labels

2025-10-13 18:47:27 +00:00

raito self-assigned this

2025-10-21 21:40:49 +00:00

raito commented

2025-10-24 00:14:31 +00:00

Author

Owner

Proposal:

AF detection logic should act this way:

If the IPv4 routing table is non-empty AND there's a source IP, IPv4 is supported
If the IPv6 routing table is non-empty AND there's a source IP, IPv6 is supported

Additionally to this logic, if the existing DNS resolvers uses an AF that is unsupported, add the support for this new AF as well.

As a conclusion:

DNS queries to 127.0.0.1:53 will always lead to an IPv4 stack even if the system is IPv6-only
An IPv6-only system will always lead to an IPv6 stack enabled in Pasta even if the DNS resolution is IPv4-only

This solves the AF detection problems. I will add more "unit testing" to the rewrite logic as well.

**Proposal:** AF detection logic should act this way: - If the IPv4 routing table is non-empty AND there's a source IP, IPv4 is supported - If the IPv6 routing table is non-empty AND there's a source IP, IPv6 is supported Additionally to this logic, if the existing DNS resolvers uses an AF that is unsupported, add the support for this new AF as well. As a conclusion: - DNS queries to 127.0.0.1:53 will always lead to an IPv4 stack even if the system is IPv6-only - An IPv6-only system will always lead to an IPv6 stack enabled in Pasta even if the DNS resolution is IPv4-only This solves the AF detection problems. I will add more "unit testing" to the rewrite logic as well.

pennae commented

2025-10-28 22:21:02 +00:00

Owner

we don't actually do any AF detection here, that part is done by pasta (which doesn't configure addresses/routes we ask it to if that would blackhole traffic). this leads to no v4 route being available on v6-only systems with resolved, not anything we do. what we can influence though is the namerserver list we provide: since pasta will forward dns queries to all nameserver we'd configure exactly the same way we should just configure both v4 and v6 nameservers in the sandbox at all times. worst case one of them can't be used because there's no route available to reach it.

we don't actually do any AF detection here, that part is done by pasta (which doesn't configure addresses/routes we ask it to if that would blackhole traffic). this leads to no v4 route being available on v6-only systems with resolved, not anything we do. what we *can* influence though is the namerserver list we provide: since pasta will forward dns queries to all nameserver we'd configure exactly the same way we should just configure both v4 and v6 nameservers in the sandbox at all times. worst case one of them can't be used because there's no route available to reach it.

lix-bot commented

2025-10-29 21:47:27 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/4501 ("doc/manual: provide more information about Pasta and its shortcomings")
commit message in cl/4500 ("libstore/linux/pasta: always list an IPv4 & IPv6 nameserver")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/4501](https://gerrit.lix.systems/c/lix/+/4501) ("doc/manual: provide more information about Pasta and its shortcomings") * commit message in [cl/4500](https://gerrit.lix.systems/c/lix/+/4500) ("libstore/linux/pasta: always list an IPv4 & IPv6 nameserver")