DNS caches slowest response
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 25/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- ocaml
- Ambito
- networking
Direzione di ricerca
Riproduci il comportamento con Docker per Windows eseguendo query dig ripetute per un hostname i cui server DNS LAN e WAN restituiscono indirizzi diversi. Usa la cattura Wireshark descritta per confrontare la prima query con quelle successive e analizzare la cache DNS di vpnkit. Il lavoro è completato quando le query successive dal container restituiscono sistematicamente la risposta corretta invece del risultato WAN più lento.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I'm running Docker For Windows, and noticed I was getting some strange results for DNS queries. The windows host machine has multiple DNS servers specified...
- LAN
- WAN
- Google (8.8.8.8)
We have an internal hostname that returns different results depending on which DNS server responds. The LAN DNS server will respond with an IP address on that LAN. The WAN DNS server will respond with an IP address from that subnet.
Just after Docker has been (re)started, doing a dig for the hostname inside a container returns the correct LAN address (vpnkit is presumable just returning the first answer it received). However all subsequent lookups for that hostname always return the incorrect WAN IP address.
Running a Wireshark capture on the Windows host, I can see that vpnkit sends the query off to all configured DNS servers the first time the lookup is done inside the container. The LAN DNS server responds first, so that is what gets returned to the docker container. However, all subsequent lookups only get sent to the LAN DNS and 8.8.8.8. Even though the WAN DNS server is not being queried, and the correct LAN IP address is being received by the host, the container is receiving the WAN IP address as the answer. Therefore, it would appear that after the first query, vpnkit has cached the slowest response and will always return that to the container.
- Lingua principale
- OCaml
- Stelle
- 1.2k
- Fork
- 214
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di moby/vpnkit
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Issue simili
-
bug(view): websocket multiplexer holds the sub-connection map lock across a blocking rejection writeApertastatus: ready for dev
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
hyperledger-labs/fabric-smart-client#1994 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
slackapi/node-slack-sdk#2753 ·
I maintainer di solito rispondono entro 1 giorno
-
[BUG] Generic OSC does not initialize OSC client on startup when "Listen for Feedback" is disabledAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
An addr-fetch peer is exempt from discouragement, where Core exempts only a manual or NoBan peerAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
btclib-org/btclib-node#1588 ·
I maintainer di solito rispondono entro 1 giorno
-
8.x enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
openmediavault/openmediavault#2284 · 2 commenti ·