[Patch] Clarify incoming peer hostname meaning

Tanguy Ortolo tanguy at ortolo.eu
Tue Sep 5 14:04:40 UTC 2017


Julien Élie, 2017-09-02 14:37+0200:
>Thanks for your message.
>I believe other parts of the documentation should be fixed with regards
>to use of the "FQDN" terminology.
>Does the following suggestion look good to you?
>
>When using getaddrinfo() or the "hostname" Linux command, does it mean
>that the result can differ between two calls?  (when the hostname has
>several FQDNs)

I do not think so, but there are two things here. First, the FQDNs that 
exist in the DNS for a given host: some may be A and AAAA records, other 
may be CNAME records, and the host may know them or not.

Second, the FQDN that the host system will report (hostname --fqdn), 
which is a single one, always the same as long as the configuration will 
not change. With GNU/Linux, it seems to be determined this way:

* if the system hostname contains a dot, return it;
* if the system hostname does not contain a dot, resolve it to an FQDN 
  using getaddrinfo() (which will resolve it to an IP address and then 
  back to a name using a reverse resolution, usually using /etc/hosts, 
  but possibly using the DNS).

>Index: doc/man/libinn.3
>===================================================================
>--- doc/man/libinn.3	(révision 10171)
>+++ doc/man/libinn.3	(copie de travail)
>@@ -277,7 +277,7 @@
> It returns false on failure or true on success.
> .PP
> .I GetFQDN
>-returns the fully-qualified domain name of the local host.
>+returns one of the fully qualified domain names of the local host.

No, this is the FQDN as returned by the system, therefore a single one.

