Ik vraag me af of dat kan.

Een externe server kan - als het goed is - helemaal niks resolven bij jouw resolver.
En code in je webbrowser is - terecht (vanwege security) - ook fors geisoleerd van je computer/OS , die kan niet zomaar 'rechtstreeks' jouw resolver bevragen.

Als javascript een naam (laat) resolven gaat dat via de code van je OS - inclusies allerlei caching in je computer , dus je hebt dan geen direct beeld van je resolver.

In plaats van te denken waar het aan ligt kun je beter KIJKEN .

Ik kan zo een paar redenen bedenken waarom het traag is/lijkt in de browser :

virusscanner kijkt eerst naar de site.
safe-browsing kijkt eerst naar de URL (heen en weer naar google, of iets anders)
honderduizend plugins doen eerst hun ding met wat je intikt.

Neem wireshark, en kijk naar het verkeer vanaf het moment dat je site laat komen.
Waarschijnlijk een snelle DNS lookup en dan heel veel andere dingen voordat de site begint te renderen.

Of leer jezelf een beetje programmeren, en schrijf een scriptje om inderdaad de snelheid van je resolver te testen.
Erg nuttige vaardigheid, om zelf wat kleine tooltjes te kunnen schrijven .

Wat is het OS ?

nslookup
DNS analyzer

Een site die een test doet van je lokale DNS resolver? Hoe had je ingedachte dat te laten werken het is lokaal om een reden
Je kan wel remote DNS testen via sites maar voor lokaal moet je toch echt vanaf jezelf een test doen via dig, nslookup of een soortgelijke tool vanaf je eigen hardware die gebruik maakt van dat command.

DNSDataView van NirSoft is eentje die in verleden altijd goed werkte en meerdere lookups kan maken maar geen query time toont de rest kan het wel. Er even van uit gaande dat je met Windows werkt.

Voor linux gebaseerde systemen een combinatie van dig en awk lijkt me het meest geschikte.


Maar je omschrijving gaat het meer over site structuur en CDN cache dan echt DNS requests, lookups.
Dat kun je beter testen met diensten als GTMetrix, Google Lighthouse. En enige problemen die daar naar voren komen zijn niet door jezelf op te lossen tenzij je de eigenaar bent van de site en onderliggende infra.
TTFB, onload waardes zijn waar je denk ik de focus op moet leggen. Je zou eventueel ook nog kunnen kijken naar enige duplicaten in 301, 302 requests aan de start van de metrix en 404 vermeldingen.

Het is niet de bedoeling dat er extern bevraagd wordt. Ik wil gewoon een script downloaden wat in de browser wordt
uitgevoerd en wat dan flink wat DNS lookups gaat doen met de standaard resolver die het OS gebruikt. Van binnenuit dus.


Precies, daarom mijn vraag. Ik heb een hypothese en ik wil die testen. Als het dit niet is moet het wat anders zijn.

Het is niet de bedoeling om er een researchproject van te maken, ik wil gewoon onderzoeken waarom "het internet soms traag is". Als ik bij die computer ga staan (Windows 10) en ik tik in de adresbar een mij bekende site in dan duurt het vaak enkele seconden voor er wat in beeld komt. Maar als ik een speedtest doe dan is het allemaal 100% in orde.
Vandaar dat ik wil weten waar die vertraging vandaan komt. DNS lookups lijkt me een mogelijkheid.

Ho stapje terug je maakt een enorme denkfout hier die je onnodig tijd gaat kosten. Je local DNS resolver poogt enkel verbinding met de eerste bron van je aanvraag je nameservers en de bijhorende DNSzone die vervolgens de aanvraag behandelt namens jou. Dit zijn vaak je ISP nameservers. Maar dat is zelden genoeg om alle requests op te halen of uberhaubt bij je oorspronkelijke site doel te komen als er ook nog een CDN tussenzit of gebruik gemaakt wordt van verdere clustering.

