Mailing List Archive

On 2022-01-15 10:33+0000 Peter Humphrey <peter@prh.myzen.co.uk> wrote:

> Hello list,
>
> Rich F said recently, "I'd avoid using the .local TLD due to RFC
> 6762."
>
> That brings me back to a thorny problem: what should I call my local
> network? It used to be .prhnet, but then a program I tried a few
> years ago insisted on a two-component name, so I changed it to
> .prhnet.local.
>
> Now I've read that RFC - well, Appendix G to it - and I'm scratching
> my head. I suppose it's possible that someone may want to connect an
> Apple device to my network, so perhaps I should clear the way for
> that eventuality.
>
> So, what TLD should I use? Should I use .home, or just go back to
> .prhnet? It isn't going to be visible to the Big Bad World, so does
> it even matter?
>

ICANN rejected .home as a TLD¹ because of name collision issues in
private networks, so that should be fine.

Another solution would be to register an inexpensive domain name and use
that. ????

Kind regards, tastytea

¹ <https://en.wikipedia.org/wiki/.home>

--
Get my PGP key with `gpg --locate-keys tastytea@tastytea.de` or at
<https://tastytea.de/tastytea.asc>.

On 15/1/22 18:33, Peter Humphrey wrote:
> Hello list,
>
> Rich F said recently, "I'd avoid using the .local TLD due to RFC 6762."
>
> That brings me back to a thorny problem: what should I call my local network?
> It used to be .prhnet, but then a program I tried a few years ago insisted on
> a two-component name, so I changed it to .prhnet.local.
>
> Now I've read that RFC - well, Appendix G to it - and I'm scratching my head.
> I suppose it's possible that someone may want to connect an Apple device to my
> network, so perhaps I should clear the way for that eventuality.
>
> So, what TLD should I use? Should I use .home, or just go back to .prhnet? It
> isn't going to be visible to the Big Bad World, so does it even matter?
>
Ive been using "localdomain" for years without any obvious problems. 
.local is not just apple but can be used by other things too (e.g.,
homeassistant uses it for device discovery, creating an extensive
ecosystem in the process.  No apple devices in sight :)

BillK

tastytea wrote:
>
> Another solution would be to register an inexpensive domain name and use
> that. ????

That's generally a good idea. After using .local for many years,
too, I have switched to my "official" domain and added "local"
for the internal IP addresses.

So my server down in the basement is something like "server.example.com"
where BIND delivers the IP address 93.some.thing.official, and a DNS
request for "server.local.example.com" delivers 10.some.thing.internal.

So there's no need any more to search for some TLD which won't interfere
with anything :-)

-Matt

On Sat, Jan 15, 2022 at 5:57 AM William Kenworthy <billk@iinet.net.au> wrote:
>
> On 15/1/22 18:33, Peter Humphrey wrote:
> > Hello list,
> >
> > Rich F said recently, "I'd avoid using the .local TLD due to RFC 6762."
> >
> > That brings me back to a thorny problem: what should I call my local network?
> > It used to be .prhnet, but then a program I tried a few years ago insisted on
> > a two-component name, so I changed it to .prhnet.local.
> >
> > Now I've read that RFC - well, Appendix G to it - and I'm scratching my head.
> > I suppose it's possible that someone may want to connect an Apple device to my
> > network, so perhaps I should clear the way for that eventuality.
> >
> > So, what TLD should I use? Should I use .home, or just go back to .prhnet? It
> > isn't going to be visible to the Big Bad World, so does it even matter?
> >
> Ive been using "localdomain" for years without any obvious problems.
> .local is not just apple but can be used by other things too (e.g.,
> homeassistant uses it for device discovery, creating an extensive
> ecosystem in the process. No apple devices in sight :)

Just about everything supports mDNS, including Gentoo:
https://wiki.gentoo.org/wiki/Avahi

(Most desktop-oriented distros enable it by default.)

You might want to look into whether it solves your problems
out-of-the-box without the need to run internal DNS. The latter still
has certain advantages, but mDNS obviously benefits from simplicity.

--
Rich

