[MacPorts] #33930: Ignore consequences of broken DNS servers
#33930: Ignore consequences of broken DNS servers -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts 2.1.0 Component: base | Version: 2.0.4 Keywords: | Port: -------------------------------------+-------------------------------------- #25128 was filed to improve MacPorts to work around [wiki:MisbehavingServers broken DNS servers] but the fix that ultimately got committed did not work around them but instead pointed the problem out to the user and required the user to intervene to continue. Following [http://lists.macosforge.org/pipermail/macports- dev/2012-January/017325.html further discussion on the mailing list], I would now like to implement the fix I originally suggested and commit my patch from #25128. -- Ticket URL: <https://trac.macports.org/ticket/33930> MacPorts <http://www.macports.org/> Ports system for Mac OS
#33930: Ignore consequences of broken DNS servers --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: MacPorts 2.1.0 Component: base | Version: 2.0.4 Resolution: fixed | Keywords: Port: | --------------------------------------+------------------------------------- Changes (by ryandesign@…): * status: new => closed * resolution: => fixed Comment: r91701 -- Ticket URL: <https://trac.macports.org/ticket/33930#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#33930: Ignore consequences of broken DNS servers --------------------------------------+------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: base | Version: 2.0.4 Resolution: | Keywords: Port: | --------------------------------------+------------------------------------- Changes (by jmr@…): * status: closed => reopened * resolution: fixed => * milestone: MacPorts 2.1.0 => Comment: I still disagree with this for all the same reasons. -- Ticket URL: <https://trac.macports.org/ticket/33930#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#33930: Ignore consequences of broken DNS servers ---------------------------+-------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: base | Version: 2.0.4 Resolution: | Keywords: Port: | ---------------------------+-------------------------- Comment (by urilabob@…): Well, it's now a year-and-a-half later and the problem hasn't resolved itself: there are more misbehaving dns servers, and dnssec isn't taking the world by storm... Meanwhile, the error message isn't very helpful (I assumed, when I first read it, that the problem was servers with stale caches...). While I would vote for jmr's fix myself, if we aren't going to have it could we at least change the error warning to something like: "Your DNS servers incorrectly give a DNS response for nonexistent hosts, probably in an attempt to be helpful. This may cause checksum mismatches for some ports. If you encounter problems, we suggest switching to a more standard DNS for the duration of your macports session." -- Ticket URL: <https://trac.macports.org/ticket/33930#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#33930: Ignore consequences of broken DNS servers ---------------------------+-------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: defect | Status: reopened Priority: Normal | Milestone: Component: base | Version: 2.0.4 Resolution: | Keywords: Port: | ---------------------------+-------------------------- Comment (by cal@…): Can we check whether a user's DNS is broken when an HTML file is downloaded (e.g. by trying to resolve nonexistant.macports.org), print an appropriate warning and continue using a different mirror? We could even try to fall back to known working DNS servers ourselves, it seems cURL >= 7.24.0 supports that when built against c-ares using `CURLOPT_DNS_SERVERS`:
Set the list of DNS servers to be used instead of the system default. The format of the dns servers option is:
host[:port][,host[:port]]...
For example:
192.168.1.100,192.168.1.101,3.4.5.6
This option requires that libcurl was built with a resolver backend that supports this operation. The c-ares backend is the only such one.
Even without c-ares support, cURL >= 7.21.3 can be tricked into using manually fetched DNS data that is known to be correct using `CURLOPT_RESOLVE`:
Pass a pointer to a linked list of strings with host name resolve information to use for requests with this handle. The linked list should be a fully valid list of struct curl_slist structs properly filled in. Use curl_slist_append(3) to create the list and curl_slist_free_all(3) to clean up an entire list.
Each single name resolve string should be written using the format HOST:PORT:ADDRESS where HOST is the name libcurl will try to resolve, PORT is the port number of the service where libcurl wants to connect to the HOST and ADDRESS is the numerical IP address. If libcurl is built to support IPv6, ADDRESS can of course be either IPv4 or IPv6 style addressing.
This option effectively pre-populates the DNS cache with entries for the host+port pair so redirects and everything that operations against the HOST+PORT will instead use your provided ADDRESS.
You can remove names from the DNS cache again, to stop providing these fake resolves, by including a string in the linked list that uses the format "-HOST:PORT". The host name must be prefixed with a dash, and the host name and port number must exactly match what was already added previously.
-- Ticket URL: <https://trac.macports.org/ticket/33930#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts