The current behavior for DNS "pinning" leads to a security hole which allows information to be sent to the wrong server, even without evil intent. Scenario is described below. I believe that the current behavior to cache DNS entries forever is a standards violation. The standard for DNS, RFC 1035 states: - With the proper search procedures, authoritative data in zones will always "hide", and hence take precedence over, cached data. - Cached data should never be used in preference to authoritative data, so if caching would cause this to happen the data should not be cached. DNS TTL information is not something that a single application should decide it doesn't want to abide by. There has been some discussion that the current behavior is in response to a "security" issue. The current behavior, however, exchanges this for a more common security problem, which occurs even if nobody is actively trying to steal information. Refusing to abide by the TTL parameter from a DNS lookup is every bit as large of a security hole, perhaps larger. Using a cached, expired DNS lookup (such as for those users using dynamic DNS services,) will end up sending the wrong information to the wrong server, possibly an e-vil server. Scenario: 1. My home server, using DHCP, receives a dynamic IP address of 18.104.22.168 2. I register the dynamic service myhome.dyndns.org to point to 22.214.171.124 3. User Alice visits my web site, using Mozilla, and begins a transaction. 4. My DHCP lease expires and I am given a new IP address of 126.96.36.199 5. My server detects the change and automatically registers myhome.dyndns.org to 188.8.131.52 6. My old DHCP address, 184.108.40.206 is given to Bob Evil's computer. 7. Alice finishes filling out a web form in Mozilla and submits it. Mozilla erroneously uses the cached IP address 220.127.116.11, and the data is incorrectly sent to Bob Evil's computer. The information sent may be stored in the HTTP log or may generate errors. Private cookies that allow the Bad Guys to forge Alice's session or impersonate Alice will also be sent. This bug also creates two major usability problems for Mozilla: 1.) I run a server from home on my DSL line. My IP address changes periodically, so I use a dynamic DNS service like dyndns.org. This allows me to use the same fully-qualified domain name that always maps to my home server. It works perfectly in every single application *except* Mozilla, which gives "Could not connect to server" errors because it caches DNS entries forever. Shutting down the browser works, but it makes everyone think that my server is actually down. No other browser has this problem. This happens quite commonly with a dynamic IP address. I've ended up hitting other peoples' DSL routers (if they have no web site set up) instead of my own server with Mozilla, even though I've registered a new IP address, and DNS lookup gives the proper new address. 2.) Load-balanced or fail-safe corporate server farms that use round-robin DNS are actually made *less* reliable using Mozilla's DNS caching mechanism. If one server is overloaded, taken down, or crashes, Mozilla is unable to connect using the old, expired DNS entry. This is one reason that some companies don't like to use Mozilla. It makes it appear that their web servers are down, when they're actually available all the time due to clever fail-over and DNS-based load balancing.
Dupe of bug 162871. See also bug 151929 comment 7 : the 'pinning' is the result of some security fix a while ago.
Oop, I misread. This was split off bug 162871 ofcourse. BTW : my daytime job is for a for telecommunciations manufacturer (I'm the developer of one the largest access servers in the world). Our software also shows this 'pinning' behaviour for a very good reason : security. We monitor remote clients and servers continuously for any change. We're not even fully respecting the TTL, we'll query the real DNS-server at least once an hour just to be sure if we can catch any change in address (TTL is basically useless if it's too large). But the difference is that we're *not* going to switch to the new ip-address directly. We could easily have a DNS-server that was hijacked (already happened), or that was misconfigured (happens even more :-). No, if the ip-address is changed, we'll warn the operators to double-check if the change is allowed (the remote address is controlled by a another network provider). I agree that we have a problem with load-balancing webservers and webserver with multiple addresses. We really should try all existing ip-addresses before deciding that a webserver is unreachable. But when the ip-address of your webserver changes (when we fixed bug 151929), we should *not* use the new address automatically. What we should do is to warn the user that the ip-address is changed, and ask permission to continue. This should especially happen when we're in the middle of a transaction !
That behavior would cause a lot of user confusion. Most users don't even know what DNS is; they will be annoyed to be prompted with warnings they don't understand. When companies use products like Cisco DistributedDirector, DNS information for a given hostname can change often. I really don't think we want to pop an error or warning every time a user runs across this.
No, load balancing wouldn't be affected, you get only the warning when a DNS-lookup changes to a completely different address, most likely because it dynamic DNS address. A name that maps to 2 or more ip-addresses (poor-man load balancing) won't trigger such a dialog. A hardware ip-switch hides several servers behind 1 static ip-address - that won't change. A redirector that uses regualar http-redirects to implement load-balancing (like used by Hotmail) won't be affected. If you really hate these dialogs to pop up, then I guess you want to remove those security popups that occur on https-sites too (untrusted certificate, etc...). I only want an extra dialog-box to warn me when an ip-address changes, so we can avoid the Princeton exploit (see bug 149943), while avoiding the security problem I see almost every week in my daytime job. The black-hat community is really using these exploit to attacks access-servers all over the Internet. Holding an ip-address in memory forever is a security problem, but allowing it to be transparently changed is a security problem too!
DistributedDirectors can and do change the IP address returned for a given hostname on a regular basis (with a short TTL on the A record). That is one of their features, and people do use it. It WILL cause your proposed dialog to be triggered under normal circumstances. If the SSL cert matches, you're fine (or you have bigger problems). If you're not using SSL, you have no assurance that you're talking to who you think you're talking to anyway. There's no security to begin with when you're relying on DNS alone.
This problem manifests itself at http://www.techtv.com/ which sends rather short-lived TTL information for its A record. After going for food and trying to reload a page, I got "could not connect to server" errors. From packet-sniffing my connection, I could see that Mozilla was trying to use an incorrect IP address that did not match authoritative DNS data. Other browsers worked fine. Restarting Mozilla fixed the problem.
This bug also occured today on the extremely popular sites http://www.amazon.com/ and http://us.imdb.com/ These sites use Coyote Systems Equalizer which tends to hand out DNS records with a TTL of about 60 seconds. Verified via packet sniffer that Mozilla was not sending to the authoritative IP address as returned by DNS. Repeatedly got "could not connect to server" error. Other browsers were able to connect.
I'm curious as to how the current security "fix" improves matters any. If the DNS record is already compromised when you start up Mozilla, then this will "pin" to the compromised address for the whole time Mozilla is running. If the DNS server gets "uncompromised," you'll be pinned to the evil server and never pick up the right one! There is no reason to believe that the address returned at whatever random moment you first did a DNS lookup of a site is secure and other subsequent times would be more insecure. The "security fix" seems valueless, as it is based on flawed assumptions. The timing is completely random, based on the time you start Mozilla. This is the worst type of "security fix," one that not only leads to a false sense of security, but is simply unable to improve security, and a violation of standards, and opens other, more common security holes and usability problems that don't require evil intent. The "security fix" should simply be removed as its benefit is purely illusory.
> please correct me if I'm wrong You are wrong. www.evil.com and evil.com are totally distinct for security purposes; the only way for one to access the other is if they both set document.domain to evil.com.
>> please correct me if I'm wrong > You are wrong. www.evil.com and evil.com are totally distinct > for security purposes; the only way for one to access the other > is if they both set document.domain to evil.com. I am sorry, I need to insist. According to the documentation at <URL:http://www.mozilla.org/projects/security/components/same-origin.html>, in my example, the attacker on http://www.evil.com could legally set document.domain="evil.com"; making his evil pages' equivalent origin the *same* as the origin of the $victim's internal server at http://evil.com, eventually allowing him access. I hope I'm not still mistaken with this extended description. Thank you for replying during your vacation, btw.
Boris is right, both pages have to set document.domain="evil.com" explicitly (even if that's the implicit value for one of the sites) in order to prevent just the attack you propose. This was not always the case and old documentation may not have caught up. IE 6.0 SP1 reportedly also made the change to require both pages to have set document.domain explicitly. That's a completely different problem so please don't drag it into the discussion on DNS pinning.
*** Bug 205148 has been marked as a duplicate of this bug. ***
Note that the patch in bug 205726 (nsDnsService rewrite) contains a preference to disable DNS pinning (default remains enabled).
ok, now that the patch for bug 205726 has landed, DNS pinning is now a think of the past. this bug is fixed (note: on the trunk only).