On Tue, Dec 29, 2009 at 10:31:25PM +0100, Vincent Lefevre wrote: > Well, the node name is unique. From that, you'll obtain the FQDN with > either the obsolete function gethostbyname or the new POSIX function > getaddrinfo (by using the AI_CANONNAME flag). POSIX says: > > If the AI_CANONNAME flag is specified and the nodename argument is > not null, the function shall attempt to determine the canonical name > corresponding to nodename (for example, if nodename is an alias or > shorthand notation for a complete name).
Read what you have written: _attempt_. It does not say that you can expect it to succeed even in common situations. > And here's what the getaddrinfo(3) man page says under Debian: > > If hints.ai_flags includes the AI_CANONNAME flag, then the ai_canonname > field of the first of the addrinfo structures in the returned list is > set to point to the official name of the host. > > Then you need to configure your machine according to the spec, i.e. > you need a single FQDN / canonical name / official name of the host. If getaddrinfo(AI_CANONNAME) fails, that is fully conformant with the spec you have quoted. > > Example: there is a router box called "gw" which has about a dozen > > addresses that resolve to "gw.<domain>" for just as many domains. Some > > addresses even share the same NIC. Which FQDN should "hostname -f" > > display? > > This doesn't really matter. The FQDN may also be another name, i.e. > the nodename may be something more meaningful than "gw". But it is not. This is a real world example. Reality does not match your dream world. > > Why that one, and not some other? > > You should ask this question to those who configured such routers > (but this would be more a practical matter, as you may have plenty > of choices). _I_ did configure it. I _know_ that none of the addresses is more important than the other. And you know, if you do not pretend such silly things that a host should have just a single FQDN or that "hostname -f" should return anything meaningful, then the above configuration works flawlessly. Only if you start to pretend things that are simply not true you start having problems. > A FQDN is not associated with an IP address, but with a host. You > cannot call them FQDN, which already has a well-established meaning. Now this is bullshit. FQDN is a term related to DNS. An FQDN resolves to a set of resource records, which may be IPv4 or IPv6 addresses and a couple of other things, but definitely _NOT_ hosts, as that term has no meaning for the DNS. If the FQDN resolves to multiple IP addresses, then the very same FQDN can belong to multiple hosts simultaneously. Similarly, if a host has multiple IP addresses, then multiple FQDNs may point to it. You can even mix these: - host1 has addresses 192.168.1.1 and 192.168.2.1 - host2 has addresses 192.168.1.2 and 192.168.2.2 - the DNS has the following records: service1.domain. IN A 192.168.1.1 IN A 192.168.1.2 service2.domain. IN A 192.168.2.1 IN A 192.168.2.2 Now both hosts has two FQDNs, and both FQDNs point to two hosts; neither "host1" nor "host2" is resolvable. And it all works just fine if you do not make invalid assumptions about what FQDNs are and how they are used. > If I understand correctly, you do a reverse DNS lookup. Now, I'm > wondering... Can a hostname obtained by reverse DNS lookup resolve > to different IP addresses? Of course it can. And it is common to refuse connections from such hosts using the PARANOID option of TCP wrappers (which was first released more than 18 years ago, so don't pretend it is some new thing). > "hostname -f" just follows the POSIX notion of canonical name (a.k.a. > FQDN). So, I doubt it will die. Please quote the exact text from POSIX that says that - there MUST be a canonical name, - and that name MUST be an FQDN. Gabor -- --------------------------------------------------------- MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences --------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org