Unable to use a label starting with a digit

Bug #1592489 reported by Paul Thomas
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Anchor
Fix Released
Undecided
Stanislaw Pitucha

Bug Description

Anchor is enforcing the RFC1034 rules on domain name labels which state that...

"The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less."

However, the subsequent RFC2181 states that...

"The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one restriction
relates to the length of the label and the full name. The length of
any one label is limited to between 1 and 63 octets. A full domain
name is limited to 255 octets (including the separators). The zero
length full name is defined as representing the root of the DNS tree,
and is typically written and displayed as ".". Those restrictions
aside, any binary string whatever can be used as the label of any
resource record."

Really the regex stored in anchor/util.py should be relaxed to not require a leading letter.
RE_DOMAIN_LABEL = re.compile("^[a-z](?:[-a-z0-9]*[a-z0-9])?$", re.IGNORECASE)

Revision history for this message
Stanislaw Pitucha (stanislaw-pitucha) wrote :

Thanks, I'll have a look at that.

Changed in anchor:
assignee: nobody → Stanislaw Pitucha (stanislaw-pitucha)
status: New → In Progress
Revision history for this message
Stanislaw Pitucha (stanislaw-pitucha) wrote :

Just checked the RFCs and I'm not sure how to handle this. The RFC 5280 defining certificates specifically refers to RFC1034. (https://tools.ietf.org/html/rfc5280#section-4.2.1.6)

Also, I really don't want to allow any binary string, since there was already at least one known problem with DNS spoofing (null characters).

Is it only the leading letter that bothers you? Would making this regex configurable be enough for your case?

Revision history for this message
Paul Thomas (afterglow) wrote :

Yes specifically for me it's the leading letter I have a domain name that begins with a number that fails the check. Allowing setting the regex would certainly solve the problem for me. I imagine the existing regex would be a problem e.g. for internationalised domains names as well which presumably should still be allowed certificates so making it configurable might not be a bad idea.

Revision history for this message
Stanislaw Pitucha (stanislaw-pitucha) wrote :

The intenationalised domain names are stored using punycode via ToASCII conversion (https://tools.ietf.org/html/rfc5280#section-7.3), so that shouldn't be affected. I'm pulling the setting into the config though - patch incoming soon.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to anchor (master)

Fix proposed to branch: master
Review: https://review.openstack.org/330334

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to anchor (master)

Reviewed: https://review.openstack.org/330334
Committed: https://git.openstack.org/cgit/openstack/anchor/commit/?id=2257b8bbedef41cdafb88aa2cc74969efe247a26
Submitter: Jenkins
Branch: master

commit 2257b8bbedef41cdafb88aa2cc74969efe247a26
Author: Stanisław Pitucha <email address hidden>
Date: Thu Jun 16 16:15:59 2016 +1000

    Allow custom domain labels

    Original validator checked for domain labels as defined by RFC1034, however real
    internet deals with other domains as well - starting with digits or symbols.
    This change allows modifying the pattern to allow custom / relaxed rules.

    Validation has been removed from adding a domain to a new extension, since it's
    only used in fixups and the domain should be already validated. (or not, if not
    configured)

    Closes-bug: 1592489

    Change-Id: Ib453054ba5f554bab28cff392c539e713fa28918

Changed in anchor:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.