Ignore MisbehavingServers rather than fail with an error

Ryan Schmidt ryandesign at macports.org
Wed Apr 11 15:57:47 PDT 2012


On Apr 11, 2012, at 05:51, Joshua Root wrote:

> On 2012-4-9 17:09 , Ryan Schmidt wrote:
>> 
>> What I'm trying to get across is that if we have an opportunity to reduce the number of tickets that get filed, that's of benefit to everyone, so why shouldn't we do it?
> 
> It's questionable that the patch will actually do that. (And you know as
> well as I that reducing the number of tickets filed is not in itself of
> benefit to everyone.)
> 
>> I agree it and a bit of a hack, but I cannot envision a situation in which it doesn't work correctly. If you can, please let me know.
> 
> The obvious failure case would be a correctly downloaded file that looks
> like HTML to file(1) but doesn't end in .htm[l].

Right, and I don't think any such file exists, at least not used as a MacPorts distfile.

> This simply hasn't been tested exhaustively, and it probably isn't
> practical to. That alone is a sufficient reason not to want it in the
> release.

I agree it would be hard or at least time-consuming to test all distfiles in all ports. We could simply put the patch into the release and see what happens when users use it. We didn't "exhaustively" test binaries either: we just turned them on one day, MacPorts started installing them for users, and a significant amount of Hell broke loose and then we had to deal with it and fix it. I anticipate significantly fewer problems as a result of my patch; I actually anticipate no problems at all.

>> Off the top of my head, here's an alternate solution: right before we ping servers to find which ones are nearby, look up the IP address of a hostname that we know doesn't exist (i.e. nonexistent.macports.org). If it returns an IP address, we know we're dealing with a broken DNS server. Then, see if any of the servers we're going to ping resolve to the same IP. If so, they should be removed from the list and treated as if they don't exist.
> 
> That and Jeff's idea of using known good DNS servers are certainly worth
> investigating.

Using known-good DNS servers is an interesting idea, and it would help for users on unrestricted networks that merely have broken/helpful DNS servers, like some home cable and DSL broadband connections and those using OpenDNS with its default settings.

To try to avoid these sloppy DNS servers I usually have Google's DNS servers 8.8.8.8 and 8.8.4.4 in my laptop's DNS settings. But I have encountered networks before where I was unable to get to certain sites, and had to remove these DNS settings and use the network's DNS servers instead.

The whole idea of many users globally using the same DNS servers -- Google DNS, OpenDNS, etc. -- is contrary to how DNS was intended to be used in the first place. But companies like these seem to be rewriting the book on DNS and making it work.

What about restricted networks: coffee shops, hotels, airports, airplanes, trains? On these you must often log in, or pay to access them, or at least agree to terms of use. If on any of these networks the restrictions are implemented entirely in DNS, using a known-good DNS to bypass them could work but could be considered a breach of the network's terms of use. And if the restrictions are more robust, then using a known-good DNS won't help; we'll still fail to fetch files until the user logs in.




More information about the macports-dev mailing list