Je kunt dit niet local afwikkelen dat bestaat niet als we het over een DNS situatie hebben die niet op afgeschermd netwerk plaatsvind bij bijvoorbeeld een domaincontroller tussen twee domeinen eigen beheer.


Content wordt vaak in delen geladen. afbeeldingrn kunnen gebruikmaken van lazy load maar dat gaat ook wel eens mis in combinatie van minification en externe media bronnen.

Wat je wilt is intensief qua tests dit is niet simpelweg een speedtest je wilt een netwerk recording analiseren en ja dat is een research project daar ontkom je niet aan. Dus als je hier niet die tijd in wilt steken dan better drop it. We kunnen de aanroep technieken niet versimpelen dit is hoe het aanroepen van content nu eenmaal is bedacht met de huidige netwerk protocols. En er zijn hele geavanceerde tools op de markt zelfs met machinelearning maar die zijn niet gratis. Maar geen enkele kan dit *enkel* local afwikkelen.
.

Dat begreep ik - en zoals ik schreef : zeer waarschijnlijk kan dat niet met javascript in een browser.


Niet waarschijnlijk;
Maar goed, met wireshark zie je heel snel of het de DNS lookup is lang duurt . (en welke lookups allemaal gedaan worden).

Andere mogelijkheid is nog de een of andere tracker/ad-site die traag is en het renderen van je bedoelde site vertraagd.

Als je geen zin/kennis/gelegenheid hebt om een los testscriptje voor DNS lookups te maken is wireshark denk ik de snelste manier om te zien of DNS lookups lang moeten wachten op antwoord.

Dan zie je ook meteen _welke_ lookups - als er iets traag is - traag zijn.

Het zou heel goed kunnen dat van alles snel is, behalve de een of andere link/hostname die vanuit je 'trage' website opgevraagd wordt.

Als je dat niet weet kun je wel met een scriptje van allerlei bekende hostnamen/domeinen gaan resolven, en de tijd meten, maar dat alleen statcounter.obscuredomain.in telkens timeout weet je dan niet - en als die in een URL zit die je 'trage' site opvraagt heb je daar telkens last van - op die site.

Klinkt als een niet-antwoordende resolver, of IPv6 wat niet wil.

Natuurlijk kan dat WEL!
Je kunt in javascript een connectie maken met een site met naam als parameter dus daarvan is de DNS lookup een deel.

Maar meteen voor de overige reaguurders: ik zit niet te wachten op "dat kan niet" of "dat moet je niet willen" of "je begrijpt het niet". Als je geen verwijzing hebt naar zo'n testsite dan ben ik niet zo geinteresseerd, ik heb vast meer ervaring met networking dan jullie.

Beste OP dezer draad,

Fijne website vind je hier: https://dnsdumpster.com/

Lees tevens als introductie- https://dnsdumpster.com/footprinting-reconnaissance/
Installeer Netcraft voor rapportjes.

Men kan al veel bereiken via 3rd party cold reconnaissance samen met error-hunting.
Er bestaat abuse listing, er is shodan en nog veel meer resources wachten op jou.

Werd dit over het algemeen meer gedaan, dan zou heer Elton Musk ons niet gaan laten bestalen
voor het beschermen van X tegen bots e.d.

Men denkt thans liever voor de meesten van ons, want dat levert meer op voor hen, die aan de knoppen zitten te draaien.

Lees ook eens door de verschillende draadjes heen hier van een top-expert op DNS terrein als onze Erik van Straten.
Ontzaglijk veel hier van deze n3rd geleerd, maar ook hem wel eens per ongeluk op de teentjes getrapt.
Want dergelijke experts hebben vaak weinig geduld met n00bs, al is het maar op enig terrein,
zoals ik een pure en eenzijdige website security figuur zijnde (cold recon scan analyst en website error-hunter)

luntrus (iemand die geduld heeft met veel mensen i.h.a.)

An error has occurred in one of your routes.
Detail: fatal.nim(53) sysFatal
asyncfutures.nim(389) read
asyncfutures.nim(389) read
asyncfutures.nim(389) read
asyncfutures.nim(389) read
asyncfutures.nim(389) read
asyncfutures.nim(389) read
packedjson.nim(294, 28) `false` unexpected end of object testing https://nitter.it/dns0eu

