pwouters at redhat.com
Thu Jun 21 21:05:09 UTC 2012
On Thu, 21 Jun 2012, Björn Persson wrote:
> I installed DNSsec-trigger a few months ago and tried it out in a few
> networks. It seemed to work as advertised in all cases. A hotspot run by a
> nearby shopping center turned out to be a very hostile network where pretty
> much everything except HTTPS was blocked or mangled, and DNSsec-trigger
> correctly detected that it had to mask DNS as HTTPS.
Great! Let me know how dnssec-trigger 0.11 works, with the additional
hotspot port 80 manglign detection.
> The only problem I found was in how the local DNS cache interacts with
> internal domains on NATed networks. I have a DNS server at home that
> translates names in my own domain to private IPv4 addresses. Some of those
> names are also visible publicly, but then they all point to my one public IPv4
> address. When I moved from my own network to another Unbound still remembered
> the private addresses, which were of course not reachable from the other
> network, and when I moved back to my own network Unbound remembered the public
> address, which is the wrong address to use there. (With IPv6 I don't have this
> problem but IPv6 isn't exactly available in every hotspot...)
> I'm not sure there is anything that DNSsec-trigger can do to work around this
> if you want it to be able to work from the cache when even HTTPS is blocked.
> Perhaps dual-view setups like mine should simply use a short TTL to minimize
> the problem.
Openswan deals with this because it gets the domain from the IKE
protocol, so it can flush the domain and everything under it from the
cache. Currently there is no way to signal this with NM. However, if
your domain is the "search prefix" in your home network, then perhaps it
would be enough if NM/dnssec-trigger would flush everything of the
previous "search domain" from the cache.
Using TTL=0 or something fairly short should help you in your case though.
> Björn Persson
More information about the devel