Topic: Strange DNS issue - can't find some sites

[michelandre]

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é

[guest22]

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.

[michelandre]

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

Code: [Select]

nameserver { "$LocalIP" }
and insert in: /etc/e-smith/templates-custom/etc/resolv.conf/25nameserver

Code: [Select]

nameserver 8.8.8.8
Is that the right way to do the custom-template for that file?
or:

Code: [Select]

nameserver {8.8.8.8}or

Code: [Select]

nameserver { "8.8.8.8" }or something else?

Michel-André

[Stefano]

Please, don't, you don't need it and you'll likely break something

[michelandre]

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.

Code: [Select]

# /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.

Code: [Select]

# 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é

[Daniel B.]

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.

[Stefano]

About the dnsbl issues, read my comment
https://forums.contribs.org/index.php/topic,53236.msg275865.html#msg275865

[michelandre]

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é

[Daniel B.]

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

[michelandre]

- 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é

[guest22]

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.

[michelandre]

Hi RequestedDeletion,

Thanks again for your fast response.

The remote server is in production but not so critical.

Michel-André

[Daniel B.]

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

[Stefano]

I agree, but it would be nice if our users help US at least with testa

[Daniel B.]

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)