Estranho. Tudo começou a funcionar de novo - como mágica.
Temos um problema muito estranho com o DNS nas instâncias do EC2. Um aplicativo que estamos executando em algumas de nossas instâncias é o serviço baseado em Java que fornece um back-end para um aplicativo Android. Como parte de sua funcionalidade, ele envia notificações por push para telefones por meio de uma API do Google. Para isso, é necessário fazer uma solicitação SSL para android.apis.google.com . Infelizmente, ao executar isso em nossas instâncias do EC2, recebemos um erro de certificado porque o nome do host não corresponde ao nome do certificado:
hostname in certificate didn't match: <android.apis.google.com> != <.gstatic.com> OR <gstatic.com> OR <.gstatic.com>
Rastreamos o problema para uma diferença nos resultados do DNS. Quando consultamos DNS para android.apis.google.com em nosso escritório (onde tudo funciona), recuperamos o seguinte:
android.apis.google.com. 300 IN CNAME clients.l.google.com.
clients.l.google.com. 160 IN A 74.125.226.230
clients.l.google.com. 160 IN A 74.125.226.231
clients.l.google.com. 160 IN A 74.125.226.232
clients.l.google.com. 160 IN A 74.125.226.233
clients.l.google.com. 160 IN A 74.125.226.238
clients.l.google.com. 160 IN A 74.125.226.224
clients.l.google.com. 160 IN A 74.125.226.225
clients.l.google.com. 160 IN A 74.125.226.226
clients.l.google.com. 160 IN A 74.125.226.227
clients.l.google.com. 160 IN A 74.125.226.228
clients.l.google.com. 160 IN A 74.125.226.229
Quando executamos a mesma consulta em um servidor EC2, recuperamos um conjunto diferente de resultados de DNS:
android.apis.google.com. 300 IN CNAME clients.l.google.com.
clients.l.google.com. 300 IN A 72.14.204.138
clients.l.google.com. 300 IN A 72.14.204.100
clients.l.google.com. 300 IN A 72.14.204.101
clients.l.google.com. 300 IN A 72.14.204.102
clients.l.google.com. 300 IN A 72.14.204.113
Alguma idéia de por que os resultados do DNS seriam tão dramaticamente diferentes no EC2? E, mais importante, como podemos corrigir isso?
Nós tentamos usar um validador de nome de host personalizado. Segundo nossos desenvolvedores, isso permitiu que a conexão prosseguisse, mas o problema é que ela está conectada ao servidor errado, então a solicitação ainda falha.
O Google tem muitos e muitos IPs e eles veiculam os IPs que estão geograficamente mais próximos de onde eles acham que estão localizados.
Quando eu dig contra o DNS público do Google em 8.8.8.8 , recebo a mesma lista do EC2:
[] csternal@~: dig @8.8.8.8 android.apis.google.com
; <<>> DiG 9.6-ESV-R4-P3 <<>> @8.8.8.8 android.apis.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38592
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;android.apis.google.com. IN A
;; ANSWER SECTION:
android.apis.google.com. 300 IN CNAME clients.l.google.com.
clients.l.google.com. 300 IN A 72.14.204.102
clients.l.google.com. 300 IN A 72.14.204.113
clients.l.google.com. 300 IN A 72.14.204.100
clients.l.google.com. 300 IN A 72.14.204.101
clients.l.google.com. 300 IN A 72.14.204.138
;; Query time: 83 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Mar 15 11:38:13 2012
;; MSG SIZE rcvd: 145
O problema que você está encontrando parece ser este: link
The solution most commonly given to resolve the error message you are receiving is to define a custom Hostname validation. The main problem that you are facing is that the domain name returned by Google's Android URL is .google.com. Unfortunately, this causes some issues as the Android SDK is at android.apis.google.com. The JVM will not validate this combination by default (.sdk.google.com would be acceptable).
Here is an example of how you can create your own hostname validator:
URL url = new URL("https://android.apis.google.com/c2dm/send"); HostnameVerifier hVerifier = new HostnameVerifier() { public boolean verify(String hostname, SSLSession session) { return true; } }; HttpsURLConnection conn = (HttpsURLConnection) url.openConnection(); conn.setHostnameVerifier(hVerifier);
Pode ser um problema proveniente da plataforma de DNS do Amazon EC2 (problema de atualização) ou um problema de resultados de armazenamento em cache proveniente de ambos, o "Virtual plateform" ou a plataforma da Amazon.