Here's how DNS lookups work:

1. An application on your device wants to get to www.example.com
   
2. It consults something on your device called a "resolver" to ask for the IP address
   
3. The resolver looks to see if it already knows it. If it does: It returns it to the app. Otherwise...
   
4. The resolver then asks one of what it's told are the DNS servers to ask. If they know the answer they return it to the device requesting it. Otherwise...
   
5. They then go out to what are called the "root nameservers" for the Internet and ask "What DNS servers are authoritative for example.com?"
   
6. One of the root nameservers replies "Here are the IP addresses of the DNS servers that are authoritative for that domain."
   
7. The DNS server in Step 4 chooses one of them and asks it "What's the IP address for www.example.com?"
   
8. That server returns the IP address to the DNS server requesting it, which returns it to the resolver on the device, which returns it to the app.

Each DNS record has associated with it a Time To Live (TTL). It may be minutes, hours, days, what-have-you. It is specified by the DNS server that is authoritative for the domain. That TTL is relative to when the answer was returned. Thus, if the A (address) record for www.example.com has a TTL of an hour, I request it at 09:00 and you request it at 09:30: It will expire for me at 10:00 and for you at 10:30.

If...

• At Step 6 the root nameservers don't have an answer (e.g.: Because there's no "whois" record for the domain), or
  
• At Step 7 none of the nameservers authoritative for the domain answers (not reachable [route failure], they're down, being DDoS'd, etc.), or
  
• At Step 7 the nameservers authoritative for the domain don't have a record for the hostname in question...

... a lookup failure code will be returned down-line ("SERVFAIL")

What this all means, in the context of the current discussion, is the only time somebody will experience the problem bald1, walkinghorse, and I have seen is if

• sigforum.com's A record (address record) has expired in our devices' resolver caches, and
  
• that A record has also expired in our specified DNS servers' caches, and
  
• at just that moment, there's a problem reaching the authoritative DNS servers for sigforum.com

This has happened several times to me over the last month or so while browsing sigforum.com. It's also happened several times when SIGforum attempted to deliver email to me, as witnessed by these...

Aug 22 14:32:48 <myhost> postfix/policy-spf[16963]: ... SPF-Result=sigforum.com: 'SERVFAIL' error on DNS 'TXT' lookup of 'sigforum.com'
Aug 31 13:27:47 <myhost> postfix/policy-spf[7725]: ... SPF-Result=sigforum.com: 'SERVFAIL' error on DNS 'TXT' lookup of 'sigforum.com'
Aug 31 13:45:32 <myhost> postfix/policy-spf[8299]: ... SPF-Result=sigforum.com: 'SERVFAIL' error on DNS 'TXT' lookup of 'sigforum.com'
Sep  2 05:37:05 <myhost> postfix/policy-spf[7616]: ... SPF-Result=sigforum.com: 'SERVFAIL' error on DNS 'TXT' lookup of 'sigforum.com'
Sep  6 16:40:33 <myhost> postfix/policy-spf[19520]: ... SPF-Result=sigforum.com: 'SERVFAIL' error on DNS 'TXT' lookup of 'sigforum.com'
Sep  7 07:35:53 <myhost> postfix/policy-spf[10519]: ... SPF-Result=sigforum.com: 'SERVFAIL' error on DNS 'A' lookup of 'sigforum.com'

It's not my ISP, my LAN, my browsers or other software, my devices, the phase of the moon, or whatever. I operate an authoritative, multi-view, recursive nameserver for my own LAN and domain and have for years--just as I did for my employer for over twenty-five years. I daresay this is a subject in which I have more than a little expertise

quote:

Originally posted by Greymann:
Samsung here, never any issues.
I don't know if this matters but chrome now leaves all tabs open. Started last spring, so now you have to close all tabs yourself. Maybe this is your issue.

I don't use Chrome