>
> On Sat, Jan 15, 2022 at 5:57 AM William Kenworthy <billk@iinet.net.au>
> wrote:
> >
> > On 15/1/22 18:33, Peter Humphrey wrote:
> > > Hello list,
> > >
> > > Rich F said recently, "I'd avoid using the .local TLD due to RFC 6762."
> > >
> > > That brings me back to a thorny problem: what should I call my local
> network?
> > > It used to be .prhnet, but then a program I tried a few years ago
> insisted on
> > > a two-component name, so I changed it to .prhnet.local.
> > >
> > > Now I've read that RFC - well, Appendix G to it - and I'm scratching
> my head.
> > > I suppose it's possible that someone may want to connect an Apple
> device to my
> > > network, so perhaps I should clear the way for that eventuality.
> > >
> > > So, what TLD should I use? Should I use .home, or just go back to
> .prhnet? It
> > > isn't going to be visible to the Big Bad World, so does it even matter?
> > >
> > Ive been using "localdomain" for years without any obvious problems.
> > .local is not just apple but can be used by other things too (e.g.,
> > homeassistant uses it for device discovery, creating an extensive
> > ecosystem in the process. No apple devices in sight :)
>
> Just about everything supports mDNS, including Gentoo:
> https://wiki.gentoo.org/wiki/Avahi
>
> (Most desktop-oriented distros enable it by default.)
>
> You might want to look into whether it solves your problems
> out-of-the-box without the need to run internal DNS. The latter still
> has certain advantages, but mDNS obviously benefits from simplicity.
>
> --
> Rich
>
> This solution, change hosts file, that Avahi suggests, is the easy
solution without DNS local server?

I never realized about the host file
—
Raphael


--
M.S. Raphael Mejias Dias
?Nuclear Engineer | Reactors

Secure e-mail: raphael.mejias.dias@protonmail.com
PGP Key for raphaxx@gmail.com:
https://pgp.mit.edu/pks/lookup?op=get&search=0x87BC5A746072F951

On 1/15/22 3:33 AM, Peter Humphrey wrote:
> Hello list,

Hi.

> Rich F said recently, "I'd avoid using the .local TLD due to RFC 6762."

Ya....

I've read RFC 6762 in the past and I just skimmed part of it again. I
didn't find anything that prohibited the use of the local top level
domain for things other than mDNS et al.

The only hard requirement that I did see is that if mDNS is used, that
queries for <anything>.local /MUST/ be sent to mDNS.

N.B. that does not preclude /also/ sending queries for <anything>.local
to other name resolution systems like traditional unicast DNS.

Ergo, RFC 6762 does not preclude the use of the local top level domain
in traditional unicast DNS.

> That brings me back to a thorny problem: what should I call my local network?

Maybe it's just me, I'm weird like that, but I vehemently believe that
*I* am the authority for the names of *MY* network(s). As such,
whatever name /I/ choose is the name that /my/ network(s) will use.

I don't care that a cable internet provider wants my router to be called
<client-ID>.<city>.<state>.<customers>.<cable company>.<tld>.

What's more is that I don't fathom, much less allow, the cable company's
-- let's go with -- questionable naming have any influence on what my
internal network is called.

> It used to be .prhnet, but then a program I tried a few years ago
> insisted on a two-component name, so I changed it to .prhnet.local.

There are /some/ complications that may have some influence on what
names are chosen.

But I point out that your network quite likely did exactly what you
wanted to do up until that point.

Q: Did you continue to use the software that you tried? Or did you end
up renaming your network for something that you are no longer using? }:-)

> Now I've read that RFC - well, Appendix G to it - and I'm scratching
> my head.

I note the distinct absence of the quintessential SHOULD or MUST that
RFCs are notorious for in RFC 6762 Appendix G. So ... I don't give the
recommendation there in much credence.

What's more is that RFC 6762 Appendix G fails to take into account
gateways that bridge mDNS into Unicast DNS. E.g. they receive an mDNS
query and gateway it to the configured uDNS. Thereby (mostly
seamlessly) tying the mDNS and uDNS name space together.

I really feel like RFC 6762 is a "you might want to consider not using
the .local top level domain on the off hand chance that you ever have
something that can't / won't work with it."

> I suppose it's possible that someone may want to connect an Apple
> device to my network, so perhaps I should clear the way for that
> eventuality.

Is that possibility significant enough to influence how /you/ run /your/
network?

/me puts his hand up to block glare looking out over the horizon looking
for the SHOULD and MUST statements again, still not finding them.

I can tell you that I have first hand experience with using Apple
devices on a network that used the local top level domain without problems.

> So, what TLD should I use? Should I use .home, or just go back to
> .prhnet? It isn't going to be visible to the Big Bad World, so does
> it even matter?

