This thread is closed as LE works both on IPV4 and IPV6. The reason I opened the thread was because I had some routing issues with IPv6. In my understanding I was serving IPv6 as some IPv6 validation sites showed that it was ok. However the router (one that is not all that easy to configure) was blocking icmp packages for extra security reasons. So, LE was trying to validate the domain but failed. I must say that some bad things end up to be good because I went back and fixed the issues that was wrong that otherwise I probably would never find out that was wrong.
At first instance one would just turn-off IPv6 or start to blame somebody else. I did that, I was wrong and I admit that! Then I decide to take the challenge to fix the IPv6 routing by going back and fixing the issues. Now, things are working. Thanks everyone that participate on this thread.
E\
So, just to summarizing;
The problem was not DNS mis-configuration but a router firewall configuration
Both of the test sites that you used are testing whether you can browse the web with IPv6 connectivity, not whether a particular server has IPv6 connectivity. By running curl -6 http://domain.org/ on a machine with IPv6 connectivity, I can see that domain.org itself does not have IPv6 connectivity working properly. (Testing in a browser is not quite a strict enough test because the browser is usually willing to fall back to IPv4 if an IPv6 connection fails, which our CA is not willing to do.)
A tester you could use that will confirm the problem is
You have to put in the domain name. You'll see that the AAAA DNS record is provided but that connections to your server fail over IPv6.
This is probably why your renewal stopped working; some weeks ago, the Let's Encrypt CA was updated to prefer IPv6 over IPv4 for domain control checks, while before that, the behavior was the opposite.
I moved this post and its replies to a new thread since the topic isn't directly related to the previous thread and there is some confusion to clear up that shouldn't clutter the original thread. Thanks!
I can see how you arrived at this conclusion but it's not quite true! As @DanCvrcek mentions pure IPv4 will work as it always has.
Knowing that some user's domains claim IPv6 support with an AAAA record but have some kind of misconfiguration/problem, we intended for the Let's Encrypt service to try IPv6 first, and if it didn't work, try IPv4 after. As you've noticed, this doesn't work in all cases right now and we have documented that in a Boulder issue to try and fix it. We appreciate your patience in the meantime!
If you do not want Let's Encrypt to ever use IPv6 to contact your domain the power is in your hands! You can remove the AAAA record from your DNS Zone for that domain name.
Hope that helps clear things up, I apologize for the trouble you've had as a result of our API change.
Your information is very helpful. I configured IPv6 with the desired to move up since IPv6 is the new way to re-distribute connection to devices and servers. My DNS is configured to work without errors, so also my home network. I can reach the ipv6 from my Browser inside my network but is not resolving to the www. I am looking into some alternatives and if that does not work, I will have no alternative but to turn off IPV6 on my server.
I just want to report back here that after I turned off the ( ipv6) + removed the records from DNS, the Letsencrypt renew was successfully done on the IPv4 protocol.
Sorry if I arrived to the wrong conclusion that IPv6 was now the preferred protocol of LE. When I started the thread I had no idea why Certbot was giving me errors on renew.
Maybe Certbot in the future could look into a configuration and if finds that IPv6 is not working properly, fall back to IPv4 and renew the Certs leaving just a warning in the logs that the client IPv6 is not resolving to outside www.domains.
Just wanted to note that I have a fix pending that will resolve the IPv6 to IPv4 fallback for HTTP-01 challenges: https://github.com/letsencrypt/boulder/pull/2852 I hope that this will be finished & deployed to production in the next few weeks.
I'm glad to hear that disabling the AT&T IPv6 was sufficient to renew in the short term.
UPDATE: I had to adjust the firewall again because last night the server was hit by a package flood from ns-netbios port udp 137 and other internet bad info packages. IPv6 for now still need to be filtered until we can find the best tune to provide the connection without let the storm in. I am experimenting with a tunnel, let see if ipv6 can work better that way.
Have a great day!
E\
Thanks Daniel @cpu ! Actually, that end up to be a good headache because I went around trying to find the issue and come up with a new configuration and now my network is 15% faster. In addition to that, I scored 19/20 in the http://ipv6-test.com/ test site and the real problem ended up to be all along the ATT router firewall reflexive package (packet) flood. Those simple things we forget to test. (I probably need to go back and delete some stuff I said about ATT that was unfair). Their network does not score the 20/20 but I am always pushing to do better. The reason I got the network faster is that I am using the OpenDNS server and Google. Thanks for getting back to me!
Yes, you’re right! The technical IT term is (packet) and that was my own typo extended mistake. Probably I was thinking too much what time USPS would arrive with the packages. Thanks for pointing that out Seth! @schoen
