Hi Shane! On 5 Nov 2024, at 14:08, Shane Kerr <sh...@time-travellers.org> wrote:
> In the security section I do mention that you don't need > cryptographically-secure random numbers. I could expand that a bit, if it is > useful. Every time I mention "random" within earshot of Lucas Pardue it invites hard stares, I think trying to figure out whether I am being unintentionally careless or just enjoy baiting people. I think it's worth at least considering whether "random" is a useful word to use or whether it invites confusion and complexity down the road. The goal here is presumably that applications that treat a set of addresses as an ordered list should be tricked into better behaviour. But in between an authority server and an application is a mess of other intermediaries and caches, and while it seems attractive to say "random all the things!" I wonder whether, especially with small RRSets, there is the potential for less variation in the observed behaviour if particular kinds of "random" introduce some kind of reinforcing bias. But I am very poorly educated in statistics and probability. Perhaps I am worried about nothing. Within that mess, every cache has the potential to defeat any randomisation by an upstream server for as long as a particular ordering persists in the cache. How much more random do we get by shuffling at authority servers and forwarders, if resolvers (or anything with a cache) are already doing it? Perhaps all we need is advice "shuffle any RRSet you obtain through a cache hit"? >> More generally from your OARC talk I think your experience is that >> (paraphrasing) not shuffling is fine for most people, but sometimes causes >> problems. Does it make sense to translate that into a normative MUST for the >> protocol? > > My own feeling is that probably it impacts many zones but people are not > aware (which could be interpreted as "is fine", but also could be interpreted > as "basically works but doesn't actually do what the user thinks it does"). > There are for sure some zones that experience problems. I'm a bit wary of imposing cost and complexity on implementations if there isn't a clear return on investment. > I'm happy to expand on that although I am doubtful it will help much. Maybe > it could be convincing enough that OS or library authors will change how they > present answers to applications though... 🤔 I think it's understandable to think that "makechanges in all DNS implementations" is a lot easier than "make changes to all hosts". Until you realise that non-mobile clients are a rounding error and there are only really two mobile operating systems. The idea of making a protocol change in the DNS to work around behaviour that might be fixable in one point release of Android and iOS. Joe _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
