Puncte:0

Windows 10 / Chrome: cererea de browser HTTP către adresa IP diferă de aceeași solicitare la numele de gazdă

drapel ru

Din nou, acesta este pe Windows 10. Aduc un nou server web de testare Ubuntu (hpmicro1.lovelady.com) în rețeaua noastră internă, care se află totul în domeniul lovelady.com. Există un server DNS pe o altă mașină care se ocupă de toate căutările DNS.

Configurația PC-ului pentru DNS este:

Configurare DNS

Când dau ping la serverul web după nume, primesc 192.168.1.5:

Rezoluție DNS

Am repornit în ultimele cinci minute.

Acum, la un browser web Chrome sau Firefox sau chiar Edge (pe care de obicei îl evit ca ciuma), când accesez serverul după nume, primesc o eroare:

Nu a reușit la utilizarea numelui de gazdă

Dar când accesez prin adresa IP, am succes:

Succes prin adresa IP

Deci, mi se pare că căutarea DNS fie nu are loc la NICIUN browser web, fie primesc rezultate diferite de ping-ul din linia de comandă. Cum pot diagnostica acest lucru și, mai exact, cum se poate remedia?

Michael Hampton avatar
drapel cz
Se pare că accesezi două mașini complet diferite.
drapel in
Ar putea fi, de asemenea, o configurație greșită a VirtualHost pe server.
drapel ru
Da, acesta este ideea, @MichaelHampton. Cum poate fi asta? Cum pot găsi aici ce folosește Chrome (sau Firefox sau Edge) pentru o adresă IP și cum pot determina utilizarea valorilor potrivite?
drapel ru
Nu sunt sigur ce spui @GeraldSchneider. Deoarece se pare că acestea sunt două servere diferite (unul al meu și unul undeva în etherland...), ce sugerați să mă uit pentru a rezolva? Cel care îmi aparține (nesigur, pe net 192.168) pare să funcționeze bine....
drapel in
Verificați anteturile http din instrumentele de dezvoltare ale browserului dvs. De obicei, adresa de la distanță este listată acolo
Michael Hampton avatar
drapel cz
Restul lumii crede că adresa IP este 206.188.192.244 pentru că asta este în DNS-ul global. Ce se petrece aici?
drapel in
Browserele dvs. sunt configurate pentru a utiliza DoH?
drapel ru
@MichaelHampton restul lumii vede capul pentru lovelady.com. Pe plan intern, există un server DNS (cred că am menționat) care furnizează și adrese pentru alte servere pe care restul lumii nu le vede. Printre acestea: hpmicro1, la 192.168.1.5.
drapel ru
Bună, Gerald. Nu am atins niciodată configurația Edge sau Firefox. Și configurație limitată a Chrome. Nu am configurat niciodată DNS prin HTTP(e) pe niciunul dintre ele. Mulțumiri.
drapel ru
Ah, și am neglijat să menționez în cazul în care cineva ar fi curios... toate chestiile astea lovelady.com sunt într-adevăr ale mele.
drapel ru
OK, mulțumesc pentru ajutor @GeraldSchneider în ceea ce privește instrumentele pentru dezvoltatori. A trebuit să pornesc câteva lucruri pentru a vedea, dar aceasta se adresează adresei 206.188... menționate mai sus. Deoarece același sistem, în „DOS BOX” arată rezoluția corectă a acestei gazde la 192.168.... Mă întreb de ce _toate cele trei_ browsere par să abordeze locația greșită. (Ca să nu mai vorbim de faptul că dacă mă adresez www.lovelady.com [aceeași adresă] totul funcționează bine....) Dar vreau să mă concentrez pe motivul pentru care adresa greșită din Windows
Puncte:1
drapel cv

Aparent, în anumite circumstanțe, clientul Windows ar încerca obțineți adresa lui HPMICRO1.... din 8.8.8.8

Aceasta nu este o eroare Windows, aceasta este prin design. Ați configurat clientul DNS Windows cu un server DNS principal și unul secundar. Serverul principal nu a răspuns, așa că clientul DNS Windows a interogat serverul secundar. Acesta este comportamentul perfect dorit. Ați prefera să eșueze la interogarea principalului și să nu interogați cel secundar? Vrei să sugerezi că alți clienți DNS nu se comportă la fel? Că vor interoga doar un singur server DNS? Se pare că încercați să faceți din asta o șapă „Windows este de vină” când, de fapt, clientul DNS Windows se comportă exact așa cum a fost proiectat. Dacă serverul principal nu răspunde, atunci încercați cel secundar, apoi cel terțiar etc. Aceasta nu este o problemă de client, este o problemă de server. Verificați-vă serverul DNS, acolo este problema.

Nu sunt sigur ce a determinat Windows să facă asta.

Ți-am dat un link către articolul care explică comportamentul. Nu este un mister. Funcționează așa cum a fost proiectat, în același mod în care orice alt rezolutor de client DNS este proiectat pentru același comportament. Interogați principalul, fără răspuns, interogați cel secundar și așa mai departe și așa mai departe.

drapel ru
Nu există nicio dovadă că DNS-ul nu a reușit să răspundă.. doar că Windows a avut două rezultate simultan. N-ar trebui să fie și nu ar fi pe alte platforme. Nu ca alții în ceea ce privește rezultatele stocării în cache, dar am terminat cu asta. Soluția a fost eliminarea celui de-al doilea DNS. De ce acest lucru duce la necesitatea de a apăra Windows este un mister la care nu mă voi gândi mai departe.
joeqwerty avatar
drapel cv
„Nu există nicio dovadă că DNS-ul nu a răspuns”. De asemenea, nu ați prezentat dovezi că a răspuns. Vă spun doar pentru ce este proiectat clientul Windows DNS și am citat documentația Microsoft. Ia-o cum vrei. Clientul DNS Windows nu este de vină aici.
Puncte:0
drapel ru

Se pare că acea configurație DNS pe care am arătat-o ​​în întrebare a fost o idee proastă. Eliminarea serverului DNS secundar a rezolvat problema. Aparent, în anumite circumstanțe, clientul Windows ar încerca să obțină adresa HPMICRO1.... de la 8.8.8.8 și, bineînțeles, asta a returnat capchall-ul. Nu sunt sigur ce a determinat Windows să facă asta (mă îndoiesc că cineva știe de ce Windows face ceva ;| ) dar după ce am luat în considerare, acel DNS secundar nu avea să facă niciodată ceea ce mi-am dorit.

Această problemă a fost rezolvată prin eliminarea DNS-ului extern (secundar) din configurație.

joeqwerty avatar
drapel cv
Aceasta nu este o problemă de client DNS Windows. Aceasta este o problemă de server DNS, deoarece serverul DNS configurat ca server DNS primar pentru clientul DNS nu răspunde la interogare. Acolo aș căuta problema. - https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-client-resolution-timeouts
drapel ru
De acord. Probabil că nu este o problemă Windows în acest caz. Dar nimeni nu poate dovedi (în acest moment și nici nu voi dedica mai mult timp) că Windows a făcut ceea ce trebuia să facă. Oricum, așa cum am sugerat, o consider o problemă de configurare a clientului. @joeqwerty
drapel ru
@joeqwerty Voi spune că majoritatea sistemelor de operare vor folosi o singură sursă, cu un fel de cache, pentru rezoluțiile DNS. Windows returnează o adresă pentru PING și o altă adresă pentru solicitările HTTP demonstrează că asta nu se întâmplă. Și mă îndoiesc că este acceptabil ca caracteristică, ceea ce o pune pe cealaltă parte a acelei caracteristici/linii de erori IMO.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.