[GH-ISSUE #218] Container-name lookup results are case-sensitive. #89

Closed
opened 2026-02-26 04:34:01 +03:00 by kerem · 4 comments
Owner

Originally created by @ulidtko on GitHub (Mar 31, 2021).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/218

Hi!

It turns out, some programs (including Postman) will garble hostnames by force-lowercasing them before querying. I'm not ready to start judging if they're right or wrong in doing that; just RFC 4343 alone tryies to clarify the whole "case-insensitivity in DNS" topic.

The fact is, DPS chokes on that. For repro, run with MG_REGISTER_CONTAINER_NAMES=1 and:

$ docker run -d --name fooBar alpine sleep infinity
6799e0325f4146dd79f8c977a2c6f7fd0170439b1412627d765605d9d00aa8b8

$ ping fooBar.docker
PING fooBar.docker (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=1 ttl=64 time=0.077 ms
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=2 ttl=64 time=0.136 ms
^C
--- fooBar.docker ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.077/0.106/0.136/0.029 ms

$ ping foobar.docker
ping: foobar.docker: Name or service not known

To the poor Postman, this manifests as ENOTFOUND from getaddrinfo("foobar.docker") with no way to workaround:

image

Regardless of the perhaps-broken client (which simply exposes the issue) — I believe, the DNS server portion of DPS is expected to make comparisons case-insensitively against its internal name db. Quoting from the original 1987 DNS RFC:

By convention, domain names can be stored with arbitrary case, but
domain name comparisons for all present domain functions are done in a
case-insensitive manner, assuming an ASCII character set, and a high
order zero bit.

DPS version: 2.19.0

Originally created by @ulidtko on GitHub (Mar 31, 2021). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/218 Hi! It turns out, some programs (including [Postman](https://learning.postman.com/docs/)) will garble hostnames by force-lowercasing them before querying. I'm not ready to start judging if they're right or wrong in doing that; just [RFC 4343][] alone tryies to clarify the whole "case-insensitivity in DNS" topic. The fact is, DPS chokes on that. For **repro**, run with `MG_REGISTER_CONTAINER_NAMES=1` and: ``` $ docker run -d --name fooBar alpine sleep infinity 6799e0325f4146dd79f8c977a2c6f7fd0170439b1412627d765605d9d00aa8b8 $ ping fooBar.docker PING fooBar.docker (172.17.0.3) 56(84) bytes of data. 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=1 ttl=64 time=0.077 ms 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=2 ttl=64 time=0.136 ms ^C --- fooBar.docker ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.077/0.106/0.136/0.029 ms $ ping foobar.docker ping: foobar.docker: Name or service not known ``` To the poor Postman, this manifests as `ENOTFOUND` from `getaddrinfo("foobar.docker")` with no way to workaround: ![image](https://user-images.githubusercontent.com/365338/113134677-ca489180-9229-11eb-9a0e-d0b1323d68a3.png) Regardless of the perhaps-broken client (which simply exposes the issue) — I believe, the DNS server portion of DPS is expected to make comparisons case-insensitively against its internal name db. Quoting from the original 1987 [DNS RFC][]: > By convention, domain names can be stored with arbitrary case, but > domain name comparisons for all present domain functions are done in a > case-insensitive manner, assuming an ASCII character set, and a high > order zero bit. DPS version: `2.19.0` [RFC 4343]: https://tools.ietf.org/html/rfc4343 [DNS RFC]: https://tools.ietf.org/html/rfc1034
kerem 2026-02-26 04:34:01 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@mageddo commented on GitHub (Mar 2, 2023):

Hey, yes, it's a DPS bug, I'm following RFC 1035 which says:

2.3.3. Character Case

For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names, etc.)
are done in a case-insensitive manner.

The fix must be simple though

<!-- gh-comment-id:1452252144 --> @mageddo commented on GitHub (Mar 2, 2023): Hey, yes, it's a DPS bug, I'm following [RFC 1035][1] which says: > 2.3.3. Character Case > > For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. The fix must be simple though [1]: https://www.ietf.org/rfc/rfc1035.txt
Author
Owner

@mageddo commented on GitHub (Mar 2, 2023):

It turns out, some programs (including Postman) will garble hostnames by force-lowercasing them before querying.

Yeah, it's not recommended by the RFC to Postman do that, anyway I will work on DPS to be compliance with the RFC .

<!-- gh-comment-id:1452258274 --> @mageddo commented on GitHub (Mar 2, 2023): > It turns out, some programs (including [Postman](https://learning.postman.com/docs/)) will garble hostnames by force-lowercasing them before querying. Yeah, it's not recommended by the RFC to Postman do that, anyway I will work on DPS to be compliance with the RFC .
Author
Owner

@mageddo commented on GitHub (Mar 3, 2023):

Fixed on #332, will be release as 3.5.3, CD will release this version package as soon as Github Actions goes back

image

<!-- gh-comment-id:1452785119 --> @mageddo commented on GitHub (Mar 3, 2023): Fixed on #332, will be release as 3.5.3, CD will release this version package as soon as [Github Actions goes back][1] ![image](https://user-images.githubusercontent.com/5281356/222605143-6529b2e8-96af-42e2-bf3e-b3c13989af52.png) [1]: https://www.githubstatus.com/
Author
Owner

@ulidtko commented on GitHub (Mar 6, 2023):

Thanks!

пт, 3 бер. 2023, 02:00 користувач Elvis Souza @.***>
пише:

Closed #218 https://github.com/mageddo/dns-proxy-server/issues/218 as
completed.


Reply to this email directly, view it on GitHub
https://github.com/mageddo/dns-proxy-server/issues/218#event-8655279912,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACZGGVTLM7PKCUXAQ77ONTW2E7CBANCNFSM42ENIHWQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

<!-- gh-comment-id:1455273707 --> @ulidtko commented on GitHub (Mar 6, 2023): Thanks! пт, 3 бер. 2023, 02:00 користувач Elvis Souza ***@***.***> пише: > Closed #218 <https://github.com/mageddo/dns-proxy-server/issues/218> as > completed. > > — > Reply to this email directly, view it on GitHub > <https://github.com/mageddo/dns-proxy-server/issues/218#event-8655279912>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACZGGVTLM7PKCUXAQ77ONTW2E7CBANCNFSM42ENIHWQ> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/dns-proxy-server-mageddo#89
No description provided.