DB connection is doing a DNS lookup

I have an application coded in Java which checks the oracle database if any new record is added.
so the line of code for eastablishing the conection is :
java.sql.Connection conn = � DriverManager.getConnection ( "jdbc:oracle:thin:@10.3.7.197:1521:DEV", "lot3","lot3" );
the application checks the database every 2 mins for any new records.
everytime the appln tries connecting to the DB, it is doing a DNS lookup. IS there any way to stop this DNS lookup?
the appln is running on AIX Unix machine.
Can anybody please help me?

I have an application coded in Java which checks the
oracle database if any new record is added.
so the line of code for eastablishing the conection
is :
java.sql.Connection conn =
DriverManager.getConnection (
"jdbc:oracle:thin:@10.3.7.197:1521:DEV",
"lot3","lot3" ); Wow, what a wasteful way to do it.
>
the application checks the database every 2 mins for
any new records.
everytime the appln tries connecting to the DB, it
is doing a DNS lookup. IS there any way to stop this
DNS lookup?Stop your application.
Maybe a better solution would be to pool database connections. That would amortize the cost of acquiring the connections.
Who writes the records in your database? If it's another application outside your Java app you're out of luck, but if it's just other objects inside your app I'd recommend that you take better advantage of the Java Beans event model and have writers notify others when they've written to the database. It's far less wasteful of resources.
he appln is running on AIX Unix machine.
Can anybody please help me?

Similar Messages

GWIA doing DNS lookup for local address

