A directory entry's common name contains a comma — what must the RFC 4514 string form of its Distinguished Name do?

middlemust knowfreq 46%

answer

the comma is punctuation, not data
escape lives in the string only
backslash form or hex pair
leading space and leading hash too
usually invalidDNSyntax(34), sometimes the wrong entry

basics

~20 s

The comma must be escaped inside the RDN value, as a backslash before it or as the hex pair for that octet. Unescaped, the comma is read as the separator between two RDNs, and the string names something other than the entry — usually nothing at all.

solid answer

~50 s

The comma is the separator between RDNs in the string form, so a comma that belongs to a value has to be escaped: cn=Bell\, Hannah,ou=curators,dc=seedbank,dc=example, or with the hex pair cn=Bell\2C Hannah,.... RFC 4514 requires escaping for ", +, ,, ;, <, > and \ anywhere in a value, for a space or # at the start of a value and a space at the end, and the NUL octet as \00; other characters, = among them, may be escaped but need not be. Crucially the backslash belongs to the encoding only — the stored attribute value is still Bell, Hannah, and an entry whose cn literally contains a backslash has a different value. Leave the comma unescaped and the parser sees an extra component; since the text after it rarely reads as type=value, the usual result is invalidDNSyntax(34).

The comma is the separator between RDNs in the string form, so a comma that belongs to a *value* has to be escaped: `cn=Bell\, Hannah,ou=curators,dc=seedbank,dc=example`, or with the hex pair `cn=Bell\2C Hannah,...`. RFC 4514 requires escaping for `"`, `+`, `,`, `;`, `<`, `>` and `\` anywhere in a value, for a space or `#` at the start of a value and a space at the end, and the NUL octet as `\00`; other characters, `=` among them, **may** be escaped but need not be. Crucially the backslash belongs to the **encoding only** — the stored attribute value is still `Bell, Hannah`, and an entry whose `cn` literally contains a backslash has a different value. Leave the comma unescaped and the parser sees an extra component; since the text after it rarely reads as `type=value`, the usual result is invalidDNSyntax(34).

code

ldif · 7 lines

ldif

dn: cn=Bell\, Hannah,ou=curators,dc=seedbank,dc=example
objectClass: inetOrgPerson
cn: Bell, Hannah
sn: Bell

# the same name written with the hex pair instead:
#   dn: cn=Bell\2C Hannah,ou=curators,dc=seedbank,dc=example

go deeper

for a junior

Remember that the comma separates the parts of a Distinguished Name, so a comma inside a value has to be escaped with a backslash. The stored value itself keeps no backslash.

for a middle

Explain the must-escape set and the by-position rules, both written forms, and why two differently escaped strings name one entry. Say that the encoding is separate from the data.

for a senior

Diagnose it: describe the difference between a name that fails to parse and a name that parses into the wrong place, and say which error each produces and why the second is more expensive.

for a principal

Treat name construction as an interface contract — mandate a single encoding routine, choose RDN attributes that cannot carry punctuation, and forbid assembling names by concatenation anywhere in the estate.

The string form is an encoding, not the data

On the wire a Distinguished Name is a sequence of RelativeDistinguishedName values, each a set of AttributeTypeAndValue pairs. RFC 4514 defines how to write that structure as a single line of text, and that text needs punctuation of its own: a comma between RDNs, an equals sign inside each one, a plus sign between the components of a multi-valued RDN.

The moment a value contains one of those characters, the encoding is ambiguous, so RFC 4514 defines escaping. The escape exists only in the string. Decode cn=Bell\, Hannah and the attribute value is Bell, Hannah — six characters before the space, no backslash anywhere. Forgetting this is the most consequential misunderstanding on this subject, because it leads people to store the backslash in the entry, after which the value genuinely contains a character nobody intended and comparisons quietly stop matching.

What must be escaped, and what merely may be

RFC 4514 separates the two, and an answer that promotes the second list into the first teaches false certainty:

