Security Professionals
- ipfw add deny all from eindgebruikers to any
DNS cache en OCSP errors
30-01-2015, 13:13 door Erik van Straten, 19 reacties
Windows en (volgens https://documentation.cpanel.net/display/CKB/How+To+Clear+Your+DNS+Cache) ook Mac OS X hebben een DNS cache service draaien. Die zorgt ervoor dat als een programma kort na elkaar DNS lookups doet, dit niet tot aanvragen naar een DNS server leidt; in plaats daarvan zegt Windows "oh dat weet ik nog wel" en beantwoordt de vraag.
DNS caches kunnen echter tot problemen leiden bij "Round-robin" DNS (https://en.wikipedia.org/wiki/Round-robin_DNS); zojuist liep ik hier tegenaan en wellicht heeft iemand er iets aan om te begrijpen wat de oorzaak is en hoe je problemen kunt proberen op te lossen.
Firefox (ESR v31.4.0) heb ik geconfigureerd voor verplichte OCSP checks. Dat wil zeggen dat als het Firefox niet lukt om na te vragen of een SSL certificaat is ingetrokken, dit tot een foutmelding moet leiden (de standaard instelling van Firefox is om, bijv. bij verbindingsproblemen met de OCSP server, er maar vanuit te gaan dat het wel goed zal zitten).
Terzijde: in recente Firefox versies ontbreekt een GUI dialoogbox om deze instelling te wijzigen, zie https://www.security.nl/posting/410482/Mozilla+dicht+9+lekken+in+Firefox+34+en+schakelt+SSLv3+uit#posting410509 (en evt. https://www.security.nl/posting/411405/Gevaarlijke+malware+gesigneerd+met+Sony-certificaat#posting411441).
De https server die ik probeerde te bezoeken gebruikt een certificaat ondertekend door Globalsign, en dat certificaat bevat "http://ocsp2.globalsign.com/gsorganizationvalg2" als URL om, gebruikmakend van het OCSP protocol, na te vragen of het betreffende certificaat is ingetrokken.
Om verbinding te kunnen maken met ocsp2.globalsign.com voerde Firefox een DNS request uit daarvoor, dat Windows doorzette naar de confonfigureerde DNS server. Als antwoord kreeg mijn PC de volgende IPv4 adressen, in deze volgorde:
Daarna probeerde Firefox meerdere keren verbinding te maken met 108.162.232.197 (het IP-adres van de eerste server uit het lijstje), en dat lukte niet. En dat leidde, na enkele seconden proberen, tot een OCSP foutmelding in Firefox. In Wireshark zag ik dat mijn PC maar liefst 12 TCP "SYN" pakketjes naar 108.162.232.197 stuurde, maar daar geen enkel antwoord op kreeg.
Vervolgens stuurde Firefox 10 TCP "SYN" pakketjes naar de eerstvolgende server uit bovenstaand lijstje, 108.162.232.207, waarna die server, 30 seconden na het eerste pakketje verzonden naar de 1e server en 9 seconden na het eerste pakketje verzonden naar deze server, een TCP "SYN.ACK" terugstuurde. Ook stuurde Firefox op de valreep nog enkele pakketjes naar de derde server uit het lijstje.
Echter, kennelijk was na 30 seconden al een OCSP timeout opgetreden en toonde Firefox de bijbehorende foutmelding, en kennelijk was dit ook aanleiding voor Firefox om de net opgebouwde verbindingen met de tweede en derde server uit het rijtje weer af te bouwen (zonder een OCSP request te verzenden).
Onder de OCSP foutmelding toont Firefox een retry button. En je raadt misschien al wat er gebeurt:
- Firefox vraag Windows opnieuw wat het IP-adres is van ocsp2.globalsign.com
- Windows heeft bovenstaand lijstje nog in cache en geeft dat terug
- Exact hetzelfde scenario herhaalt zich.
Dit kon ik doorbreken door een "cmd" prompt te starten en het volgende commando uit te voeren:
Dat commando draagt Windows op om de DNS cache leeg te maken. Overigens, in tegenstelling tot wat cpanel.net (de bovenste link in deze bijdrage) beschrijft, had ik daar (igelogd als ordinary user) geen adminrechten voor nodig.
Toen ik vervolgens op de "Retry" button onder de OCSP foutmelding in Firefox drukte, stuurde Windows een nieuwe DNS request naar de (lokale) DNS server, met het volgende antwoord als resultaat:
Oplettende lezers zullen zien dat niet alleen het eerste IP-adres anders is, maar ook dat de volgorde is gewijzigd. Er lijkt dus geen sprake van echte "Round-robin". Ik heb geen idee waarom dit zo is.
Opvallend is dat Firefox nu meteen verbinding maakte met de tweede server uit dit lijstje. Kennelijk had Firefox (onterecht) onthouden dat er een probleem was met 108.162.232.204. Hoe dan ook, de verbinding met 108.162.232.196 kwam meteen tot stand en het OSCP antwoord gaf aan dat het certificaat niet was ingetrokken.
Conclusie: als een dienstverlener gebruik maakt van Round-robin DNS (of andere variërende antwoorden) om de beschikbaarheid te verhogen, en een server (OCSP, maar ook andere servers waaronder websites) even niet bereikbaar is, kunnen DNS caches roet in het eten gooien. Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
DNS caches kunnen echter tot problemen leiden bij "Round-robin" DNS (https://en.wikipedia.org/wiki/Round-robin_DNS); zojuist liep ik hier tegenaan en wellicht heeft iemand er iets aan om te begrijpen wat de oorzaak is en hoe je problemen kunt proberen op te lossen.
Firefox (ESR v31.4.0) heb ik geconfigureerd voor verplichte OCSP checks. Dat wil zeggen dat als het Firefox niet lukt om na te vragen of een SSL certificaat is ingetrokken, dit tot een foutmelding moet leiden (de standaard instelling van Firefox is om, bijv. bij verbindingsproblemen met de OCSP server, er maar vanuit te gaan dat het wel goed zal zitten).
Terzijde: in recente Firefox versies ontbreekt een GUI dialoogbox om deze instelling te wijzigen, zie https://www.security.nl/posting/410482/Mozilla+dicht+9+lekken+in+Firefox+34+en+schakelt+SSLv3+uit#posting410509 (en evt. https://www.security.nl/posting/411405/Gevaarlijke+malware+gesigneerd+met+Sony-certificaat#posting411441).
De https server die ik probeerde te bezoeken gebruikt een certificaat ondertekend door Globalsign, en dat certificaat bevat "http://ocsp2.globalsign.com/gsorganizationvalg2" als URL om, gebruikmakend van het OCSP protocol, na te vragen of het betreffende certificaat is ingetrokken.
Om verbinding te kunnen maken met ocsp2.globalsign.com voerde Firefox een DNS request uit daarvoor, dat Windows doorzette naar de confonfigureerde DNS server. Als antwoord kreeg mijn PC de volgende IPv4 adressen, in deze volgorde:
108.162.232.197
108.162.232.207
108.162.232.204
108.162.232.199
108.162.232.200
108.162.232.196
108.162.232.202
108.162.232.201
108.162.232.203
108.162.232.205
108.162.232.198
108.162.232.207
108.162.232.204
108.162.232.199
108.162.232.200
108.162.232.196
108.162.232.202
108.162.232.201
108.162.232.203
108.162.232.205
108.162.232.198
Daarna probeerde Firefox meerdere keren verbinding te maken met 108.162.232.197 (het IP-adres van de eerste server uit het lijstje), en dat lukte niet. En dat leidde, na enkele seconden proberen, tot een OCSP foutmelding in Firefox. In Wireshark zag ik dat mijn PC maar liefst 12 TCP "SYN" pakketjes naar 108.162.232.197 stuurde, maar daar geen enkel antwoord op kreeg.
Vervolgens stuurde Firefox 10 TCP "SYN" pakketjes naar de eerstvolgende server uit bovenstaand lijstje, 108.162.232.207, waarna die server, 30 seconden na het eerste pakketje verzonden naar de 1e server en 9 seconden na het eerste pakketje verzonden naar deze server, een TCP "SYN.ACK" terugstuurde. Ook stuurde Firefox op de valreep nog enkele pakketjes naar de derde server uit het lijstje.
Echter, kennelijk was na 30 seconden al een OCSP timeout opgetreden en toonde Firefox de bijbehorende foutmelding, en kennelijk was dit ook aanleiding voor Firefox om de net opgebouwde verbindingen met de tweede en derde server uit het rijtje weer af te bouwen (zonder een OCSP request te verzenden).
Onder de OCSP foutmelding toont Firefox een retry button. En je raadt misschien al wat er gebeurt:
- Firefox vraag Windows opnieuw wat het IP-adres is van ocsp2.globalsign.com
- Windows heeft bovenstaand lijstje nog in cache en geeft dat terug
- Exact hetzelfde scenario herhaalt zich.
Dit kon ik doorbreken door een "cmd" prompt te starten en het volgende commando uit te voeren:
ipconfig /flushdns
Dat commando draagt Windows op om de DNS cache leeg te maken. Overigens, in tegenstelling tot wat cpanel.net (de bovenste link in deze bijdrage) beschrijft, had ik daar (igelogd als ordinary user) geen adminrechten voor nodig.
Toen ik vervolgens op de "Retry" button onder de OCSP foutmelding in Firefox drukte, stuurde Windows een nieuwe DNS request naar de (lokale) DNS server, met het volgende antwoord als resultaat:
108.162.232.204
108.162.232.196
108.162.232.198
108.162.232.197
108.162.232.201
108.162.232.200
108.162.232.205
108.162.232.199
108.162.232.207
108.162.232.203
108.162.232.202
108.162.232.196
108.162.232.198
108.162.232.197
108.162.232.201
108.162.232.200
108.162.232.205
108.162.232.199
108.162.232.207
108.162.232.203
108.162.232.202
Oplettende lezers zullen zien dat niet alleen het eerste IP-adres anders is, maar ook dat de volgorde is gewijzigd. Er lijkt dus geen sprake van echte "Round-robin". Ik heb geen idee waarom dit zo is.
Opvallend is dat Firefox nu meteen verbinding maakte met de tweede server uit dit lijstje. Kennelijk had Firefox (onterecht) onthouden dat er een probleem was met 108.162.232.204. Hoe dan ook, de verbinding met 108.162.232.196 kwam meteen tot stand en het OSCP antwoord gaf aan dat het certificaat niet was ingetrokken.
Conclusie: als een dienstverlener gebruik maakt van Round-robin DNS (of andere variërende antwoorden) om de beschikbaarheid te verhogen, en een server (OCSP, maar ook andere servers waaronder websites) even niet bereikbaar is, kunnen DNS caches roet in het eten gooien. Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Reacties (19)
Flush DNS Cache OS X
Af en toe de DNS cache legen onder OS X kan soms inderdaad uitkomst voor problemen bieden.
Daarnaast lijkt het me vanuit security oogpunt ook geen gek idee dat met enige regelmaat even te doen (neem het mee met het periodieke moment bij het dingetjes doorlopen).
OS X Yosemite 10.10
How to Flush DNS Cache in OS X Yosemite with discoveryutil
http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/
OS X Mavericks 10.9 tot en met OS X 10.3
How to Flush DNS Cache in Mac OS X
http://osxdaily.com/2008/03/21/how-to-flush-your-dns-cache-in-mac-os-x/
Af en toe de DNS cache legen onder OS X kan soms inderdaad uitkomst voor problemen bieden.
Daarnaast lijkt het me vanuit security oogpunt ook geen gek idee dat met enige regelmaat even te doen (neem het mee met het periodieke moment bij het dingetjes doorlopen).
OS X Yosemite 10.10
How to Flush DNS Cache in OS X Yosemite with discoveryutil
http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/
OS X Mavericks 10.9 tot en met OS X 10.3
How to Flush DNS Cache in Mac OS X
http://osxdaily.com/2008/03/21/how-to-flush-your-dns-cache-in-mac-os-x/
30-01-2015, 14:41 door
[Account Verwijderd]
-
Bijgewerkt: 30-01-2015, 14:43
[Verwijderd]
30-01-2015, 16:21 door
Erik van Straten
30-01-2015, 14:41 door pe0mot: Je schrijft dat Firefox 10x een SYN stuurt, maar is dat niet de Microsoft TCP stack die dat doet?
Of is het Firefox die 10x een TCP sessie opstart zonder het eerste resultaat af te wachten?
Met WireShark zie ik uitgaand verkeer, via WinPCap ergens "omstreeks" de netwerkkaartdriver vermoed ik. Ik neem aan dat Firefox niet zelf TCP sessies afhandelt maar via Windows API een socket probeert te openen. Eerlijk gezegd weet ik helemaal niet of Firefox dan wel Microsoft de sessies opstart die ik beschreef. Wellicht had ik moeten vermelden, sorry voor evt. verwarring daarover!Of is het Firefox die 10x een TCP sessie opstart zonder het eerste resultaat af te wachten?
Wel weet ik dat ik in Wireshark geen DNS lookups meer heb gezien (voor ocsp2.globalsign.com) totdat ik "ipconfig /flushdns" draaide.
Gisteren had ik ook al een paar OCSP errors bij het bezoeken van https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen, helaas heb ik toen geen Wireshark gestart om te kijken waardoor dat kwam. Even later werkte OCSP weer wel.
30-01-2015, 14:41 door pe0mot: Ook interessant of Firefox zelf 1x of 10x een DNSlookup doet of dat door het OS laat afhandelen.
Ik weet zo goed als zeker door Windows, want wijzigingen in de hosts file hebben invloed op Firefox (ik kan me niet voorstellen dat Firefox zelf de hosts file parst).30-01-2015, 14:41 door pe0mot: Bij Chrome zag ik ook eigenzinnig gedrag wat niet met de resultaten van nslookup was te rijmen.
Het zou mij niet verbazen als Chrome (ook?) van Google DNS servers gebruik maakt, en die hebben zo hun eigen beleid. Op 12 jan. resolvde iec.ch (en *.iec.ch) niet meer (geen authoritative server), maar via 8.8.8.8 kon ik IP-adressen nog gewoon achterhalen, en (na een entry in m'n hosts file te hebben gemaakt) een berichtje op hun website achterlaten.30-01-2015, 14:41 door pe0mot: Interessant is ook om te weten of Microsoft zich aan de standaard IETF RFC's heeft gehouden als het gaat om TCP SYN time-out en DNS gedrag!
Vast niet voor 100%, Microsoft kennende ;)Oftewel de vraag is of we de standaard, of Firefox/Chrome of Microsoft moeten aanpassen?
In dit geval denk ik dat Globalsign beter een goede load balancer achter 1 publiek IP-adres kan zetten, dan deels onbereikbare OCSP servers te hebben en op Round-robin-DNS-achtige constructies te vertrouwen. DNS caches kunnen op meerdere "plekken onderweg" zitten, niet alleen op lokale PC's.Beter nog is als steeds meer sites van OCSP-stapling gebruik gaan maken, want met de toename aan DDoS aanvallen zijn OCSP servers een leuk target als je, als aanvaller, private keys behorend bij SSL- en/of code signing certificaten hebt weten te bemachtigen.
Door Erik van Straten:
Conclusie: als een dienstverlener gebruik maakt van Round-robin DNS (of andere variërende antwoorden) om de beschikbaarheid te verhogen, en een server (OCSP, maar ook andere servers waaronder websites) even niet bereikbaar is, kunnen DNS caches roet in het eten gooien. Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Conclusie: als een dienstverlener gebruik maakt van Round-robin DNS (of andere variërende antwoorden) om de beschikbaarheid te verhogen, en een server (OCSP, maar ook andere servers waaronder websites) even niet bereikbaar is, kunnen DNS caches roet in het eten gooien. Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Deze nomineer ik voor de "open deur van de dag"....
30-01-2015, 17:06 door
[Account Verwijderd]
[Verwijderd]
Door Erik van Straten:
Oftewel de vraag is of we de standaard, of Firefox/Chrome of Microsoft moeten aanpassen?
In dit geval denk ik dat Globalsign beter een goede load balancer achter 1 publiek IP-adres kan zetten, dan deels onbereikbare OCSP servers te hebben en op Round-robin-DNS-achtige constructies te vertrouwen. DNS caches kunnen op meerdere "plekken onderweg" zitten, niet alleen op lokale PC's.Een loadbalancer geeft je alleen maar redundantie voor een server die in hetzelfde datacenter van dezelfde ISP achter dezelfde verbindingen staat.
Echt wereldwijd HA/load balancing vergt een mix van technieken, en loadbalancers in een datacenter kan een component zijn *voor één locatie*.
'Plain' Round Robin DNS is wel een tecniek die de clients kan spreiden over meerdere locaties,maar beter is om de DNS antwoorden (met korte TTL) afhankelijk te maken van waar de vraag van de client vandaan komt (lage latency), en natuurlijk of het betreffende datacenter uberhaupt bereikbaar is.
Het teruggegeven IP adres kan dan nog van een loadbalancer zijn die de betreffende locatie robuust maakt.
Beter nog is als steeds meer sites van OCSP-stapling gebruik gaan maken, want met de toename aan DDoS aanvallen zijn OCSP servers een leuk target als je, als aanvaller, private keys behorend bij SSL- en/of code signing certificaten hebt weten te bemachtigen.
Security en (high)availability staan zo'n beetje altijd haaks op elkaar.
In jouw configuratie is een DOSje op OCSP servers dus genoeg om de site van het certificaat (voor jou, en vergelijkbare config) onbereikbaar te maken.
30-01-2015, 16:42 door Anoniem:
Deze nomineer ik voor de "open deur van de dag"....
Daar heb je gelijk in. Alleen vertelt Firefox je, bij zo'n OCSP foutmelding, niet wat er aan de hand is (iets vaags met OCSP server error). En al helemaal niet dat er een probleem is met 1 IP-adres terwijl er meerdere zijn aangeboden.30-01-2015, 13:13 door Erik van Straten:
Conclusie: als een dienstverlener gebruik maakt van Round-robin DNS (of andere variërende antwoorden) om de beschikbaarheid te verhogen, en een server (OCSP, maar ook andere servers waaronder websites) even niet bereikbaar is, kunnen DNS caches roet in het eten gooien. Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Conclusie: als een dienstverlener gebruik maakt van Round-robin DNS (of andere variërende antwoorden) om de beschikbaarheid te verhogen, en een server (OCSP, maar ook andere servers waaronder websites) even niet bereikbaar is, kunnen DNS caches roet in het eten gooien. Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Deze nomineer ik voor de "open deur van de dag"....
De verleiding is op zo'n moment groot om mandatory OCSP checking maar uit te zetten, wat ik probeer aan te geven is dat een DOS-boxje starten en genoemd commando draaien op zo'n moment kan helpen.
30-01-2015, 19:50 door Anoniem:
Security en (high)availability staan zo'n beetje altijd haaks op elkaar.
In jouw configuratie is een DOSje op OCSP servers dus genoeg om de site van het certificaat (voor jou, en vergelijkbare config) onbereikbaar te maken.
Bij "gewone" OCSP wil elke webbrowser direct antwoord van een OCSP server van een certificate authority. Bij OCSP stapling vraagt de webserver regelmatig aan een OCSP-achtige server van de certificate authority een bewijs (met beperkte geldigheidsduur, dus veel minder tijdkritisch) dat het certificaat nog niet is ingetrokken en stuurt dat mee naar bezoekende webbrowsers.30-01-2015 16:21, door Erik van Straten: Beter nog is als steeds meer sites van OCSP-stapling gebruik gaan maken, want met de toename aan DDoS aanvallen zijn OCSP servers een leuk target als je, als aanvaller, private keys behorend bij SSL- en/of code signing certificaten hebt weten te bemachtigen.
Security en (high)availability staan zo'n beetje altijd haaks op elkaar.
In jouw configuratie is een DOSje op OCSP servers dus genoeg om de site van het certificaat (voor jou, en vergelijkbare config) onbereikbaar te maken.
Door Erik van Straten:
De verleiding is op zo'n moment groot om mandatory OCSP checking maar uit te zetten, wat ik probeer aan te geven is dat een DOS-boxje starten en genoemd commando draaien op zo'n moment kan helpen.
30-01-2015, 16:42 door Anoniem:
Deze nomineer ik voor de "open deur van de dag"....
Daar heb je gelijk in. Alleen vertelt Firefox je, bij zo'n OCSP foutmelding, niet wat er aan de hand is (iets vaags met OCSP server error). En al helemaal niet dat er een probleem is met 1 IP-adres terwijl er meerdere zijn aangeboden.30-01-2015, 13:13 door Erik van Straten:
Conclusie: als een dienstverlener gebruik maakt van Round-robin DNS (of andere variërende antwoorden) om de beschikbaarheid te verhogen, en een server (OCSP, maar ook andere servers waaronder websites) even niet bereikbaar is, kunnen DNS caches roet in het eten gooien. Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Conclusie: als een dienstverlener gebruik maakt van Round-robin DNS (of andere variërende antwoorden) om de beschikbaarheid te verhogen, en een server (OCSP, maar ook andere servers waaronder websites) even niet bereikbaar is, kunnen DNS caches roet in het eten gooien. Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Deze nomineer ik voor de "open deur van de dag"....
De verleiding is op zo'n moment groot om mandatory OCSP checking maar uit te zetten, wat ik probeer aan te geven is dat een DOS-boxje starten en genoemd commando draaien op zo'n moment kan helpen.
Ja maar dit is gewoon een combinatie van wanbeheer bij de OCSP provider en/of haar DNS provider, gecombineerd met
bugs in de client die je gebruikt. (die vaak weer ingebouwd worden om andere bugs te bestrijden, zoals "het duurt zo
lang voor er een foutmelding komt").
Als een service loadbalancing wil bieden dan is het onverstandig om zo veel adressen in 1 DNS reply te zetten. Gebruik
een slimmere DNS server die een kleine subset van de beschikbare adressen retourneert, met een kleine TTL, en die
alleen adressen retourneert van servers die op dat moment "up" zijn en in staat om requests te verwerken met redelijke
performance. Daar voldoet jouw OCSP server niet aan, die heeft wellicht een antieke DNS server die een statische
set adressen teruggeeft die alleen roteert. Niet meer inzetbaar in deze tijd, dat soort spul.
Daarnaast moet een client als hij meerdere adressen terug krijgt in een DNS reply deze allemaal langs gaan tot het
wel lukt. Maar dat doet Firefox kennelijk niet. Zoals gezegt, wellicht als ze dat wel zouden doen zou het naar de zin
van de gebruiker te lang duren.
Wat je ook keer op keer tegenkomt in dit soort gevallen is dat fail/succes resultaten niet gecached worden, waardoor
het probleem bij iedere klik weer terug komt (niet bij OCSP wellicht maar wel bij HTTP in het algemeen).
30 januari 2015 13:13 door Erik van Straten:
Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Firefox heeft zo te zien zelf ook een DNS-cache:
zie "about:config" de optie "network.dnsCacheExperiation" (default 60 sec.)
Daarom nog even een controlevraag:
hielp dat commando "ipconfig /flushdns" nu wel werkelijk? Of werd je voor de gek gehouden?
Want door eerst 30 seconden te wachten totdat OCSP faalt, en daarna nog eens "ipconfig/flushdns" en retry te doen,
zijn die default 60 seconden van "network.dnsCacheExperiation" waarschijnlijk ook zo'n beetje om...
En dus heeft ook Firefox waarschijnlijk ondertussen automatisch stiekem zijn DNS-cache weer geleegd?
De hamvraag is dan: welke DNS-flush heeft er nou geholpen?......
Mvg, cluc-cluc
01-02-2015, 09:16 door
Erik van Straten
Ook door eerdere ervaring weet ik dat de Windows DNS cache "lang" gegevend bewaart (aanzienlijk meer dan 60 sec.), maar hoe lang weet ik niet.
01-02-2015, 10:31 door
Briolet
Door Anoniem: OS X Yosemite 10.10
How to Flush DNS Cache in OS X Yosemite with discoveryutil
http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/
How to Flush DNS Cache in OS X Yosemite with discoveryutil
http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/
Met de introductie van Yosemite heeft Apple inderdaad afstand genomen van mDNSResponder voor DNS queries. De beschreven methode voor het flushen van de DNS caches onder Yosemite werkt echter niet voor mensen die alles vanuit een user account doen. Je moet nml. een 'sudo' command gebruiken en dat kan alleen vanuit een account met administrator rechten.
En dan heb je nog het probleem als je een eigen dns server hebt runnen. Die van mij cached alles 24 uur, dus dan is het flushen van je PC cache niet genoeg.
Door Erik van Straten: Ook door eerdere ervaring weet ik dat de Windows DNS cache "lang" gegevend bewaart (aanzienlijk meer dan 60 sec.), maar hoe lang weet ik niet.
Hoe lang de DNS gegevens bewaard mogen worden dat staat in ieder DNS record.Voor standaard statische gegevens is dat vaak 1 dag.
Voor dynamische gegevens zoals de beste server om te connecten zal dat veel korter zijn.
Ook door eerdere ervaring weet ik dat de Windows DNS cache "lang" gegevend bewaart (aanzienlijk meer dan 60 sec.), maar hoe lang weet ik niet.
FYI: erg waardevolle details over MS Windows DNS-cache vond ik hier:http://support.microsoft.com/kb/318803
Hierin wordt het "Round Robin" probleem inderdaad bevestigd, en wordt beschreven hoe je de MS Windows DNS cache helemaal naar je hand kunt zetten. Indien nodig door bijv. de Windows DNS cache tijd in de registry aan te passen.
Voor een toepassing als alleen maar wat met een browser op het internet surfen is het misschien het makkelijkst
om Windows DNS cache helemaal uit te zetten door in Windows de "DNS Client" service op "uitgeschakeld" te zetten.
(ga naar "start" -> "uitvoeren" en type in "services.msc". Zoek dan in de lijst met services: "DNS Client" , dubbelklik of ga
via het rechter muisknopmenu naar "eigenschappen", en zet vervolgens "opstarttype" op "uitgeschakeld" en dan "OK")
P.S: Firefox heeft altijd nog een default caching van 60 seconden, dus je behoudt als het goed is altijd nog een minuutje caching tijdens het surfen, waardoor de surfsnelheid meestal niet merkbaar achteruit gaat als je Windows caching uitzet.
Doe er je voordeel mee.
Mvg, cluc-cluc
Door Anoniem:
Firefox heeft zo te zien zelf ook een DNS-cache:
zie "about:config" de optie "network.dnsCacheExperiation" (default 60 sec.)
Daarom nog even een controlevraag:
hielp dat commando "ipconfig /flushdns" nu wel werkelijk? Of werd je voor de gek gehouden?
Want door eerst 30 seconden te wachten totdat OCSP faalt, en daarna nog eens "ipconfig/flushdns" en retry te doen,
zijn die default 60 seconden van "network.dnsCacheExperiation" waarschijnlijk ook zo'n beetje om...
En dus heeft ook Firefox waarschijnlijk ondertussen automatisch stiekem zijn DNS-cache weer geleegd?
De hamvraag is dan: welke DNS-flush heeft er nou geholpen?......
Mvg, cluc-cluc
30 januari 2015 13:13 door Erik van Straten:
Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Firefox heeft zo te zien zelf ook een DNS-cache:
zie "about:config" de optie "network.dnsCacheExperiation" (default 60 sec.)
Daarom nog even een controlevraag:
hielp dat commando "ipconfig /flushdns" nu wel werkelijk? Of werd je voor de gek gehouden?
Want door eerst 30 seconden te wachten totdat OCSP faalt, en daarna nog eens "ipconfig/flushdns" en retry te doen,
zijn die default 60 seconden van "network.dnsCacheExperiation" waarschijnlijk ook zo'n beetje om...
En dus heeft ook Firefox waarschijnlijk ondertussen automatisch stiekem zijn DNS-cache weer geleegd?
De hamvraag is dan: welke DNS-flush heeft er nou geholpen?......
Mvg, cluc-cluc
network.dnsCacheExpiration;60
Wanneer je deze tijdelijk op een veel hogere waarde zou zetten (6000?) heb je voldoende tijd om te kijken welk effect welke DNS-flush heeft.
Zou ik denken
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Losse Marginaaltjes / categorie overig
Door Briolet:
De beschreven methode voor het flushen van de DNS caches onder Yosemite werkt echter niet voor mensen die alles vanuit een user account doen. Je moet nml. een 'sudo' command gebruiken en dat kan alleen vanuit een account met administrator rechten.
Daar heb je hem weer met zijn 'maar ik heb een uitzondering gevonden waarin dat niet zo is'.Door Anoniem: OS X Yosemite 10.10
How to Flush DNS Cache in OS X Yosemite with discoveryutil
http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/
How to Flush DNS Cache in OS X Yosemite with discoveryutil
http://osxdaily.com/2014/11/20/flush-dns-cache-mac-os-x/
De beschreven methode voor het flushen van de DNS caches onder Yosemite werkt echter niet voor mensen die alles vanuit een user account doen. Je moet nml. een 'sudo' command gebruiken en dat kan alleen vanuit een account met administrator rechten.
Man man man, dan schakel je even over naar je admin account !
De gedachte aan de moeite alleen al... ?
Daarnaast is het vooralsnog (helaas) zo dat heel veel gebruikers standaard werken onder dat admin account, die hoeven dus niet te switchen.
En dan heb je nog het probleem als je een eigen dns server hebt runnen. Die van mij cached alles 24 uur, dus dan is het flushen van je PC cache niet genoeg.
Dat is dan vooral weer jouw specifieke probleem waar je vast heel erg last van hebt in het door Erik geconstateerde geval. Oplossing gevonden en bedacht?
Of überhaubt geen moeite genomen om daar ook maar naar te kijken ?
Wat is je doel toch iedere keer met dat gemuggezift ?
Kom toch eens met constructieve bijdragen, met oplossingen voor eventuele problemen in plaats van het plaatsen van voetnootjes in kantlijntjes.
Hoe staat het met je overige OS X & Yosemite kennis inmiddels?
Vordert dat inhoudelijk daadwerkelijk nou een beetje? Ben je er al achter waar stoute Java zich had verstopt?
Of was dat verder ook niet meer interessant en je doel ook niet om je alsnog daadwerkelijk in OS X materie te verdiepen ?
Door Anoniem:
network.dnsCacheExpiration;60
Wanneer je deze tijdelijk op een veel hogere waarde zou zetten (6000?) heb je voldoende tijd om te kijken welk effect welke DNS-flush heeft.
Zou ik denken
Wees gerust. Erik is intelligent genoeg om zoiets zelf te bedenken, en heeft er de juiste testomgeving voor Door Anoniem:
Firefox heeft zo te zien zelf ook een DNS-cache:
zie "about:config" de optie "network.dnsCacheExperiation" (default 60 sec.)
Daarom nog even een controlevraag:
hielp dat commando "ipconfig /flushdns" nu wel werkelijk? Of werd je voor de gek gehouden?
Want door eerst 30 seconden te wachten totdat OCSP faalt, en daarna nog eens "ipconfig/flushdns" en retry te doen,
zijn die default 60 seconden van "network.dnsCacheExperiation" waarschijnlijk ook zo'n beetje om...
En dus heeft ook Firefox waarschijnlijk ondertussen automatisch stiekem zijn DNS-cache weer geleegd?
De hamvraag is dan: welke DNS-flush heeft er nou geholpen?......
Mvg, cluc-cluc
30 januari 2015 13:13 door Erik van Straten:
Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Het commando "ipconfig /flushdns" lijkt te kunnen helpen in dit soort situaties.
Firefox heeft zo te zien zelf ook een DNS-cache:
zie "about:config" de optie "network.dnsCacheExperiation" (default 60 sec.)
Daarom nog even een controlevraag:
hielp dat commando "ipconfig /flushdns" nu wel werkelijk? Of werd je voor de gek gehouden?
Want door eerst 30 seconden te wachten totdat OCSP faalt, en daarna nog eens "ipconfig/flushdns" en retry te doen,
zijn die default 60 seconden van "network.dnsCacheExperiation" waarschijnlijk ook zo'n beetje om...
En dus heeft ook Firefox waarschijnlijk ondertussen automatisch stiekem zijn DNS-cache weer geleegd?
De hamvraag is dan: welke DNS-flush heeft er nou geholpen?......
Mvg, cluc-cluc
network.dnsCacheExpiration;60
Wanneer je deze tijdelijk op een veel hogere waarde zou zetten (6000?) heb je voldoende tijd om te kijken welk effect welke DNS-flush heeft.
Zou ik denken
(incl. Wireshark) om daarmee onmiddellijk adequaat vast te stellen wat er precies op het netwerk gebeurt.
Cluc-cluc had daar misschien toen geen tijd of middelen voor, of geen zin in (het is tenslotte niet zijn probleem).
Verder lijkt mij het probleem in een vervolgreactie van diezelfde cluc-cluc (#14:41 door Anoniem) zo goed als opgelost.
Cluc-cluc heeft klaarblijkelijk een ander pad bewandelt dan uittesten, en met een nuttig, degelijk resultaat.
Behalve misschien dat het nogal gericht is op Windows XP. Dus met het risico dat het in nieuwere Windows versies er soms net even anders aan toe zou kunnen gaan. Maar ook daar komen de meeste mensen met goeie wil vast zelf wel uit.
Mensen zoals Erik hebben aan een korte hint wel genoeg. (en nog welbedankt cluc-cluc en Erik! Ik had zelf weliswaar
(nog) niet zo merkbaar last van het geschetste probleem, maar allemaal best handig om te weten!)
Ik herstart Firefox (OSX) een paar keer en daarna geen OCSP errors meer op een bepaalde site.
Daaruit concludeer ik dat het niet in de cache van Firefox zit.
Ik zal
Daaruit concludeer ik dat het niet in de cache van Firefox zit.
Ik zal
sudo dscacheutil -flushcache
eens proberen bij een eventueel volgende keer.
02-02-2015, 09:41 door
Erik van Straten
01-02-2015, 12:15 door Anoniem:
Voor standaard statische gegevens is dat vaak 1 dag.
Voor dynamische gegevens zoals de beste server om te connecten zal dat veel korter zijn.
Ik heb de Wireshark capture nog even nagekeken: in elke DNS response is het "Time To Live" veld voor alle geretourneerde IP-adressen steeds hetzelfde. Tussen de verschillende antwoorden die ik geregistreerd heb, varieerde de waarde tussen 40 en 293 (vermoedelijk is de hoogste waarde die je tegen kunt komen 300).Door Erik van Straten: Ook door eerdere ervaring weet ik dat de Windows DNS cache "lang" gegevend bewaart (aanzienlijk meer dan 60 sec.), maar hoe lang weet ik niet.
Hoe lang de DNS gegevens bewaard mogen worden dat staat in ieder DNS record.Voor standaard statische gegevens is dat vaak 1 dag.
Voor dynamische gegevens zoals de beste server om te connecten zal dat veel korter zijn.
01-02-2015, 14:41 door Anoniem:
http://support.microsoft.com/kb/318803
[...]
Mvg, cluc-cluc
Handige pagina, dank voor de link! De "value name" MaxCacheTtl ontbreekt bij mij in de registry (dus in de een of andere DLL gezet), en is kennelijk ongewijzigd sinds XP/2k3, want ipconfig /displaydns geeft voor entries in mijn hosts file als "Time To Live" waarde 86400.Ook door eerdere ervaring weet ik dat de Windows DNS cache "lang" gegevend bewaart (aanzienlijk meer dan 60 sec.), maar hoe lang weet ik niet.
FYI: erg waardevolle details over MS Windows DNS-cache vond ik hier:http://support.microsoft.com/kb/318803
[...]
Mvg, cluc-cluc
Echter als ik (met Wireshark aan) uitvoer: ping ocsp2.globalsign.com gevolgd door meerdere keren ipconfig /displaydns dan zie ik dat de Windows DNS client cache netjes de opgegeven TTL waarde heeft overgenomen, en met elke seconde (voor elk IP adres) verlaagt. Zodra de cached entries verdwenen zijn, leidt een volgende ping daadwerkelijk weer tot een DNS request zichtbaar in Wireshark. Mijn vorige conclusie dat de Windows DNS client cache gegevens altijd lang bewaart lijkt dus onjuist.
In het geval van ocsp2.globalsign.com lijkt het er dus op dat als de eerste server uit een rijtje IP-adressen niet reageert, het -als je pech hebt- tot 300 seconden (5 min.) kan duren voordat er een nieuwe DNS request uitgaat die tot een ander voorkeurs IP-adres kan leiden. Die 5 minuten is best lang vergeleken met de kennelijke OCSP-timeout van ca. 30 seconden in Firefox. Het commando ipconfig /flushdns lijkt op zo'n moment te kunnen helpen, mits er "onderweg" geen andere caching DNS server zit.
Door Erik van Straten:
In het geval van ocsp2.globalsign.com lijkt het er dus op dat als de eerste server uit een rijtje IP-adressen niet reageert, het -als je pech hebt- tot 300 seconden (5 min.) kan duren voordat er een nieuwe DNS request uitgaat die tot een ander voorkeurs IP-adres kan leiden. Die 5 minuten is best lang vergeleken met de kennelijke OCSP-timeout van ca. 30 seconden in Firefox. Het commando ipconfig /flushdns lijkt op zo'n moment te kunnen helpen, mits er "onderweg" geen andere caching DNS server zit.
In het geval van ocsp2.globalsign.com lijkt het er dus op dat als de eerste server uit een rijtje IP-adressen niet reageert, het -als je pech hebt- tot 300 seconden (5 min.) kan duren voordat er een nieuwe DNS request uitgaat die tot een ander voorkeurs IP-adres kan leiden. Die 5 minuten is best lang vergeleken met de kennelijke OCSP-timeout van ca. 30 seconden in Firefox. Het commando ipconfig /flushdns lijkt op zo'n moment te kunnen helpen, mits er "onderweg" geen andere caching DNS server zit.
Ja maar dit is dus een gevolg van een combinatie van bugs in je operating system en je browser.
Je operating system maakt de fout om zelf geen rotatie toe te passen in de cache waardoor de browser bij ieder verzoek
om de domeinnaam dezelfde lijst adressen in dezelfde volgorde krijgt, en de browser is ook niet slim want die doet ook
niks om daar omheen te werken (bijvoorbeeld zelf een random adres pakken ipv het 1e).
Ik denk dat Microsoft niet het geld en de middelen heeft om deze bug te fixen (staat immers al een jaar of 10 open), maar
wellicht kun je bij Firefox wat bereiken...
De "value name" MaxCacheTtl ontbreekt bij mij in de registry (dus in de een of andere DLL gezet)
Bedoel je dat Microsoft het waarschijnlijk in "post-XP"-versies van Windows in één of andere DLL heeft gezet?Heb je al geprobeerd om "MaxCacheTtl" met de hand aan de registry toe te voegen?
Kun je vervolgens eens proberen om "MaxCacheTtl" een lage waarde van bijv. 5 of 10 sec. te geven.
Toch twijfel ik nog steeds of daar wel het probleem zit.
Want het is ingewikkeld. Wat ik niet zeker weet, is of bijv. ook jouw router nog DNS cached?
En moet de externe DNS-server er niet voor zorgen dat de volgorde van opgegeven IP-adressen
bij iedere request wisselt? Immers volgens wikipedia:
"The order in which IP addresses from the list are returned is the basis for the term round robin."
Doet ie dat wel? Of blijft de opgegeven volgorde van je externe DNS-server gedurende een hele TTL-periode
van bijv. 5 minuten steeds hetzelfde? Ook bij uitgeschakelde DNS-cache? Het zou mij niets verbazen.
En volgens wat je aanvankelijk vertelde, heeft Firefox binnen 30 seconden toch nog drie IP's geprobeerd!
Hoe kan dat?
Als de Windows DNS-cache binnen die tijd niet veranderde, dan moet het volgens mij Firefox zelf zijn
die na een poosje "op het idee kwam" om dan maar eens een volgende IP uit de Round-Robin-lijst te proberen.
Waar je tegenaan bent gelopen, is volgens mij een limitatie van het OCSP-verificatiesysteem
dat optreedt bij netwerkcongestie of als meerdere OCSP-servers min of meer overbelast raken.
Dat zal ook de hoofdreden zijn dat Firefox de settings voor OCSP default zo heeft ingesteld dat hij "genadig" doorgaat
met het laden van de gekozen website in geval er niet op tijd een OCSP-antwoord komt.
En anders zul je voor lief moeten nemen dat je soms meemaakt wat je nu aan den lijve hebt ondervonden.
De enige oplossing is dan om het na een poosje opnieuw te proberen.
Wat ik overigens zelf eens heb gedaan: ik heb willekeurig één van de OCSP-servers uit de Round-Robin-lijst in mijn hosts-file gezet. (gewoon de OCSP-server IP genomen die op dat moment goed werkte; je kunt evt. ook
de dichtstbijzijnde OCSP-server opzoeken). Nog geen problemen gehad. Wel meestal een paar seconden wachten.
Die ene IP kan eventueel ook gemakkelijk in je firewall. Zo wordt DNS omzeilt, en dus ook deze ellende.
Het ergste wat je kan overkomen, is dat men bij zeer grote drukte of bij het verdwijnen van de OCSP-functie
op dat ene specifieke IP-adres toch weer hetzelfde zal zien als jij. Maar daar weet ik dan wel raad mee.
En het voorkomt wellicht dat zoals in jouw voorbeeld een tamelijk late "SYN-ACK" door Firefox wordt genegeerd,
omdat Firefox zich zodoende 30 seconden lang blijft concentreren op dat ene specifieke OCSP IP-adres.
En verder is het wachten totdat (hopelijk) steeds meer webservers "OCSP-stapling" gaan gebruiken. ;-)
Mvg, cluc-cluc
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?