Hi,

On Sat, Aug 03, 2024 at 06:40:32PM +1000, George at Clug wrote:

I believe ICCAN are moving to possibly replacing .local, .home, .lan,
.corp, .mail, .localdomain, (and possibly others) with .internal ?

home.arpa was defined by IANA in 2018. If they go ahead with
.internal then I can only imagine it will be in addition to, not
instead of, home.arpa.

How could this affect mDNS and the use of .local?

It won't. mDNS will continue using .local.

If you use .local for other things it can interfere with mDNS but
picking almost anything else has very few repercussions (unless you
are very silly about it), so I don't understand why this topic
always generates so much debate on this list.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3 Aug 2024 12:59 +0000, from andy@strugglers.net (Andy Smith):

I believe ICCAN are moving to possibly replacing .local, .home, .lan,
.corp, .mail, .localdomain, (and possibly others) with .internal ?

home.arpa was defined by IANA in 2018. If they go ahead with
.internal then I can only imagine it will be in addition to, not
instead of, home.arpa.

The initial version of the relevant Internet Draft (as published Aug
2) doesn't even mention home.arpa, which seems like an oversight as
the intended use is very similar. Hopefully that will be corrected
before publication as a RFC.

https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-29-07-2024-en#section2.a

https://datatracker.ietf.org/doc/draft-davies-internal-tld/

https://www.ietf.org/archive/id/draft-davies-internal-tld-00.txt

.home was _specifically_ for HNCP (see RFC 7788; just as .local is _specifically_ for mDNS) and RFC 7788 was updated by RFC 8375 (the
reservation of .home.arpa) to use the more generic .home.arpa as a
default.

Assuming that there are no late showstoppers for the reservation of
.internal, we will going forward have two officially recommended
choices for where to place internal, non-unique hostnames; namely
*.internal and *.home.arpa. The third alternative is to register a
globally unique domain name and use that as the root for one's
internal DNS names; doing so guarantees global uniqueness in DNS for
the fully qualified names.

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/3/24 09:00, Andy Smith wrote:

Hi,

On Sat, Aug 03, 2024 at 06:40:32PM +1000, George at Clug wrote:

I believe ICCAN are moving to possibly replacing .local, .home, .lan,
.corp, .mail, .localdomain, (and possibly others) with .internal ?

home.arpa was defined by IANA in 2018. If they go ahead with
.internal then I can only imagine it will be in addition to, not
instead of, home.arpa.

How could this affect mDNS and the use of .local?

It won't. mDNS will continue using .local.

If you use .local for other things it can interfere with mDNS but
picking almost anything else has very few repercussions (unless you
are very silly about it), so I don't understand why this topic
always generates so much debate on this list.

Thanks,
Andy

I can hint at some of the problems Andy. Because I'm about to try to
bring another bpi-m5 up to run amanda in a 8 to 16 t-byte all solid
state NAS.

The coders in charge have gone way beyond just hiding a sensible way of
setting hostname and domainname without using some other tool that isn't
even intuitively named. You can put the arm64 boot media into another
machine, mount it and edit both /etc/hostname and /etc/domainname with
nano, write a copy of your /etc/hosts file to that media. then umount
it, put it back in the target machine, boot it, and both files are wiped
& gone. Why????

The machine has no damned idea of what its domain and hostname is.
Prefilling /etc/hosts with the correct data is a waste of time until
that is configured by the correct tool, Why????

And if it has to be that difficult to bring up a new machine on your
local 192.168.xxx.zzz unroutable network, why the heck do we not have a
fill in the blanks script to do that. This is 2024, not 1985 and AT&T's Unix-3.3. There's no excuse for that level of difficulty to exist in 2024.

I'll admit that network-mangler has now learned how to do much of that
once you have the names set, but why did it take a decade to reach that
state? It should have been fixed by the end of wheezy.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sat, Aug 03, 2024 at 10:22:43PM +0100, mick.crane wrote:

Initially the advice was .home. Then I think BT started using that on mobile network.
Then they said use .local. then they said use .home.

