Discussion:
.local searches not working
(too old to reply)
Phillip Susi
2021-04-09 18:27:16 UTC
Permalink
What special treatment does systemd-resolved give to .local domains?
The corporate windows network uses a .local domain and even when I point
systemd-resolved at the domain controller, it fails the query without
bothering to ask the dc saying:

resolve call failed: No appropriate name servers or networks for name
found
Silvio Knizek
2021-04-09 18:54:09 UTC
Permalink
Post by Phillip Susi
What special treatment does systemd-resolved give to .local domains?
The corporate windows network uses a .local domain and even when I point
systemd-resolved at the domain controller, it fails the query without
resolve call failed: No appropriate name servers or networks for name
found
Well, .local is by definition special as it is reserverd for
MulticastDNS [1].
The man page [2] itself says
Post by Phillip Susi
Multi-label names with the domain suffix ".local" are resolved using
MulticastDNS on all local interfaces where MulticastDNS is enabled.
As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6
address lookups are sent via IPv6.
Queries for multi-label names are routed via unicast DNS on local
interfaces that have a DNS server configured, plus the globally
configured DNS servers if there are any. Which interfaces are used
is determined by the routing logic based on search and route-only
domains, described below. Note that by default, lookups for domains
with the ".local" suffix are not routed to DNS servers, unless the
domain is specified explicitly as routing or search domain for the
DNS server and interface. This means that on networks where the
".local" domain is defined in a site-specific DNS server, explicit
search or routing domains need to be configured to make lookups work
within this DNS domain. Note that these days, it's generally
recommended to avoid defining ".local" in a DNS server, as RFC6762
reserves this domain for exclusive MulticastDNS use.
So in fact your network is not standard conform. You have to define
.local as search and routing domain in the configuration of sd-
resolved.

BR
Silvio

[1] https://tools.ietf.org/html/rfc6762#section-3
[2]
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
Phillip Susi
2021-04-09 19:20:10 UTC
Permalink
Post by Silvio Knizek
So in fact your network is not standard conform. You have to define
.local as search and routing domain in the configuration of sd-
resolved.
Interesting... so what are you supposed to name your local, private
domains? I believe Microsoft used to ( or still do? ) recommend using
.local to name your domain if you don't have a public domain name, so
surely I'm not the first person to run into this? Why does
systemd-resolved not fall back to DNS if it can't first resolve the name
using mDNS? That appears to be allowed by the RFC.
Mantas Mikulėnas
2021-04-09 23:02:11 UTC
Permalink
Post by Phillip Susi
Post by Silvio Knizek
So in fact your network is not standard conform. You have to define
.local as search and routing domain in the configuration of sd-
resolved.
Interesting... so what are you supposed to name your local, private
domains?
.home.arpa is reserved for that purpose by IANA (as part of the Homenet
work, but explicitly stated that its usage is not limited to Homenet
protocols).

Though if you own a public domain there's nothing wrong with using a
subdomain of it for your private LAN, either.

I believe Microsoft used to ( or still do? ) recommend using
Post by Phillip Susi
.local to name your domain if you don't have a public domain name, so
surely I'm not the first person to run into this?
It could be that at some point they did. I've seen Active Directory domains
named "university.local" (even though they *did* have a public domain...)
But IIRC they went back on that recommendation.

Why does
Post by Phillip Susi
systemd-resolved not fall back to DNS if it can't first resolve the name
using mDNS? That appears to be allowed by the RFC.
Simply falling back for each individual query is probably not desirable
because it would also leak local hostnames for people who *do* use mDNS.

Systemd-resolved could implement the "check if local. SOA exists" probe
that AFAIK Apple does, I think there was a github thread about it...