Hello,
I am running GW8.0.2 on Netware 6.5sp8. I have a server that our recreation department uses to send out confirmation emails when a customer signs up for a class. The recreation server and the GWIA are on the same subnet.
Here's the problem: When the Rec server sends out the first email confirmation, it gets sent out successfully. Subsequent emails after that fail. After about twenty minutes the next email will go out OK again but subsequent emails will fail.
The verbose logs on the GWIA don't tell me much but the diagnostic logs show what looks like a reverse DNS lookup happening at the GWIA for my local IP address of 10.0.0.3 (the Rec server). This reverse DNS lookup fails (probably a timeout) and subsequent emails from this local Rec server get dropped by the GWIA without the DNS lookup.
DNS is being done by DNS proxy on Bordermanager 9.2. I've bypassed the Bordermanager DNS and the same thing happens. I've made entries for the local Rec server into a route.cfg file but the GWIA seems to want to ignore these entries and keeps doing the DNS lookup.
The wierdest part of the puzzle is that if I restart the proxy on the Bordermanager the next email will go out with, of course, subsequent emails failing. I've looked at the proxy dns cache and can't even find an entry for my Rec server.
Attached are the entries from the Diagnostic logs of the GWIA. Novell tech support has assured me that the GWIA and the BM are working fine. I am also having this problem with a scanner that scans then emails but all other email and Bordermanager are functioning fine. This server and scanner were not having this problem before upgrading to GW8.0.2.
I don't understand why GWIA is doing DNS lookups for a local address and I don't know what I can do to stop it. Any help would be greatly appreciated.
This is a successful transfer right after restarting the proxy: 10.0.0.3 is the Rec server, 10.0.0.130 is the GWIA and 10.0.0.1 is the Bordermanager.
16:04:13 D15 NgwResQuery(3.0.0.10.in-addr.arpa, 1, 12)
16:04:13 D15 Querying server (# 1) address = 10.0.0.1
16:04:13 D15 HEADER:
16:04:13 D15 opcode = QUERY, id = 17615, rcode = SERVFAIL, flags: qr aa rd
16:04:13 D15 query = 1, answer = 0, authority = 0, additional = 0
16:04:13 D15
16:04:13 D15 QUESTIONS:
16:04:13 D15 3.0.0.10.in-addr.arpa, type = PTR, class = IN
16:04:13 D15
16:04:13 D15 rcode = 2, ancount=0
16:04:13 D15 NgwResQuery failed
16:04:13 D15 DMN: MSG 2000909 Accepted connection: [10.0.0.3] ()
16:04:13 D15 Successful login with client/server access: 10.0.0.130:1677
16:04:13 D15 DMN: MSG 2000909 Receiving file: ECMAIL/SYS:\PROGRAMS\GRPWISE\WPGATE\GWIA\3RD\receive\df30 fad4.221
16:04:13 D15 DMN: MSG 2000909 SMTP session ended: [10.0.0.3] ()
This is an unsuccessful transfer:
16:06:08 D04 timeout
16:06:08 D04 NgwResQuery: send error
16:06:08 D04 NgwResQuery failed
16:06:08 D04 DMN: MSG 2000933 Accepted connection: [10.0.0.3] ()
16:06:08 D04 DMN: MSG 2000933 SMTP session ended: [10.0.0.3] ()
Then the successful email comes back into the system:
16:06:26 AA8 MSG 2000909 Processing inbound message: ECMAIL/SYS:\PROGRAMS\GRPWISE\WPGATE\GWIA\receive\DF30FAD4 .221
16:06:26 AA8 MSG 2000909 Sender: [email protected]
16:06:26 AA8 MSG 2000909 Recipient: [email protected]
16:06:26 AA8 MSG 2000909 Queuing to MTA
16:06:26 AA8 MSG 2000909 File: ECMAIL/SYS:\PROGRAMS\GRPWISE\WPGATE\GWIA\wpcsin\4\4daf048 2.8m1 Message Id: (4DAF66F2.B67:244:35687) Size: 163.3 Kb

Thanks Massimo. I could have swore I already did that but when I did it again just to make sure it solved the problem. Appreciate the help. Have a good one.
Originally Posted by mrosen
On 02.05.2011 21:06, avanrav wrote:
>
> Hello,
>
> I am running GW8.0.2 on Netware 6.5sp8. I have a server that our
> recreation department uses to send out confirmation emails when a
> customer signs up for a class. The recreation server and the GWIA are on
> the same subnet.
>
> Here's the problem: When the Rec server sends out the first email
> confirmation, it gets sent out successfully. Subsequent emails after
> that fail. After about twenty minutes the next email will go out OK
> again but subsequent emails will fail.
>
> The verbose logs on the GWIA don't tell me much but the diagnostic logs
> show what looks like a reverse DNS lookup happening at the GWIA for my
> local IP address of 10.0.0.3 (the Rec server). This reverse DNS lookup
> fails (probably a timeout) and subsequent emails from this local Rec
> server get dropped by the GWIA without the DNS lookup.
>
> DNS is being done by DNS proxy on Bordermanager 9.2. I've bypassed the
> Bordermanager DNS and the same thing happens. I've made entries for the
> local Rec server into a route.cfg file but the GWIA seems to want to
> ignore these entries and keeps doing the DNS lookup.
>
> The wierdest part of the puzzle is that if I restart the proxy on the
> Bordermanager the next email will go out with, of course, subsequent
> emails failing. I've looked at the proxy dns cache and can't even find
> an entry for my Rec server.
The reverse DNS done by GWIA is normal, and can't be stopped or tricked.
That it fails in such odd ways must be a bug with the reverse DNS proxy
of Bordermanager though. Apparently on the second lookups, it doesn't
answer in a timely manner (the type of answer is irrelevant, just it
*has* to answer). Use a different, "real" DNS server for your GWIA.
CU,
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
Untitled Document

DNS lookups without DNS server

Hi Community,
some user in a German forum are reporting a functional DNS resolution without a configured DNS name server. Is there a hidden feature in the actual Snow Leopard release which make this possible?
Thx & Bye Tom

Kiwi Graham wrote:
Sounds like an oxymoron to me - doing a DNS lookup without DNS?
Yes, I agree.
It is certainly possible to store a set of local mappings, but it'd be a subset of the domain universe and it'd also be static. So further resolution would have to go out to a DNS server.
I thought that maybe it could be possible that there is an internal fallback server configured. But it seems that it isn't, because should this be a fact, more user should know this.
More information?
No sorry. I asked both user to make a tcpdump on port 53 to determine the answering DNS server but I got no response. But thanks for your attention
Bye Tom

9i app 9.0.2.01?Does the reverse DNS lookup have to be set up for a FQDN

HEy guys:
I'M ALWAYS GETTING STUCK IN THE SAME PLACE WHEN I AM TRYING TO INSTALL 9I APPSERVER 9.0.2.0.1 REL 2. ITS ALWATYS HAPPENING AT THE oRACLE db CONFIG assistant i have set up my host file and when i ping -a servername i get the full reply back ex. servername.domain.com but now when i ping -a 111.111.111.111 i do not get the host name back this is b/c i do not have the PTR record set up. Do i have to have a reverse dnslookup working for what oracle is stating is "FQDN" and not just the dns lookup working...how is oracle installer looking at this piece.
that is the only i see that i don't have when i look at my computer name (by the way this is a winnt environment)in properties it has the FQDN. i also have set up the host file correctly resembling 111.111.111.111 servername.domainname.com servername oracleinstall. What else am i missing here guys? thanks for the help in advance
regards,
robert

Actually, these issues were/are documented - see the addendum. Also, the install guide details which files need to be updated with the FQDN/IP.
Though it does not have to be setup in your DNS server (say if you are just doing it on a single tier to test), those machines which are looking to connect to it would need to have the proper additions to the hosts file as well.
As for why the 'non-default' http ports, this was a result of Unix security. Non-root users cannot start processes using ports below a specific range. As a result, oracle defaults them to a higher number allowing your oracle account whom lacks root access to start the http service.
As for non-oracle responses, this isn't really an official forumn. I believe those oracle peeps who do respond here are doing so on their own. If you need official/immediate responses, then i would recommend using metalink for an itar or the metalink forums.
Now on to Robert's second question. See metalink Note:209114.1: How to Change the Port used for Oracle 9iAS Portal 9.0.x. If you don't have access to metalink, let me know and I can forward the note or post it here.
Have fun!

Slow DNS Lookups after connecting via PPP VPN

I have this very annoying problem and just can't seem to find a method to resolve it.
When I connect to my work network via a PPP VPN connection, all internet connectivity thereafter takes forever to do a DNS lookup. So when I browse the internet it takes ages before the page is displayed back.
If I also do a ping in finder for a random URL, www.google.com for example, it sits there for nearly a minute before I get a response. If I then immediately perform the ping again, I get a response straight away. So it seems once it's resolved the domain name, it gets stored in a cache somewhere. If I try another domain name, I get the same delay and then it eventually gets through.
As soon as I close the VPN connection, service is resumed and DNS lookups work fast.
I've also made sure I've unchecked the option to "Send all traffic over VPN connection".
I've also set my 'Service Order' to have my wireless Airport connection in the No #1 position.
The other thing I've tried is deleting the default route (via Terminal) and adding one manually that points to my wireless router, again without success.
Does anyone have any other ideas I could try? I've also recently re-installed a fresh copy of Leopard in case something was stuffed up, but the problem is still there after installation.
Hoping someone has an easy solution!
Many thanks

I seem to have found a work-around. There is probably a neater way of doing this but here goes.
Here is my setup:
Airport Wireless to my home router
PPP VPN connection to my office windows network
3G connection via mobile phone
My aim was to be able to connect to my office network via wireless at home or via my cellular data connection, but continue to route all non-work traffic via the main connection (wireless/3G).
The #1 problem I had once I connected to my office VPN on either wireless or 3G, was that DNS lookups to general internet sites took forever. So to get around this, I created TWO VPN connections to my office network in Network Preferences and in both connections I made sure the option to send all traffic over VPN was left UNCHECKED.
The first connection I then designated for use when connecting wirelessly at home. Here I manually added the IP address of my home router as a DNS entry.
The second connection I did the same by adding a new DNS entry, except here I used the DNS server of my cellular data connection, in this case T-Mobile UK.
When connecting to my office network I just use either of the above connections depending on whether I am connecting wirelessly at home or via my mobile phone.
It seems a bit long winded I grant you, but after literally months of trying to resolve this annoying problem, this appears to be the only fix that works.
The downfall of this would be that DNS resolution to any servers on your office network might not work, but that isn't a problem for me since I manually add any servers I use at work to my local hosts file. This negates any need for DNS lookups and actually speeds up access to my work servers.
In amongst this I did several reboots, so you give your machine a reboot once you've completed the above steps, just in case.
The 3G connection won't work for you if your provider changes the DNS server every time you connect, but this is unlikely.
If anyone's got any comments, I'd love to hear them.
Cheers
Phil

MBP - Too Long doing DNS lookups?

I've noticed that my brand-new MBP seems to take an excessively long time to do DNS lookups. I'll load Firefox and type in google.com in the URL bar. In the status bar below it will say "looking up google.com" for at least 10 seconds. Meanwhile, I've opened a terminal window and done an nslookup on google.com and received the IP address. Any idea why I can do a quick lookup in the terminal but the browser takes quite awhile?

Change your DNS servers in the network system preferences.
Use Verizon's Level 3 servers.. they're very fast
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6
Or the OpenDNS servers:
208.67.222.222
208.67.220.220

Wireless Intermittent Super Slow DNS lookup bug in 10.6.4

I don't normally post things on forums these days, as usually I can find just about any solution by searching long enough, but this issue has perplexed me to the point I actually had to come on here.
Believe me, that's a big deal, I don't give up easily.
I have spent -countless- hours searching, on here, on google, on any "solutions" or "technical" sites I could find, and the closest I can find to a solution are countless people complaining about the EXACT SAME PROBLEM that I have observed and, repeatedly, reproduced again and again, which in every single case boil down to this:
You had 10.6.x (x being 3 or less) with a wireless connection on your home network and all is well.
You upgraded to 10.6.4 and all seemed fine for maybe 24 hours or so... then it happens. You go to load a website, and it's "looking for site" or "waiting for site" in your status bar... hmm, maybe it's just this site you say, so you try another, or a few others in other tabs, but they all have the same problem.
You try to ping the sites, but the network utility can't resolve the domain to even ping them.
Your roommate, all the while, is surfing and gaming just fine on the exact same router you are on, so no, it's not the network hardware, it's not your ISP, hmm, what could it be?
All of a sudden, ALL of the sites you had in like 20 tabs load up at screaming speeds, "WOW" you say, "guess there must have just been some gunk in the wires or something" (notice the irony of the situation: no wires)... anyway, all seems fine again suddenly, surfing is fine for a few minutes, you're back to normal... and it happens again, suddenly NO site will resolve, NO dns will resolve, you can't check email or ping any domain... and so the cycle begins. Of course, you can just plug an ethernet cable straight into the router, but doesn't that kind of defeat the purpose of having wireless networking in the first place?
It continues like this, indefinitely, and it all starts roughly 24 hours after 10.6.4 has been installed.
I have read reports of people on macbooks, people on imacs, people on all sorts of different wireless hardware, but the symptoms are the same.
I know the problem is with the OS update, it's purely software. I know that it has nothing to do with hardware because simply reverting to 10.6.3 solves the problem -every single time- and then "upgrading" to 10.6.4 causes the problem to come back within 24 hours -every single time- (have been reverting using Time Machine to simplify this testing process), so no, where the problem is isn't what perplexes me; what perplexes me is that there are posts that started almost a few days after 10.6.4 came out, and so far there's STILL no fix? Are you freaking serious? Does the Apple programming team not have access to anything other than Apple-Branded Airport Extreme Base Stations to perform wireless network QA testing on?
Get a Linksys guys, grab a D-Link, go get some of the hardware people actually USE and test it on that and see what happens, it doesn't take long to see what's happening.
I blame the programmers because I am one myself and know how easy it is to screw up a rock-solid system with one little typo. Heck, which patch was it, 10.5.7 or 10.5.8 I think? Can't remember exactly, but it was supposed to be such a great "bug fix" patch... and it came with the config file for Apache set to DENY ALL INCOMING EXTERNAL CONNECTIONS by default (in a hidden file that can only be modified by the root user mind you... so much for the average user running a personal web server on THAT version), so yeah, one tiny mistake and it has huge consequences, my question is: what's taking so long to track down what's going on in 10.6.4 and fix it? Can we at least get a patch or something?
I find it really lame and really such a cop-out to see so many irrelevant "solutions" offered, "try specifying different DNS servers" (doesn't matter, whatever causes this bug doesn't care which servers you have specified, it simply sits there and does NOTHING for 2-3 minutes, and THEN when it actually DOES do a dns lookup, it gets the results in the time expected: instantly), to more extreme matters, like resetting hardware, which again has absolutely nothing to do with this bug.
Here is why anyone can see this is an obvious bug that the programming team needs to admit, investigate and correct:
A. happens immediately after the software update
B. happens to EVERYONE who uses traditional wireless routers for internet use
C. is 100% repeatedly reproducible
D. occurs on all different models of computers and all different ISP's and with all different DNS servers specified.
E. has the same symptoms on every system (lightning fast internet for 2-3 minutes, then "waiting for site" for 1-3 minutes)
F. affects EVERY network-using program on the computer (email, network utility, firefox, safari) SIMULTANEOUSLY
G. does not affect surfing to or interacting with IP addresses directly, only with trying to perform DNS lookups from ANY program with ANY dns server (or no dns server) set in network preferences.
Come on guys, just read it through, think about it for a few minutes, for anyone that has worked with and knows the underlying source code, and what changes went in between 10.6.3 and 10.6.4 specifically to networking, should have a light bulb pop up over their head and say "oh YEAH, we never uncommented that one line..." or something to that effect.

I see a very similar issue, but it's been occurring on my laptop for 4 or 5 months, which must be way before 10.6.4. My roommate and friend's laptops all work fine on my network. And my laptop works fine on anyone else's network. But MY laptop on MY network always gives the abysmal DNS performance as described in the original post: 40% of requests time out. Wireless or wired, it doesn't matter. Exact same behavior.
It also doesn't matter whether I use my Netgear router as DNS server, or my ISP, or OpenDNS, or Google. Exact same behavior.
When I do a network trace, it looks like most DNS requests my computer sends out simply never get responded to. (Could they be malformed when they hit the wire? I don't even see an error reply) A few make it through. And when there's a IPv6 (AAAA) record sent, my computer returns a "port unreachable" ICMP message. A screenshot of all of this dialogue is here:
http://img545.imageshack.us/i/screenshot20100913at114.png/
I recently had opportunity to cancel my cable service, and reinstate it for a lower price. They came out, tested the line (strong signal), gave me a new cable box. Yet the issue persists. Exact same behavior.
Firewall is disabled. I've deleted the network interfaces and added them back. Nothing helps.
(As I recall, this issue may even have been present before I reinstalled 10.6 over 10.5, so I'm not too confident a total reinstall would help.)
Any help? I'm about ready to buy a new laptop to fix this damned problem. Web browsing is nearly impossible, as is.

DNS lookups to VPN hijacked by WRVS4400N (fw v1.1.13)?

I have a WRVS4400N on the latest firmware offered by Cisco. After a whole run of problems with previous firmware, this one seems to be almost perfect except for this odd issue I've been encountering now (that I hadn't encountered on previous firmware).
It seems as though DNS lookups through the WRVS4400N are being redirected through a different DNS from the one set on the client (presumably, the router is taking all outbound UDP DNS queries and 'fixing' them to direct at the WAN DNS).
I've verified this by using the 'host' command in UNIX (where 192.168.2.140 is the DNS server on the remote VPN network):
1) Using a standard UDP DNS lookup from the LAN (192.168.1.0) to the VPN
$ host test.intranetdomain.com 192.168.2.140
Using domain server:
Name: 192.168.2.140
Address: 192.168.2.140#53
Aliases:
Host test.intranetdomain.com not found: 3(NXDOMAIN)
2) Using a TCP DNS lookup from the LAN to the VPN
$ host -T test.intranetdomain.com 192.168.2.140
Using domain server:
Name: 192.168.2.140
Address: 192.168.2.140#53
Aliases:
test.intranetdomain.com has address 192.168.2.5
3) Using a standard DNS lookup to an unassigned IP on the local LAN
$ host test.intranetdomain.com 192.168.1.250
;; connection timed out; no servers could be reached
4) Using a standard DNS lookup to a nonsense internet IP
$ host test.intranetdomain.com 254.254.254.254
Using domain server:
Name: 254.254.254.254
Address: 254.254.254.254#53
Aliases:
Host test.intranetdomain.com not found: 3(NXDOMAIN)
These tests are pretty revealing:
Test #1 shows a standard DNS query as a client system would typically perform it. It's querying the server and the server is returning that the address I've asked it for is not known. This is unexpected behaviour as the server at that IP address definitely knows test.intranetdomain.com exists.
Test #2 shows that if queried using TCP instead of UDP, the DNS does know test.intranet.domain.com exists. So, is the host command in Test #1 actually talking to my server? It doesn't seem so.
Test #3 is a demonstration of the expected response when host cannot talk to a remote DNS or that server doesn't exist. In this case, I'm using host to query an IP on my LAN that doesn't have anything on it. This should be the response I get when I try to query a nonexistent server on the internet as well.
Test #4 shows that in spite of the expected responses in Test #3, the WRVS4400N doesn't act as expected. It shows the same type of response we saw in Test #1 even when querying non-existent IPs.
In summary, the tests show that the WRVS4400N in firmware 1.1.13 is capturing all standard UDP DNS queries regardless of the IP they're directed to, and forwarding them to another DNS (I assume the WAN DNS).
This seems like it may have been thrown in as an unmentioned 'feature' and is behaviour I might expect from a 'home' routing solution but not a small office solution such as this. My company VPN requires DNS to be resolved by our servers inside the office network so this is not acceptible.
Configuration Details:
WAN: DHCP, dynamic IP, dyndns
LAN: defaults for everything, static DNS set to use servers across the VPN
VPN: IPSec tunnel to remote network 192.168.2.x
IPS: Disabled
Firewall: Defaults
Any assistance or commentary from someone in-the-know would be appreciated. Also, any comments from those also experiencing variations on this issue.
Message Edited by litui on 03-10-2009 06:25 PM