Kan iemand hier dit verklaren? Een grammaticale fout verbeterd via QuilBot

Je hebt wel gesnapt dat je linktips GEEN antwoord zijn op vraag van de OP ?

Zoals OP zowel in topic start als in 20 sep 16:28 duidelijk uitlegde :

OP wil performance van z'n lokaal ingestelde resolver testen.

Dan dit: https://superuser.com/questions/1647407/how-to-properly-test-a-local-dns-server-locally

Heeft ie dig app op z'n smartfoon?

Waarom in hemelsnaam wil je netwerk audits gaan verrichten via een smartphone als je beschikking hebt over desktop, notebook met hoogstwaarschijnlijk meer performance inclusief de netwerkkaart en mogelijkheden om output verder te verwerken.

De keren dat ik terminal op een smartphone heb moeten gebruiken voor dit soort situaties kan ik op een hand tellen in 20 jaar tijd en dat waren destijds speciale telefoons met een ethernet aansluiting mogelijkheid waar op de locatie het aansluiten van notebooks tricky was door niet genoeg fysieke ruimte om apparatuur mee te slepen laat staan beweging ruimte had voor het typen.

In een particuliere, hobbyist situatie ga je toch niet moeilijker maken dan nodig is lijkt me.

Inmiddels het Linux tooltje "dnsperf" gevonden wat in feite doet wat ik zoek maar dan vanaf een Linux systeem op de commandline. Het zou mooi zijn als zo iets bestond in Javascript zodat je het kunt testen op de WIndows machine waarop de issues zich afspelen zonder software te moeten installeren en in traces te moeten duiken.

Dit ding geeft in ieder geval goed aan wat de tijden per query zijn en hoeveel queries (absoluut en relatief) helemaal niet beantwoord worden. En je kunt zien wat de query is die het langste duurde.

Is wel een klusje om een lijst te maken van DNS namen, die zit er helaas niet bij.

Nou ja, de source code staat op github, misschien kun je het zelf (met eventueel wat aanpassingen) compilen voor windows?
Of misschien kun je het via WSL gebruiken (zou ik eerst proberen als ik geen linux zou draaien).

Het is niet handig om software te moeten installeren op die Windows systemen. Dan moet er eerst als een administrator worden ingelogd. Bovendien test ik het liefst vanuit de browser, want dat is immers ook waar het probleem ervaren wordt.

Dat kan aan van alles liggen, het hoeft niet per se DNS te zijn.

Wat ik in jouw situatie als eerste zou doen is de developer tools van de browser openen. Je meldde niet welke browser je gebruikt, geloof ik, maar zowel Firefox als Chromium hebben erg op elkaar lijkende developer tools die met F12 op te roepen zijn, en Edge heeft ze zo te zien ook. Klik binnen die tool op de network-tab en open daarna een webpagina. Je krijgt geen DNS-verkeer te zien, maar je kan wel alle HTTP-requests live volgen die voor de pagina gedaan worden, compleet met een weergave van de tijdlijn van de afhandeling van de requests. Als DNS de oorzaak van de vertraging is zou de eerste request voor een website met die vertraging moeten verschijnen. Maar als het aan bijvoorbeeld een traag reagerende webserver ligt, of als er eerst idioot veel requests worden gedaan voordat er iets getoond wordt, dan zie je dat meteen.

Wireshark is al genoemd als tool om los van de browser netwerkverkeer te volgen. De hoeveelheid gegevens die je dan ziet kan nogal overweldigend zijn. Nadat je een trace gestart hebt kan je bij "display filter" simpelweg "dns" (zonder de aanhalingstekens) invullen om uitsluitend de DNS-queries en -antwoorden te zien. Als je alleen https-verkeer wilt zien kan je "tcp.port==443" gebruiken, en "dns or tcp.port==443" als je beide wilt zien.

