[libvirt PATCH] conf: network: remove hostname validation

Ján Tomko jtomko at redhat.com
Mon Jan 31 12:27:16 UTC 2022

On a Sunday in 2022, Laine Stump wrote:
>On 1/27/22 4:33 PM, Ján Tomko wrote:
>>We used to validate that the first character of the hostname is a
>>letter. Later, RFC1123 relaxed the requirements to allow a number
>>as well.
>>Drop the validation completely, since we do not care about the
>>following characters, and neither does dnsmasq (even if it's a comma,
>>which is a delimiter in the hosts file).
>Was there some discussion somewhere that prompted this patch (and thus 
>invalidates the opinion I'm about to spout)? The only email I could 
>find about it was the email of the "reverted" patch itself (sent by 
>Peter on behalf of the author, with r-b given in the same email).
>My opinion is that if a current RFC restricts the first letter of a 

It restricts all of the characters, not just the first one.
But in the past we only checked for one specific restriction of the
first character, that it is a letter. So I believe the better way
to remove the restriction is to remove the first check, not add a new

I am unsure where the restriction came from (looking at the dates of
the RFCs the "reverted" commit references, I was too young to care at
the time.) The libvirt commit:

   commit b73d4957540938a61b95bd30696efa6553d14b5f
   CommitDate: 2008-08-20 12:50:29 +0000

     * src/network_conf.c src/network_conf.h src/qemu_driver.c: allow to
       add static host definition for dnsmasq

added the check with no explanation.

 From RFC 952 (Oct 1985):
The old check enforced one specific restriction
       <hname> ::= <name>*["."<name>]
       <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
RFC 1123 (Oct 1989):
       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

So, someone could add a validation for all of these constraints,
but I have not verified whether non-compliant hostnames actually
are broken with dnsmasq.

>then we should validate that too, *especially* if dnsmasq 
>doesn't; who knows what entity beyond dnsmasq will barf on it in some 
>way, and the closer to the source the non-compliance is reported, the 
>easier it will be to fix. (Additionally, it's easy to remove extra 
>validation, but much more difficult to add it back later if we decide 
>it shouldn't have been removed)

Right, we don't seem to have a separate validation step for network
parsing at the moment so adding a new check would be tedious.
But as-is, this check is pointless.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220131/576dc918/attachment-0001.sig>

More information about the libvir-list mailing list