I've experienced the same DNS hijacking unable to use OpenDNS features unless I set the outside interface to static which is really DHCP by my cable provider. Of course, this is only a temporary work-around. Linksys/Cisco could allow for selectable DNS on the outside interface to resolve this problem, but they won't even look at a code change... unless EVERYONE complains. I requested this almost a year ago via a TAC case & their reaction was development almost never update unless they get many requests.

Do CNAME records result in a second DNS lookup

Hi,
I am trying (with no luck) to find out if Windows 8 client receives a CNAME record, Does Windows 8 understand how to deal with this record ? I mean, Does the CNAME record results in a second DNS lookup ?
Thanks,
Rami

DNS lookups which point to a CNAME record only result in a single lookup from the client end, but technically they're an A record lookup (since the client doesn't know before hand whether it's an A record or CNAME record they're querying).
Say you have a CNAME record for cname.mydomain.com which points to
www.otherdomain.com and that in turn has an A record pointing to 123.123.123.123.
The client queries DNS requesting the A record for cname.mydomain.com. The DNS resolver does the lookup, and discovers that it's a CNAME record. At this point it does a second lookup (without going back to the client) for the IP address of
www.otherdomain.com, and then finally once it has that information it passes those details back to the client which it then uses to connect to the relevant resource.
You can see it for yourself. In a cmd prompt if you run nslookup, then type "set q=a", then enter the full CNAME address you're trying to resolve. You'll see the output will appear as :
Name:      www.otherdomain.com
Address:   123.123.123.123
Aliases:    cname.mydomain.com

