8 hrs and counting

[morty]

I submitted a ticket 8 hrs ago and it still has yet to be resolved. Mind you this is NOT a new or difficult issue - it is a recurring issue and I have pointed out the solution and tech support still doesnt get it

unbelievable

Greg, are you reading this? Please do something about getting this taken care of once and for all

ticket number is 13463450

[JPC-Masood]

I submitted a ticket 8 hrs ago and it still has yet to be resolved.

When you submit a ticket it can take time to resolve the issue depending on the complexity of the issue. You may think its same issue and you know the solution to it but it is not always the case. I see your ticket is being worked on by techs.

[morty]

I have seen and experienced this problem so many times (because JAG fAILS TO ACTUALLY DO ANYTHING ABOUT MONITORING AND/OR MAKING SURE SETTINGS ARE OPTIMIZED) that I want to gag.

Unfortunately, now that Rizwan is gone, noone seems to have any idea how to fix this, even though the problem has gone (for the time being anyow). It was I who originally had to identify the general source of the problem while fighting tech support. Rizwan was at least able to take it from there.

JAG needs to pay more attention to the DNS server settings. I was given assurances that this would be done but I continually have to put in tickets. I know the symptoms and it is the same each time.


UPDATE: It appears I was mistaken - it wasn't fixed at all

[Ron]

Morty,
Do you know what kind of DNS issue are you seeing?

[morty]

Morty,
Do you know what kind of DNS issue are you seeing?

My programs and website rely on resolving canonical names for various reasons, including security and monitoring. When there are difficulties resolving these names, my site slows down, and monitoring becomes next to impossible at times. Rizwan tracked the problem to the DNS server settings. Beyond that I couldn't tell you exactly what he did though he said something about swapping and resetting priorities.

[JPC-Masood]

Name server resolver has been changed on your server. Please check now.

[Ron]

My server experienced a similar problem for a long, long time. I also have a security product that does various lookups including gethostbyname(). Further, when the issue was happening I'd be swamped with SPAM as spamassassin couldn't do its lookups either.

When it was happening, logging onto the server via SSH would take 20 seconds (it must do some sort of a dns lookup!). Even issuing a simple

wget google.com