Wees erop verdacht dat er browsers zijn die DNS over HTTPS gebruiken. Dat kan een verschil opleveren met DNS-queries die je buiten je browser doet, zodat dat inderdaad niet representatief hoeft te zijn voor wat je browser doet.

Het klopt dat je moet testen met je webbrowser om dingen te kunnen volgen die specifiek in/met die webbrowser misgaan. Maar dat betekent niet dat de tools waarmee je test uitsluitend in de webbrowser moeten draaien. Je kan bijvoorbeeld prima een browser- en Wireshark-venster naast elkaar open hebben staan zodat je in Wireshark live kan volgen wat je browser voor netwerkverkeer genereert.

Net als anderen hier ben ik niet op de hoogte van een website die kant en klaar een JavaScript-implementatie biedt die je kan gebruiken. Ik zie wel dat node.js een API biedt om DNS-queries vanuit JavaScript te doen:
https://nodejs.org/api/dns.html
Misschien kan je daar zelf iets mee in elkaar knutselen of kan je er zoekargumenten aan ontlenen waarmee je gerichter kan zoeken. Maar ik betwijfel of dat je meer inzicht oplevert dan de developer tools en Wireshark.

Bedenk dat als alleen mensen die zo'n testsite kennen hadden gereageerd je (tot nu toe) helemaal geen reacties had gehad. Dan had je je nu zitten afvragen of je vraag wel door iemand was gelezen of wat maakte dat die kennelijk totaal genegeerd werd. De reacties waar je je nu aan ergert laten je zien dat je vraag niet alleen gelezen is maar ook mensen aan het meedenken zet.

Dat het antwoord waarop je hoopt ontbreekt laat zien dat zo'n website niet algemeen bekend is en mogelijk niet bestaat. En als iets niet bestaat of helemaal geen bekendheid verwerft is dat een indicatie dat het niet zoveel toevoegt als jij vermoedt en dat andere manieren om het uit te zoeken voor de rest van de mensheid volstaan. Staar je dus niet blind op die ene benadering en neem tips voor andere benaderingen serieus.

Dat weet ik, maar ik wil graag uitsluiten dat het dat is. Want dat ligt meer in mijn invloedssfeer dan bepaalde andere mogelijke problemen (ik kan evt de resolver veranderen of de configuratie ervan).


Ja klopt, het is Edge, maar helaas staat dat F12 disabled in een policy. Geen idee waarom overigens, zal dat eens uitzoeken en evt omkeren, ik denk dat het komt omdat er gewoon een standaard "restrictief" template gebruikt is. Kan zijn dat de maker daarvan gedacht heeft "dat brengt de gebruiker alleen maar in verwarring als ie er per ongeluk op drukt".


Nou dan had ik me dat na een paar dagen wel een keer afgevraagd. Ik denk dat er in het algemeen niet zo heel goed gelezen wordt en vaak verkeerde aannames gedaan worden, waardoor een topic al gauw ontspoort.
En dan is dit nog een van de weinige topics op deze site die niet meteen ontspoort richting "kwaadaardige overheid".

Je denkt veel te moeilijk. Als je de mogelijkheid hebt om je resolvers aan te passen dan waarom test je gewoon niet hoe je het verkeer ervaart tussen je oude resolver en de nieuwe. Zit daar geen noemenswaardig verschil in dan weet je dat het niet aan de resolvers zelf ligt en kun je focus verleggen geen exacte metingen nodig. Zie je wel aanzienlijk verschil dan kun je of de oude resolvers verder auditen of gewoon kiezen voor de nieuwe als het je weinig uitmaakt en geen invloed heeft voor overige zaken.

Je wou geen research project hier van maken *dan doe het ook niet*


F12 moet gewoon werken als er een policy enabled is dan gaat het om de policy gpedit.msc Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Toolbars -> Turn off Developer Tools
https://gcdnb.pbrd.co/images/sffaAc8mbSDK.png