DNS lookup speed.

DNS lookup seems to be quite variable and (IMHO) overly long at times.
No hard evidence, but since we are locked into BT DNS (HH5, BT infinity) it
seems quite important.
Does the same lockin apply if a user switches to their own modem/router?

Hi pe2dave,
Thanks for posting. Sorry you're having problems with the connection. We'll need to take a closer look at this for you so can you drop me an email with the details? You'll get the 'contact us' link in my profile.
Cheers
David
BTCare Community Mod
If we have asked you to email us with your details, please make sure you are logged in to the forum, otherwise you will not be able to see our ‘Contact Us’ link within our profiles.
We are sorry but we are unable to deal with service/account queries via the private message(PM) function so please don't PM your account info, we need to deal with this via our email account :-)

DNS Lookup Timeout Problems with Cisco SA520w

Hello,
We are trying to configure our new Cisco SA520w with our Internet connection.
As soon as we replace our existing Linksys RV042 with the Cisco SA520w, we find that DNS lookups start to take longer and longer to resovle. For example, an nslookup against yahoo.com will timeout, or take 10-12 seconds. Web browser requests simillarly take 30-45 seconds to resolve.
We've tried using both Google's and OpenDNS servers, as well as our ISP's nameservers. In all cases, the long DNS resolution takes place.
At first we thought that the firewall was misconfigured. However, we removed all firwall rules, and continued to experience the problem.
We've tried checking and unchecking the DNSProxy checkbox, but this doesn't seem to have any noticeable impact.
Does anyone have any idea about which setting impact DNS looksups, or what else we might try to troubleshoot this issue?
Thanks,
Chris

