https://bugs.contribs.org/show_bug.cgi?id=10300
--- Comment #64 from Jean-Philippe Pialasse <[email protected]> ---
(In reply to Dave Liquorice from comment #63)
> (In reply to Jean-Philippe Pialasse from comment #59)
> > but i will dig more
>
> Ha Ha, "dig" more. B-)
thank for catching this one !
just build a new one only for SME9 so you will be able to test.
/usr/bin/plague-client build djbdns djbdns-1_05-11_el6_sme sme9
Package djbdns enqueued. Job ID: 1736.
%changelog
* Wed Jul 19 2017 Jean-Philipe Pialasse <[email protected]> 1.05-11.sme
- improve short ttl cname resolution and glueless answer from akadns [SME:
8362]
- 500-cutom-dnscache-maxloop.patch: set QUERY_MAXLEVEL 5 QUERY_MAXLOOP 500
QUERY_MAXNS 16
How I test :
3 terminals
one with
tail -f /var/log/dnscache.forwarder/current|tai64nlocal
one with :
tail -f /var/log/dnscache/current|tai64nlocal
the third
yum update djbdns --enablerepo=smeupdates-testing,smetest
sv t dnscache.forwarder; sv t dnscache
curl https://acme-v01.api.letsencrypt.org/directory
with this you should see a lot of lines in first terminal, and it should
resolve at first try
you can repeat the two last lines ad nauseam (or ad libido, your choice). wait
only few seconds between the two lines.
sv t dnscache.forwarder; sv t dnscache
curl https://acme-v01.api.letsencrypt.org/directory
(In reply to Michael Doerner from comment #62)
> (In reply to John Crisp from comment #60)
>
> > [root@test ~]# 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)
>
> I just could replicate this issue on a server (SME9.2) where we were using
> the ISP's default DNS.
in this case you do not resolve yourself, so you are not using
dnscache.forwarder. And probably your ISP is having the same djbdns on their
servers ;)
> That ISP's DNS has caused us trouble before and we should avoid using this
> so I set Google's DNS servers to be used via the server manager - and
> straight after that, there was no such Curl problem any longer and the
> process worked here immediately.
the issue with Google's DNS is that they tends to not be so localized, and as
you are fare away of the USA, you might see a lot of websites to be reallly
realllllllllllly slow, when you could have a more close server to serve you the
page .... but I get out of the topic
--
You are receiving this mail because:
You are the QA Contact for the bug.
_______________________________________________
Mail for each SME Contribs bug report
To unsubscribe, e-mail [email protected]
Searchable archive at https://lists.contribs.org/mailman/public/contribteam/
