Folks:
In my /etc/hosts file, there's a line:
127.0.1.1 yosemite.mars.lan yosemite
I think Debian put it there.
Later in the file, I've got:
192.168.254.30 yosemite.mars.lan yosemite
Folks:
In my /etc/hosts file, there's a line:
127.0.1.1 yosemite.mars.lan yosemite
I think Debian put it there.
Later in the file, I've got:
192.168.254.30 yosemite.mars.lan yosemite
So there are two entries for the same (my) machine. Is this a problem? Specifically, could it cause problems with email (Exim4 or OpenSMTPD)?
In my /etc/hosts file, there's a line:
127.0.1.1 yosemite.mars.lan yosemite
I think Debian put it there.
Later in the file, I've got:
192.168.254.30 yosemite.mars.lan yosemite
So there are two entries for the same (my) machine. Is this a problem? Specifically, could it cause problems with email (Exim4 or OpenSMTPD)?
Am 24.05.2024 um 17:17:45 Uhr schrieb [email protected]:
On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
[...]
If you operate mail servers, you must have a FQDN. .lan can't be
used for the global DNS stuff, so set a proper FQDN that belongs to
you.
I think this is wrong in that sweeping generality.
In the case it should communicate with other MTAs in the internet, this
will be true because many of them require a resolvable (also reverse)
FQDN in HELO/EHLO that matches the IPv4/IPv6 addresses of the server.
On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
[...]
If you operate mail servers, you must have a FQDN. .lan can't be
used for the global DNS stuff, so set a proper FQDN that belongs to
you.
I think this is wrong in that sweeping generality.
If you operate mail servers, you must have a FQDN. .lan can't be used
for the global DNS stuff, so set a proper FQDN that belongs to you.
Am 24.05.2024 um 17:17:45 Uhr schrieb [email protected]:
On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
[...]
If you operate mail servers, you must have a FQDN. .lan can't be
used for the global DNS stuff, so set a proper FQDN that belongs to
you.
I think this is wrong in that sweeping generality.
In the case it should communicate with other MTAs in the internet, this
will be true because many of them require a resolvable (also reverse)
FQDN in HELO/EHLO that matches the IPv4/IPv6 addresses of the server.
On Fri, May 24, 2024 at 05:22:14PM +0200, Marco Moock wrote:
Am 24.05.2024 um 17:17:45 Uhr schrieb [email protected]:
On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
[...]
If you operate mail servers, you must have a FQDN. .lan can't be
used for the global DNS stuff, so set a proper FQDN that belongs to you.
I think this is wrong in that sweeping generality.
In the case it should communicate with other MTAs in the internet, this will be true because many of them require a resolvable (also reverse)
FQDN in HELO/EHLO that matches the IPv4/IPv6 addresses of the server.
Most MTAs do not look in /etc/hosts when reading their configuration. Whatever name they identify with (in the HELO or EHLO command) comes
from some MTA-specific configuration file.
Thus, the contents of /etc/hosts are for *other* things, not related to
MTA configuration. Just being able to resolve your own hostname to any address that "works" is the goal. 127.0.1.1 works well for this, which
is why Debian uses it as the default. If you've got a static LAN address, you can use that instead.
On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
[...]
If you operate mail servers, you must have a FQDN. .lan can't be
used for the global DNS stuff, so set a proper FQDN that belongs to
you.
I think this is wrong in that sweeping generality.
On Fri, May 24, 2024 at 05:22:14PM +0200, Marco Moock wrote:
Am 24.05.2024 um 17:17:45 Uhr schrieb [email protected]:
On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
[...]
If you operate mail servers, you must have a FQDN. .lan can't be
used for the global DNS stuff, so set a proper FQDN that
belongs to you.
I think this is wrong in that sweeping generality.
In the case it should communicate with other MTAs in the internet,
this will be true because many of them require a resolvable (also
reverse) FQDN in HELO/EHLO that matches the IPv4/IPv6 addresses of
the server.
Most MTAs do not look in /etc/hosts when reading their configuration. Whatever name they identify with (in the HELO or EHLO command) comes
from some MTA-specific configuration file.
Thus, the contents of /etc/hosts are for *other* things, not related
to MTA configuration. Just being able to resolve your own hostname
to any address that "works" is the goal. 127.0.1.1 works well for
this, which is why Debian uses it as the default. If you've got a
static LAN address, you can use that instead.
On Fri, 24 May 2024 11:40:30 -0400
Greg Wooledge <[email protected]> wrote:
On Fri, May 24, 2024 at 05:22:14PM +0200, Marco Moock wrote:
Am 24.05.2024 um 17:17:45 Uhr schrieb [email protected]:
On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
[...]
If you operate mail servers, you must have a FQDN. .lan can't be
used for the global DNS stuff, so set a proper FQDN that
belongs to you.
I think this is wrong in that sweeping generality.
In the case it should communicate with other MTAs in the internet,
this will be true because many of them require a resolvable (also reverse) FQDN in HELO/EHLO that matches the IPv4/IPv6 addresses of
the server.
Most MTAs do not look in /etc/hosts when reading their configuration. Whatever name they identify with (in the HELO or EHLO command) comes
from some MTA-specific configuration file.
Thus, the contents of /etc/hosts are for *other* things, not related
to MTA configuration. Just being able to resolve your own hostname
to any address that "works" is the goal. 127.0.1.1 works well for
this, which is why Debian uses it as the default. If you've got a
static LAN address, you can use that instead.
Long ago, lo used to be just 127.0.0.1, which is what most people would
try to ping to check localhost, and what appeared in /etc/hosts. There
is some subtle reason, which I used to know but have now long forgotten,
why Debian started using 127.0.1.1 in /etc/hosts instead. As far as I'm aware, any 127. address will resolve to localhost.
On Fri, 24 May 2024 17:17:45 +0200
<[email protected]> wrote:
On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
[...]
If you operate mail servers, you must have a FQDN. .lan can't be
used for the global DNS stuff, so set a proper FQDN that belongs to
you.
I think this is wrong in that sweeping generality.
I believe the dynamic DNS services will supply an FQDN if you don't
have one, it just won't be personal, it will be one of theirs. But
trying to run a mail server on a dynamic address leads to all kinds of blacklist problems.
On Fri, May 24, 2024 at 11:13 AM Paul M Foster <[email protected]> wrote:
192.168.254.30 yosemite.mars.lan yosemite
127.0.1.1 is traditionally used for the fully qualified domain name
(fqdn). So I would expect to see 'yosemite.mars.lan', but not
'yosemite'.
Also, fqdn's end in dot '.' to denote the top of the dns tree.
Long ago, lo used to be just 127.0.0.1, which is what most people would
try to ping to check localhost, and what appeared in /etc/hosts. There
is some subtle reason, which I used to know but have now long forgotten,
why Debian started using 127.0.1.1 in /etc/hosts instead.
On Fri, May 24, 2024 at 11:13 AM Paul M Foster <[email protected]> wrote:
Folks:
In my /etc/hosts file, there's a line:
127.0.1.1 yosemite.mars.lan yosemite
I think Debian put it there.
Later in the file, I've got:
192.168.254.30 yosemite.mars.lan yosemite
So there are two entries for the same (my) machine. Is this a problem? Specifically, could it cause problems with email (Exim4 or OpenSMTPD)?
127.0.1.1 is traditionally used for the fully qualified domain name
(fqdn). So I would expect to see 'yosemite.mars.lan', but not
'yosemite'.
Also, fqdn's end in dot '.' to denote the top of the dns tree. So I
would expect to see 'yosemite.mars.lan.' (note the trailing dot), and
not 'yosemite.mars.lan' (note the lack of the trailing dot). What can
happen with 'yosemite.mars.lan' is, search domains can be added to it.
So if dhcp says 'isp.com' is a search domain, then your network stack
might make requests for 'yosemite.mars.lan.isp.com'.
On Fri, May 24, 2024 at 1:46 PM Greg Wooledge <[email protected]> wrote:
On Fri, May 24, 2024 at 01:40:38PM -0400, Jeffrey Walton wrote:
On Fri, May 24, 2024 at 11:13 AM Paul M Foster <[email protected]> wrote:
192.168.254.30 yosemite.mars.lan yosemite
127.0.1.1 is traditionally used for the fully qualified domain name (fqdn). So I would expect to see 'yosemite.mars.lan', but not
'yosemite'.
I don't know why you would expect that. What purpose would that serve?
Sorry I was not clear. I would expect that because 127.0.1.1 is
traditionally used for a fully qualified domain name, not a hostname.
On Fri, May 24, 2024 at 01:49:58PM -0400, Jeffrey Walton wrote:
On Fri, May 24, 2024 at 1:46 PM Greg Wooledge <[email protected]>
wrote:
On Fri, May 24, 2024 at 01:40:38PM -0400, Jeffrey Walton wrote:
On Fri, May 24, 2024 at 11:13 AM Paul M Foster <[email protected]> wrote:
192.168.254.30 yosemite.mars.lan yosemite
127.0.1.1 is traditionally used for the fully qualified domain
name (fqdn). So I would expect to see 'yosemite.mars.lan', but
not 'yosemite'.
I don't know why you would expect that. What purpose would that
serve?
Sorry I was not clear. I would expect that because 127.0.1.1 is traditionally used for a fully qualified domain name, not a
hostname.
What traditions are you referring to?
Here's Debian's documentation for this whole thing:
https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution
convention� as it pertains to the 127.0.0.1 iIP address is that it
is meant to be used for testing purposes on a whole.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 159:00:55 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,759 |