>--- doc/man/nnrpd.track.5	(révision 10171)
>+++ doc/man/nnrpd.track.5	(copie de travail)
>@@ -27,7 +27,7 @@
> .fi
> .RE
> .PP
>-The first field is either the FQDN of a host, or a domain name (in
>+The first field is either one of the FQDNs of a host, or a domain name (in

Right, but I think should be clarified, since this is about a 
verification of a host name, which, in the first form (FQDN) can be done 
either by direct resolution of that name to IP addresses, that will be 
compared to the client IP address, or by reverse lookup of the client IP 
address to a name that will be compared to that name. In the second form 
(domain name), I think only the second method (reverse lookup) is 
usable.

I do not know which method is used by nnrpd, but that should be checked 
before changing the manpage.

>Index: doc/pod/inn.conf.pod
>===================================================================
>--- doc/pod/inn.conf.pod	(révision 10171)
>+++ doc/pod/inn.conf.pod	(copie de travail)
>@@ -875,7 +875,7 @@
> =item I<addinjectionpostinghost>
>
> Whether to add a posting-host attribute to the Injection-Info: header to
>-all local posts giving the FQDN (when known) and IP address of the system
>+all local posts giving an FQDN (when known) and IP address of the system

Right, but this should be specified better. My guess would be that the 
name used here is obtained by reverse lookup of the client IP address, 
so if this is the case, this should better be specified.

>@@ -882,7 +882,7 @@
> obfuscating the name of the client.  That has to be done with a user-written
> Perl filter, if desired.
>
>-When this parameter is set to true, the FQDN (or, if unknown, the IP address)
>+When this parameter is set to true, an FQDN (or, if unknown, the IP address)

Same remark.

>Index: doc/pod/innfeed.conf.pod
>===================================================================
>--- doc/pod/innfeed.conf.pod	(révision 10171)
>+++ doc/pod/innfeed.conf.pod	(copie de travail)
>@@ -680,9 +680,11 @@
>
> =item I<ip-name>
>
>-This key requires a word value.  The word is the host's FQDN, or the dotted
>-quad IP-address.  If this value is not specified, then the name of the
>-peer in the enclosing I<peer> block is taken to also be its I<ip-name>.
>+This key requires a word value.  The word is either one of the host's FQDNs,
>+or the dotted-quad IP address of the peer for IPv4, or the colon-separated
>+IP address of the peer for IPv6.  If this value is not specified, then
>+the name of the peer in the enclosing I<peer> block is taken to also
>+be its I<ip-name>.

Right.

>Index: doc/pod/install.pod
>===================================================================
>--- doc/pod/install.pod	(révision 10171)
>+++ doc/pod/install.pod	(copie de travail)
>@@ -821,10 +821,10 @@
> This is the name of your news server as you wish it to appear in the Path:
> header of all postings which travel through your server (this includes
> local posts and incoming posts that you forward out to other sites).  If
>-this parameter is unspecified, the fully-qualified domain name (FQDN) of
>-the machine will be used instead.  Please use the FQDN of your server or
>-an alias for your server unless you have a very good reason not to; a
>-future version of the news RFCs may require this.
>+this parameter is unspecified, one of the fully qualified domain names (FQDN)
>+of the machine will be used instead.  Please use one of the FQDNs of your
>+server unless you have a very good reason not to; a future version of the
>+news RFCs may require this.

No and yes. The first occurrence should rather be:
… If this parameter is unspecified, the fully-qualified domain name 
(FQDN) of the machine, as reported by the operating system, will be used 
instead.

The second part could be rewritten this way:
… Please use the canonical FQDN of your server or an alias unless…

>Index: doc/pod/nnrpd.pod
>===================================================================
>--- doc/pod/nnrpd.pod	(révision 10171)
>+++ doc/pod/nnrpd.pod	(copie de travail)
>@@ -195,8 +195,8 @@
> Replace the paths with something appropriate to your INN installation.
> This will create a self-signed certificate that will expire in a year.
> The B<openssl> program will ask you a variety of questions about your
>-organization.  Enter the fully qualified domain name of the server as the
>-name the certificate is for.
>+organization.  Enter one of the fully qualified domain names of the server
>+as the name the certificate is for.

Here, the best would be to explicitly suggest using the news service 
FQDN (whether that is the server canonical name, like 
neufchatel.example.com or a dedicated alias like news.example.com is up 
to the administrator):
… Enter the FQDN of your news service.

>Index: lib/getfqdn.c
>===================================================================
>--- lib/getfqdn.c	(révision 10171)
>+++ lib/getfqdn.c	(copie de travail)
>@@ -11,7 +11,7 @@
>
>
> /*
>-**  Get the fully-qualified domain name for this host.
>+**  Get one of the fully qualified domain names for this host.
> */

Rather “Get the fully-qualified domain name for this host, as reported 
by the system”.

>Index: samples/nntpsend.ctl
>===================================================================
>--- samples/nntpsend.ctl	(révision 10171)
>+++ samples/nntpsend.ctl	(copie de travail)
>@@ -6,7 +6,7 @@
> ##    site:fqdn:max_size:[<args...>]
> ##      <site>        The name used in the newsfeeds file for this site;
> ##                    this determines the name of the batch file.
>-##      <fqdn>        The fully-qualified domain name of the site,
>+##      <fqdn>        A fully qualified domain name for the site,
> ##                    passed as the parameter to innxmit.
> ##      <size>        Size to truncate batch file if it gets too big;
> ##                    see shrinkfile(1).

Right.

In fact, I think the problem is mostly the over-usage of the term 
“FQDN”, which can sometimes be incorrectly understood as meaning “a 
host's canonical name”. This is emphasized by the fact that some news 
services, if not most of them, are referred to with a service name such 
as news.example.com, which is fully qualified, but which is just an 
alias to the server canonical name such as gruyere.example.com, which 
will probably be the result of a reverse lookup of its IP address as 
well.

Most of the time, when resolving a host name to an IP address), the fact 
that it is fully qualified or not is irrelevant, as long as it does 
resolve. In such cases, it is enough to just mention “a host name”.

For checking a client IP address against a host name, the fact that it 
is FQ or not is again irrelevant, but what is relevant is whether this 
check is done by direct lookup of the configured host name, or by 
reverse lookup of its IP address.

For reporting connections with a host name rather than an IP address, it 
is not relevant either, this is just a reverse lookup, and it will 
almost always return an FQDN indeed, but that depends on the system 
configuration.

In fact, I think the only place where it is relevant to mention an FQDN, 
is for configuration of things that will be used for protocol or format 
informations that are supposed to be FQDNs.

Nouvellement,

-- 
Tanguy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20170905/917fc951/attachment.bin>


More information about the inn-workers mailing list