Must be escaped, wherever they appear in a value: ", +, ,, ;, <, > and \.
Must be escaped by position: a space or # at the beginning of a value, and a space at the end. An accession label typed with a stray leading space is a real source of this.
Must be escaped as a hex pair: the NUL octet, written \00.
May be escaped, at the writer's discretion: anything else, including =. A producer that escapes more than required is still conformant; a consumer must accept both.

Two interchangeable forms exist for any escaped character:

Form	Example	Reading
Backslash before the character	`cn=Bell\, Hannah`	escape the comma literally
Backslash plus the hex pair for the octet	`cn=Bell\2C Hannah`	same value, written by octet

Both decode to the same AttributeTypeAndValue, so two DN strings that differ only in escaping style name the same entry. String equality is therefore the wrong test for DN equality.

What actually goes wrong when it is omitted

Take a seed-bank accession whose label is Wheat, Durum and write the name without escaping:

ou=Wheat, Durum,dc=seedbank,dc=example

The parser splits on every unescaped comma and gets four components: ou=Wheat, Durum, dc=seedbank, dc=example. The second carries no attribute type and no equals sign, so it is not an AttributeTypeAndValue at all and the whole string is not a Distinguished Name. A directory server answering an operation with that name in it returns invalidDNSyntax(34).

The nastier case is the minority one. If the fragment after the comma happens to read as type=value — a label like Durum, ou=landraces — the string parses perfectly into a different, well-formed name that points somewhere the entry is not. Nothing is malformed, so nothing complains about syntax; the operation simply fails to find anything and comes back noSuchObject(32), or, worse for a write, succeeds against the wrong place in the tree. So: usually a syntax error, occasionally a valid name for the wrong entry, and it is the second that costs an afternoon.

Where this rule does not reach

The escaping in a Distinguished Name is not the escaping used in an LDAP search filter, and neither is the percent-encoding used inside an LDAP URL. Three different grammars, three different escape rules, and a value that has been correctly escaped for one of them is not thereby safe in another. Carrying an escaped string from one context into another unchanged is its own bug class.

Practical consequences worth stating in an interview

Never build a DN by string concatenation from user input. Use the encoding rules, or a routine that implements them, exactly as you would not build a query language statement by pasting text together.
Compare names by decoding, not by comparing strings. Escaping style, and case in attribute types, both vary without changing the name.
Prefer an RDN attribute that cannot carry punctuation. Naming curator entries by a short identifier rather than by a person's rendered name sidesteps commas, plus signs and leading spaces permanently — a naming-design choice, not a parsing fix.
Expect the failure at a distance. The stack that reports the error is often not the one that built the name, because the badly encoded string travels through a configuration file or an environment variable first.

