GNOME Bugzilla – Bug 750941
nmcheck.gnome.org should have a DNS TTL of 0
Last modified: 2016-12-07 18:54:32 UTC
From discussion at https://lists.fedoraproject.org/pipermail/devel/2015-June/211406.html which can be summed up in two quotes: "If the captive portal uses the system's DNS, and the system has cached www.gnome.org from when you were on a previous network, your captive portal check might use a cached DNS resolve and try to use an HTTP connection to a blocked IP address, because the local forged DNS answer to the local hotspot IP never got triggered. So if you use www.gnome.org, you have to make sure the portal software is not using the system DNS cache for DNS lookups. So it is better for captive portal login to use hotspot-nocache.fedoraproject.org, which will always have a TTL of 0, so it will not cached." (Note: not using the system DNS cache is not possible with WebKitGTK+ and will probably never be possible.) "[I]f the portal uses DNS hijacking only and does not hijack TCP connections to the real www.gnome.org, and we attempt to open a TCP session to the real www.gnome.org, and the portal is only expecting us to visit a different host due to its DNS hijacking, then I understand that we're out of luck and the portal's login page will never show." (Note: our current behavior is exactly what web browser would probably do. This is an opportunity to make our portal helper more reliable than a web browser.) I guess the best way to solve this without hardcoding the Fedora URL upstream is make the URL configurable at build time.
(In reply to Michael Catanzaro from comment #0) > From discussion at > https://lists.fedoraproject.org/pipermail/devel/2015-June/211406.html which > can be summed up in two quotes: > > "If the captive portal uses the system's DNS, and the system has cached > www.gnome.org from when you were on a previous network, your captive > portal check might use a cached DNS resolve and try to use an HTTP > connection to a blocked IP address, because the local forged DNS answer > to the local hotspot IP never got triggered. So if you use www.gnome.org, > you have to make sure the portal software is not using the system DNS cache > for DNS lookups. So it is better for captive portal login to use > hotspot-nocache.fedoraproject.org, which will always have a TTL of 0, > so it will not cached." (Note: not using the system DNS cache is not > possible with WebKitGTK+ and will probably never be possible.) If the system DNS cache is the regular glibc resolver using /etc/resolv.conf than this isn't an issue since such a cache can only exist in a process scope and thus any new instance starts with an empty cache. If the system DNS cache is implemented by a local resolver daemon (i.e. /etc/resolv.conf has a single static entry 127.0.0.1:53) then wouldn't it be safer (on a systemwide level) if said daemon was told to clear the cache whenever the local host gets a new IP address configured?
(In reply to Rui Matos from comment #1) > If the system DNS cache is implemented by a local resolver daemon which is what we're doing for F23 > (i.e. > /etc/resolv.conf has a single static entry 127.0.0.1:53) then wouldn't it be > safer (on a systemwide level) if said daemon was told to clear the cache > whenever the local host gets a new IP address configured? *Shrug.* It would have to be implemented :)
We use nmcheck.gnome.org nowadays.
Note: this is not a problem with www.gnome.org anymore, but there is no Bugzilla component for nmcheck.gnome.org.
TTL of nmcheck.gnome.org is now zero as requested.
OK, FIXED then, thanks Andrea!