Hostfile przestaje działać po dodaniu strony do Cloudflare

[michaldybczak]

Dziwna sprawa, ale po dodaniu wtyczki cache do strony i wrzuceniu domeny do CDN’a Cloudflare mam problem z przełączaniem na serwer produkcyjny, bo hostfile po prostu nie działa. Sprawdzałem na dwóch różnych komputerach w różnych sieciach – to samo.

Jeśli zostawię IP inny w hostfile i na następny dzień wejdę to wtedy strona otwiera się już z tego nowego IP, ale tak na bieżąco mogę sobie zmieniać i dalej ściąga z tego samego IP – innego niż na hostfile.

Wtyczka cache na wordpressie raczej nie powinna takich dziwów robić, więc pewnie Cloudflare jest winny, bo domena używa jego severa DNS i pewnie jakieś inne ustawienia cache DNS są i system pewnie je czyta zamiast hostfile, co jest i tak dziwne, bo hostfile powinno być ważniejsze.

Może jest jakaś komenda na czyszczenie cache DNSów? Na windowsie była taka metoda, ale na Linuxie nie było to chyba takie bezpośrednie z tego co pamiętam. Jakieś pomysły?

EDYCJA:

Po wyszukaniu w sieci, Arch domyślnie nie ma cache DNSów, ale w Manjaro wyczaiłem, że mam zainstalowany server DNS i DHCP:

dnsmasq

Czyli gdzieś tutaj muszę szukać odpowiedzi.

EDYCJA 2:

W /etc/dnsmasq.conf widzę takie linijki:

# Normally responses which come from /etc/hosts and the DHCP lease
# file have Time-To-Live set as zero, which conventionally means
# do not cache further. If you are happy to trade lower load on the
# server for potentially stale date, you can set a time-to-live (in
# seconds) here.
#local-ttl=

Czyli niby ok, DHCP lease Time-To-Live powinno być na zero domyślnie… Tylko czemu przed podłączeniem strony do Cloudflare hostfile działał a teraz nie skoro TTL powinno być zerowe i system powinien czytać hostfile i olewać server DNS Cloudlflare?
Dalej coś mi tu nie pasuje. Hmm… W man jest więcej, ale nie rozumiem wszystkiego, ale może ktoś mi pomoże wskazać właściwą opcję:

 --dhcp-ttl=<time>
              As  for  --local-ttl, but affects only replies with information from DHCP
              leases. If both are given, --dhcp-ttl applies for DHCP  information,  and
              --local-ttl  for  others.  Setting  this to zero eliminates the effect of
              --local-ttl for DHCP.

       --neg-ttl=<time>
              Negative replies from  upstream  servers  normally  contain  time-to-live
              information in SOA records which dnsmasq uses for caching. If the replies
              from upstream servers omit this information, dnsmasq does not  cache  the
              reply.  This  option  gives a default value for time-to-live (in seconds)
              which dnsmasq uses to cache negative replies even in the  absence  of  an
              SOA record.

       --max-ttl=<time>
              Set a maximum TTL value that will be handed out to clients. The specified
              maximum TTL will be given to clients instead of the true TTL value if  it
              is lower. The true TTL value is however kept in the cache to avoid flood‐
              ing the upstream DNS servers.

       --max-cache-ttl=<time>
              Set a maximum TTL value for entries in the cache.

       --min-cache-ttl=<time>
              Extend short TTL values to the time given when caching  them.  Note  that
              artificially  extending TTL values is in general a bad idea, do not do it
              unless you have a good reason, and understand what you are  doing.   Dns‐
              masq limits the value of this option to one hour, unless recompiled.

       --auth-ttl=<time>
              Set the TTL value returned in answers from the authoritative server.

[napcok]

Dnsmasq domyślnie czyta /etc/hosts, więc sprawdź czy masz poprawne wpisy w tym pliku.
Na jaki adres system resolwuje domenę sprawdzisz poleceniem:
host domena

Appki pod konsolę | czasem piszę tutaj | Pomóż sobie i innym - mądrze zadawaj pytania

[Autor]

Posty