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=NICE_REPLY_A,
	RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 29305 invoked from network); 18 Dec 2020 16:14:05 -0000
Received: from ewsd.inri.net (107.191.116.128)
  by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2020 16:14:05 -0000
Received: from mail.posixcafe.org ([45.76.19.58]) by ewsd; Fri Dec 18 11:05:31 -0500 2020
Received: from [10.68.200.62] (static-198-54-131-174.cust.tzulo.com [198.54.131.174])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 242f2883 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Fri, 18 Dec 2020 10:05:20 -0600 (CST)
To: 9front@9front.org
References: <E06274A460F2164F27C2EE6C9A5F73B9@felloff.net>
From: Jacob Moody <moody@mail.posixcafe.org>
Message-ID: <cc1085c8-1d3e-da4d-235e-ba2a78273eaa@mail.posixcafe.org>
Date: Fri, 18 Dec 2020 10:05:18 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <E06274A460F2164F27C2EE6C9A5F73B9@felloff.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: content-driven firewall SVG DOM interface polling-aware standard 
Subject: Re: [9front] [Patch] ndb/dns: DNSKEY and OPT RR types
Reply-To: 9front@9front.org
Precedence: bulk

On 12/18/20 9:21 AM, cinap_lenrek@felloff.net wrote:
> 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.

Thank you for the feedback.
 From my understanding, the opt record is only used to to communicate the protocol extension.
 From my testing with other DNS servers the opt RR is included in the additional section (->ar)
of the response when the client sends a request that includes it's own opt RR in the additional section.

Are your concerns regarding the caching the fact that opt RR's coming from upstream would be cached?

On 12/18/20 6:25 AM, hiro wrote:

> why not just one line maxudp = 4096 ?


I agree, I will fix that in a revised patch if this behavior is still desired.
If this whole EDNS stuff is undesired I can rip that part of the patch out, but still think
the code should catch the Tdnskey RR's, 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