command would take about 30 seconds to complete. (first it would try to resolve google.com then it would get a redirect to www.google.com. Both took 15 seconds to accomplish.

Restarting the DNS resolver seemed to fix the problem in the immediate time frame. I don't know if they ever fixed the problem directly, I didn't have the issue in quite some time. Also, a couple of months ago a tech decided to change the default DNS server to google's open DNS server at 8.8.8.8.

Hope something about this helps.

[morty]

Name server resolver has been changed on your server. Please check now.

Thanks

What I want to know is WHAT IS JAG GOING TO DO TO PREVENT THIS FROM CONTINUALLY REOCURRING????????

[JPC-Masood]

Thanks

What I want to know is WHAT IS JAG GOING TO DO TO PREVENT THIS FROM CONTINUALLY REOCURRING????????

We'll upgrade our local resolver and add more resolvers to distribute the load.

[Ron]

Masood,

Is the resolver "named"?
If so...

How does this work? Does named lookup in a config file and find an IP addy for a DNS server?
I assume that my old issue wasn't one of the DNS server not working (my visitors are being served OK), then any idea why was my server pointed at google's DNS?

This may have been done while investigating another problem on my server, as I have an outstanding (2 months) DNS issue with WHM. The zones I can edit in WHM are apparently old, out of date and not consistent with what is on JAG's public-facing DNS, so I can't edit or add to a public DNS server. In fixing this issue I'd be very concerned that this incorrect zone file would be accidentally put into production, I'd guess that production needs to be copied to the editable zone file before that zone file is pointed back to production.

[JPC-Masood]

named is binary that can act as a resolver on behalf of others or authoritative resolver for a particular domain. In the context of this thread the resolvers are what you get from your ISP as well to resolve domains. Without those resolvers computers/servers will not able to resolve domains to IPs. Same type of resolvers are required for hosting servers. When you do "wget google.com" it needs a resolver to resolve google.com to IP.

How they work is that resolver have IP addresses of root servers in a config file. When the resolver receives a request it asks one of the root server to provide name server of the TLD. In case of google.com it will receive .com TLD servers. Then it will ask one of the .com TLD servers to provide name servers of google.com, and once it gets them it will ask for IP. If you try

dig +trace google.com

you can see it in action:

# dig +trace google.com

; <<>> DiG 9.3.4-P1 <<>> +trace google.com
;; global options:  printcmd
.                       37512   IN      NS      g.root-servers.net.
.                       37512   IN      NS      a.root-servers.net.
.                       37512   IN      NS      h.root-servers.net.
.                       37512   IN      NS      k.root-servers.net.
.                       37512   IN      NS      e.root-servers.net.
.                       37512   IN      NS      d.root-servers.net.
.                       37512   IN      NS      b.root-servers.net.
.                       37512   IN      NS      l.root-servers.net.
.                       37512   IN      NS      i.root-servers.net.
.                       37512   IN      NS      f.root-servers.net.
.                       37512   IN      NS      c.root-servers.net.
.                       37512   IN      NS      j.root-servers.net.
.                       37512   IN      NS      m.root-servers.net.
;; Received 228 bytes from 4.2.2.2#53(4.2.2.2) in 21 ms

com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
;; Received 488 bytes from 192.112.36.4#53(g.root-servers.net) in 112 ms

google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.
;; Received 164 bytes from 192.35.51.30#53(f.gtld-servers.net) in 58 ms

google.com.             300     IN      A       74.125.45.105
google.com.             300     IN      A       74.125.45.99
google.com.             300     IN      A       74.125.45.103
google.com.             300     IN      A       74.125.45.147
google.com.             300     IN      A       74.125.45.104
google.com.             300     IN      A       74.125.45.106
;; Received 124 bytes from 216.239.34.10#53(ns2.google.com) in 13 ms

All this action is being done by resolvers and depending on cache it can return the result without doing all those queries for each request. "+trace" above makes sure to do direct queries. Pretty helpful in diagnosing DNS issues.

Your DNS issue in WHM or any problem with zone file of your domains is not related to those resolvers. Those name servers used by your domains are not generic resolvers and are not used for resolving domains outside its authority (e.g. google.com).

Have you opened a support ticket to have that issued looked into? What you see in WHM DNS edit is what should be in public facing resolver for your domains. Unless you have DNS zone hosted on shared named servers while you are editing reseller name servers? or something like that.

[Ron]

Thanks Masood. I think I got most of that.

I haven't opened a ticket on that directly, it was being worked by a Level 3 tech, and was put on hold as another solution (me moving my sites) is/was being looked at. One of the problems with my moving the sites to another account is I'm afraid the WHM move process will grab the WHM zone file that is outdated/broken. So I'm not going to move before this problem is resolved. I don't know if it affects just my account or all reseller accounts on the box.

I am afraid to have "just any" tech look at this issue because I don't know what all of the entries are in the WHM-accessible zone file, I don't know when they are from. I know I found them pointing at the "wrong" nameserver (they were pointing to nocdirect instead of my "private nameserver") and if they get put into production I'm afraid that things will get hosed.

Also I guess I'm still confused about why dig shows that 8.8.8.8 is being used as the primary nameserver;
Didn't dig used to point to the local namneserver?
Does this mean that the "root" server in named's config file is pointing to 8.8.8.8?

$ dig ibm.com

; <<>> DiG 9.2.4 <<>> ibm.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63034
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ibm.com.                       IN      A

;; ANSWER SECTION:
ibm.com.                4699    IN      A       129.42.38.1

;; Query time: 2 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Dec 16 17:33:23 2011
;; MSG SIZE  rcvd: 41

Yeah, Back when I first had this problem ( DNS: Edited DNS zone, added a subdomain but not resolving )

Well now it gets even more problematic.

nslookup ns1.privatenameserver.org
Server:         69.73.181.166
Address:        69.73.181.166#53

Non-authoritative answer:
Name:   ns1.privatenameserver.org
Address: 64.22.65.220

Compared to now:

nslookup ns1.privatenameserver.org
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   ns1.privatenameserver.org
Address: 64.22.65.220

[JPC-Masood]

8.8.8.8 is showing up because the server where you ran this command has that as one of the resolvers.

[Ron]

8.8.8.8 is showing up because the server where you ran this command has that as one of the resolvers.

OK, what I originally asked was:

Does named lookup in a config file and find an IP addy for a DNS server?

What I got was a nice lesson in DNS resolving, which was great! But it left me still wondering about the basic question I asked. Part of that answer was:

named is binary that can act as a resolver on behalf of others or authoritative resolver for a particular domain.
[...]
How they work is that resolver have IP addresses of root servers in a config file.

So I'm still wondering... When you say "they" have an IP address of a "root server", do you really mean that in named's configuration file someone has put 8.8.8.8 as the primary address to use for resolution of DNS requests? Or are we talking about two completely different things, because I wouldn't think that 8.8.8.8 is considered a "root server".

Part of this is I'm trying to understand why this was changed during the attempt to fix the fact that the WHM zonefiles are not the same as what is seen by the nameservers.

[Main Street James]

I submitted a ticket 8 hrs ago and it still has yet to be resolved. Mind you this is NOT a new or difficult issue - it is a recurring issue and I have pointed out the solution and tech support still doesnt get it

unbelievable

morty,
You're not alone. We've had several problems that have been recurring or not properly address on the first, second, third, fourth, etc, etc ... time that we report them. At the moment we've been going down several times a day for the past 11 days and get a different diagnosis and excuse every time (that is if they tell us anything at all).

We had one problem that caused our Apache server to crash repeatedly throughout the day that lasted 72 days. We opened multiple tickets along the way and placed several phone calls. Our correct diagnosis and supporting detail was simply ignored until our public complaints got someone from JPC tech support to actually look at the log entries we submitted (they never did accept the detailed system snapshots we offered).

Nagging and chronic issues seem to be the norm ... at least until you start making noise in some public forums. That's what seems to get someone to look at the details and actual problem you're reporting. It's unfortunate that it has to take that route, but that has been my repeated experience with JPC tech support.