"Peter J. Philipp" <p...@centroid.eu> writes: > Hi, > > I'm not the best in reading patches, so I'm going to query you. Does > your patch check for the "AD" flag from the resolver?
The patch doesn't change anything here. We don't look at that flag for res_mkquery, the application is supposed to do so. getrrsetbyname(3) already checks the ad bit to set RRSET_VALIDATED. > As basically a > DNSSEC able recursive nameserver should set this meaning it has > authenticated the data. I wrote a patch for DNSSEC (possibly erroneous > by comparing it to you) and posted it to #opensmtpd in hopes that eric > would see it. Much of that functionality is superfluous now but it does > have an "AD_MASK" check. You're right that we still need to handle the AD flag better, that part was missing from my first diff. > Here is my patch from last year, which I gave up on, feel free to cherry > pick anything needed out of it. You'll see some similarities but they > are different enough to show two different peoples work. > > http://centroid.eu/private/dnssec.patch.txt Setting the AD flag for a query is possible, however those semantics are newer than the EDNS0 extension. As far as I know, rfc6840 introduced AD=1 for queries in 2013, whereas rfc3225 specifies the DO flag since 2001. https://tools.ietf.org/html/rfc3225 https://tools.ietf.org/html/rfc6840#section-5.7 Also EDNS0 can give you more than 512 bytes on UDP (if the resolver supports it). So I thought I'd rather implement RES_USE_DNSSEC on top of EDNS0. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
