Problem z serwerami DNS - błędne rozwiązywanie subdomen

Fizyda · 14 Lutego 2019

Od razu mówię, że żaden dział mi nie pasował, ale sytuacja jest dziwna i jeśli to nie ja coś źle interpretuję to ma znaczący związek z bezpieczeństwem. Do rzeczy.

Zauważył ktoś ostatnimi czasy problemy z działaniem serwerów DNS - globalnych i operatorów?

Od kilku dni zauważyłem długi czas ładowania się niektórych stron - w tym moich (nie od razu to powiązałem). Gdy zacząłem drążyć temat na swoich stronach okazało się, że strony ładują się długo ze względu na długi czas oczekiwania na odpowiedź z serwera DNS. Dodatkowo w między czasie problem się nasilił do tego stopnia, że czasami strony się nie ładowały - po sprawdzeniu okazało się, że brak odpowiedzi serwera DNS lub brak poprawnego rozwiązania subdomeny na adres IP. Co ciekawe problem z tego co widzę dotyczy tylko subdomen typu CNAME. To znaczy, nie są one rozwiązywane poprawnie przez serwery DNS operatorów.

Myślałem, że problem dotknął tylko moich domen i jest on spowodowany jakimś błędem z mojej strony. Przepraszam, dokładnie to chodziło o subdomeny typu CNAME dla jednej domeny, reszta na tym samym serwerze działała.

Obecnie problem nagle pojawił się też na innej stronie która nie należy do mnie (learncpp[.]com). Tutaj problem identyczny jak u mnie, domena główna rozwiązuje się poprawnie subdomena www typu CNAME już nie.

Testując wszystko odpytywałem bezpośrednio serwery DNS 3 różnych firm, dodatkowo sprawdzałem to na dwóch łączach (stałym i mobilnym). Serwery DNS to:

- serwer operatora internetu stacjonarnego (ma tylko jeden jako główny ustawia serwer Google 8.8.4.4, a swój jako zapasowy) - dalej nazwany serwer O

- serwery googla - oba, nazwane serwer G8 (8.8.8.8), serwer G4 (8.8.4.4)

- serwer chyba cloudflare 1.1.1.1 nazwany serwer CF

Jeśli chodzi o moją domenę to żadna subdomena typu CNAME (potem domyślnie o nie chodzi) to sytuacja jest następująca:

- G8 i G4 w ogóle ich nie rozwiązują, ale tylko w ramach jednej domeny

- serwer O i CF rozwiązują je bez problemu

- wszelkiej maści testery online również działały bez problemu

Jeśli chodzi o domenę learncpp:

- domena główna jest rozwiązywana tylko przez serwer G8

- subdomena www tylko przez serwer G4 (główna już nie)

- CF i O nie ogarnia niczego

Wątpię by strona learncpp znikła z sieci bo po prostu niedawno była jej aktualizacja (chyba 1 lutego).

Generalnie całość wygląda dla mnie dziwnie i nie ma związku logicznego, poza tym, że dotyczy serwerów DNS cachujących. Nie wiem skąd takie dziwne wyniki się biorą na poziomie różnych serwerów DNS.

Dodam, że jeśli chodzi o moje domeny to nie dokonywałem żadnych zmian w strefie tuż przed, jak i w momencie wystąpienia problemów.

Obecnie, aby mieć możliwość pobrania poczty musiałem ręcznie wymusić serwery DNS które poprawnie rozwiązują moją domenę (subdomeny), tylko teraz nie działa mi learncpp ...

Moja subdomena z którą mam problem to np. www[.]fizyda[.]com. Problem dotknął wszystkich subdomen tylko w tej mojej domenie, które były typu CNAME, dla przykładu subdomena mail typu A działała bez problemu.

Poniżej przykłady tego co mi wypluwa dig w momencie kończenia pisania tego postu (miało być dodane w spoiler, ale nie działa):

Moja domena główna:

; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 fizyda[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41441
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;fizyda[.]com.			IN	A

;; ANSWER SECTION:
fizyda[.]com.		0	IN	A	87.98.236.85

;; Query time: 1105 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Feb 14 23:44:06 CET 2019
;; MSG SIZE  rcvd: 55


; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.4.4 fizyda[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19455
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;fizyda[.]com.			IN	A

;; ANSWER SECTION:
fizyda[.]com.		0	IN	A	87.98.236.85

;; Query time: 1107 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Feb 14 23:44:15 CET 2019
;; MSG SIZE  rcvd: 55


; <<>> DiG 9.10.3-P4-Debian <<>> @1.1.1.1 fizyda[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13672
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;fizyda[.]com.			IN	A

;; ANSWER SECTION:
fizyda[.]com.		1003	IN	A	87.98.236.85

;; Query time: 5 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Feb 14 23:44:22 CET 2019
;; MSG SIZE  rcvd: 55


; <<>> DiG 9.10.3-P4-Debian <<>> @10.0.0.1 fizyda[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60026
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fizyda[.]com.			IN	A

;; ANSWER SECTION:
fizyda[.]com.		3600	IN	A	87.98.236.85

;; Query time: 42 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Thu Feb 14 23:44:32 CET 2019
;; MSG SIZE  rcvd: 44

Moja subdomena typu CNAME

; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 www.fizyda[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12592
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.fizyda[.]com.			IN	A

;; Query time: 1193 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Feb 14 23:44:46 CET 2019
;; MSG SIZE  rcvd: 43


; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.4.4 www.fizyda[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45448
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.fizyda[.]com.			IN	A

;; Query time: 1063 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Feb 14 23:45:10 CET 2019
;; MSG SIZE  rcvd: 43


; <<>> DiG 9.10.3-P4-Debian <<>> @1.1.1.1 www.fizyda[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56225
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;www.fizyda[.]com.			IN	A

;; ANSWER SECTION:
www.fizyda[.]com.		950	IN	CNAME	fizyda[.]com.
fizyda[.]com.		950	IN	A	87.98.236.85

;; Query time: 6 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Feb 14 23:45:15 CET 2019
;; MSG SIZE  rcvd: 73


; <<>> DiG 9.10.3-P4-Debian <<>> @10.0.0.1 www.fizyda[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31077
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.fizyda[.]com.			IN	A

;; ANSWER SECTION:
www.fizyda[.]com.		3600	IN	CNAME	fizyda[.]com.
fizyda[.]com.		3600	IN	A	87.98.236.85

;; Query time: 3577 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Thu Feb 14 23:45:27 CET 2019
;; MSG SIZE  rcvd: 62

Learncpp - domena główna

; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 learncpp[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15268
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;learncpp[.]com.			IN	A

;; ANSWER SECTION:
learncpp[.]com.		4601	IN	A	67.210.102.158

;; Query time: 27 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Feb 14 23:46:27 CET 2019
;; MSG SIZE  rcvd: 57


; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.4.4 learncpp[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20551
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;learncpp[.]com.			IN	A

;; ANSWER SECTION:
learncpp[.]com.		5158	IN	A	67.210.102.158

;; Query time: 27 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Feb 14 23:46:38 CET 2019
;; MSG SIZE  rcvd: 57


; <<>> DiG 9.10.3-P4-Debian <<>> @1.1.1.1 learncpp[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46883
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;learncpp[.]com.			IN	A

;; Query time: 4233 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Feb 14 23:46:49 CET 2019
;; MSG SIZE  rcvd: 41


; <<>> DiG 9.10.3-P4-Debian <<>> @10.0.0.1 learncpp[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43055
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;learncpp[.]com.			IN	A

;; Query time: 4066 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Thu Feb 14 23:47:08 CET 2019
;; MSG SIZE  rcvd: 30

Learncpp - subdomena

; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 www.learncpp[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49361
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.learncpp[.]com.		IN	A

;; Query time: 3068 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Feb 14 23:47:17 CET 2019
;; MSG SIZE  rcvd: 45


; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.4.4 www.learncpp[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46167
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.learncpp[.]com.		IN	A

;; ANSWER SECTION:
www.learncpp[.]com.	8652	IN	CNAME	learncpp[.]com.
learncpp[.]com.		8652	IN	A	67.210.102.158

;; Query time: 28 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Feb 14 23:47:22 CET 2019
;; MSG SIZE  rcvd: 75


; <<>> DiG 9.10.3-P4-Debian <<>> @1.1.1.1 www.learncpp[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2266
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;www.learncpp[.]com.		IN	A

;; Query time: 4208 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Feb 14 23:47:33 CET 2019
;; MSG SIZE  rcvd: 45


; <<>> DiG 9.10.3-P4-Debian <<>> @10.0.0.1 www.learncpp[.]com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48605
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.learncpp[.]com.		IN	A

;; Query time: 4065 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Thu Feb 14 23:47:51 CET 2019
;; MSG SIZE  rcvd: 34

Edytowane 14 Lutego 2019 przez Fizyda

Mion · 15 Lutego 2019

7 godzin temu, Fizyda napisał:

Gdy zacząłem drążyć temat na swoich stronach okazało się, że strony ładują się długo ze względu na długi czas oczekiwania na odpowiedź z serwera DNS

Przecież przeglądarka (klient) DNS jest odpytywany raz na (n) czasu i później IP serwera skojarzonego z domeną jest w cache... wiec skąd miały by być te opóźnienia ? Cyba, że za każdym wywołaniem strony robisz ipconfig /flushdn.

Fizyda · 15 Lutego 2019

@Mion

Zapomniałem o tym szczególe, tak jak mówisz początkowo strony miały problem z ładownie raz na N wejść. Gdy zacząłem drążyć temat to robiłem pełne przeładowanie strony - z czyszczeniem htmli w cache, a gdy zauważyłem problemy z DNSami to zacząłem dodatkowo flushować dnsy w systemie. Potem dopiero zabrałem się za diga i nslookup by stwierdzić w których DNSach jest problem.

Od początku obstawiałem, że problem leży w moim serwerze WWW, później w serwerze DNS. Pomimo, że od bardzo dawna nic w configuracji nie zmieniałem. Był update, ale to trochę wcześniej niż zaczęły pojawiać się problemy. Fakt liczyłem się z tym, że to mogła być przyczyna aktualizacji, chociaż dziwne wydawało mi się, że problemy zaczęły się chyba tydzień czy dwa po jej wykonaniu. Ale wszystko jest możliwe i nie wykluczałem i takiej możliwości.

Mion · 15 Lutego 2019

Przegladarki w narzędziach mają statystyki sieci w tym ile czasu zajmuje odpytanie DNS:

Polecam również strony typu page speed test jak: https://tools.pingdom.com/

Sprawdź jak to wygląda "z zewnątrz", bo nie sądzę by powodem wolnego działania strony były globalne serwery DNS.

Fizyda · 15 Lutego 2019

Z całym szacunkiem, zobacz co odpowiadają serwery DNS, których odpowiedzi załączyłem w temacie. Największym problemem nie jest długi czas, a w ogóle brak rozwiązania domeny na adres IP.

Dev toolsy w tym przypadku się nie sprawdzą, bo zwrócą mi wynik zależnie od tego jaki DNS ustawię w swojej sieci lub dla kompa. Albo nie będą w stanie określić lokalizacji hosta, albo strona uruchomi się bez problemu.

Strony, które sugerujesz również dowiedziałem i efekt jest taki, że zależnie od lokalizacji wyniki są różne. Albo działa, albo nie działa. Domyślam się, że różne lokalizacje korzystają z różnych serwerów DNS stąd zależnie czy uda się rozwiązać adres na ip na danym serwerze to albo test się powiedzie albo nie.

2 godziny temu, Mion napisał:

Sprawdź jak to wygląda "z zewnątrz", bo nie sądzę by powodem wolnego działania strony były globalne serwery DNS.

Skoro odpytuję konkretny serwer DNS o konkretną nazwę i zwraca mi błędne dane, to jakim cudem nie jest to jego wina? Serwer DNS domeny zwraca poprawne wyniki, strefa nie była modyfikowana. Problem jest od dłuższego czasu (dłużej niż 72h), więc nawet jeśli założymy, że mój serwer dał ciała i cache DNSy zapamiętały błędne odpowiedzi to problem trwa zbyt długo, bo już dawno powinno się to zaktualizować.

Może zbyt pochopnie temat założyłem i tylko serwery Googla mają jakiś dziwny problem, wielu serwerów DNS też nie testowałem, ale to dlatego, że wręcz randomowe wyniki otrzymywałem. Dziś sytuacja wygląda jeszcze inaczej, ale nadal nie wszystko działa sprawnie.

Edytowane 15 Lutego 2019 przez Fizyda

Mion · 15 Lutego 2019

47 minut temu, Fizyda napisał:

Największym problemem nie jest długi czas, a w ogóle brak rozwiązania domeny na adres IP.

Dlatego pisałem jak sugeruje tytuł

Cytuj

Problem z serwerami DNS - błędne rozwiązywanie subdomen

byś sprawdzał z rożnych miejsc. " Sprawdź jak to wygląda "z zewnątrz", bo nie sądzę by powodem wolnego działania strony były globalne serwery DNS. "

-------

Jeśli porblem jak Piszesz tychy rekordów CNAME, to są one tylko aliasami Alias do innego hosta (CNAME) – Pozwala na zdefiniowanie aliasu (alternatywnej nazwy) rekordu A dla domeny.

A jaka Ci subdomena nie działa ta: admin.fizyda.com, która faktycznie nie działa ?

Edytowane 15 Lutego 2019 przez Mion

Fizyda · 15 Lutego 2019

56 minut temu, Mion napisał:

byś sprawdzał z rożnych miejsc. " Sprawdź jak to wygląda "z zewnątrz", bo nie sądzę by powodem wolnego działania strony były globalne serwery DNS. "

Co mi to da skoro serwer zwraca błąd, że nie znalazł rozwiązani dla danego adresu?

Poza tym pisałem, że sprawdzałem na dwóch łączach ...

Przykładową subdomenę z którą mam problem też podałem, nie wiem skąd pomysł z jakimś admin.

Mion · 15 Lutego 2019

9 minut temu, Fizyda napisał:

nie wiem skąd pomysł z jakimś admin.

Z twoich DNSów

Fizyda · 15 Lutego 2019

Odpytywałeś mój serwer DNS który obsługuję moją domenę czy mówisz o logach które załączyłem?

Mion · 15 Lutego 2019

# dig CNAME fizyda.com

; <<>> DiG 9.10.3-P4-Debian <<>> CNAME fizyda.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21533
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fizyda.com.                    IN      CNAME

;; AUTHORITY SECTION:
fizyda.com.             600     IN      SOA     ns1.fizyda.com. admin.fizyda.com. 2019012420 3600 600 1209600 600

;; Query time: 27 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Feb 15 13:59:10 CET 2019
;; MSG SIZE  rcvd: 85

root@ovhvps:~#


dig A  admin.fizyda.com
fizyda.com.             600     IN      SOA     ns1.fizyda.com. admin.fizyda.com. 2019012420 3600 600 1209600 600

Fizyda · 15 Lutego 2019

Co Ty tutaj próbujesz robić? Odpytujesz DNS o nieistniejący rekord w odpowiedzi otrzymujesz tylko SOA, a admin to jest adres email do kontaktu ... zgodnie ze specyfikacją rekordu SOA.

Potem znów odpytujesz o nieistniejący rekord dla nieistniejącej subdomeny.

Dodatkowo odpytujesz domyślne serwery DNS ustawione dla Twojego VPSa. A ja mówię o problemie występującym na konkretnych serwerach DNS. Więc jakie ma znacznie skąd są wysyłane zapytania? Skoro działa mi połączenie do serwera to z każdego miejsca dostanę tą samą odpowiedź dla tego samego zapytania, chyba, że się w między czasie coś zaktualizuje.

Zresztą nawet masz jak byk napisane w konsoli, że dla dig CNAME fizyda.com nie ma żadnej odpowiedzi/dopasowania ...

Edytowane 15 Lutego 2019 przez Fizyda

Tomek · 15 Lutego 2019

Witajcie,

Powiem tak - coś chyba jest na rzeczy, tzn było - bo dziś się uspokoiło. Przez 2 ostatnie dni otrzymałem około 40 raportów błędów z naszych systemów które mówiły o braku możliwości rozwiązania nazwy domeny (akurat tutaj rekordy typu A). Dla porównania - normalnie są to 2-3 tego typu raporty w miesiącu. Mówię tutaj o serwerach DNS Google.

Fizyda · 15 Lutego 2019

@Tomek Dzięki za info, rano jak sprawdzałem DNS Google dla mojej domeny dalej miał problem. Dodatkowo mogę powiedzieć, że ostatni tydzień, prawie dwa ich zapasowy serwer działał wolno - wnioskuję to z tego, że mój operator serwer Googla ustawia jako główny dla swoich klientów, a w tym okresie czasu zauważyłem wolne wczytywanie się wielu stron przy pierwszej wizycie, za nim IP był wrzucony do lokalnego cache.

Fizyda · 18 Lutego 2019

Sporo czasu już minęło, a DNS Googla dalej nie znają wszystkich subdomen tej jednej domenie ... Dodam, że już przed założeniem tematu próbowałem flushować DNSy dla domeny jak i subdomen przy pomocy panelu udostępnionego przez Google.

Ma ktoś jakiś pomysł? Ewentualnie jest ktoś w stanie stwierdzić, gdzie leży problem, w moim serwerze czy to jednak błąd na serwerach Googla.

mariaczi · 18 Lutego 2019

$ dig CNAME www.fizyda.com @8.8.8.8

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> CNAME www.fizyda.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8318
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.fizyda.com.			IN	CNAME

;; ANSWER SECTION:
www.fizyda.com.		0	IN	CNAME	fizyda.com.

;; Query time: 1068 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Feb 18 16:52:07 CET 2019
;; MSG SIZE  rcvd: 57


$ dig CNAME www.fizyda.com @8.8.4.4

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> CNAME www.fizyda.com @8.8.4.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57679
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.fizyda.com.			IN	CNAME

;; ANSWER SECTION:
www.fizyda.com.		0	IN	CNAME	fizyda.com.

;; Query time: 1072 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Mon Feb 18 16:52:13 CET 2019
;; MSG SIZE  rcvd: 57

Hmm, mi wygląda na to, że jest w porządku.

psz · 19 Lutego 2019

Pojawiające się co chwilę kody błędu "SERVFAIL" (co bardziej, pokazują to różni usługodawcy) sugerują problem po stronie serwera DNS dla domeny. Jako, że używasz własnego VPS, podejrzewam, że masz ustawienia firewalla, które albo blokują TCP/UDP port 53, albo jakiś rate-limiting. Patrząc na szybko są problemy z różnymi rekordami, nic specyficznego dla CNAME.

Jeśli nie masz jakiegoś wyraźnego powodu dlaczego nie chcesz używać zewnętrznych serwerów DNS, to polecałbym Cloudflare (najszybszy DNS na świecie wg https://www.dnsperf.com/).

Disclaimer: Pracuję dla Cloudflare, ale tutaj odpowiadam prywatnie.

23 godziny temu, mariaczi napisał:

Hmm, mi wygląda na to, że jest w porządku.

Czasy odpowiedzi > 1000 ms to z pewnością nic w porządku. Wyraźnie widać, że serwery Google w ogóle odpowiadają, ponieważ próbują po kilka razy. Odpowiedzi z TTL = 0 to prawdopodobnie tzw. stale cache, co samo w sobie jest ciekawym pomysłem (w skrócie: "wiem, że mój cache wygasł, ale serwer ma problem, więc odpowiem tym, co wiem").

Fizyda · 19 Lutego 2019

Trochę nie ogarniam, tylko jeden usługodawca - Google, zwraca SERVFAIL. Używam swojego VPS i serwera dla zabawy, nauki i doświadczenia. Co prawda nie mam nic wspólnego z sysadminowaniem, ani nie jestem devopsem, ale uważam, że taka wiedza się może przydać. FW uważam że jest dobrze skonfigurowany, na pewno wszystkie porty są odblokowane.

7 godzin temu, psz napisał:

Patrząc na szybko są problemy z różnymi rekordami, nic specyficznego dla CNAME.

Możesz rozwinąć?

psz · 19 Lutego 2019

Dla przykładu, dostaję losowe timeouty gdy odpalam takie komendy:

dig a fizyda.com @ns1.fizyda.com
dig ns fizyda.com @ns1.fizyda.com

$ ping fizyda.com
PING fizyda.com (87.98.236.85): 56 data bytes
64 bytes from 87.98.236.85: icmp_seq=0 ttl=49 time=16.907 ms
64 bytes from 87.98.236.85: icmp_seq=1 ttl=49 time=114.178 ms
64 bytes from 87.98.236.85: icmp_seq=2 ttl=49 time=136.342 ms
64 bytes from 87.98.236.85: icmp_seq=3 ttl=49 time=174.192 ms
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
64 bytes from 87.98.236.85: icmp_seq=6 ttl=49 time=16.450 ms
Request timeout for icmp_seq 7
64 bytes from 87.98.236.85: icmp_seq=8 ttl=49 time=23.186 ms
64 bytes from 87.98.236.85: icmp_seq=9 ttl=49 time=17.876 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
^C
--- fizyda.com ping statistics ---
14 packets transmitted, 7 packets received, 50.0% packet loss
round-trip min/avg/max/stddev = 16.450/71.304/174.192/63.010 ms

Teraz widzę, że masz bardzo duże straty pakietów, tu bym poszukał przyczyny problemów. Może serwer jest przeciążony, albo wadliwy (jeśli dedyk). Polecam zapytać supportu OVH.

Fizyda · 20 Lutego 2019

Dzięki wielkie, przy okazji potwierdziłeś moje przypuszczenia, w tej sprawie już pisałem do OVH. Serwer to VPS więc raczej jest przeciążony, będę musiał z tym zawalczyć.

Wracając jeszcze do DNS, myślisz, że to może być przyczyną problemów z DNSami Googla? Wiadomo, przyczyną może być, bardziej chodzi mi o to czy jest to bardzo prawdopodobna przyczyna, czy nie i trzeba szukać jednak dalej. Niemniej timeoutami trzeba się zająć i to bez dwóch zdań.

psz · 20 Lutego 2019

Tak, myślę, że jest to przyczyna. Google DNS ma dosyć słabą konfigurację cache, szczególnie dla mało popularnych domen. Nie dzieli stanu cache pomiędzy serwerami wewnątrz PoP'u przez to bardzo często musi pytać nameserverów dla domeny, a to bardzo cierpi przy stratach pakietów.

Fizyda · 20 Lutego 2019

Dzięki za informację w takim razie na razie olewam temat DNS i walczę ze stratami pakietów, jak się z tym uporam to wraca na tapetę temat DNSa .

Zaloguj się

Cześć!

Problem z serwerami DNS - błędne rozwiązywanie subdomen

Rekomendowane odpowiedzi

Fizyda

Mion

Fizyda

Mion

Fizyda

Mion

Fizyda

Mion

Fizyda

Mion

Fizyda

Tomek

Fizyda

Fizyda

mariaczi

psz

Fizyda

psz

Fizyda

psz

Fizyda

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Zarejestruj nowe konto

Zaloguj się

Ostatnio przeglądający 0 użytkowników

Przeglądaj

Cała aktywność

TOP100

Powiadomienie o plikach cookie