Use whatever TLD you want to use. Be aware of any potential gotchas and
decide if they are worth avoiding or not.

The old fable of "The Miller, his son, and the donkey" comes to mind.
-- Make yourself happy.



--
Grant. . . .
unix || die

On Sat, Jan 15, 2022 at 2:35 PM Raphael Mejias Dias <raphaxx@gmail.com> wrote:
>>
>> You might want to look into whether it solves your problems
>> out-of-the-box without the need to run internal DNS. The latter still
>> has certain advantages, but mDNS obviously benefits from simplicity.
>>
>>
> This solution, change hosts file, that Avahi suggests, is the easy solution without DNS local server?
>
> I never realized about the host file

Are you talking about the nsswitch.conf file? If so, then yes. If
you run the avahi daemon and configure nsswitch.conf so that the
resolver includes it, then any host on the network that supports
zeroconf should be accessible via hostname.local. Most stuff does
these days. Obviously there is more you can do with full-blown
DNS/DHCP, but if all you care about is that your printer shows up at
printer.local or whatever, and so on, then you're fine. Likewise your
gentoo box would be available to anything else on the network via its
hostname.local.

Oh, and if you want to prefer IPv4 then use mdns4_minimal and mdns4 in
the config.

--
Rich

On Sat, Jan 15, 2022 at 2:54 PM Grant Taylor
<gtaylor@gentoo.tnetconsulting.net> wrote:
>
> RFC 6762 does not preclude the use of the local top level domain
> in traditional unicast DNS.

Of course it doesn't. You can also go ahead and use some of Amazon's
AWS IP space to number your home network too if you want. Just don't
be surprised when random websites break when they try to load stuff
and the HTTP GET goes to your television instead of the webserver it
is hosted on. If you want to name your mail server google.com that
works fine too, assuming you're not too attached to being able to use
the real Google.

Your DNS will work fine if you use .local. It just means that you
can't also use mDNS, and if at some point you change your mind about
your decision you have to go and reconfigure everything to use a
different DNS name which of course sort-of defeats the purpose of
using DNS in the first place.

Use whatever domain name you want. I'm just pointing out that this
particular one is used for other things that are mainly useful around
the house. If want to live like it is 1982 feel free to stick to DNS
the way it was always meant to be... ;)

--
Rich

On Sat 15 Jan 2022 11:53:58 GMT, tastytea wrote:
> On 2022-01-15 10:33+0000 Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> > Hello list,
> >
> > Rich F said recently, "I'd avoid using the .local TLD due to RFC
> > 6762."
> >
> > That brings me back to a thorny problem: what should I call my local
> > network? It used to be .prhnet, but then a program I tried a few
> > years ago insisted on a two-component name, so I changed it to
> > .prhnet.local.
> >
> > Now I've read that RFC - well, Appendix G to it - and I'm scratching
> > my head. I suppose it's possible that someone may want to connect an
> > Apple device to my network, so perhaps I should clear the way for
> > that eventuality.
> >
> > So, what TLD should I use? Should I use .home, or just go back to
> > .prhnet? It isn't going to be visible to the Big Bad World, so does
> > it even matter?
> >
>
> ICANN rejected .home as a TLD¹ because of name collision issues in
> private networks, so that should be fine.
>
> Another solution would be to register an inexpensive domain name and use
> that. ????
>
> Kind regards, tastytea
>
> ¹ <https://en.wikipedia.org/wiki/.home>

home.arpa has to be used instead

--
Alarig

* tastytea:

> Another solution would be to register an inexpensive domain name and
> use that. ????

Quite so. For example, Hetzner (no affiliation) charges 3,36 EUR per
year for a .de Domain. An officially registered domain saves a lot of
hassle.

-Ralph

On Saturday, 15 January 2022 19:54:13 GMT Grant Taylor wrote:
> On 1/15/22 3:33 AM, Peter Humphrey wrote:

> > Rich F said recently, "I'd avoid using the .local TLD due to RFC 6762."
>
> Ya....

--->8

> Ergo, RFC 6762 does not preclude the use of the local top level domain
> in traditional unicast DNS.

OK.

> > That brings me back to a thorny problem: what should I call my local
> > network?
>
> Maybe it's just me, I'm weird like that, but I vehemently believe that
> *I* am the authority for the names of *MY* network(s). As such,
> whatever name /I/ choose is the name that /my/ network(s) will use.