Regarding the question on 5-10 days for product support to become active, I followed up with the CA team and received the following, which is good for All partners to know...
Below is a description of the primary cause of delays in contract registration.
Contract registration takes 24-48hrs. Delays are generally caused by the Reseller/Partner who doesn't provide the product serial numbers to Cisco when they purchase the service. The contract cannot be registered until the Reseller or the Disti provides the serial numbers to Cisco via SMS3 (or B2B). In cases where Disti doesn't have a mechanism to collect the serial number before the product is shipped, or in cases of drop-ship, the Distis often have to track down their Resellers to get the serial numbers to Cisco.
There is a new program being discussed (drawing board now, so not available today) which will to allow the end-user to register the contract themselves, thus eliminating the need for the Disti or the Reseller to collect the serial number an input it into SMS3.
But in any case (now or later), when a customer calls in for support, if their contract has not yet been registered, the SBSC can work with the Global Entitlement Team to look-up the contract via the PO or SO number and complete the registration so service can be provided.
Hope this helps...
Steve

DNS lookup failing on Macbook with Fios

Hello all
I've had Verizon Fios for over a year and had no problems connecting wirelessly to my MacBook. Out of the blue today, both my MacBook and my brother's began to have issues accessing the internet. Every attempt would yield the same response:
This webpage is not available
The server at google.com can't be found, because the DNS lookup failed. DNS is the web service that translates a website's name to its Internet address. This error is most often caused by having no connection to the Internet or a misconfigured network. It can also be caused by an unresponsive DNS server or a firewall preventing Google Chrome from accessing the network.
Here are some suggestions:
Reload this web page later.
Check your Internet connection. Reboot any routers, modems, or other network devices you may be using.
Check your DNS settings. Contact your network administrator if you're not sure what this means.
Try disabling network prediction by following these steps: Go to Wrench menu > Preferences > Under the Hood and deselect "Predict network actions to improve page load performance." If this does not resolve the issue, we recommend selecting this option again for improved performance.
Try adding Google Chrome as a permitted program in your firewall or antivirus software's settings. If it is already a permitted program, try deleting it from the list of permitted programs and adding it again.
If you use a proxy server, check your proxy settings or check with your network administrator to make sure the proxy server is working.
If you don't believe you should be using a proxy server, try the following steps: Go to Applications > System Preferences > Network > Advanced > Proxies and deselect any proxies that have been selected.
Error 105 (net::ERR_NAME_NOT_RESOLVED): Unable to resolve the server's DNS address.
I called Verizon for support, and while their reset of my internet has allowed me to connect directly from a ethernet cord from my router, I'm still getting the same result on any attempts to connect via wi-fi. Since Verizon decided it was a Mac issue and not a Verizon issue at this point, they pointed me in the direction of applecare, but I don't have the money to spend right now on a support call.
It seems that the router is connecting to the internet, and I can connect through ethernet, but their is a problem with the wireless communication between my computer and the router. Any suggestions?

