Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt
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, internet-dra...@ietf.org 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt
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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Doodle poll for DNSOP WG interim week 25-29 October 2021
Dear DNSOP WG, We are planning our second DNSOP WG interim meeting in the week of 25-29 October. The draft dns-error-reporting is on the agenda for the interim meeting: - https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ Please fill in the Doodle poll to settle on a day and time: - https://doodle.com/poll/nandts5k295y6i6q?utm_source=poll_medium=link We will close the Doodle poll at the end of Thursday 14 October. Best regards, Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question on interpretation of DO and CD
On 07/10/2021 08:52, Mark Andrews wrote: DNSSEC will work reasonably well if the upstream are just DNSSEC aware (keep the RRSIGs with the data they cover, pass through negative proofs required for the answers) if there is not spoofed traffic, a mix of DNSSEC aware and DNSSEC oblivious server for the zone, etc. A validating upstream will block this badness and only pass through good responses. A non-validating upstream will cache this garbage. It will fail abysmally if the upstreams are not DNSSEC aware. Don’t even attempt it. With the getdns API library and stub resolver design, quite a bit of effort has gone into "road block avoidance" i.e. checking if the upstream resolver is DNSSEC aware and falling back to full recursion if it isn't (to obtain the DNSSEC data for end-point validation). For pictures, see the slide desk https://getdnsapi.net/slides/an-earnest-stub.pdf, slide 17 and onwards. -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
