Does anyone else think that its a bit odd that if it were simply "DNS problems" that a redirect for www.google.com would end up at a location which provided this: http://img179.echo.cx/img179/7959/googlehacked7to.jpg [or] http://img241.echo.cx/img241/6208/googlemsn3lp.png Seems more than simple "DNS problems" to me. I hate being played like an idiot.... - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
On Sun, May 08, 2005 at 02:18:19AM +0000, Fergie (Paul Ferguson) wrote:
Does anyone else think that its a bit odd that if it were simply "DNS problems" that a redirect for www.google.com would end up at a location which provided this:
All of the "hack" evidence is from people looking at a whois query and fretting over: Server Name: GOOGLE.COM.SUCKS.FIND.CRACKZ.WITH.SEARCH.GULLI.COM IP Address: 80.190.192.24 Registrar: KEY-SYSTEMS GMBH Whois Server: whois.rrpproxy.net Referral URL: http://www.key-systems.net Server Name: GOOGLE.COM.HAS.LESS.FREE.PORN.IN.ITS.SEARCH.ENGINE.THAN.SECZY.COM IP Address: 209.187.114.130 Registrar: INNERWISE, INC. D/B/A ITSYOURDOMAIN.COM Whois Server: whois.itsyourdomain.com Referral URL: http://www.itsyourdomain.com We've been over this before, whois queries also return nameservers, which people take advantage of.
http://img179.echo.cx/img179/7959/googlehacked7to.jpg
[or]
http://img241.echo.cx/img241/6208/googlemsn3lp.png
Seems more than simple "DNS problems" to me.
I hate being played like an idiot....
- ferg
Wow, one person being redirected to a competitors site, ever heard of spyware? (Yes, even on a Mac) -- Matthew S. Hallacy FUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
At 02:18 AM 08-05-05 +0000, Fergie (Paul Ferguson) wrote:
Does anyone else think that its a bit odd that if it were simply "DNS problems" that a redirect for www.google.com would end up at a location which provided this:
http://img179.echo.cx/img179/7959/googlehacked7to.jpg
[or]
http://img241.echo.cx/img241/6208/googlemsn3lp.png
Seems more than simple "DNS problems" to me.
I hate being played like an idiot....
I really like Google. I like what they do. But lately, their security team is a joke. I had a problem with their POP Gmail service and the advise I got from their Gmail team was to turn off my CA EZ antivirus and my ZApro firewall and to try again and see if the problem repeats itself. For a moment I thought it was an April 1st joke. When playing with Gmail or Ggroups - try to find a link to report abuse or a security problem (yes - one exists - but not one that is easy to find from Gmail or Ggroups). I attribute it to size - when one gets big enough - one truly believes that gravity is affected by your company. Unless Google shapes up, they will quickly find out what happens to large, cumbersome, and clueless companies. -Hank
- ferg
Hank Nussbacher wrote,
I really like Google. I like what they do. But lately, their security team is a joke. I had a problem with their POP Gmail service and the advise I got from their Gmail team was to turn off my CA EZ antivirus and my ZApro firewall and to try again and see if the problem repeats itself. For a moment I thought it was an April 1st joke.
When playing with Gmail or Ggroups - try to find a link to report abuse or a security problem (yes - one exists - but not one that is easy to find from Gmail or Ggroups).
I attribute it to size - when one gets big enough - one truly believes
that
gravity is affected by your company. Unless Google shapes up, they will quickly find out what happens to large, cumbersome, and clueless companies.
Well I am not a DNS expert but why Google have the primary gmail MX record without load balancing and all secondaries are sharing the same priority level. I have a server that relay usenet messages to my gmail account and here is a week worth of stats showing how google mail servers are handling incoming mails: Total Number of messages sent to gmail: 1945 messages of which: 1888 (97%) messages were gated through Gmail's Primary mail server (gmail-smtp-in.l.google.com). 21 messages were gated through Gmails Secondary (gsmtp171.google.com) 13 messages were gated through Gmail's Secondary (gsmtp171-2.google.com) 10 messages were gated through Gmail's Secondary (gsmtp185-2.google.com). So in short, 97% of the email was delivered through the primary while the secondaries only served 3%. My question why they do not make all mail servers at the same priority level instead of current which load balance the Secondaries only. BTW mx records for google gmail are: MX 5 gmail-smtp-in.l.google.com. MX 10 gsmtp171.google.com. MX 10 gsmtp185.google.com. MX 10 gsmtp171-2.google.com. MX 10 gsmtp185-2.google.com. MX 20 gsmtp57.google.com. each have 1 minute TTL. -aljuhani
On 5/8/05, aljuhani <info@riyadmail.com> wrote:
Well I am not a DNS expert but why Google have the primary gmail MX record without load balancing and all secondaries are sharing the same priority level.
Has it occured to you that there are other ways of load balancing mailserver clusters than just setting MX records? -- Suresh Ramasubramanian (ops.lists@gmail.com)
Suresh Ramasubramanian wrote:
On 5/8/05, aljuhani <info@riyadmail.com> wrote:
Well I am not a DNS expert but why Google have the primary gmail MX record without load balancing and all secondaries are sharing the same priority level.
Has it occured to you that there are other ways of load balancing mailserver clusters than just setting MX records?
And actually it's quite common to have only one MX record today if the secondaries have no clue of the valid recipients. (to avoid queueing bounces) Pete
On 8 May 2005, at 17:07, aljuhani wrote:
Well I am not a DNS expert but why Google have the primary gmail MX record without load balancing and all secondaries are sharing the same priority level.
Huh ? [...]
1888 (97%) messages were gated through Gmail's Primary mail server (gmail-smtp-in.l.google.com).
gmail-smtp-in.l.google.com is at least two machines, but much more likely to be at least two clusters of machines ... : ;; ANSWER SECTION: gmail-smtp-in.l.google.com. 232 IN A 64.233.185.27 gmail-smtp-in.l.google.com. 232 IN A 64.233.185.114 .. load-balanced in some way. One MX record doesn't mean one machine and no load-balancing by any means. -- Regards, Andy Davidson http://www.fotoserve.com/ Great quality photo prints, gifts and clothing from digital photos.
On 8 May 2005, at 21:13, Andy Davidson wrote:
gmail-smtp-in.l.google.com is at least two machines, but much more likely to be at least two clusters of machines ... :
;; ANSWER SECTION: gmail-smtp-in.l.google.com. 232 IN A 64.233.185.27 gmail-smtp-in.l.google.com. 232 IN A 64.233.185.114
.. load-balanced in some way. One MX record doesn't mean one machine and no load-balancing by any means.
Yes you are right .. perhaps I did not put my point right when I mentioned load balancing, I was trying to see the affect of DNS outage on Gmail Services. -aljuhani
Hank Nussbacher wrote:
I really like Google. I like what they do. But lately, their security team is a joke. I had a problem with their POP Gmail service and the advise I got from their Gmail team was to turn off my CA EZ antivirus and my ZApro firewall and to try again and see if the problem repeats itself. For a moment I thought it was an April 1st joke.
While I know exactly what you mean, I run POP service for several tens of thousands of mailboxes, and broken antivirus scanners that insert themselves between the mail client and the server are now our leading cause of "my mail program can't read messages any more" support questions. By far. And the second most common cause is -- wait for it -- broken personal firewall systems that have apparently gone insane and decided to block a port for no explainable reason (we actually see this with POP, SMTP, and FTP). So when the basic "are your hostname, username and password correct?" check doesn't help, we now tell our customers to try exactly what Google told you, as long as they have XP service pack 2 (our incoming mail is already virus scanned). Depressingly often, doing so fixes the problem. -- Robert L Mathews, Tiger Technologies http://www.tigertech.net/
participants (8)
-
aljuhani -
Andy Davidson -
Fergie (Paul Ferguson) -
Hank Nussbacher -
Matthew S. Hallacy -
Petri Helenius -
Robert L Mathews -
Suresh Ramasubramanian