Prefer IPv4 for validation when ACME client requests are IPv4

Feature Requests
1

Hi @cpu

I have a suggestion: if the client requests are from ipv4 network, the server prefers ipv4 first, then try ipv6. And if the requests are from ipv6 network, the server should try ipv6 first, then try ipv4.

It that something you guys ever thought about ?

Thanks.

2

Hi @Neilpang,

I split this post into its own thread since its a separate feature request and not directly tied to the troubleshooting in the other ticket. Thanks!

That's an interesting idea but I think the primary flaw is that it conflates the network the ACME client is on and the network the server being contacted for validation is on. They aren't necessarily the same.

It also strikes me as something fairly non-standard, do you know of any other implementations of this idea? The method we use today is closer to the "happy eyeballs" methodology that is common across this space and I suspect easier to explain to folks than an approach based on the address family of the ACME client request.

3

Hi @cpu

Would a DIG of the domain for both A and AAA records then choosing based on responsiveness be an option how does the current logic work??

Something like?

IF (AAAA RECORD) {
USE IT
}

ELSE {
USE IPV4
}

I think a preflight check might be an option as well on the client side rather than using boulder

How much extra load would trying both IPs create?

Andrei

4

Hi @cpu

Also what is the rationale of this Preferring IPv6 for challenge validation of dual-homed hosts

I am curious why IPV6 addresses are preferred as from my experience most customers are still on IPV4 public IPs

Andrei

1 Like
5

IPv6 addresses are preferred when both are advertised. If customers are on IPv4 public IPs why do they have an AAAA IPv6 record?

6

i am confused about that as well.

Could it be a default DNS provider thing?

Or it could it be that they have an IPV6 record but forget to configure the Web Server to listen for it

Andrei

7

Hi @cpu

Sorry, for the late reply.

I don’t see any other implementations. That’s just my thoughts.

When a user is requesting from ipv4 network, probably he prefers ipv4 than ipv6, although there are both A record and AAAA record on his domain.

It also might be possible that his ipv6 address is not (good) route-able to the letsencryptCA’s ipv6 network. That’s why he prefers ipv4 to connect to letsencrypt CA server.

Anyway, I think there might be something the CA server can do here.

8

Less special behaviour > more special behaviour.

There is no inherent reason why an IPv4 client should cause an IPv4 connection from the server. If you don’t want IPv6, don’t advertise it in your DNS records. It’s as simple as that. If your IPv6 connection is flaky, fix the problem instead of creating more and more workarounds.

3 Likes
9

Or it could it be that they have an IPV6 record but forget to configure the Web Server to listen for it

That's what I hit the other day. It would have been nice if the LE server had fallen back to IPv4 when IPv6 didn't work.

10

It's supposed to fall back to IPv4 in some circumstances, but apparently there is a bug. (I don't know if it's supposed to cover your circumstances.)

1 Like
11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.