Additional DHCP client hostname validations

[ainar-g]

In #2946 we've added some validations for clients' hostnames. Some additional validations that we would like to add are:

1. Hostname uniqueness validation among our DHCP clients.

2. I'm not sure if we want this, but probably we should validate that the hostnames that clients send are actually valid domain name labels (that is, my-example-machine) as opposed to domain names (that is, my.example.machine).

   We decided to instead normalise the names using the algorithm described in this comment below.

@ameshkov, what do you think? Anything else I forgot?

[ameshkov]

are actually valid domain name labels

I am not fully sure about that, they may easily send just plain strings that have nothing to do with domain names.

Wouldn't it be better to accept everything and convert to valid hostnames?

[ainar-g]

@ameshkov

I am not fully sure about that, they may easily send just plain strings that have nothing to do with domain names.

Not according to the RFC:

This option specifies the name of the client.  The name may or may
not be qualified with the local domain name (see section 3.17 for the
preferred way to retrieve the domain name).  See RFC 1035 for
character set restrictions.

Then again, we've already seen in the original issue that some device manufactureres just don't care, heh. But changing spaces into hyphens seems harmless enough (although I still have some doubts). On the other hand, if we consider that clients can send any random data there and that we somehow have to make sense of it, then we will have to define an algorithm for doing that and also support that algorithm. Possibly reimplementing it in other products. Whether it's Punycode or something custom.

In my personal opinion, it's better (and simpler) to just be strict by default. But I'm not sure about the usability of such solution. Maybe I'll implement the uniqueness validation and leave the other part as is for now.

[ameshkov]

Well, the simple algorithm we could use is lower-casing + replacing all unsupported characters with hyphens

[ainar-g]

@ameshkov, I'm afraid that that won't do. Consider a client sending something like xn!!d1acpjx3f, which we convert into xn--d1acpjx3f, which will then be interpreted as an IDNA for яндекс. Honestly, the more you analyse the problem or making sense of random strings as domain names, the sillier the solutions become. I'm still in favour or more strictness.

[ameshkov]

But we already know about existing issues where strictness would do more harm than good.

[ainar-g]

@ameshkov

We could use a three-step process of first replacing every invalid character with a hyphen, then collapsing all sequences of more than one hyphen into one, and then lowercasing it. So that something like:

My @#$%^&* Phone

Becomes:

my-phone

I still have doubts about it, but in combination with the uniqueness check I proposed in the OP this could probably work.

[ameshkov]

Yep, that looks good to me

[ainar-g]

This is now merged. If anyone finds any bugs or other issues, please file new bugs. Thanks!