And as the addresses are all unroutable outside the LAN, that could be
anything.

--->8

> > It used to be .prhnet, but then a program I tried a few years ago
> > insisted on a two-component name, so I changed it to .prhnet.local.
>
> There are /some/ complications that may have some influence on what
> names are chosen.
>
> But I point out that your network quite likely did exactly what you
> wanted to do up until that point.

It did, yes.

> Q: Did you continue to use the software that you tried? Or did you end
> up renaming your network for something that you are no longer using? }:-)

No and yes, in that order. Guilty as charged. :)

--->8

> I really feel like RFC 6762 is a "you might want to consider not using
> the .local top level domain on the off hand chance that you ever have
> something that can't / won't work with it."
>
> > I suppose it's possible that someone may want to connect an Apple
> > device to my network, so perhaps I should clear the way for that
> > eventuality.
>
> Is that possibility significant enough to influence how /you/ run /your/
> network?

Could be. I occasionally take my machine to my daughter's house, and she's an
Apple person. This is one reason for my current musing.

Thanks Grant. I think I've been worrying needlessly. The network will revert
to its original name.

--
Regards,
Peter.

> home.arpa has to be used instead

Just to follow up on this. According to [0] "the domain name home.arpa was
reserved by the IETF in May 2018 as a special-use domain name for non-unique DNS
services in residential networking" (see the section "Residential Networking").

I think this is also RFC 8375 [1].

[0]: https://en.wikipedia.org/wiki/.arpa
[1]: https://datatracker.ietf.org/doc/rfc8375/

-- Thomas

-----Original Message-----
From: tastytea <gentoo@tastytea.de>
Sent: Saturday, January 15, 2022 2:54 AM
>To: gentoo-user@lists.gentoo.org
>Subject: Re: [gentoo-user] TLD for home LAN?
>
>On 2022-01-15 10:33+0000 Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
>> Hello list,
>>
>> Rich F said recently, "I'd avoid using the .local TLD due to RFC
>> 6762."
>>
>

Glancing at that RFC, if you want to be compliant (which, it's *your* network, and this is all link-local only, so there's no reason you *have* to be), all you need to do is make sure that any .local addresses you assign are resolvable via multicast DNS.

The standard does not prohibit the names being resolvable via unicast DNS as well, though it does recommend that you make sure the two resolution paths return consistent results since most systems will take the first response they get.

If you assign .local addresses which aren't resolvable via mdns then there is the possibility that some piece of software will only check mdns and not regular dns before grabbing a name and cause a conflict. But as long as it's your network and your devices that's not terribly hard to sort out should it ever happen.

LMP

On Tue, Jan 18, 2022 at 12:28 PM Laurence Perkins <lperkins@openeye.net> wrote:
>
> The standard does not prohibit the names being resolvable via unicast DNS as well, though it does recommend that you make sure the two resolution paths return consistent results since most systems will take the first response they get.

If a host queries DNS first, and obtains an NXDOMAIN from an
authoritative name server, I'm not sure most would even check mDNS. I
think I had that issue back when I was using .local before I heard of
zeroconfig.

Obviously do as you will but I see no point in not having it
available. After all, if for whatever reason you plug in a host and
it doesn't end up configuring the IP you expected, it would be useful
to be able to access it via hostname.local and actually reach the host
instead of whatever your DNS server things the host ought to be. I
have DNS set up for just about everything on my LAN but it is still
really handy when I get some new device and it broadcasts itself as
raspbian.local or whatever. Granted, I can just check my DHCP logs
but zeroconfig is handy. It even works on a switch without any
DHCP/DNS server at all (there is an IP space set aside for this
purpose which hosts will autoconfigure for and discover each other).

--
Rich

>>-----Original Message-----
>>From: Rich Freeman <rich0@gentoo.org>
>>Sent: Tuesday, January 18, 2022 11:41 AM
>>To: gentoo-user@lists.gentoo.org
>>Subject: Re: [gentoo-user] TLD for home LAN?
>>
>>On Tue, Jan 18, 2022 at 12:28 PM Laurence Perkins <lperkins@openeye.net> wrote:
>>>
>>> The standard does not prohibit the names being resolvable via unicast DNS as well, though it does recommend that you make sure the two resolution paths return consistent results since most systems will take the first response they get.
>>
>>If a host queries DNS first, and obtains an NXDOMAIN from an authoritative name server, I'm not sure most would even check mDNS. I think I had that issue back when I was using .local before I heard of zeroconfig.
>>

