On Tue, Apr 14, 2020 at 02:16:20AM -0400, Viktor Dukhovni wrote: > 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.
If you're on dialup or saturated DSL or cellular link, they're easily 300-1000 ms away. Each round trip costs that. In any case this is a separate topic. > > 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. Given your above assumption that everyone is on fiber or similar, I think you might be a bit optimistic about what we can rely on... > > > 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. We support environments that haven't been touched since 2009 or so, and to a lesser/minimal-support extent ones that haven't been touched since around 2004. Your idea of environments Postfix might be running on musl in is very different from the concept of environments that arbitrary applications binaries linked to musl might be running in. So if there's any chance of this breaking there almost certainly needs to be a way to turn it off that works even on static binaries. > > 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. Putting it in resolv.conf on an options line is probably the best. The main remaining question is just which default to use, and where to apply it (at res_mkquery or at res_send). > > > 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. Do you know if the usual Windows, Android, iOS, etc. ones always set it? If so it's almost surely safe to do so and this might not even need to be an option (which would really be my favorite coarse of action -- making it unconditional so there's no new configuration to invent). Rich
