In order to make progress on the glue-is-not-optional draft, we need the
working group to reach consensus on the requirement level for sibling glue
(MUST, SHOULD, or MAY).
The only situation in which a failure to include sibling glue leads to a
resolution failure is when there is a sibling glue cyclic dependency. e.g.:
bar.test. 86400 IN NS ns1.foo.test.
bar.test. 86400 IN NS ns2.foo.test.
foo.test. 86400 IN NS ns1.bar.test.
foo.test. 86400 IN NS ns2.bar.test.
A few months back I analyzed the zone files available to me via CZDS for
sibling glue. Out of some 209,000,000 total delegations, 222 of them had only
sibling NS records in a cyclic dependency as above. The domains ADOBE.NET and
OMTRDC.NET is one real-world example.
The arguments for making sibling glue a MUST are:
1. accommodates (the 0.0001% of) domains with cyclic sibling glue.
2. simpler to specify, don’t need differing requirements for in-domain and
sibling glue.
The arguments against are:
1. domains with cyclic sibling delegations should be considered “broken” and
not expected to work, perhaps similar to TsuNAME-style external delegation
cycles.
2. increases response sizes, truncation probability, and amount of TCP.
DW
> On Oct 11, 2021, at 4:51 PM, Wessels, Duane <[email protected]> wrote:
>
> Dear DNSOP,
>
> Changes to this draft from the previous version are as follows:
>
> * Clarified scope to focus only on name server responses, and not
> zone/registry data.
> * Reorganized with section 2 as Types of Glue and section 3 as
> Requirements.
> * Removed any discussion of promoted / orphan glue.
> * Use appropriate documentation addresses and domain names.
> * Added Sibling Cyclic Glue example.
>
> I'd say we still do not have consensus on treatment of sibling glue. Section
> 3.2 currently has the strict requirements with optional more lenient
> requirements in [square brackets]:
>
> 3.2. Sibling Glue
>
> This document clarifies that when a name server generates a referral
> response, it MUST [SHOULD] include available sibling glue records in
> the additional section. If all sibling glue records do not fit in a
> UDP response, the name server MUST [is NOT REQUIRED to] set TC=1.
>
>
> DW
>
>
>> On Oct 11, 2021, at 4:30 PM, [email protected] wrote:
>>
>> Caution: This email originated from outside the organization. Do not click
>> links or open attachments unless you recognize the sender and know the
>> content is safe.
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of the
>> IETF.
>>
>> Title : Glue In DNS Referral Responses Is Not Optional
>> Authors : M. Andrews
>> Shumon Huque
>> Paul Wouters
>> Duane Wessels
>> Filename : draft-ietf-dnsop-glue-is-not-optional-03.txt
>> Pages : 9
>> Date : 2021-10-11
>>
>> Abstract:
>> The DNS uses glue records to allow iterative clients to find the
>> addresses of nameservers that are contained within a delegated zone.
>> Authoritative Servers are expected to return all available glue
>> records in referrals. If message size constraints prevent the
>> inclusion of all glue records in a UDP response, the server MUST set
>> the TC flag to inform the client that the response is incomplete, and
>> that the client SHOULD use TCP to retrieve the full response. This
>> document updates RFC 1034 to clarify correct server behavior.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-glue-is-not-optional-03.html
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-03
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
