12 Sep 2025 |
toonn | I really don't see a good reason for it to be out of spec, it's just an arbitrary decision AFAICT. | 13:53:07 |
Jassuko | Ahh. Well, that is a use case I have not had. :D | 13:53:13 |
magic_rb | Does the spec restrict valid TLDs? .local is very very common | 13:57:29 |
toonn | I think the spec requires .local actually. | 13:57:51 |
K900 | No, but the mDNS spec does not allow multiple parts in the domain name | 13:58:17 |
K900 | It does require .local | 13:58:36 |
K900 | But foo.bar.local is not allow | 13:58:42 |
K900 | * But foo.bar.local is not allowed | 13:58:45 |
K900 | Only foo.local | 13:58:48 |
magic_rb | Oh, so no subdomains | 13:59:14 |
magic_rb | Weird | 13:59:16 |
toonn | I assume it's because some printer's implementation somewhere splits on the first `.` and then proceeds to freak out. | 13:59:56 |
K900 | No, it's because | 14:01:21 |
Jassuko | Not weird, really. The .local thingy is intended for host discovery on local network by name. And the hostname is by definition the last part of the fqdn. :p | 14:01:24 |
K900 |
Most computer users neglect to type the trailing dot at the end of a
fully qualified domain name, making it a relative domain name (e.g.,
"www.example.com"). In the event of network outage, attempts to
positively resolve the name as entered will fail, resulting in
application of the search list, including ".local.", if present. A
malicious host could masquerade as "www.example.com." by answering
the resulting Multicast DNS query for "www.example.com.local.". To
avoid this, a host MUST NOT append the search suffix ".local.", if
present, to any relative (partially qualified) host name containing
two or more labels. Appending ".local." to single-label relative
host names is acceptable, since the user should have no expectation
that a single-label host name will resolve as is. However, users who
have both "example.com" and "local" in their search lists should be
aware that if they type "www" into their web browser, it may not be
immediately clear to them whether the page that appears is
"www.example.com" or "www.local".
| 14:01:26 |
magic_rb | Aaaah DNS is cursef | 14:03:19 |
K900 | Technically not really an issue anymore in many ways because browsers ship the public suffix list | 14:03:41 |
K900 | And can consult it and avoid this kind of nonsense | 14:03:47 |
K900 | But it was a concern at the time of writing the RFC and it was never updated since | 14:04:01 |
Jassuko | Public Suffix List is problematic as well. :D | 14:04:39 |
K900 | In other ways, yes | 14:05:02 |
Jassuko | Yeah. It would not need to exist, if the cookie spec was sane.. I think it's just rabbit holes all the way down at this point, lol. :D | 14:05:45 |
toonn | K900: That applies to sub.host but not to sub.host.local, not appending ".local." would still "just work." | 14:06:11 |
K900 | Yes, except you could not know when not to append .local | 14:06:54 |
K900 | Before the PSL existed | 14:06:54 |
toonn | I don't see how subdomains make that more problematic though. Just never append if the hostname has a ".?" | 14:08:39 |
K900 | I mean, you're welcome to propose a spec change if you want this so much | 14:13:43 |
K900 | But as it stands, it is out of spec | 14:13:48 |
toonn | I doubt I can convince anyone, mDNS seems to be rather universally despised. As long as I can get avahi to resolve subdomains for me, I'm happy. | 14:16:00 |
toonn | magic_rb: Maybe I was naively hoping `pack . unpack` avoids reading the entire lazy bytestring into memory. I don't know if I elided the type declaration on purpose or just temporarily because I was changing things, probably the latter. | 14:24:21 |