Subject: [DNSOP] Fwd: New Version Notification for draft-andrews-dnsop-glue-is-not-optional-00.txt

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Apr 2020 17:13:23 +1000

This is a long standing issue.  While rare it needs to be addressed by all vendors.  BIND sets TC=1
when it can’t fit any glue records in and if a glue record matches the qname it chooses that.  Before
anyone complains that I’ve listed a response from .GOV servers they where informed years ago about
the issue.

Mark

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-andrews-dnsop-glue-is-not-optional-00.txt
> Date: 15 April 2020 at 16:03:46 AEST
> To: "Mark Andrews" <[email-masked]>, "M. Andrews" <[email-masked]>
> 
> 
> A new version of I-D, draft-andrews-dnsop-glue-is-not-optional-00.txt
> has been successfully submitted by M. Andrews and posted to the
> IETF repository.
> 
> Name:		draft-andrews-dnsop-glue-is-not-optional
> Revision:	00
> Title:		Glue In DNS Referral Responses Is Not Optional
> Document date:	2020-04-14
> Group:		Individual Submission
> Pages:		5
> URL:            https://www.ietf.org/internet-drafts/draft-andrews-dnsop-glue-is-not-optional-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/
> Htmlized:       https://tools.ietf.org/html/draft-andrews-dnsop-glue-is-not-optional-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-andrews-dnsop-glue-is-not-optional
> 
> 
> Abstract:
>   The DNS uses glue records to allow iterative clients to find the
>   addresses of nameservers that live within the delegated zone.  Glue
>   records are expected to be returned as part of a referral and if they
>   cannot be fitted into the UDP response, TC=1 MUST be set to inform
>   the client that the response is incomplete and that TCP SHOULD be
>   used to retrieve the full response.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Apr 2020 10:08:01 -0400

Since this is a one line RFC change of an erroneous omission of text , could it be done as an errata instead?

How widespread is this broken behaviour ?

Paul

> 
> On Apr 15, 2020, at 03:13, Mark Andrews <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Apr 2020 16:51:31 +0000

> Since this is a one line RFC change of an erroneous omission of text , could it be done as an errata instead?

No. It is not an error in the spec that someone noticed 30 years later: it is an operational observation followed by implementation requirement.

> How widespread is this broken behaviour ?

Enough for this clarification to be needed.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Apr 2020 09:52:30 -0700

Paul Hoffman wrote on 2020-04-15 09:51:
>> Since this is a one line RFC change of an erroneous omission of
>> text , could it be done as an errata instead?
> 
> No. It is not an error in the spec that someone noticed 30 years
> later: it is an operational observation followed by implementation
> requirement.

+1.

-- 
P Vixie