## The string form is an encoding, not the data On the wire a Distinguished Name is a sequence of `RelativeDistinguishedName` values, each a set of `AttributeTypeAndValue` pairs. RFC 4514 defines how to write that structure as a single line of text, and that text needs punctuation of its own: a comma between RDNs, an equals sign inside each one, a plus sign between the components of a multi-valued RDN. The moment a *value* contains one of those characters, the encoding is ambiguous, so RFC 4514 defines escaping. **The escape exists only in the string.** Decode `cn=Bell\, Hannah` and the attribute value is `Bell, Hannah` — six characters before the space, no backslash anywhere. Forgetting this is the most consequential misunderstanding on this subject, because it leads people to store the backslash in the entry, after which the value genuinely contains a character nobody intended and comparisons quietly stop matching. ## What must be escaped, and what merely may be RFC 4514 separates the two, and an answer that promotes the second list into the first teaches false certainty: - **Must be escaped, wherever they appear in a value:** `"`, `+`, `,`, `;`, `<`, `>` and `\`. - **Must be escaped by position:** a space or `#` at the **beginning** of a value, and a space at the **end**. An accession label typed with a stray leading space is a real source of this. - **Must be escaped as a hex pair:** the NUL octet, written `\00`. - **May be escaped, at the writer's discretion:** anything else, including `=`. A producer that escapes more than required is still conformant; a consumer must accept both. Two interchangeable forms exist for any escaped character: | Form | Example | Reading | |---|---|---| | Backslash before the character | `cn=Bell\, Hannah` | escape the comma literally | | Backslash plus the hex pair for the octet | `cn=Bell\2C Hannah` | same value, written by octet | Both decode to the same `AttributeTypeAndValue`, so two DN strings that differ only in escaping style name **the same entry**. String equality is therefore the wrong test for DN equality. ## What actually goes wrong when it is omitted Take a seed-bank accession whose label is `Wheat, Durum` and write the name without escaping: `ou=Wheat, Durum,dc=seedbank,dc=example` The parser splits on every unescaped comma and gets four components: `ou=Wheat`, ` Durum`, `dc=seedbank`, `dc=example`. The second carries no attribute type and no equals sign, so it is not an `AttributeTypeAndValue` at all and the whole string is not a Distinguished Name. A directory server answering an operation with that name in it returns **invalidDNSyntax(34)**. The nastier case is the minority one. If the fragment after the comma happens to read as `type=value` — a label like `Durum, ou=landraces` — the string parses perfectly into a *different, well-formed* name that points somewhere the entry is not. Nothing is malformed, so nothing complains about syntax; the operation simply fails to find anything and comes back **noSuchObject(32)**, or, worse for a write, succeeds against the wrong place in the tree. So: usually a syntax error, occasionally a valid name for the wrong entry, and it is the second that costs an afternoon. ## Where this rule does not reach The escaping in a Distinguished Name is **not** the escaping used in an LDAP search filter, and neither is the percent-encoding used inside an LDAP URL. Three different grammars, three different escape rules, and a value that has been correctly escaped for one of them is not thereby safe in another. Carrying an escaped string from one context into another unchanged is its own bug class. ## Practical consequences worth stating in an interview 1. **Never build a DN by string concatenation from user input.** Use the encoding rules, or a routine that implements them, exactly as you would not build a query language statement by pasting text together. 2. **Compare names by decoding, not by comparing strings.** Escaping style, and case in attribute types, both vary without changing the name. 3. **Prefer an RDN attribute that cannot carry punctuation.** Naming curator entries by a short identifier rather than by a person's rendered name sidesteps commas, plus signs and leading spaces permanently — a naming-design choice, not a parsing fix. 4. **Expect the failure at a distance.** The stack that reports the error is often not the one that built the name, because the badly encoded string travels through a configuration file or an environment variable first.

Do two Distinguished Name strings that differ only in escaping style name the same entry?
Yes. `cn=Bell\, Hannah,...` and `cn=Bell\2C Hannah,...` decode to the identical sequence of attribute types and values, so they denote one entry. It follows that byte comparison is the wrong way to test two DNs for equality: decode both and compare the components, allowing for the attribute type being case-insensitive.
What is the difference between `cn=Bell\, Hannah` and an entry whose `cn` value genuinely contains a backslash?
In the first, the backslash is encoding punctuation and disappears on decode, leaving `Bell, Hannah`. An entry whose value really contains a backslash carries it in the data, and its name must escape that backslash too — `cn=Bell\\Hannah` in the string form. Storing the escape character in the value is the classic corruption, and it silently breaks every later comparison against the intended value.

saying these in an interview costs you the question

Thinks the backslash is part of the stored attribute value
Believes only the comma ever needs escaping in a name
Wraps the value in quotes or percent-encodes it instead
Assumes an unescaped comma always raises a syntax error
Applies search-filter escaping rules to a Distinguished Name
Compares two Distinguished Names by comparing the raw strings

A directory entry's common name contains a comma — what must the RFC 4514 string form of its Distinguished Name do?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The string form is an encoding, not the data

What must be escaped, and what merely may be

What actually goes wrong when it is omitted

Where this rule does not reach

Practical consequences worth stating in an interview

▾common follow-ups2 questions

▾red flags6 flags

The string form is an encoding, not the data

What must be escaped, and what merely may be

What actually goes wrong when it is omitted

Where this rule does not reach

Practical consequences worth stating in an interview

answer

go deeper