As it is, if the interface-defaulted squid machine was dual-homed to providers X and Y that don't peer, a customer of X could get the A record for the interface in Y's space. The client would then have to take the transit path between X and Y, which for many X's and Y's, sucks.
Yes. But there are a lot of other reasons for specific paths to suck, and I don't consider this one to be detectable, or even representative.
You could take in all the BGP data from your providers (read-only as it were) then link that into your DNS server so that it returns an IP address according to the 'best' (however you define that...) route that you have back to them...?
No. DNS does not guarantee meaningful ordering of RRs within RRsets, and except in the case of MX or SRV which have explicit priorities, clients are free to sort or randomize or even subset the A RRset they get back. Also, consider caches that are used directly or indirectly by clients whose addresses may not be ideal for the original ordering, even if ordering were preserved. Server ordering of A RRsets is just not a useful approach.
I think the whole purpose t Paul V's madness in creating this solution was to avoid doing just that.
My approach avoids the use of BGP, but not for the above stated reasons. As I said at the SF NANOG, it is hard to get transit providers to send a full BGP table, it is hard to accept it, and it would take a modified GateD that randomized destinations in order to keep BGP's path selection from leading 90% of your routes down 1/Nth of your transit providers. BGP was the wrong answer.
Also I seem to remember something in Paul's take that took care of this situation. Maybe he can elaborate.
Just as DNS Round Robin is suboptimal but better than nothing, so it is that first hop path symmetry is not a complete solution but far better than a single static default when buying transit from N providers. At some point I will revisit the interface default logic and add round robin selection for outbound TCP sessions -- obviously the first hop path symmetry trick only works for inbound sessions. None of this will ever lead to optimality but it's more robust than a single connection from any provider I know of, and it's better than randomizing BGP or depending on stable ordering in DNS. The next step after outbound round robin is teaching Squid to keep track of connection quality from clients, and to send back HTTP redirects if a client comes in on the "wrong" interface. This is the only way to fix the MSIE and NSN brain damage whereby only the first A RR of a response is used, and when I get this part done it will be a product rather than a giveaway like the interface default stuff. (Yes, I have enough investors and customers for this, thanks for your interest.)