Enum domain::bits::name::LabelContent[][src]

pub enum LabelContent<'a> {
    Normal(&'a [u8]),
    Binary(u8&'a [u8]),
}

The contents of a label.

There are two types of labels with content currently in use: termed normal labels and binary labels herein. The type of a label is determined by the first octet of the label’s wire representation.

Originally, RFC 1035 decreed that the label type shall encoded in this octet’s two most-significant bits. 0b00 was to mean a normal label and 0b11 was to indicate the pointer of a compressed domain name. Since that left only two more types, RFC 2671 declared 0b01 to signal an extended label type with the rest of the first octet stating which label type exactly. RFC 2673 used this mechanism to define binary labels as type 0x41.

However, because domain names are such a fundamental part of the DNS, it turned out that adding a new label type resulted in all sorts of compatibility issues. It was thus decided with RFC 6891 to abandon this experiment and deprecate binary labels.

The LabelContent type still has two variants for normal and binary labels. Because it is an enum, creation of values cannot be regulated which means that any value of this type not directly acquired through a call to Label::content() may contain invalid data. Despite that, the implementations of the various std::fmt traits provided by this type happily assume correctly encoded data and will panic.

Variants

A normal label.

Normal labels consist of up to 63 octets of data. While RFC 1034 proposes to limit the octets to ASCII letters, digits, and hyphens, no hard restriction exists and all values are allowed.

When encoded, normal labels start with a one-octet value containing the number of octets in the label’s content followed by that content. Because the label type in the most-significant bits of that first octet is 0b00, the value of the octet really is length and no masking is required.

A binary label, also called a bit-string label.

Binary labels contains a sequence of one-bit labels. The bits in the label are treated each as a label of its own. The intention was to provide a way to express arbitrary binary data in DNS allowing zone cuts at any point in the data. This was supposed to make the zone delgation for reverse pointers in IPv6 easier and more flexible.

The content of a binary label consists of one octet giving the number of bits in the label. The value of zero indicates 256 bits in order to make empty labels impossible. This octet is followed by the smallest number of octets necessary to contain that many bits with excess bits set to zero.

Confusingly, the bits are arranged in reverse order. The most-significant bit (bit 7 of the first octet) contains the right-most label in customary label order. However, two consecutive binary labels are arranged as normal.

This variant contains the number of bits in its first element and a bytes slice of the bits in its second element. The bit count is kept as is, ie., 0 still means 256 bits.

Trait Implementations

impl<'a> Display for LabelContent<'a>
[src]

Formats the value using the given formatter. Read more

impl<'a> Octal for LabelContent<'a>
[src]

Formats the value using the given formatter.

impl<'a> LowerHex for LabelContent<'a>
[src]

Formats the value using the given formatter.

impl<'a> UpperHex for LabelContent<'a>
[src]

Formats the value using the given formatter.

impl<'a> Binary for LabelContent<'a>
[src]

Formats the value using the given formatter.

impl<'a> Debug for LabelContent<'a>
[src]

Formats the value using the given formatter. Read more

Auto Trait Implementations

impl<'a> Send for LabelContent<'a>

impl<'a> Sync for LabelContent<'a>