When performing domain validation, will the Let’s Encrypt backend support querying servers over IPv6?
It should work as long as the DNS resolves.
Actually AFAIK as of launch we won’t be able to contact IPv6-only hosts, although hopefully this will be resolved quickly.
If you need help testing against IPv6 only hosts let me know as I do have a few myself.
Just tried an a VM that is only accessible from the Internet via IPv6 and it failed.
Failed authorization procedure. $HOST (dvsni): unknownHost :: The server could not resolve a domain name :: No IPv4 addresses found for $HOST
The following ‘unknownHost’ errors were reported by the server:
Error: The server could not resolve a domain name
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contains the right IP address.
Ironically the help text suggests to check the A/AAAA records.
It’s correct; IPv6 connectivity for validation is still roadmap functionality, though we all certainly want it!
I would like to add my support for IPv6-only tests. Please don’t make IPv6 a second class citizen!
Indeed. Quoting a recent Linux kernel commit.
"This patch makes the default to build IPv6 into the kernel. IPv6
now has significant traction and any remaining vestiges of IPv6
not being provided parity with IPv4 should be swept away. IPv6 is now
core to the Internet and kernel.
Points on IPv6 adoption: - Per Google statistics, IPv6 usage has reached 7% on the Internet and continues to exhibit an exponential growth rate https://www.google.com/intl/en/ipv6/statistics.html - Just a few days ago ARIN officially depleted its IPv4 pool - IPv6 only data centers are being successfully built (e.g. at Facebook)"
So it’s strange a new project would choose to neglect IPv6 support when supporting it from the start should require basically no effort these days.
Both the Boulder CA software and the Let’s Encrypt client fully support IPv6, and the majority (53%!) of traffic to the Let’s Encrypt APIs is IPv6.
The problem is the validation piece due not to software development but rather datacenter connectivity. I’ve heard that it’s been helpful to point the datacenter folks to all the discussion as a demonstration that IPv6 really is in demand.
(As a note, the selection criteria on the datacenter was driven far more by security requirements than IPv6 support. We figured we could encourage IPv6 adoption, as long as the security was top-notch.)
Another motivation is that a few VPS hosting providers have started to offer lower prices for instances with IPv6-only connectivity (ie, no IPv4 connectivity). When HTTP DCV, these servers won’t have options to get validated other than via IPv6.
To clarify: are you lacking v6 connectivity to the DC, or in the DC, or both? In any case, can you assert that folks are working on connectivity? It sounds like you’re saying they aren’t yet.
Is there anything the community can do in the interim to help? If 53% of traffic is IPv6 then I’d say getting IPv6 working for validation should be pretty high up, so some of us may be willing to help bridge the gap (accounting for security concerns etc) until the DC supports it.
We’re pushing on the appropriate organizations. Being high security environments, no one wants to be specific about how much of the delay is process control versus reconfiguring or replacing old hardware.
We’re looking at other options. One thing that has come up is to do an analysis of the security properties of doing validation through a 6to4 tunnel, or similar. I haven’t had time to do such a review personally, and I know the ops team has their hands full as well. Certainly we don’t want to add more opportunities for a MITM, but since DNS wouldn’t be through 6to4, in theory this may work, but someone has to write the analysis and get it peer reviewed before we can trust the Internet to it.
Happy to peer if/when you get to that point.
FWIW, IPv6 support is more than 7% now; it’s at 9% and growing exponentially. In certain countries, it’s over 35% (US has a bit over 20%). I wouldn’t recommend 6to4; you’re at the mercy of the return relay (and your own relay, but that’s easier to control), and due to the anycasted nature, a MITM is much, much easier than regular IPv4 or IPv6. It’s also pretty much dead these days, so connectivity is going to be spotty.
And yes, I also have a v6-only hostname that wants SSL
My DNS server will happily spit out an AAAA record for xyz789.blah to an IPv4 client. For validation, if the fact that the request is coming from the same IP as the authoritative and DNSSEC-signed NS for xyz789.blah is not sufficient, I’d love to be able to have LE run a simple SQL query (where I can easily give the executing user very specific permissions at the database level) to update a SRV or TXT record in the DNS instead of giving it root access to run an httpd just to verify a little string.
I signed up to add my support to this subject. The host of concern for me is IPv6-only by design, but I could/would happily conform to any alternative requirements for validation.
I’m happy to participate in any kind of testing or other form of assistance if it would be helpful at any stage; I’m watching this topic.
Are there any updates about IPv6 support ?
There are several IPv6-related issues in the GitHub repo, but for IPv6-only validation, you can probably watch this issue for updates.
As @gary pointed out, Boulder has some to-dos for IPv6 validation, but those are low priority since we’re still waiting on resolution from our datacenter folks for them to do their required changes and give us IPs.
Speaking from experience, we’re likely not going to get any status updates, just a sudden “here are your IP blocks” email.
I spoke to a few people at IETF 94 about IPv6 tunnel protocols (including @sds!) and got some mixed gut feelings about whether it would invalidate trust in validation or be (only) a risk increase. I think, without doing the legwork on an analysis, it’s too early to say. Based on that, and everyone being super-busy with the public launch, I believe the right answer is native IPv6 connectivity. Which means it won’t be there for GA, I’m afraid.
But I guess we already knew that since Boulder’s in a launch freeze.