... Actually, if you manually set an interface's search domain in resolved
to "local", doesn't that make it start using DNS for this domain? I cannot
test right now, but I'm *sure* I've seen something like that in resolved's
docs.
Mantas Mikulėnas
2021-04-09 23:03:03 UTC
Permalink
Post by Mantas Mikulėnas
Post by Phillip Susi
Post by Silvio Knizek
So in fact your network is not standard conform. You have to define
.local as search and routing domain in the configuration of sd-
resolved.
Interesting... so what are you supposed to name your local, private
domains?
.home.arpa is reserved for that purpose by IANA (as part of the Homenet
work, but explicitly stated that its usage is not limited to Homenet
protocols).
Er, I think I mixed up IANA and IETF there. It should be the latter, I
think.
Post by Mantas Mikulėnas
Though if you own a public domain there's nothing wrong with using a
subdomain of it for your private LAN, either.
I believe Microsoft used to ( or still do? ) recommend using
Post by Phillip Susi
.local to name your domain if you don't have a public domain name, so
surely I'm not the first person to run into this?
It could be that at some point they did. I've seen Active Directory
domains named "university.local" (even though they *did* have a public
domain...) But IIRC they went back on that recommendation.
Why does
Post by Phillip Susi
systemd-resolved not fall back to DNS if it can't first resolve the name
using mDNS? That appears to be allowed by the RFC.
Simply falling back for each individual query is probably not desirable
because it would also leak local hostnames for people who *do* use mDNS.
Systemd-resolved could implement the "check if local. SOA exists" probe
that AFAIK Apple does, I think there was a github thread about it...
... Actually, if you manually set an interface's search domain in resolved
to "local", doesn't that make it start using DNS for this domain? I cannot
test right now, but I'm *sure* I've seen something like that in resolved's
docs.
Lennart Poettering
2021-04-10 12:49:26 UTC
Permalink
Post by Phillip Susi
Post by Silvio Knizek
So in fact your network is not standard conform. You have to define
.local as search and routing domain in the configuration of sd-
resolved.
Interesting... so what are you supposed to name your local, private
domains?
This draft RFC suggests .home or .corp:

https://www.ietf.org/archive/id/draft-chapin-additional-reserved-tlds-02.txt

It never made it beyond a draft, but I think that#s already enough to
be pretty sure these domains unlikely will be used elsewhere.

RFC 6762, Appendix G suggests using .lan, .intranet, .internal and
.private.

RFC 8375 suggests .home.arpa. This is probably the RFC that is the
most official one, but OTOH its probably at the moment the least
widely used one. Still, probably the safest bet, though it does sound
a bit weird when used in a corporate context.
Post by Phillip Susi
I believe Microsoft used to ( or still do? ) recommend using
.local to name your domain if you don't have a public domain name, so
surely I'm not the first person to run into this? Why does
systemd-resolved not fall back to DNS if it can't first resolve the name
using mDNS? That appears to be allowed by the RFC.
You can enable this, just add ~local to the routing domains of the
relevant DNS server.

We won't do this automatically for security reasons, as locally scoped
names should not be routed to Internet DNS servers, as that leaks
pretty sensitive information about the local network infrastructur

Lennart

--
Lennart Poettering, Berlin
Ulrich Windl
2021-04-12 06:57:20 UTC
Permalink
Nachricht
What special treatment does systemd‑resolved give to .local domains?
The corporate windows network uses a .local domain and even when I point
systemd‑resolved at the domain controller, it fails the query without
resolve call failed: No appropriate name servers or networks for name
found
I don't know who established using ".local" for Windows AD "DNS" names, but
RFC 6762 says:
1. Users may use these names as they would other DNS names,
entering them anywhere that they would otherwise enter a
conventional DNS name, or a dotted decimal IPv4 address, or a
literal IPv6 address.
Since there is no central authority responsible for assigning
dot-local names, and all devices on the local network are
equally entitled to claim any dot-local name, users SHOULD be
aware of this and SHOULD exercise appropriate caution. In an
untrusted or unfamiliar network environment, users SHOULD be
aware that using a name like "www.local" may not actually
connect them to the web site they expected, and could easily
connect them to a different web page, or even a fake or spoof
of their intended web site, designed to trick them into
revealing confidential information. (...)
3. Name resolution APIs and libraries SHOULD recognize these names
as special and SHOULD NOT send queries for these names to their
configured (unicast) caching DNS server(s). (...)
4. Caching DNS servers SHOULD recognize these names as special and
SHOULD NOT attempt to look up NS records for them, or otherwise
query authoritative DNS servers in an attempt to resolve these
names.(...)
5. Authoritative DNS servers SHOULD NOT by default be configurable
to answer queries for these names, and, like caching DNS
servers, SHOULD generate immediate NXDOMAIN responses for all
such queries they may receive.(...)
6. DNS server operators SHOULD NOT attempt to configure
authoritative DNS servers to act as authoritative for any of
these names.(...)
7. DNS Registrars MUST NOT allow any of these names to be
registered in the normal way to any person or entity. (...)

RFC 7368 (Home Networking):
If, however, a global name space is not available, the homenet will
need to pick and use a local name space, which would only have
meaning within the local homenet (i.e., it would not be used for
remote access to the homenet). The .local name space currently has a
special meaning for certain existing protocols that have link-local
scope and is thus not appropriate for multi-subnet home networks.

Regards,
Ulrich
_______________________________________________
systemd‑devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd‑devel
Loading...