That is a different issue. Most likely, your university IT has misconfigured their network and only tested it on Windows where little details like TCP/IP subnets aren't even checked. This sounds pretty typical for university IT. Unfortunately, you will have zero luck getting them to fix the problem because they don't support MACS.
First of all, your question is pretty important and shouldn't be tucked inside a Verizon FiOS thread where no one will see it. I suggest starting a new question so that people looking for this topic in the future can find the answer.
I am familiar with this problem. It is an IT configuration problem. I just rolled my own hack for it. I should probably try to improve my hack since obviously other people are experiencing the same problem.
Before I get started. Why are you even looking? What is the exact problem that you are having? My problem was specific to VPNs but your issue seems even more basic than that. What, exactly, does or does not happen to cause you to search for a fix?
In the Terminal, run the command "scutil list". How many DNS entries are listed? What are they? You should have one that says "State:/Network/Global/DNS". Type "show State:/Network/Global/DNS". What does it return? Are these the DNS servers that you added?
Let me know the respones to the above and then I can craft a command that will correct and possibly override those servers properly.

Airport Extreme DNS lookups stalling; creating page load delays

As of the last few days, maybe a week, I've noticed my Airport Extreme (the most recent version, tall squarish one) has been getting slow at random times. Nothing on the network locally would be causing it. The slowness appears to be in DNS lookups... you know, that bit the browser does behind the scenes to turn google.com into 173.194.37.4. At first I thought it was just a slow DNS server setup we had configured in the Airport (8.8.8.8 and 8.8.4.4) but I've switched them to something that performs a bit better (if you can call 12 ms vs 14 ms lookups, "better", lol).
The issue manifests itself over wired and wireless computers connected to the Airport.
We also have a airport express (the short squarish one, newest model) that is setup for the purposes of creating a roaming network. Another thought was maybe it flipped over to try to issue IPs, so I looked to ensure it was on the proper settings, and it is.
The software on the airport management client (in windows) and the airport extreme + express are updated. I have already tried to reset them from scratch and reconfigure, to no avail.
Interestingly, what leads me to believe it's related to DNS Lookups is, when I am experiencing the issue, if I download a file - say a really large file, just to test, the download speed is as it should be from my ISP. But if you try to browse to any ole page, apple.com, google.com, arstechnica.com, or sites that are generally really quick, like msn.com or wsj.com, it would be faster to tap it out in stone.
We're experiencing this on a interesting set of devices, Windows 7 and 8 computers, an iPad, a Android tablet, android phone, iPhone, and a Windows phone.
Does anyone have any suggestions? I've found a few older threads with similar issues, but they are outdated and/or seem to chalk it up to a bug and Apple needs to fix via update. This is just super frustrating.

