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 14855 invoked from network); 18 Dec 2020 18:41:03 -0000 Received: from ewsd.inri.net (107.191.116.128) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2020 18:41:03 -0000 Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Fri Dec 18 13:37:00 -0500 2020 Message-ID: <3395DB36FC208BF9DEEEB50FB1C681CD@felloff.net> Date: Fri, 18 Dec 2020 19:18:24 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: 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: optimized anonymous service ActivityPub hardware-scale DOM locator Subject: Re: [9front] [Patch] ndb/dns: DNSKEY and OPT RR types Reply-To: 9front@9front.org Precedence: bulk > Are your concerns regarding the caching the fact that opt RR's coming from upstream would be cached? I'm concerned because theres some logic that checks if the answer section is empty (msg->ar == nil). The current code *does* some filtering on the answers to avoid cache poisoning or caching unknown record types. But i dont want to bet on it that it will filter hacks like Topt records. I'd rather keep the opt records separate. One thing less to worry about. No accidents. > I agree, I will fix that in a revised patch if this behavior is still desired. Thanks. > If this whole EDNS stuff is undesired I can rip that part of the patch out, No, this is good work. But i agree that it would be better as separate patches. > but still think the code should catch the Tdnskey RR's, Yes, absolutely. > as having those get caught in the default case was causing some > parsing issues(or perhaps there is a another nice way of handling > that, I am not sure) > > Thanks, > Moody -- cinap