On Mon, Jul 27, 2020 at 03:30:52AM +0200, Jeremie Courreges-Anglas wrote: > On Sun, Jul 26 2020, Jesper Wallin <jes...@ifconfig.se> wrote: > > On Sat, Jul 25, 2020 at 02:01:06PM +0200, Jeremie Courreges-Anglas wrote: > >> > >> For those two reasons I think the feature should be opt-in. > > > > Yeah, I agree with you. My first approach was to have it check what > > kind of DNS record that was requested, and add the AD-flag only if type > > was SSHFP, but that felt even uglier. I also wasn't so sure my approach > > was the right one after reading the RFCs Peter J. Philipp mentioned. > > The quote from RFC6840 seems clear to me, care to share why you had some > doubts if they still exist?
Sorry for being unclear, I was referring to the previous RFCs, but no, no doubts. RFC6840 is indeed clear on the matter. > > Perhaps another approach would be to make use of the currently unused > > flags argument in getrrsetbyname(3)? This way, only getrrsetbyname(3) > > and certain requests are affected by it. > > I thought about that too, but getrrsetbyname(3) isn't the only function > of interest. There's also res_query(3) and friends, which are in more > widely use in the larger ecosystem. I guess we could restrict AD flag > tweaking to APIs where the caller can actually access the AD flag in the > response, but the "default vs opt-in" question is still present. > Yeah, true. I'd say that opt-in is the proper way to go, no matter what approcah is taken. For what it's worth, my vote is to go with your trust-ad approach. It's a lot more elegant than mine. It would need some manuals changes though, to cover the cases benno@ mentioned. I still think the RES_USE_AD option might be a useful though, for when you want to decide on an application-level whether to trust AD or not? Yours, Jesper Wallin
