Never use 8.8.8.8 or 1.1.1.1

Hello
I see numerous places where dns servers are hardcoded into hestia. Would there be an issue to set all of them to 127.0.0.1 as recursion is enabled on the localhost ?

What is the hestia method to remove all these external resolvers ? thanks

This does have some obvious false hits but there are several hardcoded resolvers

rooot@heestiaaaa:~/hestia# grep -rl  8.8.8.8
php/sbin/php-fpm
php/sbin/hestia-php
php/include/php/ext/standard/basic_functions_arginfo.h
php/include/php/ext/standard/php_math.h
php/bin/php-cgi
php/bin/php
php/bin/phpdbg
bin/v-add-dns-on-web-alias
web/webfonts/fa-brands-400.ttf
web/fm/dist/img/fa-solid-900.svg
web/fm/dist/favicon.ico
web/images/logo.svg
nginx/conf/nginx.conf
nginx/sbin/hestia-nginx
install/hst-install-ubuntu.sh
install/rpm/nginx/nginx.conf
install/deb/nginx/nginx.conf
install/hst-install-debian.sh
install/upgrade/versions/1.8.0.sh

We use it often as the default resolver and it supposed to be changed if we detected correct avaiblity of any other resolvers …

Are from source code created by php

web/webfonts/fa-brands-400.ttf
web/fm/dist/img/fa-solid-900.svg
web/fm/dist/favicon.ico
web/images/logo.svg

Are font’s / logos Ik I am sure the make 0 connections to 8.8.8.8

bin/v-add-dns-on-web-alias

Only contains an comment:

I agree this should be 1.2.3.4 instead of 8.8.8.8

In /etc/nginx/nginx.conf we use 8.8.8.8 as default resolver but it it has been configured correctly it should be replaced with the local resolvers…

In hestiacp/func/syshealth.sh at 5feca851075c90d107ef68cc9edc7650ef8f3f1f · hestiacp/hestiacp · GitHub

We also ajust the default resolver in for “nginx” used for Hestia…

thanks for the reply.
Was pretty sure the graphic files didnt do anything but wasnt sure if resolvers had been added to the php code

So I take it that /etc/resolv.conf is only read, never written, and these 2 files mentioned below are the only places hestia defines resolvers, and that if I manually edit these 2 files nothing from within hestia will change them ?

8.8.8.8 was in/etc/resolv.conf when I installed hestia. Makes sense

This was the one that got my attention. In the current release of Hestia this code is in /etc/init.d/hestia but appeared to be commented out. Now that is has moved to syshealth.sh should it be labeled as a function ?

What would you think about adding a v-update-sys-resolvers that utilizes a version of the function in syshealth and updates /etc/nginx/nginx.conf and $HESTIA/nginx/conf/nginx.conf with one of these choices 1./etc/resolv.conf, 2. hestia defaults, or 3.custom resolvers ? Maybe it is just simpler to manually edit these 2 files.

Thanks for all the info

We have changed parts in the new 1.9.0 it might not have been released yet

At least I can’t see it in here

1 Like

yea it is in main. My points were that should it be labeled a function , and it could be used to allow users to use a v-file to update all the resolvers that hestia has set.

But I believe you have answered my main questions : Where are all the places hestia sets a resolver and if I manually update them will they be safe from updates and refreshes of hestia

It is part of th update script that runs after the package has been updated

I have
resolver 8.8.8.8 8.8.4.4 valid=300s ipv6=off;
resolver_timeout 10s;

in nginx.conf

So, to sum up, what should be the ideal setting? because I got lost :grinning::grinning:

The one you are using is fine. I would replace one of the resolvers by another one so they don’t belong to the same provider but there is nothing wrong with that conf… maybe I would lower the timeout to 3 or 5 seconds.

1 Like

resolver 1.1.1.1 1.0.0.1 8.8.8.8 8.8.4.4 valid=300s ipv6=off;
resolver_timeout 3s;

1 Like

Yes to clarify ,if you use 8.8.8.8 or 1.1.1.1.1 ( google or cloudflare), or their related ip addresses, will work fine as dns resolvers. It is a personal choice not to use them and they are simple to avoid.

So if I understand it correctly:
that file controls how the nginx proxy and possible web server handles dns. Hestia web interface uses a different file and possible configuration. Apache , if installed, and the rest of the server would use the values in /etc/resolv.conf . My goal was to sync them all and to permanently set them to my preference.

I had not used Nginx before and am not accustomed to dns resolving being set in so many separate places. I appreciate all the help

1 Like

Yes, resolver directive tells to Nginx what are the resolvers to be used to resolve domain names. Nginx uses this instead of OS resolver, because OS resolver is not asynchronous and it could block all Nginx connections while a resolver call is used.

Yes, indeed it’s another Nginx instance completely independent.

Yes.

Just a tip for you @Devdoit.pl and @jperkins , if you use Exim and Spamhaus as a block list (by default it is enabled) you should not use neither Google nor Cloudflare public dns resolvers (there a few public resolvers out there that won’t work too). If you use Google’s resolvers (8.8.8.8 and/or 8.8.4.4), al request to Spamhaus will be ignored so you never will block spammers. If you use Cloudflare’s resolvers (1.1.1.1 and/or 1.0.0.1) ALL incoming mails will be blocked.

You could use any of these public resolvers if you create a Free Data Query Service Account. More info here.

I created a script to check if your dns resolver will work with Spamhaus.

To check the default primary name server in your OS:

curl -fsSL https://7j.gg/chksph2 | bash -s --

To check an specific name server:

curl -fsSL https://7j.gg/chksph2 | bash -s -- 1.1.1.1
3 Likes

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