Re: Debian and FQDN lookup
On 2015-04-04 10:02:22 +0100, Joe wrote: On Fri, 3 Apr 2015 20:39:26 -0500 David Wright deb...@lionunicorn.co.uk wrote: I think I/we ought to be using .local http://tools.ietf.org/html/rfc6762 because this won't get onto the Internet. Really? I've seen an Exchange Server refuse mail from a BT server for this connection, the BT server is actually the client. because the latter identified itself with .local as tld in the HELO. BT knows nothing about email. I doubt this has anything to do with BT. MTA's will generally provide the FQDN as the HELO name (as described in the corresponding RFC), and if the FQDN has been chosen to end with .local then you'll get that in the HELO. Anyway the HELO should really be ignored in practice as it provides no useful information for the recipient. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150407112333.gc9...@ypig.lip.ens-lyon.fr
Re: Debian and FQDN lookup
On Tue, 7 Apr 2015 13:23:33 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2015-04-04 10:02:22 +0100, Joe wrote: On Fri, 3 Apr 2015 20:39:26 -0500 David Wright deb...@lionunicorn.co.uk wrote: I think I/we ought to be using .local http://tools.ietf.org/html/rfc6762 because this won't get onto the Internet. Really? I've seen an Exchange Server refuse mail from a BT server for this connection, the BT server is actually the client. because the latter identified itself with .local as tld in the HELO. I doubt this has anything to do with BT. MTA's will generally provide the FQDN as the HELO name (as described in the corresponding RFC), and if the FQDN has been chosen to end with .local then you'll get that in the HELO. My point was that the default is only of use for a machine directly exposed to the Net, with a hostname resolvable in public DNS. This one clearly wasn't, and its admin should have overridden the default. And should have *known* that it was something he/she needed to fix. Anyway the HELO should really be ignored in practice as it provides no useful information for the recipient. Possibly so, but it is currently an integral part of the SMTP transaction, and it is a common requirement of a receiving mail server that the sender's HELO be resolvable in public DNS. It's one of the common options offered by exim4, though not the default. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150407192020.3e070...@jresid.jretrading.com
Re: Debian and FQDN lookup
Brian wrote: Every time I use d-i in expert mode I wonder what other people make of it. I was puzzled by it the very first time and even now think it is one of the most difficult fields to fill in because the background knowledge needed isn't immediately as apparent as it is with language or location, say. The installation manual is really of no help as it has little commentary on its significance, I only very rarely use expert mode. I almost always use the normal mode. Then I fix up anything I want to change after the installation is complete. As an example, let us suppose your ISP in the UK is talktalk.co.uk. You put this as your domain name because that is all you can think of. After all, it is in your email address and you do not have your own domain. I am spoiled because for my installations there has always been a valid domain name to use. It is good to be reminded that not everyone has that environment. Thanks. Your hostname is copernicus. So your canonical hostname becomes copernicus.bt.com, which doen't exist and doesn't resolve. Now - what harm is done? No immediate harm. Some strange things with mail routing and so forth. But very few people do local mail delivery these days. And that would be mostly fine regardless. It would provide the domain in the /etc/hosts file. That would make most things happy. Leaving the field blank often gets you what your router provides; copernicus.lan in my case. Cool! What mechanism supports that happening? Is the default domain in your router's dhcp config the .lan domain? David Wright wrote: Quoting David Wright (deb...@lionunicorn.co.uk): Do you think there's time to get such advice into jessie's installer for domestic users (assuming it's good advice)? ... er, or even the opposite advice (appendix G) which shows how fraught this area is! Yes. Certainly! It is a confusing topic. *I* am confused by the topic of local private domains. It would be good to provide some guidance at installation time. And now a short diversion about Postfix related to hostnames... Previously in Wheezy 7 and before postfix $mydomain defaulted to $myhostname minus the first component, or localdomain. $myhostname defaulted to gethostname() and if that had no dots it appended $mydomain forming names such as foo.localdomain when the configured hostname was a short name (the general Debian recommendation) rather than a FQDN. That would match the names used in /etc/hosts and everything would work. For a system defaulting to localhost: root@localhost:~# postconf -d myhostname myhostname = localhost.localdomain root@localhost:~# postconf -d mydomain mydomain = localdomain To set correct domains I always set myhostname explicitly to the FQDN in the Postfix main.cf configuration. Setting just myorigin = /etc/mailname (a Debian specific patch) doesn't really set all of the names correctly for a standalone system. root@localhost:~# postconf -d myorigin myorigin = $myhostname AFAICS the defaults of setting localhost.localdomain both in /etc/hosts and in the Postfix config cause the complete loop to be correct and work for the simple standalone unconnected case. It will get localhost.localdomain in both places and the virtual circuit is valid throughout. Local delivery at least works without errors. Of course someone setting up a full mail server will need to assign a valid hostname and a valid domain name. That connects everything correctly too. The interesting case is when there is a local hostname that isn't localhost but no valid domain has been set. That should never happen on a system trying to be a valid mail server. But it obviously does get set up by users just installing the system and trying to do the best they can with the information they have at the time. That feels like a corner case to me. One that should be discouraged. Having some extra description at installation time to help avoid it would be a good thing in my opinion. It would avoid the cases where 'hostname -f' returns a name without any dots which confuses software written that insists there must be dots in there. Bob signature.asc Description: Digital signature
Re: Debian and FQDN lookup
On Fri, 3 Apr 2015 20:39:26 -0500 David Wright deb...@lionunicorn.co.uk wrote: I think I/we ought to be using .local http://tools.ietf.org/html/rfc6762 because this won't get onto the Internet. Really? I've seen an Exchange Server refuse mail from a BT server because the latter identified itself with .local as tld in the HELO. BT knows nothing about email. But there's a certain amount of Microsofting going on here. A few random machines in a private network don't have a 'domain', the term has no meaning for them. It's not until the network runs a DNS server, or provides some service across the Internet, that 'domain' and 'FQDN' become meaningful. Even in the latter case, 'domain' applies only to the external interface and to any network machines carrying public IP addresses, and means nothing to machines behind NAT. But MS have re-used the word 'domain' for their network security system, which is really (nearly) a Kerberos realm. This causes endless confusion in the MS world, which seems now to have spilled over. A purely private MS DNS server, if given the same 'domain' name as the real Internet domain of the owner, will make external domain resources invisible to internal users. So the DNS server has to have external resource names bodged into it by some means or other, which invariably doesn't get documented properly, and breaks when an IP address changes... One or more workstations using an Active Directory server *must* have a 'domain', which need have no relationship with any Internet domain if IP addressing is private. But a few random Linux (or other OS) machines connecting to the Net through a NAT router have no use for 'domain'. I would agree that this is difficult to convey in an installer screen, but I would think that anyone who really needs to have a domain specified for a workstation already knows that, and knows how to organise it. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150404100222.767e3...@jresid.jretrading.com
Re: Debian and FQDN lookup
Brian wrote: Bob Proulx wrote: The debian-installer will set things up right with an entry such as this one. 127.0.1.1 foo.example.com foo If 'Domain name' is blank you get '127.0.1.1 foo'. Ah, yes, I had left that out. We had discussed that point in a previous email. However I don't think the domain should be left blank for the installer. Certainly not for an email server. One of these days we should get together and create or update a documentation page with all of the information on this topic all in one place. :-) But there is already the fine Debian Reference maintained by Osamu Aoki. All it takes is time and that seems in less supply every day. Bob signature.asc Description: Digital signature
Re: Debian and FQDN lookup
On Fri 03 Apr 2015 at 14:29:49 -0600, Bob Proulx wrote: Brian wrote: Bob Proulx wrote: The debian-installer will set things up right with an entry such as this one. 127.0.1.1 foo.example.com foo If 'Domain name' is blank you get '127.0.1.1 foo'. Ah, yes, I had left that out. We had discussed that point in a previous email. However I don't think the domain should be left blank for the installer. Certainly not for an email server. One of these days we should get together and create or update a documentation page with all of the information on this topic all in one place. :-) But there is already the fine Debian Reference maintained by Osamu Aoki. All it takes is time and that seems in less supply every day. Every time I use d-i in expert mode I wonder what other people make of it. I was puzzled by it the very first time and even now think it is one of the most difficult fields to fill in because the background knowledge needed isn't immediately as apparent as it is with language or location, say. The installation manual is really of no help as it has little commentary on its significance, As an example, let us suppose your ISP in the UK is talktalk.co.uk. You put this as your domain name because that is all you can think of. After all, it is in your email address and you do not have your own domain. Your hostname is copernicus. So your canonical hostname becomes copernicus.bt.com, which doen't exist and doesn't resolve. Now - what harm is done? Leaving the field blank often gets you what your router provides; copernicus.lan in my case. The Debian Reference doesn't appear to have anything to say about domain name either. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150403233415.gk22...@copernicus.demon.co.uk
Re: Debian and FQDN lookup
Quoting Brian (a...@cityscape.co.uk):
On Fri 03 Apr 2015 at 14:29:49 -0600, Bob Proulx wrote:
Brian wrote:
Bob Proulx wrote:
The debian-installer will set things up right with an entry such as
this one.
127.0.1.1 foo.example.com foo
If 'Domain name' is blank you get '127.0.1.1 foo'.
Ah, yes, I had left that out. We had discussed that point in a
previous email. However I don't think the domain should be left blank
for the installer. Certainly not for an email server.
One of these days we should get together and create or update a
documentation page with all of the information on this topic all in
one place. :-) But there is already the fine Debian Reference
maintained by Osamu Aoki. All it takes is time and that seems in less
supply every day.
I agree. I think I may have stumbled on the same or a similar
discussion regarding 127.0.1.1 foo and I tried making changes
accordingly. The result of one of these was that I got a message about
my MTA, hostname and --fqdn so I reverted to having
#127.0.1.1 foo
192.168.1.19 foo.home foo
And I vaguely remember having problems when I moved a machine from
work to home and had to change all the networking parameters:
finding them all and knowing what to change them to. Files like
/etc/{networks,mailname}
Every time I use d-i in expert mode I wonder what other people make of
it. I was puzzled by it the very first time and even now think it is one
of the most difficult fields to fill in because the background knowledge
needed isn't immediately as apparent as it is with language or location,
say. The installation manual is really of no help as it has little
commentary on its significance,
As an example, let us suppose your ISP in the UK is talktalk.co.uk. You
put this as your domain name because that is all you can think of. After
all, it is in your email address and you do not have your own domain.
Your hostname is copernicus. So your canonical hostname becomes
copernicus.bt.com, which doen't exist and doesn't resolve. Now - what
harm is done? Leaving the field blank often gets you what your router
provides; copernicus.lan in my case.
The Debian Reference doesn't appear to have anything to say about domain
name either.
I'm one of the many who use .home
https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-00
and this paper points out that there's an awful lot of leakage onto
the Internet.
I think I/we ought to be using .local
http://tools.ietf.org/html/rfc6762
because this won't get onto the Internet.
Do you think there's time to get such advice into jessie's installer
for domestic users (assuming it's good advice)?
Cheers,
David.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150404013926.gb16...@alum.home
Re: Debian and FQDN lookup
Quoting David Wright (deb...@lionunicorn.co.uk): I'm one of the many who use .home https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-00 and this paper points out that there's an awful lot of leakage onto the Internet. I think I/we ought to be using .local http://tools.ietf.org/html/rfc6762 because this won't get onto the Internet. Do you think there's time to get such advice into jessie's installer for domestic users (assuming it's good advice)? ... er, or even the opposite advice (appendix G) which shows how fraught this area is! ie .intranet .internal .private .corp .home .lan as appropriate. Cheers, David. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150404024157.ga20...@alum.home
Re: Debian and FQDN lookup
On Thu 02 Apr 2015 at 16:47:56 -0600, Bob Proulx wrote: Alex Mestiashvili wrote: and as far as I see it simply asks the DNS about the hostname using getaddrinfo. But, with stock nsswitch.conf, it issues uname(2) syscall first, goes to /etc/hosts second, and if it encounters FQDN hostname - it all ends here. If /etc/hosts contain only bare hostname - it'd return a bare hostname. But /etc/hosts shouldn't have a bare hostname, right? It should always have a canonical name first followed by aliases second. For many people it will not matter. For setting up a mail server it will matter. man hosts This manual page describes the format of the /etc/hosts file. This file is a simple text file that associates IP addresses with hostnames, one line per IP address. For each host a single line should be present with the following information: IP_address canonical_hostname [aliases...] The debian-installer will set things up right with an entry such as this one. 127.0.1.1 foo.example.com foo If 'Domain name' is blank you get '127.0.1.1 foo'. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/03042015153119.78a432cff...@desktop.copernicus.demon.co.uk
Re: Debian and FQDN lookup
Alex Mestiashvili wrote: and as far as I see it simply asks the DNS about the hostname using getaddrinfo. But, with stock nsswitch.conf, it issues uname(2) syscall first, goes to /etc/hosts second, and if it encounters FQDN hostname - it all ends here. If /etc/hosts contain only bare hostname - it'd return a bare hostname. But /etc/hosts shouldn't have a bare hostname, right? It should always have a canonical name first followed by aliases second. man hosts This manual page describes the format of the /etc/hosts file. This file is a simple text file that associates IP addresses with hostnames, one line per IP address. For each host a single line should be present with the following information: IP_address canonical_hostname [aliases...] The debian-installer will set things up right with an entry such as this one. 127.0.1.1 foo.example.com foo Some people will be running software such as CAD/EDA software that passes IP addresses around interchangeably with hostnames. That software is fundamentally broken. But for those using it the only possibility is to work around it. The old classical Unix config would have had a single public IP address there instead. 93.184.216.34 foo.example.com foo That works but requires always on networking. It isn't suitable for laptops or other mobile devices. But it is fine for an always on server host. Only if /etc/hosts does not contain a hostname - a DNS search will be performed (or other resolving method, all according to nsswitch.conf). The entire 'hostname --fqdn' hack is really a nasty hack that I wish had never entered the GNU/Linux community. You won't find it on a classic Unix system. Actually I have debugged many installation scripts that call 'hostname -f' and instead set the hostname to -f. On legacy Unix systems there are no options. Whatever is in the first argument is what is set as the hostname. But that isn't the worst of it. The 'hostname -f' model thinks that a host has one IP address and that one IP address maps to one host. It looks up the name and finds the first IP address. It looks up that IP address to find the name associated with it. Basically it assigns the name found through DNS lookups. It expects a one-to-one mapping of exactly one IP address and the entire loop must match. That thinking is so 1985! It is now 30 years later in 2015 and that relationship just isn't true in the general case. Lots of servers have multiple IP addresses. A server might be serving multiple domains. What is the canonical domain in that case? I sarcastically say that 'hostname -f' will always pick the wrong one for you if you have several to choose from. That is one of the reasons for the great compromise of using '127.0.1.1 fqdn' in the /etc/hosts file. The /etc/nsswitch.conf file configures name lookups. The usual line for the hosts file lookup mapping is: hosts: files dns That looks in /etc/hosts first and dns second. (Some sites may have NIS/yp or LDAP or other configured there.) Since files is first it has priority for /etc/hosts entries before DNS entries. That allows the strategy mapping through 127.0.1.1 to work. Here is some discussion on the various issues. https://lists.debian.org/debian-boot/2005/06/msg00639.html https://lists.debian.org/debian-devel/2013/07/msg00809.html https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/234543 There is also 'libnss-myhostname' which I mention for completeness. However I find it causes me more bugs and problems than not using it and simply using the above strategies. Therefore I recommend NOT using the libnss-myhostname package. Yes, agree, though you will not see any of steps above if nscd is running as it was in my case. You menion nscd and that trips another pet peeve. The nscd is another Evil bad model that never understood the /etc/passwd file structure and explicit order. The nscd hashes the contents and destroys the order. Therefore nscd is fundamentally broken whenever there are multiple names mapped to the same uid number. That is a very common configuration in many environments. I always purge nscd whenever I want correct behavior. It doesn't improve performance significantly. Correct is better than fast anyway. And if account lookups are slow then it is better to add more NIS/yp or LDAP slaves and improve your performance there anyway. Bob signature.asc Description: Digital signature
Debian and FQDN lookup
Hi al, WHen issuing 'hostname --fqdn', I'm supposed to get the FQDN. Anyway when trying some different combinations, involving /etc/hostname, /etc/domainname, /etc/hosts, /etc/resolv.conf, I cannot figure out where the FQDN is looked up AND with what precedence. Would you know the mechanism (precedence) and worlkflow where a Debian 7 machine gets its FQDN? Thank you.
Re: Debian and FQDN lookup
On 04/02/2015 02:10 PM, Mihamina Rakotomandimby wrote: Hi al, WHen issuing 'hostname --fqdn', I'm supposed to get the FQDN. Anyway when trying some different combinations, involving /etc/hostname, /etc/domainname, /etc/hosts, /etc/resolv.conf, I cannot figure out where the FQDN is looked up AND with what precedence. Would you know the mechanism (precedence) and worlkflow where a Debian 7 machine gets its FQDN? Thank you. Hi, the mechanism is described here: http://sources.debian.net/src/hostname/3.15/hostname.c/ and as far as I see it simply asks the DNS about the hostname using getaddrinfo. On my system the --fqdn flag doesn't work if my /etc/resolv.conf doesn't have domain mydomain or search mydomain option enabled. You can see it with strace hostname --fqdn. Also see man resolver for additional information. Alex | |
Re: Debian and FQDN lookup
and as far as I see it simply asks the DNS about the hostname using getaddrinfo. But, with stock nsswitch.conf, it issues uname(2) syscall first, goes to /etc/hosts second, and if it encounters FQDN hostname - it all ends here. If /etc/hosts contain only bare hostname - it'd return a bare hostname. Only if /etc/hosts does not contain a hostname - a DNS search will be performed (or other resolving method, all according to nsswitch.conf). Yes, agree, though you will not see any of steps above if nscd is running as it was in my case. On my system the --fqdn flag doesn't work if my /etc/resolv.conf doesn't have domain mydomain or search mydomain option enabled. Or it's because you have a bare hostname in /etc/hosts ;) It is because /etc/hosts had a wrong entry at the time I was testing it... Thank you for putting it all together. Alex -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/551d965f.70...@biotec.tu-dresden.de
Re: Debian and FQDN lookup
Hi. On Thu, 02 Apr 2015 14:54:19 +0200 Alex Mestiashvili a...@biotec.tu-dresden.de wrote: the mechanism is described here: http://sources.debian.net/src/hostname/3.15/hostname.c/ and as far as I see it simply asks the DNS about the hostname using getaddrinfo. But, with stock nsswitch.conf, it issues uname(2) syscall first, goes to /etc/hosts second, and if it encounters FQDN hostname - it all ends here. If /etc/hosts contain only bare hostname - it'd return a bare hostname. Only if /etc/hosts does not contain a hostname - a DNS search will be performed (or other resolving method, all according to nsswitch.conf). On my system the --fqdn flag doesn't work if my /etc/resolv.conf doesn't have domain mydomain or search mydomain option enabled. Or it's because you have a bare hostname in /etc/hosts ;) You can see it with strace hostname --fqdn. All this invaluable information above was provided you by strace :) Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150402193119.cba12c779df50ae576558...@gmail.com
