Am 05.02.2014 um 17:20 schrieb Stuart Henderson <stu_AT_spacehopper.org>:
> On 2014/02/05 11:10, Simon Perreault wrote:
>> Le 2014-02-05 03:33, Eric Faurot a écrit :
>>> Just a question before I commit it. The '/' character is apparently
>>> used in dname labels sometimes. Can anyone think of other chars that
>>> should be allowed too? Or do we want to be even more lenient wrt dname
>>> validation?
>>
>> Why validate at all? Strictly speaking, all bytes are allowed in DNS
>> labels...
>
> Right - the usual restriction "letters, digits or hyphens" is on host
> names only, not DNS labels.
I do not think so. As stated in
http://tools.ietf.org/search/rfc6672#section-2.1
The DNAME target is a domain name as defined in
http://tools.ietf.org/search/rfc1035 Section 2.3.1
> https://tools.ietf.org/html/rfc6672#section-6.2
>
> The advisory remarks in [RFC2317] concerning the choice of the "/"
> character apply here as well.
Yes, but only for _reverse_ delegations.
> https://tools.ietf.org/html/rfc2317 (section 4)
>
> Some DNS implementations are not kind to special characters in domain
> names, e.g. the "/" used in the above examples. As [3] makes clear,
> these are legal, though some might feel unsightly. Because these are
> not host names the restriction of [2] does not apply. Modern clients
> and servers have an option to act in the liberal and correct fashion.
>
>
> [3] https://tools.ietf.org/html/rfc2181#section-11
This one is obsolete and updated by others.
> " 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. "
Received on Thu Feb 06 2014 - 12:23:53 CET