Als dit een systeem is wat jezelf beheert dan mijn advies documenteer al je policy changes in vervolg.
Als het een overgenomen systeem is had je beter alles kunnen wipen voor ingebruikname.
Dit is hoe dan ook niet een policy die standaard in Pro, Enterprise aan staat dit moet een handmatige handeling zijn geweest.


Over je opmerking over afdwaling van topics je gaat overal trolls vinden of mensen die doen alsof ze ergens kennis over hebben of eigen agenda propageren. Dat is het internet welkom in de real world. Het is aan jou als aanvrager om zelf de bshit te filteren van de potentiele waardevolle informatie niemand anders kan dat voor je doen het is nu eemaal een open forum en je gaat zelden een kant en klaar antwoord vinden enkel puzzelstukjes met vaak duplicaten. Bedenk verder dat de meeste hier waarschijnlijk veel geld vragen in hun dagelijkse leven voor dit soort adviezen en gratis jou ondersteunen in hun pauze tijd of tussen opdrachten in uit verveling of uit passie voor het vak of sympathie voor je situatie.

Maar het helpt je absoluut niet als je vervolgens tegen al die mensen gaat zeggen dat je meer ervaringen hebt in networking dan anderen terwijl je wel hulp vraagt om exact dat vakgebied. Drop the ego niemand interesseert het of je certificaten hebt jaren ervaring in het vak of beginner bent als het *niet relevant is voor de aanvraag nog je oplossing.


Ik denk zoals de meeste hier niet dat je resolver de issue is Maar uitsluiten kan nooit kwaad.
De enige meer voorkomende situatie die ik me kan bedenken omtrent resolvers op client niveau is als je je hosts file hebt volgepropt met domain rules die bouncen of simpelweg te veel lookups generen voor de hardware die je in gebruik hebt. Server resolvers zijn een pain in the butt maar windows client niveau is flushdns vaak alles dat nodig is.

Doe met de adviezen wat je wilt maar als bijna iedereen zegt dat iets wat je wilt bereiken niet zo 1 2 3 gaat dan misschien tijd om je aanpak te veranderen in plaats van conclussie te trekken dat mensen niet begrijpen wat je bedoeld. En mocht je dat niet willen probeer anders je vraag in ChatGPT of soortgelijke LMM bot te stellen. Kun je misschien zelf wat in elkaar knutselen. Heb je nog steeds wel kennis nodig over het onderwerp om werkend prototype te maken maar je zegt dat te hebben dus dat moet wel goedkomen.

https://www.grc.com/dns/benchmark.htm

Natuurlijk kan dat WEL!
Je kunt in javascript een connectie maken met een site met naam als parameter dus daarvan is de DNS lookup een deel.[/quote]In Firefox is een DNS lookup mogelijk met javascript:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns/resolve
Toch gaat dit hoogstwaarschijnlijk geen reëel beeld van de performance geven, vanwege hetgeen in de allereerste reactie in deze thread genoemd wordt.

Oh je stelt een vraag op een openbaar forum, stelt zeer exacte eisen aan welke reacties wel of niet toegestaan zijn, en gedraagt je dan als een hork als je je zin niet krijgt? Doei!

????
Je komt zelf aanzetten met deze tool, zegt dat het is wat je zoekt, maar dat je het op windows wilt gebruiken.
Ik geef 2 manieren om dat eventueel te doen en vervolgens reageer je dat het niet is wat je zoekt...

Nou, dan zeg ik: "zoek het lekker verder maar uit, ik ga hier geen energie meer in steken."

Uiteindelijk na lang zoeken en testen vanaf een Linux systeem ontdekt dat het pobleem inderdaad niet zit in de resolver
maar in de client devices zelf. En dan met name in het USB3 docking station waar zowel de netwerk verbinding als
twee 1920x1200 schermen aan hangen. Dat is kennelijk teveel gevraagd, met een nieuwer type docking station werkt
het wel goed. Dit probleem is ook wel terug te vinden met googlen als je het eenmaal weet.
Hoe het kan dat bijv een speedtest wel goed werkt maar webbrowsen niet dat kan ik echter niet verklaren.

