From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24082 invoked from network); 18 Dec 2020 15:28:06 -0000 Received: from ewsd.inri.net (107.191.116.128) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2020 15:28:06 -0000 Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Fri Dec 18 10:22:02 -0500 2020 Message-ID: Date: Fri, 18 Dec 2020 16:21:50 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <9df1d568-ff75-8e46-6b0f-98323786a8e1@mail.posixcafe.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: stateless storage hosting module configuration grid Subject: Re: [9front] [Patch] ndb/dns: DNSKEY and OPT RR types Reply-To: 9front@9front.org Precedence: bulk i wonder if the opt record should really be an RR and exposed to the caching code. it is just a hack to communicate protocol extensions by query, no? its not really part of the answer (->ar) to the dns query? in that case attaching Topt records to the queried domains seems very wrong to me. -- cinap