
how-to block ads
|
 packet8SPT
join:2005-07-06 Santa Clara, CA
1 edit | Response from Packet8
Packet8 just emailed the following explanation and resolution procedure for correcting the Register.com DNS failure:
At 7 pm last night (January 22, 2008) Register.com changed the DNS for »www.packet8.net and »www.packet8.com by omitting the DNS and substituting a landing page in its place. The net result was call failures and the inability to reach Packet8's website. Our telephones and DTAs have several hard coded fail-over processes built into them. However, due to the landing page put up by Register.com, the end points were given a false signal of success and did not fail over to the backup IP addresses built into each device.
Within minutes Packet8 engineers saw the issue, contacted Register.com and got the issue resolved with proper routing instructions broadcast to all DNS servers on the Internet.
Most Internet Service Providers updated to the correct DNS routing instantly. However, we have reports that ATT, ATT-Mobile and Time Warner Roadrunner on the East coast have not updated DNS servers with the correct information.
If you are having issues with the Packet8 service or reaching our self-service portal, please provide the solutions below to renew the DNS information in your modem, router, and computers.
If the solutions do not work, your ISP may be providing outdated DNS information. Please call Packet8 support with the following information and we will contact your ISP regarding the issue.
Call Packet8 Support at 1-888-898-8733 or, if outside the US, call 1-408-687-4120
Solutions:
1. Point the DNS server settings of your Packet8 endpoints and telephones to 63.209.12.18 or set your routers DNS settings to Open DNS with 208.67.222.222 and 208.67.220.220.
2. Edit your hosts file to force »www.packet8.net to 63.209.12.100
3. Provide a network power cycle with step by step instructions shown below
Network Power Cycle:
Power cycling the entire network refreshes and re-syncs all network devices with the most current network information broadcast from the ISP.
1. Unplug power from the back of all network devices (modem, router, & Packet8 device) & shutdown any computers. Then wait one minute.
2. Plug the power cord back into the modem and wait one minute to let the modem synchronize with the ISP. (Check for ONLINE/Internet light)
3. Plug the power cord back into the Router and wait one minute.
4. Plug the power cord back into the Packet8 device and wait 30 seconds
5. Check the Packet8 phone for a dial tone. Also, the PHONE LED on the Packet8 device should come light up when the receiver is picked up or turned on.
6. Check lights: solid POWER LED & an occasionally flickering LINK LED
If no dial tone, turn on a computer and make sure the customer can browse the internet.
Clear computer of old DNS information:
(Windows) Start --> Run --> type in: cmd --> type in: ipconfig /flushdns (Mac 10.4-) command: lookupd -flushcache (Mac 10.5+) command: dscacheutil -flushcache | |   FRAK PACKET8
@rr.com | awesome, thanks...best response yet! | |   Anonymous Coward
@optonline.net
| reply to packet8SPT said by packet8SPT :Packet8 just emailed the following explanation and resolution procedure for correcting the Register.com DNS failure:... However, due to the landing page put up by Register.com, the end points were given a false signal of success and did not fail over to the backup IP addresses built into each device. And that is nevertheless your failure for failing to a.) entrust register.com with servicing all of your domains, and b.) designing a proper, SECURE service mechanism: your software is unable to tell that the server it is talking to is not the "real you"? Ever heard of SSL/TLS and signed certificates?
So in the current state, every botnet/trojan that changes a Windows hosts file (which you yourself advocated as a temporary workaround) with a www.packet8.com entry (or certain others controlling service for your client) can disrupt service for your endusers, or worse, possibly redirect the SIP clients to wherever the attackers want them to point to? I sure hope for everyone's sake that that condition does NOT apply here.
said by packet8SPT :Within minutes Packet8 engineers saw the issue, contacted Register.com and got the issue resolved with proper routing instructions broadcast to all DNS servers on the Internet. That is the most ridiculous, uneducated, mis-leading and patently false description of how DNS supposedly works I have ever heard. You honestly think you can make people believe that you can broadcast information to every single one of the millions of nameservers on the Internet? And that your problem is just that a lot of them are not listening to you? We wonder why!
There is no "broadcast". There's only "pull" - from client resolvers to authoritative servers of your domains. Too bad the DNS records register.com's DNS servers were dispensing for that period were the wrong ones - there is no possible recall of that information during the TTL (time-to-live) period that was attached to those bad records THE MOMENT THEY WERE SERVED.
said by packet8SPT :Most Internet Service Providers updated to the correct DNS routing instantly. However, we have reports that ATT, ATT-Mobile and Time Warner Roadrunner on the East coast have not updated DNS servers with the correct information. This second statement, once again, is uneducated, misleading, patently false and of defamatory character: there's nothing these ISPs are doing wrong, and there is no action required on their part. Period. They got served (only obvious to you: bogus) DNS records with a set TTL (time-to-live) by register.com for your domains, and they are PROPERLY SERVING THESE RECORDS to their subscribers for the ENTIRE DURATION OF THAT TTL. And only after that TTL has expired, will they re-resolve these names/records, if one of their subscribers requests DNS resolution for them. You got a problem with the TTL and what register.com dished out on your behalf, you say?
I have no doubt in my mind, and firmly believe that these falsehoods are intentional on Packet8's part: throw up a smoke screen, blame register.com, blame the ISPs, blame everyone else but yourself for this shooting yourself in the foot bigtime - starting with a single point of failure. You probably regret entrusting register.com with your service by now, as it was (from the description) register.com that temporarily suspended service to the domains, but started to serve bogus DNS records for both the nameservers (NS records) and hostnames (A records) for the domains (with a TTL of unknown duration):
register.com permitted themselves to do this in the fine print of your contract with them maybe, but it was nevertheless service-disrupting in a big way for you: learn how to read the fine print already: you could have picked a registrar that doesn't try to generate revenue by leeching click-through traffic by putting up their own NS/A records in place of your own the moment a domain is suspended or expires: a patently dishonest "monetization scheme" in my humble opinion. Now imagine what happens if a large DNSBL's domain is suddenly shut down this way...and the world's email begins to bounce (a lot of it), as every DNS request is answered with an IP number (of the landing page's server), indicating an active blocklisting condition (and don't get me started on replies other than 127.x.x.x that should not be treated as such)....
said by packet8SPT :If the solutions do not work, your ISP may be providing outdated DNS information. Please call Packet8 support with the following information and we will contact your ISP regarding the issue. And you expect ISPs big and small to clear their collective 1000's of recursive caching DNS servers JUST for you, after this ridiculous finger-pointing and blame-game you're trying to play here? Cache invalidations/reloads in the middle of the business day, that are impairing server performance for millions of users and millions of other domains that are working fine?
I can tell you exactly where you'd get with this over here: we'd laugh hysterically until we'd hang up on you - followed by us instructing customer service what to tell complaining customers: that we are aware that packet8 has a DNS problem of their own making, which will probably resolve itself in "the next 24 hours" - and to feel free to call back tomorrow, if the problem hasn't resolved itself. I have a good idea who they're going to call next. | |   butercon
@comcast.net
| These guys are losers plain and simple. Their JV, to say the least. Look at the CEO and all his garbage with the financials every quarter. Then, take a look at the highly incompetent Board of Directors (all of which should have been retired 30 or so years ago).
Add all these up and what you have are a bunch of wanna-be executives who want to run your phone service.
Buyer beware. These guys are clowns. | |   VOIPJedi
join:2009-01-23
| reply to Anonymous Coward Good Job Anonymous Coward, you went straight to the heart of the issue. Obviously Packet 8 hates their customers with a passion. Why else would they bother to post on this website the troubleshooting fix necessary to restore service. Nothing about this outage points to a vicious scam against anyone yet you seem eager to jump on very circumstantial evidence in order to make an isolated incident seem much worse than it is.
The nature of the service Packet 8 and other VOIP companies provide does make them susceptible to general networking and internet issues. This does not mean though that these companies are indifferent when an issue like this occurs. VOIP users need to understand that these issues will sometimes be inevitable but any good service based company will be able to work through most issues quickly and efficiently. | |
-
|