Right. If you have .local names registered with your DNS, but not resolvable via mDNS, then if you plug in a device which tries to assign a conflicting name and it only checks mDNS for conflicts (the standard only *says* to check mDNS for conflicts, even though checking DNS as well would seem to always be a good idea) you could end up with DNS and mDNS returning different results. This can be confusing if different devices have different resolver preference orders.

So, if you're going to have your DNS resolve .local names it's a really good idea to provide those names via mDNS as well. At least if there's any significant chance of a conflict arising.

LMP

On Tue, Jan 18, 2022 at 3:12 PM Laurence Perkins <lperkins@openeye.net> wrote:
>
>
>
> >>-----Original Message-----
> >>From: Rich Freeman <rich0@gentoo.org>
> >>Sent: Tuesday, January 18, 2022 11:41 AM
> >>To: gentoo-user@lists.gentoo.org
> >>Subject: Re: [gentoo-user] TLD for home LAN?
> >>
> >>On Tue, Jan 18, 2022 at 12:28 PM Laurence Perkins <lperkins@openeye.net> wrote:
> >>>
> >>> The standard does not prohibit the names being resolvable via unicast DNS as well, though it does recommend that you make sure the two resolution paths return consistent results since most systems will take the first response they get.
> >>
> >>If a host queries DNS first, and obtains an NXDOMAIN from an authoritative name server, I'm not sure most would even check mDNS. I think I had that issue back when I was using .local before I heard of zeroconfig.
> >>
>
> Right. If you have .local names registered with your DNS, but not resolvable via mDNS...

No, I'm talking about the opposite situation. I'm talking about you
have foo.local resolvable via mDNS, but not DNS - then there is a
chance you won't be able to access the host. Basically having an
authoritative nameserver for .local may disable mDNS on your network
for some devices.

--
Rich

>
>-----Original Message-----
>From: Rich Freeman <rich0@gentoo.org>
>Sent: Tuesday, January 18, 2022 12:50 PM
>To: gentoo-user@lists.gentoo.org
>Subject: Re: [gentoo-user] TLD for home LAN?
>
>On Tue, Jan 18, 2022 at 3:12 PM Laurence Perkins <lperkins@openeye.net> wrote:
>>
>>
>>
>> >>-----Original Message-----
>> >>From: Rich Freeman <rich0@gentoo.org>
>> >>Sent: Tuesday, January 18, 2022 11:41 AM
>> >>To: gentoo-user@lists.gentoo.org
>> >>Subject: Re: [gentoo-user] TLD for home LAN?
>> >>
>> >>On Tue, Jan 18, 2022 at 12:28 PM Laurence Perkins <lperkins@openeye.net> wrote:
>> >>>
>> >>> The standard does not prohibit the names being resolvable via unicast DNS as well, though it does recommend that you make sure the two resolution paths return consistent results since most systems will take the first response they get.
>> >>
>> >>If a host queries DNS first, and obtains an NXDOMAIN from an authoritative name server, I'm not sure most would even check mDNS. I think I had that issue back when I was using .local before I heard of zeroconfig.
>> >>
>>
>> Right. If you have .local names registered with your DNS, but not resolvable via mDNS...
>
>No, I'm talking about the opposite situation. I'm talking about you have foo.local resolvable via mDNS, but not DNS - then there is a chance you won't be able to access the host. Basically having an authoritative nameserver for .local may disable mDNS on your network for some devices.
>
>--
>Rich
>
Yeah, I can see that also being a possibility, and it's likely to be annoying to deal with since different clients can have different preferred resolver orders and may or may not take the authoritative part seriously and any program hard-coded to use mDNS will work fine, so there could be a big wad of inconsistent behaviour that obscures what's going on.

LMP

On 1/18/22 1:50 PM, Rich Freeman wrote:
> No, I'm talking about the opposite situation. I'm talking about you
> have foo.local resolvable via mDNS, but not DNS - then there is a
> chance you won't be able to access the host.

It's the same problem just opposite directions.

The solution is to use something to unify the .local name in the mDNS
and uDNS name spaces. This can be done via a gateway that speaks both
protocols. E.g. listens for mDNS queries as well as being an
authoritative uDNS server for the .local domain / TLD.

It's not /simple/ but nor is it /impossible/.



--
Grant. . . .
unix || die