public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: "Neitzert, Greg A" <greg.neitzert@unisys.com>
Cc: "linux-man@vger.kernel.org" <linux-man@vger.kernel.org>
Subject: Re: Man page bug - hostname.7
Date: Tue, 7 Apr 2026 00:08:44 +0200	[thread overview]
Message-ID: <adQuqIkfnyMmigP7@debian> (raw)
In-Reply-To: <DM8PR07MB8854A4169C2DD8BC4DAD6ED0885DA@DM8PR07MB8854.namprd07.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 3878 bytes --]

Hi Greg,

On 2026-04-06T19:19:36+0000, Neitzert, Greg A wrote:
> Hello,
> 
> In the man-pages source, in the man.7 section, there is what I believe a bug/inaccuracy in the hostname page.
> Specifically this paragraph:
> 
> "Each element of the hostname must be from 1 to 63 characters long
>        and the entire hostname, including the dots, can be at most 253
>        characters long.  Valid characters for hostnames are ASCII(7)
>        letters from a to z, the digits from 0 to 9, and the hyphen (-).
>        A hostname may not start with a hyphen."
> 
> The last sentence is the issue.
> I believe it should state:
> 
> "A hostname may not start or end with a hyphen."
> (suggest adding "or end")
> 
> The glibc source and kernel source themselves enforce no rules as to naming.  You can call sethostname in glibc directly and set the hostname to anything as long as it is 63 characters, violating standard rules like RFCs.
> The 'hostname' program which is maintained by debian does enforce the first and last character rule.  It lives above glibc and calls glibc:
> 
>        /* Handle leading and trailing hyphen now. */
>         if (!len || !isalnum(name[0]) || !isalnum(name[len-1]))
>                 return 0;
> 
> From maintainer:
>  https://tracker.debian.org/pkg/hostname
> 
> This isn't necessarily binding on you I don't think, but it is consistent with the RFC rules.
> 
> At the bottom of your man page you do refer in the SEE ALSO to the pertinent RFCs:
> 
>      IETF RFC 1123 ⟨http://www.ietf.org/rfc/rfc1123.txt⟩
>      IETF RFC 1178 ⟨http://www.ietf.org/rfc/rfc1178.txt⟩
> 
> 
> 
> RFC 1178 has some general best practices and is not really governing for this.
> RFC 1123 however, and the RFC it refers back to, RFC-952 are directly on point.
> 
> RFC UPDATES RFC-952 and refers to it:
> 
> "The syntax of a legal Internet host name was specified in RFC-952
>       [DNS:4].  One aspect of host name syntax is hereby changed: the
>       restriction on the first character is relaxed to allow either a
>       letter or a digit.  Host software MUST support this more liberal
>       syntax.
> 
>  Host software MUST handle host names of up to 63 characters and
>       SHOULD handle host names of up to 255 characters."
> 
> 
> Referring back to RFC-952:
> 
> "1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
>    to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
>    sign (-), and period (.).  Note that periods are only allowed when
>    they serve to delimit components of "domain style names". (See
>    RFC-921, "Domain Name System Implementation Schedule", for
>    background).  No blank or space characters are permitted as part of a
>    name. No distinction is made between upper and lower case.  The first
>    character must be an alpha character.  The last character must not be
>    a minus sign or period."
> 
> 
> Taking RFC 952, and the updates in RFC-1123 we end up with the following:
> 1. Length is now of 63 characters minimum (superceding 24).
> 2. The first character must be an alpha (or numeric - as amended by RFC 1123).
> 3. The last character MUST NOT be a minus sign (from RFC 952 and left unchanged).
> 
> Therefore, to be accurate with the standard you are referring to (RFC 1123 and the RFC it updates 952), I believe you should have:
> 
> "A hostname may not start or end with a hyphen."
> 
> All of your text is in harmony with RFC 952 and RFC 1123 except for the issue regarding the hyphens - at least from my reading.

Thanks for the very detailed report.  I've applied a patch following
your suggestion (will push tomorrow or so).


Have a lovely night!
Alex

> 
> Thanks.
> Greg Neitzert
> Greg.Neitzert@unisys.com
> 
> 
> 
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2026-04-06 22:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-06 19:19 Man page bug - hostname.7 Neitzert, Greg A
2026-04-06 22:08 ` Alejandro Colomar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adQuqIkfnyMmigP7@debian \
    --to=alx@kernel.org \
    --cc=greg.neitzert@unisys.com \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox