Opened 13 years ago

Last modified 11 years ago

#33930 reopened defect

Ignore consequences of broken DNS servers

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: base Version: 2.0.4
Keywords: Cc: cooljeanius (Eric Gallager), rabbim@…
Port:

Description

#25128 was filed to improve MacPorts to work around 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 further discussion on the mailing list, I would now like to implement the fix I originally suggested and commit my patch from #25128.

Change History (6)

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: newclosed

comment:2 Changed 13 years ago by jmroot (Joshua Root)

Milestone: MacPorts 2.1.0
Resolution: fixed
Status: closedreopened

I still disagree with this for all the same reasons.

comment:3 Changed 11 years ago 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."

comment:4 Changed 11 years ago by neverpanic (Clemens Lang)

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.

comment:5 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:6 Changed 11 years ago by rabbim@…

Cc: rabbim@… added

Cc Me!

Note: See TracTickets for help on using tickets.