[GH-ISSUE #3996] validateDomain() is too strict #8211

Closed
opened 2026-08-05 01:16:51 -04:00 by saavagebueno · 3 comments
Owner

Originally created by @zvpunry on GitHub (Jun 17, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/3996

The domainPattern regex in management/server/nameserver.go is too strict, it doesn't allow labels that are completely valid according to rfc1035. As an example, it forbids labels like "x", "x1, "x--x" as tld and possibly some more.

The validateDomain() function must allow rfc1035 labels. The easiest fix is to remove the regex and just depend on dns.IsDomainName() which is not very strict.

If some additional validation is needed, it must allow rfc1035 labels. But maybe even rfc1035 is too strict: See https://www.rfc-editor.org/rfc/rfc2181#section-11

Originally created by @zvpunry on GitHub (Jun 17, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/3996 The domainPattern regex in management/server/nameserver.go is too strict, it doesn't allow labels that are completely valid according to rfc1035. As an example, it forbids labels like "x", "x1, "x--x" as tld and possibly some more. The validateDomain() function must allow rfc1035 labels. The easiest fix is to remove the regex and just depend on dns.IsDomainName() which is not very strict. If some additional validation is needed, it must allow rfc1035 labels. But maybe even rfc1035 is too strict: See https://www.rfc-editor.org/rfc/rfc2181#section-11
saavagebueno added the feature-requestdns labels 2026-08-05 01:16:51 -04:00
Author
Owner

@zvpunry commented on GitHub (Jun 17, 2025):

There is also https://www.rfc-editor.org/rfc/rfc1123#section-2 which references the syntax from rfc952 (which is the same as rfc1035) but also allows a label to start with a digit. A regex to validate such a name would be ^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9])\.?)+$ https://regex101.com/r/GXfv3m/1

I mentioned rfc2181 earlier, it basically says everything can be used as a label but it must be limited to 63 bytes and the whole domainname must fit into 255 bytes, which is enforced by dns.IsDomainName().

<!-- gh-comment-id:2981887795 --> @zvpunry commented on GitHub (Jun 17, 2025): There is also https://www.rfc-editor.org/rfc/rfc1123#section-2 which references the syntax from rfc952 (which is the same as rfc1035) but also allows a label to start with a digit. A regex to validate such a name would be `^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9-]*[a-zA-Z0-9])\.?)+$` https://regex101.com/r/GXfv3m/1 I mentioned [rfc2181](https://www.rfc-editor.org/rfc/rfc2181#section-11) earlier, it basically says everything can be used as a label but it must be limited to 63 bytes and the whole domainname must fit into 255 bytes, which is enforced by dns.IsDomainName().
Author
Owner

@zvpunry commented on GitHub (Jan 4, 2026):

Image

This screenshot should make it more clear where my problem is. When adding or modifying a DNS Server, it isn't possible to add a list of Match Domains (i.e. "intranet" and "intranet2").

I use my own patch (see pull request #4000) that just removes the too strict tests without a problem.

<!-- gh-comment-id:3708512223 --> @zvpunry commented on GitHub (Jan 4, 2026): <img width="576" height="643" alt="Image" src="https://github.com/user-attachments/assets/d5f8b382-93b2-478f-ac60-3e9a5aa5993d" /> This screenshot should make it more clear where my problem is. When adding or modifying a DNS Server, it isn't possible to add a list of Match Domains (i.e. "intranet" and "intranet2"). I use my own patch (see pull request #4000) that just removes the too strict tests without a problem.
Author
Owner

@zvpunry commented on GitHub (Jan 29, 2026):

Fixed by https://github.com/netbirdio/netbird/pull/5211

<!-- gh-comment-id:3820365844 --> @zvpunry commented on GitHub (Jan 29, 2026): Fixed by https://github.com/netbirdio/netbird/pull/5211
Sign in to join this conversation.
No Label dns feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#8211