Koozali.org: home of the SME Server
Obsolete Releases => SME Server 9.x => Topic started by: Randall on July 22, 2017, 09:04:44 PM
-
Recently I've notices a strange issue resolving some URLs (SME is running in server-only mode). I've found that I can't access some prominent URLs, such as www.paypal.com or access.redhat.com, although I can access paypal.com and redhat.com. These used to work, and then stopped for inexplicable reason (possibly due to updates - notice bind and djbdns have been updated).
If I disable SME's DHCP and use my router's, I do have access to these sites, though I can't access those I've set up in SME's local hostnames definitions. djbdns looks to be fairly complex. Does anyone have any suggestions as to where to start looking?
Thanks
-
I think this might be relevant:
https://bugs.contribs.org/show_bug.cgi?id=8362
-
I would agree with Brian.
For SME Server 9.2 it would be https://bugs.contribs.org/show_bug.cgi?id=10381
-
Thanks much for the replies.
This does sound relevant, but this is the version I'm currently using (djbdns-1.05-10.el6.sme.x86_64 in currently installed). Ironically, I suspect (but am not sure) that upgrade to this version (from 1.05-8) may have been when this started occurring.
I upgraded from 8.2 about 3 weeks ago (June 30) - prior to that have never had any issue whatsoever (in probably 15 years of using SME). A week later, after updates I did start experiencing issues with backup, though (unrelated - filed bug 10390). I think dns was working ok after fresh install (prior to updates), but access to this site is not that frequent, so maybe just didn't notice.
Thanks
-Randall
-
your testing results would be appreciated, especially since we are in the middle of things to find out what is going on.
-
Sure. Just let me know what info I can provide.
-R
-
Thanks, please submit all your 'strange' findings to the relevant bug, and any methods you try to 'get it right'. The devs are on top of those bugs, but less active on the forums.
-
Will do. Thought I'd try here first, but will open a bug for it.
-R
-
Hi RequestedDeletion,
A friend of mine in France has the same problem with Let's Encrypt as: https://bugs.contribs.org/show_bug.cgi?id=10381.
After an update, Let's Encrypt stopped working: "ERROR: Problem connecting to server (get for http://cert.int-x3.letsencrypt.org/; curl returned with 6)".
- The server was using /etc/letsencrypt... I installed the new one which uses /etc/dehydrated. Not working.
- I brought back to SME certificate.
- I installed the Let's Encrypt contrib and still not working.
- For a test, I changed the IP nameserver in /etc/resolve.conf to 84.200.69.80. (Of course, I will loose this with a reboot). Let's Encrypt started working correctly.
Bug 10381 says "RESOLVED FIXED" but I do not get how to fix it.
Any help appreciated,
Michel-André
-
As per suggestion of Michael, I have set the SME Server DNS settings (Configure this server) to Google's DNS being 8.8.8.8
After that it worked for me.
HTH
-
Be aware that doing so you'd have big issues with dnsbl part (search the forums, I already pointed out it)
-
So is it safe to say that something is broken?
-
sorry, my memory is broken
read here: https://forums.contribs.org/index.php/topic,52003.msg265759.html#msg265759
-
Hi all,
As I wrote before, I removed the Let's Encrypt contrib.
While reading a lot of bug related subjects about that problem, I found:
At: https://forums.contribs.org/index.php/topic,53044.0/all.html
« Reply #29 on: May 14, 2017, 10:01:41 AM » by RequestedDeletion
Please make sure you remove everything. Uninstalling the contrib does not remove e.g. db config info e.g. 'config show letsencrypt'
I went back to https://wiki.contribs.org/Letsencrypt to see how to uninstall this contrib. I found nothing about uninstallation contrary to other contribs. I hope it is my error that I did not see the uninstallation lines.
QUESTION:
How do i get rid of:
letsencrypt=service
ACCEPT_TERMS=yes
configure=none
email=toto@toto.com
hookScript=disabled
status=test
Thank you all,
Michel-André
PS: Special thanks to:
Dan Brown, RequestedDeletion, John Crisp, Stefan Schulz, Jean-Philippe Pialasse, Michael Doerner, Dave Liquorice, and other people...
for their works trying to resolve that problem.
-
config delete letsencrypt
-
Hi RequestedDeletion,
Thanks a lot for your fast response.
You wrote before that you "set the SME Server DNS settings (Configure this server) to Google's DNS being 8.8.8.8"
I tried that after reading your post but, in /etc/resolv.conf, there is still the local IP of the server. Is that normal?
Michel-André
-
I really wouldn't know. Gordon Rowell made this part of SME Server and I guess either Daniel or JPP would be able to shed some light on this. Sorry.
-
Hi RequestedDeletion,
Thanks again for your fast response.
I am thinking about making a custom-template to replace: /etc/e-smith/templates/etc/resolv.conf/25nameserver
nameserver { "$LocalIP" }
and insert in: /etc/e-smith/templates-custom/etc/resolv.conf/25nameserver
nameserver 8.8.8.8
Is that the right way to do the custom-template for that file?
or:
nameserver {8.8.8.8}or
nameserver { "8.8.8.8" }or something else?
Michel-André
-
Please, don't, you don't need it and you'll likely break something
-
Hi all,
The server is remote so I have to be carefull.
The correct syntax is: nameserver = 8.8.8.8 and it did not work.
I followed Stefano's advice and I deleted the custom template and reboot.
# /etc/dehydrated/dehydrated -c
# INFO: Using main config file /etc/dehydrated/config
ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)
#
This is the problem in bug 10300: https://bugs.contribs.org/show_bug.cgi?format=multiple&id=10300
John Crisp 2017-07-18 18:27:02 CEST // Comment 60
- I checked my friend's server.
# rpm -qa | grep djbdns
djbdns-1.05-10.el6.sme.x86_64
#
- Then I did like RequestedDeletion "I have set the SME Server DNS settings (Configure this server) to Google's DNS being 8.8.8.8"
/etc/dehydrated/dehydrated -c was working.
- I tried 84.200.69.80
/etc/dehydrated/dehydrated -c was working.
I leave 84.200.69.80 for the DNS because I saw somewhere that if far from US, 8.8.8.8 might not work and since 84.200.69.80 is working I prefer to use it.
- I was happy to solve the problem. If the the server is rebooted, Let's Encrypt will always work now.
- I send an email to my friend to say that the problem for DNS/reboot was solved.
* Email rejected.
Connected to "friend ip" but sender was rejected.
Remote host said: 550 Mail from HELO "my domain" rejected because it 127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 84.200.69.80]
- I checked the email address and it was correct.
- I change to google 8.8.8.8 // reboot
* Email rejected.
Connected to "friend ip" but sender was rejected.
Remote host said: 550 Mail from HELO "my domain" rejected because it 127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 74.125.47.2]
- I checked the email address and it was correct.
- I whois 74.125.47.2 and it was a Google IP.
- I took out the DNS from (Configure this server), reboot and Let's Encrypt did not work anymore, email was working.
- I tried 84.200.69.80 in /etc/resolv.conf and Let's Encrypt is working, email is working.
- I tried 8.8.8.8 in /etc/resolv.conf and Let's Encrypt is working, email is working.
PROBLEM:
If server is rebooted, Let's Encrypt will not work anymore.
Someone has any idea what I can try next?
Michel-André
-
This original topic is about problem resolving some DNS names. To explain a bit how this works: SME itself will always use 2 dnscache instances to resolve DNS names. That's why you'll always get the local IP of your SME Server in /etc/resolv.conf and you should not change this for different reasons.
Queries goes to a first dnscache instance (which is /service/dnscache). This first instance only acts as a forwarder, and a caching service. It'll forward queries for locally managed domains to tinydns, and everything else to the second DNS cache instance (/service/dnscache.forwarder). Now, this second dnscache instance is where external domain names are resolved. In the default config (which is what is recommended), this instance acts as a cache, and a recursive resolver, meaning it'll directly query the root servers, and all the chain up to the queried name. If you set a DNS server (or two DNS server), this instance still acts as a cache, but then only forward the query to the upstream server you've specified (it's now a simple forwarder, no a recusive resolver anymore).
You should now understand why you can have DNSBL issues when you set a public DNS server: all the queries to the DNSBL servers will be made by the DNS server you've set. Which a lot of other users are using too, and so, most of the time above the quota. While when you're acting as a recursive DNS resolver yourself, querries will be sent from your own IP, which only you are using, so unless you receive a huge amount of email, you won't hit the quota of those lists.
-
About the dnsbl issues, read my comment
https://forums.contribs.org/index.php/topic,53236.msg275865.html#msg275865 (https://forums.contribs.org/index.php/topic,53236.msg275865.html#msg275865)
-
Thanks Daniel B. I learned something new about SME DNS with your explanation.
If the DNS of the server is configured with the standard (original and nothing changed), I received the curl error 6.
ERROR: Problem connecting to server (get for https://acme-v01.api.letsencrypt.org/directory; curl returned with 6)
Accorfing to: https://ec.haxx.se/usingcurl-returns.html "Available exit codes":
6. Couldn't resolve host. The given remote host's address was not resolved. The address of the given server could not be resolved. Either the given host name is just wrong, or the DNS server is misbehaving and doesn't know about this name when it should or perhaps even the system you run curl on is misconfigured so that it doesn't find/use the correct DNS server.
So it seems like my friend's server is not able to resolve the Let's Encrypt address.
If Bug 10381 is resolved, it might resolve this issue too.
Michel-André
-
If the DNS of the server is configured with the standard (original and nothing changed), I received the curl error 6.
Let's Encrypt's servers are just one case of possible failure. Others are impacted too (like paypal)
If Bug 10381 is resolved, it might resolve this issue too.
There's a potential fix, but it has not been released yet, because it has not been verified. If you want to help, please subscribe to the bug, and test the proposed update
-
- According to bug 10381: https://bugs.contribs.org/show_bug.cgi?id=10381, there is a new version (11) for djbdns but it is in test mode.
- I tested this version (11) of djbdns on a virtual machine at my place and "/usr/bin/curl https://acme-v01.api.letsencrypt.org/directory" was OK.
* At my place, all the SME servers always respond correctly to this command.
* But, on the remote SME server, this command respond correcly only if I put a different IP ( 8.8.8.8 ) in /etc/resolv.conf.
- On the remote server (in production mode), I would like to put back the original local IP in /etc/resolve.conf, install, and test djbdns-1.05-11.el6.sme.x86_64. But, if something go wrong, I would like to go back to djbdns-1.05-8.el6.sme.x86_64.
- In case of problem with the new djbdns, will I still be able to communicate to the remote server using ssh?
- Also, in case of problem, how can I go back to the earlier version of djbdns?
Michel-André
-
I think we have a serious issue here and we can not ask our users to 'work around' things. Testing stuff is ok, but we need to acknowledge there is something wrong. This effects production servers and security.
-
Hi RequestedDeletion,
Thanks again for your fast response.
The remote server is in production but not so critical.
Michel-André
-
I think we have a serious issue here and we can not ask our users to 'work around' things. Testing stuff is ok, but we need to acknowledge there is something wrong. This effects production servers and security.
That's exactly why I came on this topic. Putting 8.8.8.8 as forwarder is a workaround. The problem is already acknowledge, there are bugs opened for this. And a proposed fixe. AFAIK, there's no security related issue with this, only a tiny number of DNS names not being able to resolve
-
I agree, but it would be nice if our users help US at least with testa :-)
-
In case of problem with the new djbdns, will I still be able to communicate to the remote server using ssh?
Yes, inbound SSH do not need working DNS
Also, in case of problem, how can I go back to the earlier version of djbdns?
A simple yum downgrade djbdns will do it.
Note that the risk is low. I'm running 1.05-11 on my own server without issue (but, as I cannot reproduce the original problem, I can't say if it's fixed or not)
-
Thanks Daniel B,
In the worse case, there is a backup for the remote server...
I will try version 11 and report soon.
Michel-André
-
Hi All,
Total victory.
Hissons la bannière de la victoire!
Finally, Let's Encrypt is working :-)
Again thanks to the gang of bug 10381.
Michel-André
PS: I had to keep the 8.8.8.8 in /etc/resolv.conf to be able to install the new version of djbdns.
-
Forgot to mention that after the "signal-event post-upgrade; signal-event reboot" the original local IP was back in /etc/resolv.conf.
Michel-André