Thx voor de update.
Onverwacht dat het aan een USB3 dock blijkt te liggen .
Kun je nog URL delen naar het/ probleem/forum/apparaat waar je meer informatie erover vond ?

Het voornaamste verschil tussen een speedtest en 'webbrowsen' is dat een speedtest een enkele verkeersstroom is , en 'webbrowsen' een hoop sessies zijn (een DNS lookup is een 'sessie', en al die verschillende HTTP requesten ook) .

Ik snap alleen niet goed waarom een ding als een USB3 dock gevoelig is voor dat verschil - het is wel 'normaal' bij "netwerk-intelligentie" apparaten (NAT, firewalls etc) om vooral # nieuwe flows als beperking te hebben, maar voor zo'n USB dock snap ik dat niet .
Het andere verschil - ietwat packetloss in een lopende sessie is veel minder voelbaar dan packetloss tijdens DNS lookup dan wel sessie-setup (syn/syn-ack) . Maar 'ietwat packetloss' zou een behoorlijk slechte speed test moeten geven, feitelijk.

Het gaat om de Dell D6000. Inderdaad heel vreemd dat dit zo gaat, ik zou denken dat dit ding alleen op ethernet packet nivo werkt en niets weet van connecties. Ik heb niet kunnen vaststellen dat DNS lookups faalden, dat was juist wat ik wilde testen. Maar het gedrag leek er sterk op: als je een sitenaam intikte in de adresbalk opende die traag, ging je rondklikken in de site dan was dat meestal een stuk sneller. En opnieuw openen ook.

Volgende stap is onderzoek wanneer het nou precies fout gaat, bijv of 1 scherm wel OK is. Die google resultaten wijzen wel een beetje in die richting maar zelf nog niet geprobeerd.
De nieuwere Dell WD19S docks die we later gekocht hebben (december 2022) die hebben dit probleem niet, dat is wel vastgesteld.

Je kunt toch net als bij een DNS leak test een lokale lookup doen via JS en die value vergelijken met de website data of hoe werkt zo een leak detector??

Je schreef over testen met Linux - was dat op een ander systeem, of met Linux in hetzelfde op dezelfde laptop+dock ?

Uit 'dock' maak ik op 'bedraad netwerk ' - klopt dat ? En weet je 100% zeker dat je bedraad/via dock werkt tijdens de storingen ?

Als de bedrade verbinding wegvalt en de laptop dan overschakelt op Wifi heb je tijdens dat schakelmoment natuurlijk een heel merkbare vertraging .

Verder wordt het steeds interessanter om een packet capture te hebben - en liefst meerdere :

Eentje op een device dat in het probleem-dock hangt, en indien mogelijk ook eentje van het netwerk achter het dock.

Het mooie van twee parallele captures zou zijn dat je echt precies ziet "ik stuur een frame erin, en de capture achter het dock ziet die niet meer. Of andersom - een frame op het netwerk naar de laptop is er, maar komt niet aan in de capture op de laptop ".

Maar uit captures op de client in het dock kun je al heel goed afleiden meestal dat/welke frames gedropt zijn.

Dan zou je goed het verschil moeten zien tussen 'browsen' en 'speedtest' .

Nee dat was een heel ander systeem, geen laptop, wat alleen voor een test was.


Ja de manier waarop we ontdekten dat het daar aan lag was dat als je de netwerkverbinding uit de dock trekt, en de laptop dus overschakelt op WiFi, het probleem weg is.
Ik ga nu eerst kijken wat de specs zijn van die dock en hoe dat "video over USB3" eigenlijk technisch werkt.
Want ik kan me best voorstellen dat 2 monitoren van 1920x1200 plus netwerk gewoon teveel gevraagd is voor 1 USB3 van de versie die daar in zit (dit wordt steeds sneller dus moet kijken welke spec het precies is).

Zelf bouwen voor Firefox/Firefox Android met dns.resolve(), of met node.js. Ik zie graag de url tegemoed...