Stdlib::Fqdn type accepts ipv4 addresses, also allows truncated addresses

[canihavethisone]

Describe the Bug

Specifying a variable as type Stdlib::Fqdn allows ipv4 addresses. This issue is compounded when using Stdlib::Host as with the inclusion of Fqdn it allows truncated ipv4 addresses such as 10.10.10.10.10.

Expected Behavior

IPv4 addresses should be validated when using Stdlib::Host and not accepted within the Stdlib:Fqdn type

Steps to Reproduce

Steps to reproduce the behavior:

1. Create a variable with type Stdlib::Fqdn

2. Submit valid or truncated ipv4 address, which passes (the regex)

3. Create a variable with type Stdlib::Host

4. Submit a truncated ipv4 address, which passes (the regex)

Environment

• stdlib v8.4.0
• Puppet 6x

Additional Context

Unsure if this is a flaw in catering for numerical fqdn's, and how it can be addressed. TL:DR is that using Stdlib::Host does not ensure ipv4 addresses are valid

[ekohl]

Unsure if this is a flaw in catering for numerical fqdn's, and how it can be addressed. TL:DR is that using Stdlib::Host does not ensure ipv4 addresses are valid

My bet would indeed be on the numberical FQDNs because Stdlib::Host has the problem already as shown in #1283.

[canihavethisone]

Interesting problem to solve. I'm wondering if a possible solution should include a test for invalid ipv4, such as 10.10.10.300.

[ekohl]

I'd suspect that the host definition should check that the last part (TLD) should be non-numeric. That should catch it.

[b4ldr]

it allows truncated ipv4 addresses such as 10.10.10.10.10

FTR this is a valid FQDN

a host domain name is now allowed to begin with a digit and could legally be entirely numeric

re: rfc1123 Section 2

I'd suspect that the host definition should check that the last part (TLD) should be non-numeric. That should catch it.

There are two issues with this

• A fqdn can contain just one label i.e. com, net, google are all valid FQDN's as such this type can and will be used to validated hostnames (FQDN's with a single label) which could contain a numbers e.g. webserver1001
• This only assumes the IANA DNS it doesn't account for:
  • private TLDs e.g. 7up may have there own private DNS with a 7up. tld
  • Pseudo TLD's e.g. i2p

Arguably the IANA DNS is the one most users would want to check however i think we should add a new type for this e.g. Stdlib::DNS::IANA

[ekohl]

re: rfc1123 Section 2

This part looks relevant:

Whenever a user inputs the identity of an Internet host, it SHOULD
be possible to enter either (1) a host domain name or (2) an IP
address in dotted-decimal ("#.#.#.#") form. The host SHOULD check
the string syntactically for a dotted-decimal number before
looking it up in the Domain Name System.

That reads to me as an XOR: either a domain name or an IP. It should prefer it as an IP. So I think a fully numeric FQDN is invalid.

You can catch that with [a-z0-9]*[a-z]+[a-z0-9]* for the last domain component.

[b4ldr]

That reads to me as an XOR: either a domain name or an IP. It should prefer it as an IP.

I think that's valid if it matches (loose) pattern \d{3}\.\d{3}\.\d{3}\.\d{3} then it should be treated as an ip address however

So I think a fully numeric FQDN is invalid.

• 100
• 100.100
• 100.100.100
• 100.100.100.100.100

should all be treated as DNS names

[smortex]

Thank you for these insightful information and links.

The rfc1123 Section 2 quoted above make me think we can accept an IP address as a FQDN: in an ideal world we would not, but this would need to happen in puppet with a custom data type that tries to parse the value as an IP address, raise an error if it succeed and does the actual test otherwise. I do not think we can do this at the stdlib level. So accepting IP addresses here looks like an acceptable compromise.

I will update #1345 to take this into account.

Thank you 💯 💯 💯