Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[Shumon Huque <[e-mail]>]

On Wed, Jul 28, 2021 at 2:26 AM Geoff Huston <[e-mail]> wrote:

> The language of sections 2 and 3 are clear and purposeful. For DNS
> resolution to work
> the glue records for “in-balliwick” name servers of a zone MUST be
> provided as glue records
> in a DNS response. clear.
>
> Section 4 in Sibling Glue ther heads into a different direction It notes
> that “In many
> cases, these are not strictly required for resolution” but then simply
> adds them as a MUST
> be returned in referral responses without any apparent justification.
>
> If this is an optimisation technique, then SHOULD or MAY, with some
> explanation, makes
> more sense to me in this document. But frankly even this seems to be a
> different
> recommendation (and a different document) to me.
>
> Up to section 4, this document appears to be stating clearly an omission
> in the current
> DNS spec, namely that all in-bailiwick name server names MUST be present
> as a Glue record in
> a referral response for resolution to work.
>

Sibling glue was already covered in RFC 1034 (even though there was no term
for it). To quote
(Section 4.3.2, 3b):

            Copy the NS RRs for the subzone into the authority
            section of the reply.  Put whatever addresses are
            available into the additional section, using glue RRs
            if the addresses are not available from authoritative
            data or the cache.  Go to step 4.

Text was not as precise back then, but my reading of this is that the
nameserver should
put "whatever" addresses it has in the additional section. It says to
include glue RRs (defined
earlier as data that allows access to subzones), but doesn't differentiate
between glue below
the zone cut of the referral or glue it has for other subzones.

(An earlier section does say that glue is only necessary if it's below the
cut, but the
intent of the paragraph seems clear. Put "whatever" addresses I have in the
referral. And
"only necessary" doesn't address the corner cases we've described where
sibling glue is
required for resolution).

This paragraph also says to include addresses it may have from
authoritative data, which is
okay, but that's not glue, so we didn't cover it in the draft.

It also says 'addresses from cache' (mixed mode recursive/authoritative
servers were more
common then). This phrase should be deprecated in my opinion. Cached
addresses may
include things that are certainly out of bailiwick of the delegating zone,
and I assume would
likely be disregarded by most paranoid resolvers.

Shumon.