Hi tbonecopper,
If you feel you are having DNS-related slowness on your Airport Extreme, you may find the following article helpful (it is written with a computer focus, but the same principles should also apply at the router):
Non-responsive DNS server or invalid DNS configuration can cause long delay before webpages load
http://support.apple.com/kb/ts2296
Regards,
- Brenden

[SOLVED] Slow DNS lookup, I think

Hi
I have a really annoying problem. My DNS lookup in Arch is painfully slow. I know it's not a network problem, as I don't have any problems in my Ubuntu installation. I have tried to run two simple tests to show you what I mean. The first is a simple ping google.
########### Ubuntu ###########
carsten@carsten-laptop:~$ time ping -c 3 www.google.com
PING www.l.google.com (216.239.61.104) 56(84) bytes of data.
64 bytes from sn-in-f104.google.com (216.239.61.104): icmp_seq=1 ttl=245 time=17.4 ms
64 bytes from sn-in-f104.google.com (216.239.61.104): icmp_seq=2 ttl=245 time=20.6 ms
64 bytes from sn-in-f104.google.com (216.239.61.104): icmp_seq=3 ttl=245 time=11.4 ms
--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 11.465/16.529/20.641/3.809 ms
real 0m2.290s
user 0m0.000s
sys 0m0.004s
########### Arch ###########
carsten ~/Desktop $ time ping -c 3 www.google.com
PING www.l.google.com (216.239.61.104) 56(84) bytes of data.
64 bytes from sn-in-f104.google.com (216.239.61.104): icmp_seq=1 ttl=245 time=12.3 ms
64 bytes from sn-in-f104.google.com (216.239.61.104): icmp_seq=2 ttl=245 time=10.7 ms
64 bytes from sn-in-f104.google.com (216.239.61.104): icmp_seq=3 ttl=245 time=12.4 ms
--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 10.776/11.867/12.476/0.778 ms
real 0m15.305s
user 0m0.013s
sys 0m0.007s
Ubuntu: 0m2.290s vs. Arch: 0m15.305s.
In the second test I tried to fake a pacman update by downloading the .db files from my primary server. On both Ubuntu and Arch I used this simple script
repos=( core extra community )
time for repo in ${repos[@]}
do
wget http://archlinux.unixheads.org/$repo/os/i686/$repo.db.tar.gz
done
When I run it in, I get this result
########### Ubuntu ###########
carsten@carsten-laptop:~/Desktop$ ./updatetest
--2008-11-10 07:58:23-- http://archlinux.unixheads.org/core/os/i686/core.db.tar.gz
Resolving archlinux.unixheads.org... 204.152.186.174
Connecting to archlinux.unixheads.org|204.152.186.174|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 32515 (32K) [application/x-gzip]
Saving to: `core.db.tar.gz'
100%[=============================================================>] 32.515 --.-K/s in 0,1s
2008-11-10 07:58:23 (331 KB/s) - `core.db.tar.gz' saved [32515/32515]
--2008-11-10 07:58:23-- http://archlinux.unixheads.org/extra/os/i686/extra.db.tar.gz
Resolving archlinux.unixheads.org... 204.152.186.174
Connecting to archlinux.unixheads.org|204.152.186.174|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 422622 (413K) [application/x-gzip]
Saving to: `extra.db.tar.gz'
100%[=============================================================>] 422.622 242K/s in 1,7s
2008-11-10 07:58:25 (242 KB/s) - `extra.db.tar.gz' saved [422622/422622]
--2008-11-10 07:58:25-- http://archlinux.unixheads.org/community/os/i686/community.db.tar.gz
Resolving archlinux.unixheads.org... 204.152.186.174
Connecting to archlinux.unixheads.org|204.152.186.174|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 369845 (361K) [application/x-gzip]
Saving to: `community.db.tar.gz'
100%[=============================================================>] 369.845 206K/s in 1,8s
2008-11-10 07:58:27 (206 KB/s) - `community.db.tar.gz' saved [369845/369845]
real 0m3.837s
user 0m0.016s
sys 0m0.036s
########### Arch ###########
carsten ~/Desktop $ ./updatetest
--2008-11-10 08:01:33-- http://archlinux.unixheads.org/core/os/i686/core.db.tar.gz
Resolving archlinux.unixheads.org... 204.152.186.174
Connecting to archlinux.unixheads.org|204.152.186.174|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 32515 (32K) [application/x-gzip]
Saving to: `core.db.tar.gz'
100%[==============================================================================>] 32,515 --.-K/s in 0.1s
2008-11-10 08:01:47 (303 KB/s) - `core.db.tar.gz' saved [32515/32515]
--2008-11-10 08:01:47-- http://archlinux.unixheads.org/extra/os/i686/extra.db.tar.gz
Resolving archlinux.unixheads.org... 204.152.186.174
Connecting to archlinux.unixheads.org|204.152.186.174|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 422622 (413K) [application/x-gzip]
Saving to: `extra.db.tar.gz'
100%[==============================================================================>] 422,622 253K/s in 1.6s
2008-11-10 08:02:02 (253 KB/s) - `extra.db.tar.gz' saved [422622/422622]
--2008-11-10 08:02:02-- http://archlinux.unixheads.org/community/os/i686/community.db.tar.gz
Resolving archlinux.unixheads.org... 204.152.186.174
Connecting to archlinux.unixheads.org|204.152.186.174|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 369845 (361K) [application/x-gzip]
Saving to: `community.db.tar.gz'
100%[==============================================================================>] 369,845 262K/s in 1.4s
2008-11-10 08:02:17 (262 KB/s) - `community.db.tar.gz' saved [369845/369845]
real 0m44.153s
user 0m0.047s
sys 0m0.017s
Ubuntu: 0m3.837s vs. Arch: 0m44.153s
I get the same update time whenever I update pacman normally.
I have googled a lot to figure out an answer, but nothing helps, so I was hoping somebody could help me figure this out, as it's very annoying. My hosts file looks like this
hosts:
# /etc/hosts: static lookup table for host names
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost.localdomain localhost arch
# End of file
rc.conf:
# /etc/rc.conf - Main Configuration for Arch Linux
# LOCALIZATION
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# USEDIRECTISA: use direct I/O requests instead of /dev/rtc for hwclock
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
LOCALE="en_US.utf8"
HARDWARECLOCK="UTC"
USEDIRECTISA="no"
TIMEZONE="Asia/Singapore"
KEYMAP="dk"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
# HARDWARE
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
MODULES=(e100 mii iwl3945 fuse acpi-cpufreq cpufreq_ondemand cpufreq_conservative cpufreq_powersave loop !pcspkr !snd_pcsp)
# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"
# NETWORKING
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
HOSTNAME="arch"
# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
# - prefix an entry in INTERFACES with a ! to disable it
# - no hyphens in your interface names - Bash doesn't like it
# DHCP: Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"
eth0="dhcp"
INTERFACES=(!eth0 !wlan0)
# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
# - prefix an entry in ROUTES with a ! to disable it
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
# Enable these network profiles at boot-up. These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
# - set to 'menu' to present a menu during boot-up (dialog package required)
# - prefix an entry with a ! to disable it
# Network profiles are found in /etc/network.d
# This now requires the netcfg package
#NETWORKS=(main)
# DAEMONS
# Daemons to start at boot-up (in this order)
# - prefix a daemon with a ! to disable it
# - prefix a daemon with a @ to start it up in the background
DAEMONS=(syslog-ng !network hal !netfs crond fam wicd cups laptop-mode oss gdm)
SPLASH="splashy"
Thanks in advance!
Last edited by Sharpeee (2008-11-15 10:39:42)

Just tried to remove the "search..." line from my /etc/resolv.conf file, but nothing! It's okay if I remove the line after it connects right? Wicd overwrites the file anyways if I reconnect.
I don't really think changing to a different network-manager will help me. It works perfectly fine in Ubuntu with both network-manager and wicd, do don't think that's the problem. It must be a configuration file somewhere.
#### EDIT ####
I just tried to disable wicd and enable the wired network in /etc/rc.conf. After a reboot and it's still the same, even on the wired, so it's got be some other settings somewhere that's messing things up!
Also, for some reason my theme, in Gnome, isn't loaded after I disabled wicd? I have to manually run "gnome-appearance-manager"??
Last edited by Sharpeee (2008-11-11 05:01:46)

DNS lookup failed. How to fix with Google chrome?

"The server at _____.com can't be found, because the DNS lookup failed. This error is often caused by having no connection to the internet or a misconfigured network. It can also be caused by an unresponsive DNS server or a firewall preventing google chrome from accessing the network."

Is Safari the same?

DB connection is doing a DNS lookup

Similar Messages

Maybe you are looking for