Subject: ambiguity between root DNSSL and padding in RFC8106

From: 神明達哉 <[email-masked]>
Date: Mon, 12 Mar 2018 11:17:03 -0700

I just happened to notice there might be an ambiguity in the DNSSL RA
option as defined in RFC8106:

   Domain Names of DNS Search List
               One or more domain names of the DNSSL that MUST be
               encoded as described in Section 3.1 of [RFC1035].  With
               this technique, each domain name is represented as a
               sequence of labels ending in a zero octet, defined as a
               domain name representation.  For more than one domain
               name, the corresponding domain name representations are
               concatenated as they are.  Note that for the simple
               decoding, the domain names MUST NOT be encoded in the
               compressed form described in Section 4.1.4 of [RFC1035].
               Because the size of this field MUST be a multiple of
               8 octets, for the minimum multiple including the domain
               name representations, the remaining octets other than the
               encoding parts of the domain name representations MUST be
               padded with zeros.

Since a zero value octet also means the DNS root name ('.'), it would
be impossible if it should be considered as part of the search list or
a padding.  This wouldn't necessarily be a protocol flaw at least in
practice, since the root name is meaningless as a search list suffix.
But I can imagine a configuration accident where the root name is
specified in the middle of the list in the router configuration and
the rest of the names are ignored by the receiver.  From a quick look
at the FreeBSD implementation it actually seems possible to happen.

Am I missing something, or would it be helpful to clarify it in some
way, perhaps as an erratum for RFC8106?

--
JINMEI, Tatuya