I don't recall anything about .home being recommended, but yeah
Microsoft did suggest .local back in the early 2000s and then go
back on that. The RFC for mDNS standardised its use of .local in
2013.

Once things end up in some Internet RFC that's a bit more weight
than just a vendor suggesting it. Vendors do crazy things, like
putting captive portals on the 1.1.1.1 IP address.

I was going to change everything yet again to home.arpa but now it might be .internal?

At worst I expect both will be reserved for this use.

There's unlikely to be any terrible problem with whatever you use
now so I wouldn't worry about it.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3 Aug 2024 22:22 +0100, from mick.crane@gmail.com (mick.crane):

I was going to change everything yet again to home.arpa but now it might be .internal?

To use .home.arpa is absolutely fine if you don't need (or want)
globally unique names. It has been properly assigned specifically for "non-unique use in residential home networks". (RFC 8375.)

.internal is _in the process of_ being standardized for "private
applications". It isn't quite there yet, but it _has_ been reserved
for that purpose in the global root DNS zone so unless the ICANN Board
reneges on that decision no one is going to buy themselves a gTLD of
.internal either now or in the future.

The downsides of using .home.arpa over .internal (as proposed) are
basically only that (a) it's two labels instead of one, which some
people care about; and (b) it _looks_ weird in a corporate or other organizational context to have a word referencing residential use in
hostnames.

I'm pretty sure a bare .home has never been recommended other than as
a default for HNCP (which was since changed), and in any case people
coming up with so many different variants on their own shows the value
of standardizing on something especially in the current world where
acquiring a gTLD is _far_ easier than it was a few decades ago. Just
look at the mess it must have created with what people intended as
internal names when Google not only acquired .dev, but also made it a HSTS-preloaded TLD.

