DNS issue only in kubernetes on a windows host
Nobody has claimed this yet.
- Dominant language
- OCaml
- Stars
- 1.2k
- Forks
- 214
- PR merge metrics
- No merged PRs in 30d
Description
First, here is some context, I have a domain for local dev with this records :
@ A 127.0.0.1
* A 127.0.0.1
_acme-challenge TXT xxxxxxxxxxxxxxxxxxxxx
This issue is only happening on windows 11 (maybe 10 ?), there is no problem on Linux and MacOS.
Now if run this dns query from windows I have this result which is the expected one according to the zone :
dig cname _acme-challenge.linoa.dev.
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> cname _acme-challenge.linoa.dev.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30141
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;_acme-challenge.linoa.dev. IN CNAME
;; AUTHORITY SECTION:
linoa.dev. 78 IN SOA desi.ns.cloudflare.com. dns.cloudflare.com. 2304297281 10000 2400 604800 3600
;; Query time: 0 msec
;; SERVER: 172.28.208.1#53(172.28.208.1) (UDP)
;; WHEN: Tue Mar 14 18:02:22 CET 2023
;; MSG SIZE rcvd: 116
Now if I run the same query from a pod inside the kubernetes cluster I have this result, with a CNAME pointing to itselft coming from nowhere.
dig cname _acme-challenge.linoa.dev.
; <<>> DiG 9.9.5-9+deb8u19-Debian <<>> cname _acme-challenge.linoa.dev.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34937
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_acme-challenge.linoa.dev. IN CNAME
;; ANSWER SECTION:
_acme-challenge.linoa.dev. 5 IN CNAME _acme-challenge.linoa.dev.
;; Query time: 3 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Tue Mar 14 17:01:
When the request is sent from the pod and we analyse the response in windows with wireshark the dns response is correct and then when we analyse the response with tcpdump inside the kubernetes cluster there is this CNAME appearing.
Expected behavior
This dns query is supposed to have the same behaviour on windows, linux and macos.
Here is my machine information :
Version WSL : 1.2.1.0
Version du noyau : 5.15.90.1
Version WSLg : 1.0.51
Version MSRDC : 1.2.3770
Version direct3D : 1.608.2-61064218
Version de DXCore : 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Version de Windows : 10.0.22621.1555
I tried with Docker for Windows v4.18 (with WSL2 and Hyper-V backend) and minikube.
Steps to reproduce the behavior
- Install Docker for dekstop latest release
- Enable kubernetes
- kubectl run tmp-shell --rm -i --tty --image nicolaka/netshoot
- dig _acme-challenge.linoa.dev. CNAME
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue with Docker Desktop Kubernetes and the nicolaka/netshoot pod, then run the documented dig query. Compare the response from the pod's Kubernetes DNS server at 10.96.0.10 with the Windows, Linux, and macOS results and the packet captures described in the report. Done means the query returns consistent, correct records across the supported host platforms.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, kubernetes
- Domain
- devops, networking, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100