distfile fetching vs ISP "site-help" spoofing: any suggestions?

Matthew Seaman matthew at freebsd.org
Tue Jun 18 08:07:52 UTC 2013

On 18/06/2013 06:07, Andrew Reilly wrote:
> I've just tried to portupgrade after a three-month hiatus and noticed a problem with the libgcrypt distfile
> checksum that didn't go away after my usual strategy of waiting for a couple of days,
> re-syncing the ports tree and trying again.  Closer inspection and a hint from a google search
> revealed that the first-level problem is that the wrong file had been fetched: it was a short
> HTML file, rather than the expected tar.bz2 file.  How did that happen?  Apparently my ISP
> (Bigpond, in Australia) has recently turned on a "site-helper" mechanism that spoofs any site
> for which a DNS-lookup fails.  That is, there are now no "missing" or expired sites.  In this
> case, the first item in the ports/Mk/bsd.sites.mk list used by the security/libgcrypt Makefile
> is gnupg.org.favoritelinks.net which does not (any longer?) resolve.

Your ISP is screwing you over.  Complain, loudly.  Vote with your feet.

There was a big to-do about this sort of behaviour around the BIND
community a few years ago, and the overwhelming consensus was that not
returning NXDOMAIN for a non-existent domain was simply wrong and an
evil plot to monetize people's inaccurate typing.

> I've arranged to proceed by deleting the line in bsd.sites.mk, which allowed the fetch to
> succeed.  This seems a bit lame though, because perhaps that site will come back one day.
> Seems like a fragile, non-scaling approach.
> It might be possible to subvert my ISP's evil helpfulness by pointing my DNS requests further
> upstream, but that might prevent the government from blocking my access to things it considers
> distasteful, and I'm not sure I want to go there just yet.

Run your own recursive resolver instance.  The default config for named
in base is set up for this: pretty much all you need to do is turn on
named and modify /etc/resolv.conf to say 'localhost' for your nameserver.

Or use the Google nameservers -- and

> Anyone have any suggestions or best practices?
> Should I try to raise a PR against bsd.sites.mk or security/libgcrypt?

No, don't do that.  There's nothing wrong with bsd.sites.mk.  The
problem here is local to your site / ISP, and that's where you should
look for a solution.



More information about the freebsd-ports mailing list