On Wed, Oct 30, 2013 at 03:22:55PM -0400, William Herrin wrote:
> 1. Use only English alphabetic characters (a-z, A-Z), numeric
> characters (0-9), the hyphen and the period.

This was never required by any DNS RFC.  Also, they're not English
characters, but ASCII ones. 

The full stop character is not actually part of the name.  It's a
separator.  For presentation format (i.e. the one you see and
manipulate) you need to use it, but be aware that it is not a part of
the name as such.  (This is why IDNA can't provide an "alternate"
separator.)

In my opinion, it's really better to think in terms of labels.  Labels
are separated by dots in presentation format, and by label length
markers in wire format.  In order to maximise interoperability, it is
wise to stick to the LDH rule (which is roughly what William says
above: ASCII letters either upper or lower case, digts, and the
hyphen).  But in principle, labels can be made of any octets you like.

Note that, if you use IDNA (internationalized labels) in the most
recent version (IDNA2008), the U-label form doesn't allow upper case.
This yields the bizarre example that Fass is a label (LDG) and fass is
a label (LDH) and faß is a label (U-label) but Faß is _not_ a valid
label.

> 3. Start each section of the name with a letter, not a number or hyphen.

This isn't a requirement and hasn't been since the so-called "3com
rule" change in RFC 1123.  See RFC 1123 section 2.1.  The topmost
label, however, _cannot_ begin with a number.  No label may begin with
a hyphen.

> 4. Two hyphens can't be side by side, nor can a hyphen start or end a
> section of the name.

Two hyphens can be side be side, but if you plan to be compatible with
IDNA they can't be side by side in the 3d and 4th positions.  That is,
foobar--baz is a perfectly good label.  fo--obarbaz is not.  This is
so that strategies along the lines of "xn--", which is used for INDA,
can be used again in the future for other issues.

> Finally, the cardinal rule of reverse dns: whatever name the address
> resolves to must resolve back to the address. 

This is a requirement for matching reverse.  As I've already suggested
in this thread more than once, it is by no means an uncontroversial
claim.

Best,

A

-- 
Andrew Sullivan
Dyn, Inc.
asulli...@dyn.com
v: +1 603 663 0448

Reply via email to