(And no, effectively saying "we don't recommend it, but if you must,
here are some that people use" does not constitute a recommendation.)

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Aug 03, 2024 at 04:10:33PM -0400, gene heskett wrote:

On 8/3/24 09:00, Andy Smith wrote:

Hi,

[Very interesting Stuff snipped about ICANN and domain suffixes]

If you use .local for other things it can interfere with mDNS but
picking almost anything else has very few repercussions (unless you
are very silly about it), so I don't understand why this topic
always generates so much debate on this list.

Thanks,
Andy

Part of the reason it generates more heat than light, Andy, is because off-topicness creaps in. It's an occupational hazard on this list.

I can hint at some of the problems Andy. Because I'm about to try to bring another bpi-m5 up to run amanda in a 8 to 16 t-byte all solid state NAS.

Gene,

With the best will in the world: you'll be bringing up another small
ARM board ro do something and assuming that any and all discussion
of any other topic is relevant to that.

Most of the boards you have are running Armbian (information gathered
from another reply from you on debian-arm mailing list recently at https://lists.debian.org/debian-arm/2024/07/msg00018.html .)

The folks at Armbian do one job really well. They take the board
support packages and random kernels that vendors put out when you buy
a board from an OEM somewhere in SE Asia. Those BSPs and kernel versions
may not correspond to anything aybody else has - Armbian take them,
get the boards running and then drop a Debian or an Ubuntu userland on top. Whatever the vendor has put out to boot up the new board and deal with all
its hardware quirks - Armbian will make that run. They don't necessarily undertake to revise it, support it long term. That's not their job as
they see it, theirs is to get a board up and running and (relatively)
stable before they move on to the next one. That they do *really* well

One more time: Armbian may be using a Debian based userland but it's
NOT Debian.The underpinning bootstrap routines may be different. They
may have chosen different options as they've built effectively yet
another Debian derivative per new ARM board.

The coders in charge have gone way beyond just hiding a sensible way of setting hostname and domainname without using some other tool that isn't
even intuitively named. You can put the arm64 boot media into another machine, mount it and edit both /etc/hostname and /etc/domainname with nano, write a copy of your /etc/hosts file to that media. then umount it, put it back in the target machine, boot it, and both files are wiped & gone.
Why????

You'll need to take that up with the Armbian folks and see how they've configured Debian userland and the settings in their master image. You'll
have to look at the steps that you've taken to customise your instances on
your machines on your internal network at coyote.den

The machine has no damned idea of what its domain and hostname is.
Prefilling /etc/hosts with the correct data is a waste of time until that is configured by the correct tool, Why????

What logs are you seeing / what error messages? What's the behaviour
if your network doesn't give out DHCP but the Armbian software is expecting
it? We have no information even for an informed guess.

And if it has to be that difficult to bring up a new machine on your local 192.168.xxx.zzz unroutable network, why the heck do we not have a fill in
the blanks script to do that. This is 2024, not 1985 and AT&T's Unix-3.3. There's no excuse for that level of difficulty to exist in 2024.

What are the defaults?

I'll admit that network-mangler has now learned how to do much of that once you have the names set, but why did it take a decade to reach that state? It should have been fixed by the end of wheezy.

In default of better information, the rest of us won't know if it's a
Debian problem or a Gene problem.

With every good wish, as ever,

Andy Cater
(amacater@debian.org)

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/3/24 18:09, Andrew M.A. Cater wrote:

On Sat, Aug 03, 2024 at 04:10:33PM -0400, gene heskett wrote:

On 8/3/24 09:00, Andy Smith wrote:

Hi,

[Very interesting Stuff snipped about ICANN and domain suffixes]

If you use .local for other things it can interfere with mDNS but
picking almost anything else has very few repercussions (unless you
are very silly about it), so I don't understand why this topic
always generates so much debate on this list.

Thanks,
Andy

Part of the reason it generates more heat than light, Andy, is because off-topicness creaps in. It's an occupational hazard on this list.

I can hint at some of the problems Andy. Because I'm about to try to bring >> another bpi-m5 up to run amanda in a 8 to 16 t-byte all solid state NAS.

Gene,

With the best will in the world: you'll be bringing up another small
ARM board ro do something and assuming that any and all discussion
of any other topic is relevant to that.

Most of the boards you have are running Armbian (information gathered
from another reply from you on debian-arm mailing list recently at https://lists.debian.org/debian-arm/2024/07/msg00018.html .)

The folks at Armbian do one job really well. They take the board
support packages and random kernels that vendors put out when you buy
a board from an OEM somewhere in SE Asia. Those BSPs and kernel versions
may not correspond to anything aybody else has - Armbian take them,
get the boards running and then drop a Debian or an Ubuntu userland on top. Whatever the vendor has put out to boot up the new board and deal with all its hardware quirks - Armbian will make that run. They don't necessarily undertake to revise it, support it long term. That's not their job as
they see it, theirs is to get a board up and running and (relatively)
stable before they move on to the next one. That they do *really* well

One more time: Armbian may be using a Debian based userland but it's
NOT Debian.The underpinning bootstrap routines may be different. They
may have chosen different options as they've built effectively yet
another Debian derivative per new ARM board.

The coders in charge have gone way beyond just hiding a sensible way of
setting hostname and domainname without using some other tool that isn't
even intuitively named. You can put the arm64 boot media into another
machine, mount it and edit both /etc/hostname and /etc/domainname with nano, >> write a copy of your /etc/hosts file to that media. then umount it, put it >> back in the target machine, boot it, and both files are wiped & gone.
Why????

You'll need to take that up with the Armbian folks and see how they've configured Debian userland and the settings in their master image. You'll have to look at the steps that you've taken to customise your instances on your machines on your internal network at coyote.den

The machine has no damned idea of what its domain and hostname is.
Prefilling /etc/hosts with the correct data is a waste of time until that is >> configured by the correct tool, Why????

What logs are you seeing / what error messages? What's the behaviour
if your network doesn't give out DHCP but the Armbian software is expecting it? We have no information even for an informed guess.

And if it has to be that difficult to bring up a new machine on your local >> 192.168.xxx.zzz unroutable network, why the heck do we not have a fill in
the blanks script to do that. This is 2024, not 1985 and AT&T's Unix-3.3.
There's no excuse for that level of difficulty to exist in 2024.

What are the defaults?

IDK, I've written the nobel server install to a 128GB micro-sd, along
with setting the hosts file from this machine as the master copy. Since 192.168.nn.2 wasn't used, I added amanda.coyote.den there, played to see
it it recognized the pair of SP 4t's drives, seems to but if the hub
with the 4T attached is in the same vertical pair of usb ports the
keyboard button is disabled. Left to right pairing works fine.
Rebooting it resets the hostname to bannapim5 and blanks the domainname.
I'll next install the debian-arm bookworm server and see how it behaves

I'll admit that network-mangler has now learned how to do much of that once >> you have the names set, but why did it take a decade to reach that state? It >> should have been fixed by the end of wheezy.

In default of better information, the rest of us won't know if it's a
Debian problem or a Gene problem.

With every good wish, as ever,

Andy Cater
(amacater@debian.org)

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sat, Aug 03, 2024 at 10:08:55PM +0000, Andrew M.A. Cater wrote:

On 8/3/24 09:00, Andy Smith wrote:

If you use .local for other things it can interfere with mDNS but
picking almost anything else has very few repercussions (unless you
are very silly about it), so I don't understand why this topic
always generates so much debate on this list.

Part of the reason it generates more heat than light, Andy, is because off-topicness creaps in.

I've been thinking about it and I also wonder if it's because
home.arpa is relatively new and weird-sounding so anyone who's been
around for a while probably does not use it themselves. When certain
such people read a post that says that home.arpa is the standard
they somehow feel personally called out ("they're saying I'm
NON-COMPLIANT!?") and compelled to either question it, argue it or
simply state a personal anecdote about what they use on their
network and why it is okay / has always been okay.

So I want to emphasise again that while standards are useful so
we're all on the same page, in this particular case it's not a big
deal, likely nothing terribly bad is going to happen to you even if
you do squat on some already-allocated TLD let alone a possible
future one. We should just accept what the standard is and consider
it next time we set things up.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 4 Aug 2024 12:59:55 +0000
Andy Smith <andy@strugglers.net> wrote:

Hi,

On Sat, Aug 03, 2024 at 10:08:55PM +0000, Andrew M.A. Cater wrote:

On 8/3/24 09:00, Andy Smith wrote:

If you use .local for other things it can interfere with mDNS
but picking almost anything else has very few repercussions
(unless you are very silly about it), so I don't understand why
this topic always generates so much debate on this list.

Part of the reason it generates more heat than light, Andy, is
because off-topicness creaps in.

I've been thinking about it and I also wonder if it's because
home.arpa is relatively new and weird-sounding so anyone who's been
around for a while probably does not use it themselves. When certain
such people read a post that says that home.arpa is the standard
they somehow feel personally called out ("they're saying I'm NON-COMPLIANT!?") and compelled to either question it, argue it or
simply state a personal anecdote about what they use on their
network and why it is okay / has always been okay.

So I want to emphasise again that while standards are useful so
we're all on the same page, in this particular case it's not a big
deal, likely nothing terribly bad is going to happen to you even if
you do squat on some already-allocated TLD let alone a possible
future one. We should just accept what the standard is and consider
it next time we set things up.

Exactly. I've run a DHCP server since about 2010, and used one of my
own domain names in my network since 2006. I know what to do about
external resources on the same domain, not that I have any at the
moment. I've never had any kind of networking trouble that is
associated with using that internal domain name.

--
Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 04-08-2024 at 22:59 Andy Smith wrote:

Hi,

On Sat, Aug 03, 2024 at 10:08:55PM +0000, Andrew M.A. Cater wrote:

On 8/3/24 09:00, Andy Smith wrote:

If you use .local for other things it can interfere with mDNS but picking almost anything else has very few repercussions (unless you
are very silly about it), so I don't understand why this topic
always generates so much debate on this list.

Part of the reason it generates more heat than light, Andy, is because off-topicness creaps in.

I've been thinking about it and I also wonder if it's because
home.arpa is relatively new and weird-sounding so anyone who's been
around for a while probably does not use it themselves. When certain
such people read a post that says that home.arpa is the standard
they somehow feel personally called out ("they're saying I'm NON-COMPLIANT!?") and compelled to either question it, argue it or
simply state a personal anecdote about what they use on their
network and why it is okay / has always been okay.

So I want to emphasise again that while standards are useful so
we're all on the same page, in this particular case it's not a big
deal, likely nothing terribly bad is going to happen to you even if
you do squat on some already-allocated TLD let alone a possible
future one. We should just accept what the standard is and consider
it next time we set things up.

Sorry, but I feel confused about what the 'current' standard is, and how long it might be a standard.

<rant>

I have been traumatised by things changing. Just when I think I know something, someone goes and changes it.

I will accept that for now that home.arpa but having anything end is "arpa" sounds wrong.

It is not iptables anymore, it is nftables. It is not 'reboot' or 'shutdown -r now' it is 'systemctl reboot', it is not syslog it is journalctl.

I still want to use 'shutdown -h now' (because of 1990's slackware) instead of 'systemctl poweroff'.

So when was .local high jacked for mDNS? It was for my Microsoft Small Business server internal domain.

I need to just "get over it", I guess. And keep up with the times.

</rant>

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sun, Aug 04, 2024 at 11:54:07PM +1000, George at Clug wrote:

On Sunday, 04-08-2024 at 22:59 Andy Smith wrote:

So I want to emphasise again that while standards are useful so
we're all on the same page, in this particular case it's not a big
deal, likely nothing terribly bad is going to happen to you even if
you do squat on some already-allocated TLD let alone a possible
future one. We should just accept what the standard is and consider
it next time we set things up.

Sorry, but I feel confused about what the 'current' standard is,
and how long it might be a standard.

Standards don't tend to be abolished unless there's a good reason.
There wasn't a standard before home.arpa. Since 2013 it's been "use
your own globally unique registered domain, or else use home.arpa".
But in this case even if you don't do that, or don't want to do
that, *it doesn't really matter*!

Are you sure you aren't dramatically "feeling confused" about this
simple thing as an excuse to have a big complain?

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4 Aug 2024 14:35 +0100, from joe@jretrading.com (Joe):

Exactly. I've run a DHCP server since about 2010, and used one of my
own domain names in my network since 2006.

Using a domain name that you control has never been problematic. Or,
well, for as long as DNS has been a thing at least (pre-DNS hostnames
are a slightly different matter).

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 05-08-2024 at 00:19 Andy Smith wrote:

Hi,

On Sun, Aug 04, 2024 at 11:54:07PM +1000, George at Clug wrote:

On Sunday, 04-08-2024 at 22:59 Andy Smith wrote:

So I want to emphasise again that while standards are useful so
we're all on the same page, in this particular case it's not a big
deal, likely nothing terribly bad is going to happen to you even if
you do squat on some already-allocated TLD let alone a possible
future one. We should just accept what the standard is and consider
it next time we set things up.

Sorry, but I feel confused about what the 'current' standard is,
and how long it might be a standard.

Standards don't tend to be abolished unless there's a good reason.
There wasn't a standard before home.arpa. Since 2013 it's been "use
your own globally unique registered domain, or else use home.arpa".
But in this case even if you don't do that, or don't want to do
that, *it doesn't really matter*!

Are you sure you aren't dramatically "feeling confused" about this
simple thing as an excuse to have a big complain?

Na, I just get confused too easily, when I feel things are not clear. But thanks to everyone posting, and reading on the links people have provided, and a few searches, I now believe home.arpa is good for now, and expect .internal will also be good for
the future. Until things change once more.

Actually, I do thank everyone for their posts, I am learning a lot. I almost decided to give up on this email thread, but now I am pleased to stay for awhile.

On the topic of firewalls, over the years I have had many speak with distain about blocking outgoing ports, and only a few who support the concept as a security measure. I am very curious if there are any valid arguments for not implementing the blocking
of NEW connections for outgoing ports as we do for incoming ports. So far the only valid argument I have heard is that is more trouble than it is worth, but from my experience, it is not much trouble at all, so even if the benefit is low, why not? But
when to do it is very situational, e.g. certain servers, and for when I am connection my computer to a potentially risky network.

Thank you, Andy,

George.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5 Aug 2024 00:34 +1000, from clug@goproject.info (George at Clug):

Standards don't tend to be abolished unless there's a good reason.
There wasn't a standard before home.arpa. Since 2013 it's been "use
your own globally unique registered domain, or else use home.arpa".

The RFC specifying .home.arpa is from 2018.

But thanks to everyone posting, and reading on the links people have provided, and a few searches, I now believe home.arpa is good for
now, and expect .internal will also be good for the future. Until
things change once more.

The odds that either .home.arpa _or_ .internal (after it has gone
through the full RFC process) will be retired for the purpose of
non-unique private use seem low. The cost of retiring either will be
relatively high if they end up being widely used, and the benefit of
doing so will be quite low.

So for right now, as far as I am aware, the officially recommended (by
ICANN and IANA) options are to either (a) use a domain name you
actually control (whether or not names in it are resolvable on the
global Internet), or (b) use .home.arpa.

At some point in the near future, that list will very likely be
extended with (c) use .internal.

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday 04 August 2024 09:54:07 am George at Clug wrote:

<rant>

I have been traumatised by things changing. Just when I think I know something, someone goes and changes it.

Yeah, I keep seeing things changed to something new, and wonder why the heck I need that...

--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

George at Clug wrote:

It is not iptables anymore, it is nftables. It is not 'reboot' or 'shutdown -r now' it is 'systemctl reboot', it is not syslog it is journalctl.

iptables still exists, and it calls nftables to do the work
underneath.

If you are using systemd, it's systemctl reboot, but you don't
have to use systemd. Since you are using systemd, both
/sbin/reboot and /sbin/shutdown should have been linked to
systemctl for you.

The systemd journal is pretty awful, but just installing
rsyslogd on a systemd system does almost everything you want.

There have certainly been missteps. Mostly they get fixed.

-dsr-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat 03 Aug 2024 at 12:59:45 (+0000), Andy Smith wrote:

On Sat, Aug 03, 2024 at 06:40:32PM +1000, George at Clug wrote:

I believe ICCAN are moving to possibly replacing .local, .home, .lan, .corp, .mail, .localdomain, (and possibly others) with .internal ?

home.arpa was defined by IANA in 2018. If they go ahead with
.internal then I can only imagine it will be in addition to, not
instead of, home.arpa.

How could this affect mDNS and the use of .local?

It won't. mDNS will continue using .local.

If you use .local for other things it can interfere with mDNS but
picking almost anything else has very few repercussions (unless you
are very silly about it), so I don't understand why this topic
always generates so much debate on this list.

Possibly because people aren't warned against using it unless they're
on a network that is already using it for Microsoft servers. It would
be simple to add such a warning to the screen below, and perhaps some
advice on home.arpa etc at the same time.

┌─────────────────────────┤ [!!] Configure the network ├────────────────────┐
│ │
│ The domain name is the part of your Internet address to the right of your │
│ host name. It is often something that ends in .com, .net, .edu, or .org. │
│ If you are setting up a home network, you can make something up, but make │
│ sure you use the same domain name on all your computers. │
│ │
│ Domain name: │
│ │
│ _ │
│ │
│ <Go Back> <Continue> │
│ │
└───────────────────────────────────────────────────────────────────────────┘

With any group of people for whom the second line is useful
information, I think a significant proportion would choose a name
like "local" after reading the third line.

BTW you can't /buy/ your own domain, only rent it—and prompt payment
is required to make sure you keep it.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5 Aug 2024 23:51 -0500, from deblis@lionunicorn.co.uk (David Wright):

Possibly because people aren't warned against using it unless they're
on a network that is already using it for Microsoft servers. It would
be simple to add such a warning to the screen below, and perhaps some
advice on home.arpa etc at the same time.

┌─────────────────────────┤ [!!] Configure the network ├────────────────────┐
│ │
│ The domain name is the part of your Internet address to the right of your │
│ host name. It is often something that ends in .com, .net, .edu, or .org. │
│ If you are setting up a home network, you can make something up, but make │
│ sure you use the same domain name on all your computers. │
│ │
│ Domain name: │
│ │
│ _ │
│ │
│ <Go Back> <Continue> │
│ │
└───────────────────────────────────────────────────────────────────────────┘

With any group of people for whom the second line is useful
information, I think a significant proportion would choose a name
like "local" after reading the third line.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054557

--
Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I believe ICCAN are moving to possibly replacing .local, .home, .lan,
.corp, .mail, .localdomain, (and possibly others) with .internal ?


How could this affect mDNS and the use of .local?


https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024
Staff have assessed that there have been no responses that would cause
them to view the analysis as erroneous or to require re-assessment or
a different conclusion. Therefore the proposed selection (.INTERNAL),
along with the outcome of the public comment proceeding, will be
presented to the ICANN Board for further consideration.

https://icannwiki.org/Name_Collision
ICANN deemed two strings, .home and .corp, as "high-risk" because of
the widespread use of the terms on internal networks. Currently, ICANN
is indefinitely delaying the delegation of these string to the root.
Public Comments
      2. Case Studies of Collision Strings (.corp, .home, .mail, .internal, .lan, and .local) based on DNS query data from A and J root
servers in light of DNS evolution.


https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf
ICANN has stated that it will indefinitely defer delegating three
TLDs: .corp, .home, and .mail. These
gTLDs are still in common use in private namespaces, and thus pose a significantly higher risk for
collisions than other TLDs. The deferral is not guaranteed to be
forever, so any organization using one
of those names as a private namespace should still follow the
directions in Section 4 or Section 5 for
migrating from the private namespace.


https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf


https://www.theregister.com/2024/01/29/icann_internal_tld/


https://datatracker.ietf.org/doc/html/rfc6762
   Using ".local" as a private top-level domain conflicts with
Multicast DNS and may cause problems for users.


https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-113-en.pdf

https://wiki.archlinux.org/title/Systemd-resolved

https://www.freedesktop.org/software/systemd/man/latest/nss-resolve.html

<html>
<head>
<style type="text/css">
body,p,td,div,span{
font-size:13px; font-family:Arial, Helvetica, sans-serif;
};
body p{
margin:0px;
}
</style>
</head>
<body><div><br></div><div>I believe ICCAN are moving to possibly replacing .local, .home, .lan, .corp, .mail, .localdomain, (and possibly others) with .internal ?</div><div><br></div><div>How could this affect mDNS and the use of .local?<br></div><div><

https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024<br>Staff have assessed that there have been no responses that would cause them to view the analysis as erroneous or to require re-assessment

or a different conclusion. Therefore the proposed selection (.INTERNAL), along with the outcome of the public comment proceeding, will be presented to the ICANN Board for further consideration.<br><br>https://icannwiki.org/Name_Collision<br>ICANN deemed
two strings, .home and .corp, as "high-risk" because of the widespread use of the terms on internal networks. Currently, ICANN is indefinitely delaying the delegation of these string to the root.<br>Public Comments<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.
Case Studies of Collision Strings (.corp, .home, .mail, .internal, .lan, and .local) based on DNS query data from A and J root servers in light of DNS evolution.</div><div><br></div><div>https://www.icann.org/en/system/files/files/name-collision-
mitigation-01aug14-en.pdf<br>ICANN has stated that it will indefinitely defer delegating three TLDs: .corp, .home, and .mail. These<br>gTLDs are still in common use in private namespaces, and thus pose a significantly higher risk for<br>collisions than
other TLDs. The deferral is not guaranteed to be forever, so any organization using one<br>of those names as a private namespace should still follow the directions in Section 4 or Section 5 for<br>migrating from the private namespace.</div><div><br></div>
<div>https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf</div><div><br></div><div>https://www.theregister.com/2024/01/29/icann_internal_tld/</div><div><br></div><div>https://datatracker.ietf.org/doc/html/rfc6762<br>&nbsp;&
nbsp; Using ".local" as a private top-level domain conflicts with Multicast DNS and may cause problems for users.</div><div><br></div><div>https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-113-en.pdf<br><br>
https://wiki.archlinux.org/title/Systemd-resolved<br><br>https://www.freedesktop.org/software/systemd/man/latest/nss-resolve.html</div><div><br></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)