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

From: Brian Dickson <[email-masked]>
Date: Thu, 11 Mar 2021 19:11:11 -0800

>From the status updates today, I see this draft has expired. I really like
it (and it is quite simple), and would like to see it picked up and
completed (adopted, rough consensus reached, published).

Having reread it and the discussion, I am wondering if useful guidance can
be provided regarding the TC=1 and records added.

If as much glue as will fit is included, but not all glue fits, add all the
glue that fits, and set TC=1.
The resolver SHOULD attempt to use the available glue, but retry over TCP
if none of the servers found via the available glue respond.
I.e. How is TC=1 interpreted currently by different implementations, and is
THAT an issue that could/should be clarified, either in this document, or
in a separate document?

Is it necessary (at all) to mention keeping the glue that fits before
setting TC=1?
I don't think so, but maybe some commentary to that effect would be helpful?

Brian

On Fri, Jun 5, 2020 at 11:57 AM Paul Hoffman <[email-masked]> wrote:

> On Jun 5, 2020, at 10:37 AM, Wessels, Duane <dwessels=
> [email-masked]> wrote:
> >
> > The essence of this draft is the addition of once sentence to RFC 1034:
> >
> >  "If glue RRs do not fit set TC=1 in the header."
> >
> > I worry that this is too ambiguous.  Does it mean all glue?  One glue?
> As much as will fit?
> >
> > AFAIK most software today is designed to fill up the additional section
> with as much glue as possible.  Is the name server allowed to add only some
> glue RRs, even if more would fit (without truncating, or in a TCP response)?
> >
> > Is the name server allowed to fill the additional with all records of
> one type, AAAA or A, when the resolver might only have connectivity of the
> other type?
> >
> > There is also the question of in-domain vs sibling-domain glue.  RFC
> 8499 (Terminology) notes that "Glue records for sibling domains are
> allowed, but not necessary."  Should in-domain glue take priority over
> sibling-domain glue?  Can sibling-domain glue be omitted even if it would
> fit?
>
> The current document is indeed ambiguous. I propose that it be changed to:
>    If all glue RRs do not fit, set TC=1 in the header.
>
> Given Duane's questions above, we can do better with another change to RFC
> 1034 in this document. In this same paragraph from RFC 1034, it says:
>    Put whatever addresses are available into the additional
>    section, using glue RRs if the addresses are not available from
>    authoritative data or the cache.
> That could instead be:
>    Put at least one available address into the additional
>    section, using glue RRs if the addresses are not available from
>    authoritative data or the cache.
>
> I don't think it is worthwhile to go into more detail about how to choose
> how many to put in (because RFC 1034 didn't explicitly talk about message
> size), or the mix of A and AAAA (because RFC 1034 didn't anticipate more
> than one address type).
>
> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 19 Mar 2021 12:24:30 +0100

On Thu, 2021-03-11 at 19:11 -0800, Brian Dickson wrote:
> From the status updates today, I see this draft has expired. I really like it (and it is quite simple), and would like to see it picked up and completed (adopted, rough consensus reached, published).
> 
> Having reread it and the discussion, I am wondering if useful guidance can be provided regarding the TC=1 and records added.
> 
> If as much glue as will fit is included, but not all glue fits, add all the glue that fits, and set TC=1.
> The resolver SHOULD attempt to use the available glue, but retry over TCP if none of the servers found via the available glue respond.

This sounds like something that might be very hard to fit into the flow
of at least some code bases out there.

> I.e. How is TC=1 interpreted currently by different implementations, and is THAT an issue that could/should be clarified, either in this document, or in a separate document?

Answered below for us.

> Is it necessary (at all) to mention keeping the glue that fits before setting TC=1?

When we (PowerDNS auth) set TC=1, we empty the packet, based on the
(somewhat under-argued) belief that different resolvers may draw
different conclusions from what is there and what is not, and emptyingthe packet avoids ambiguity. 

Mirroring that, if the PowerDNS Recursor receives a TC=1 response (with
rcode NOERROR or NXDOMAIN), no records are harvested and the whole
query is retried over TCP.

Based on only our choices, it is pointless to have any content in a
TC=1 response. Others may feel somewhat differently, of course!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/