On Mon, Apr 13, 2020 at 11:53:03PM -0400, Rich Felker wrote: > > Your local nameserver has already done the TCP failover and paid the > > cost of obtaining the full RRset, your stub resolver is just failing to > > give it the opportunity to return the full data to you. The performance > > cost is low, and such records are a minority. Correctness trumps > > performance where I come from. Cutting corners for performance and > > violating requirements is not acceptable. > > This is true for users running local nameservers, which ideally will > eventually be everyone, but at present that's far from the case.
Well, ISP resolvers and anycast resolvers from Google, Cloudflare, Verisign and Quad are generally not too far away. And then there's that "small" matter of correctness. Since DNS truncation (corretly implemented upstream) never truncates an RRset down the middle, a sufficiently large RRset (~500 bytes), be it AAAA records, TLSA records, ... will simply not be sent via UDP, all you get is the TC bit. Much as you might prefer to not pay the cost of TCP fallback, it is simply required by the protocol. Performance considerations do not trump correctness. The MUSL library highlights standards conformance it is promotion material, and the truth should match the marketing. > OK, if that's true in practice then it probably suffices to always set > it. I'll see if I can find any more information on this. Searching for > dig noadflag suggests there were at least historically problems with > certain nameservers and firewalls dropping requests with the AD bit > set... That was quite some time ago... This is no longer a problem that needs to be addressed by clients. > > there is also no AD bit in the reply. Implementors of stub resolvers > > need to read many RFCs or consult experts who have: > > > > https://tools.ietf.org/html/rfc6840#section-5.7 > > I've read the ones we implement thoroughly. That does not include the > latest additions, That RFC was published in 2013. That's long enough ago. > From the text you linked, it looks like this use of the AD bit (in > queries) is considerably newer than the DO bit. Well, draft 00 of the RFC is from 2005! It was finally published in 2013. The version that specified AD bit use in queries is -10 from 2010. This is no longer news. > I see. I don't think imposing policy about what IPs are "local" or not > is within the scope of musl, though. There are lots of setups people > use where the sense of "local" is rather muddled. In that case, set the AD bit unconditionally, or provide a documented mechanism to do so via a suitable configuration file. > The "trusted" resolver is whatever you write in resolv.conf, to > whatever extent you intend to trust it. There's no point in a separate > whitelist; resolv.conf is that whitelist. Well, for some systems that setting is from DHCP, and is not trustworthy at all, though one might hope that not too many MTAs get their resolver settings from DHCP. Still limiting AD bit solication (by default) has some merit. At the moment you never solicit it, so sending it only sometimes is not worse. This is a tradeoff, I'll leave it to your project to decide. > > You can safely set it unconditionally, or just to the loopback ones (to > > help remove an AD-bit MiTM footgun). No known resolvers will object to > > the AD in queries. > > Do you know any research on this? That's my hope too but I did turn up > some results from around 2013-2015 that seemed to be folks running > into problems that might have been servers or firewalls dropping it. Find me a resolver that fails when the AD bit is set. Stub resolvers that always set it have been around for some time now. > > > Is it only for the sake of not using TLSA records in unsigned > > > domains? That kind of policy can be implemented at the resolver > > > level > > > > It cannot and should not be implemented at the resolver level. > > Noted that this is your position. :-) No, it is a cold hard fact. Not a matter of opinion. You may not yet have come across all the background evidece required to see this, but that does not change the situation. -- Viktor.
