MEO - Tópico Oficial

Porque será que a MEO queira bloquear os DNS 1.1.1.1 e 8.8.8.8 ?
O que ganham com isso?

Não ganham nada, logo é estranho.

Da informação que tenho, apenas uma parte da rede (mais propriamente um dos Nós de LX - 195.8.30.237) foi afectada por esta situação, e que está tudo OK com a ligação à CloudFlare
Não tenho mais informação acerca disto
 
Não ganham nada, logo é estranho.

Da informação que tenho, apenas uma parte da rede (mais propriamente um dos Nós de LX - 195.8.30.237) foi afectada por esta situação, e que está tudo OK com a ligação à CloudFlare
Não tenho mais informação acerca disto
Por aqui, 188.83.187.XX, está com o da Google bloqueado e da cloudflare ok.
 
Acabados de fazer, numa ligação fibra 200/100. Logo dou feedback de como está o ADSL

Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:

1 3 ms 2 ms 3 ms meo.Home [192.168.1.254]
2 * * * Request timed out.
3 9 ms 11 ms 8 ms telepac16-hsi.cprm.net [195.8.30.250]
4 10 ms 11 ms 7 ms dvs-cr1-bu10-200.cprm.net [195.8.30.249]
5 12 ms 14 ms 14 ms lis2-cr1-hu12-0-0.cprm.net [195.8.1.62]
6 13 ms 12 ms 13 ms 172.68.100.254
7 12 ms 12 ms 12 ms one.one.one.one [1.1.1.1]

Trace complete.


Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms meo.Home [192.168.1.254]
2 * * 18 ms 10.241.128.1
3 7 ms 7 ms 7 ms telepac16-hsi.cprm.net [195.8.30.250]
4 11 ms 10 ms 10 ms dvs-cr1-bu10-200.cprm.net [195.8.30.249]
5 13 ms 14 ms 14 ms lis1-cr1-hu11-0-0.cprm.net [195.8.1.65]
6 13 ms 13 ms 13 ms googlept1.cprm.net [195.8.10.78]
7 20 ms 20 ms 20 ms 216.239.56.185
8 36 ms 36 ms 36 ms 216.239.41.19
9 42 ms 43 ms 41 ms 216.239.48.75
10 49 ms 41 ms 42 ms 209.85.142.91
11 41 ms 41 ms 41 ms 74.125.252.183
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.


Como podem ver, igual ao ADSL, isto tudo no distrito de Lisboa

EDIT: Em termos de velocidades, tudo OK (teste feito por wifi)

 
Não sei se já está assim há muito tempo. Pois eu por acaso tive aquela mês de oferta da sportv. Mas o canal NBA só dá para quem tem sportv?
Desde quando isto é assim....
 
Como podem ver, igual ao ADSL, isto tudo no distrito de Lisboa

Também estou no distrito de Lisboa:

Código:
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.254
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     5 ms     2 ms     3 ms  lis2-cr1-bu10-200.cprm.net [195.8.30.241]
  5     4 ms     1 ms     1 ms  googlept2.cprm.net [195.8.10.102]
  6     9 ms     9 ms    34 ms  216.239.56.185
  7    25 ms    25 ms    25 ms  216.239.41.237
  8    30 ms    30 ms    30 ms  216.239.51.118
  9    30 ms    30 ms    29 ms  74.125.37.59
10    30 ms    29 ms    29 ms  108.170.231.173
11     *        *        *     Request timed out.
12     *        *        *     Request timed out.
13     *        *        *     Request timed out.
14     *        *        *     Request timed out.
15     *        *        *     Request timed out.
16     *        *        *     Request timed out.
17     *        *        *     Request timed out.
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20    29 ms    29 ms    29 ms  google-public-dns-a.google.com [8.8.8.8]

O traceroute é uma péssima forma de ver se um host está acessível porque tem timeouts que podem levar a pensar erradamente que não está acessível (além de poder demorar muito tempo).
Na verdade o 8.8.8.8 como DNS está acessível e a trabalhar como é suposto, testei mesmo agora.
O resultado do ping:

Código:
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=30ms TTL=45
Reply from 8.8.8.8: bytes=32 time=29ms TTL=45
Reply from 8.8.8.8: bytes=32 time=29ms TTL=45
Reply from 8.8.8.8: bytes=32 time=29ms TTL=45
 
Também estou no distrito de Lisboa:

Código:
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.254
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     5 ms     2 ms     3 ms  lis2-cr1-bu10-200.cprm.net [195.8.30.241]
  5     4 ms     1 ms     1 ms  googlept2.cprm.net [195.8.10.102]
  6     9 ms     9 ms    34 ms  216.239.56.185
  7    25 ms    25 ms    25 ms  216.239.41.237
  8    30 ms    30 ms    30 ms  216.239.51.118
  9    30 ms    30 ms    29 ms  74.125.37.59
10    30 ms    29 ms    29 ms  108.170.231.173
11     *        *        *     Request timed out.
12     *        *        *     Request timed out.
13     *        *        *     Request timed out.
14     *        *        *     Request timed out.
15     *        *        *     Request timed out.
16     *        *        *     Request timed out.
17     *        *        *     Request timed out.
18     *        *        *     Request timed out.
19     *        *        *     Request timed out.
20    29 ms    29 ms    29 ms  google-public-dns-a.google.com [8.8.8.8]

O traceroute é uma péssima forma de ver se um host está acessível porque tem timeouts que podem levar a pensar erradamente que não está acessível (além de poder demorar muito tempo).
Na verdade o 8.8.8.8 como DNS está acessível e a trabalhar como é suposto, testei mesmo agora.
O resultado do ping:

Código:
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=30ms TTL=45
Reply from 8.8.8.8: bytes=32 time=29ms TTL=45
Reply from 8.8.8.8: bytes=32 time=29ms TTL=45
Reply from 8.8.8.8: bytes=32 time=29ms TTL=45


Mas no tracert não era suposto não haver nenhum request time out?
 
Mas no tracert não era suposto não haver nenhum request time out?

Não, basta equipamentos pelo meio bloquearem o tráfego do tipo UDP ou ICMP para dar timeout. Para ver se um destino está activo basta o ping, o traceroute serve apenas e só para ver como se chega ao destino sendo que quem gere as maquinarias pode aceitar ou não responder a esse pedido.
 
Última edição:
Mas numa ligação normal, é suposto existirem esses equipamentos?

É perfeitamente normal. Faz uns testes para sites conhecidos estrangeiros e na maioria dos casos vais apanhar com timeouts. Olha um exemplo feito mesmo agora no ebay.com (que está a funcionar, obviamente):

Código:
traceroute to www.ebay.com (88.221.66.8), 30 hops max, 60 byte packets
1  dsldevice.lan (192.168.1.254)  2.284 ms  2.843 ms  3.439 ms
2  * * *
3  * telepac14-hsi.cprm.net (195.8.30.242)  11.275 ms *
4  lis1-cr1-bu10-200.cprm.net (195.8.30.237)  11.648 ms lis2-cr1-bu10-200.cprm.net (195.8.30.241)  12.073 ms lis1-cr1-bu10-200.cprm.net (195.8.30.237)  12.354 ms
5  lis1-cr1-hu12-0-0.cprm.net (195.8.1.61)  14.671 ms  15.409 ms *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Já agora uma curiosidade, se optares por usares ICMP em vez de UDP as coisas ficam mais interessantes e rápidas:

Código:
traceroute -I www.ebay.com
traceroute to www.ebay.com (88.221.66.8), 30 hops max, 60 byte packets
1  dsldevice.lan (192.168.1.254)  4.709 ms  5.260 ms  5.340 ms
2  10.240.192.1 (10.240.192.1)  14.345 ms  16.458 ms  22.544 ms
3  telepac14-hsi.cprm.net (195.8.30.242)  7.987 ms  8.170 ms  8.248 ms
4  lis2-cr1-bu10-200.cprm.net (195.8.30.241)  11.193 ms  11.680 ms  11.864 ms
5  lis1-cr1-hu12-0-0.cprm.net (195.8.1.61)  9.558 ms  9.646 ms  9.730 ms
6  a88-221-66-8.deploy.static.akamaitechnologies.com (88.221.66.8)  7.381 ms  3.110 ms  3.344 ms

(o tracert do Windows acho que só funciona com UDP)
 
Mt gente a queixar-se que a MEO bloqueou os DNS 1.1.1.1 e 8.8.8.8 agora se foi de propósito não bloquearam os respectivos DNS secundários ...

9qk673pi1qg21.jpg

Porque será que a MEO queira bloquear os DNS 1.1.1.1 e 8.8.8.8 ?
O que ganham com isso?

Isso aconteceu, creio que foi nos Estados Unidos, bloquearam os DNS da Cloudflare e as rotas impedindo assim o acesso a sites tipo Piratebay etc.
Pode ter sido um problema ocasional, mas se persistir e continuar o problema e vierem a implementar isso em Portugal... Não será nada bom.

Tens aqui um exemplo disso que falei a cima: https://torrentfreak.com/internet-backbone-cogent-blocks-cloudflares-new-pirate-site-ip-addresses-170322/

O que ganham com isso? Menos acessos a sites piratas, mais lucros para os videoclubes e serviços de Streaming e canais Premium.
 
É perfeitamente normal. Faz uns testes para sites conhecidos estrangeiros e na maioria dos casos vais apanhar com timeouts. Olha um exemplo feito mesmo agora no ebay.com (que está a funcionar, obviamente):

Código:
traceroute to www.ebay.com (88.221.66.8), 30 hops max, 60 byte packets
1  dsldevice.lan (192.168.1.254)  2.284 ms  2.843 ms  3.439 ms
2  * * *
3  * telepac14-hsi.cprm.net (195.8.30.242)  11.275 ms *
4  lis1-cr1-bu10-200.cprm.net (195.8.30.237)  11.648 ms lis2-cr1-bu10-200.cprm.net (195.8.30.241)  12.073 ms lis1-cr1-bu10-200.cprm.net (195.8.30.237)  12.354 ms
5  lis1-cr1-hu12-0-0.cprm.net (195.8.1.61)  14.671 ms  15.409 ms *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Já agora uma curiosidade, se optares por usares ICMP em vez de UDP as coisas ficam mais interessantes e rápidas:

Código:
traceroute -I www.ebay.com
traceroute to www.ebay.com (88.221.66.8), 30 hops max, 60 byte packets
1  dsldevice.lan (192.168.1.254)  4.709 ms  5.260 ms  5.340 ms
2  10.240.192.1 (10.240.192.1)  14.345 ms  16.458 ms  22.544 ms
3  telepac14-hsi.cprm.net (195.8.30.242)  7.987 ms  8.170 ms  8.248 ms
4  lis2-cr1-bu10-200.cprm.net (195.8.30.241)  11.193 ms  11.680 ms  11.864 ms
5  lis1-cr1-hu12-0-0.cprm.net (195.8.1.61)  9.558 ms  9.646 ms  9.730 ms
6  a88-221-66-8.deploy.static.akamaitechnologies.com (88.221.66.8)  7.381 ms  3.110 ms  3.344 ms

(o tracert do Windows acho que só funciona com UDP)

Parece-me que no Windows é só UDP, anyway, se puderem deixem também os vossos testemunhos no site baixo:

https://www.tekcore.pt/2019/02/meo-bloqueia-dns-1.1.1.1-8.8.8.8.html
 
Parece-me que no Windows é só UDP, anyway, se puderem deixem também os vossos testemunhos no site baixo:

https://www.tekcore.pt/2019/02/meo-bloqueia-dns-1.1.1.1-8.8.8.8.html

É para rir? Primeiro dizias que o site aberto de Madrugada é de amadores e criticas, e agora dizes que a MEO "bloqueou" o DNS? Com que provas? Com traceroutes? Deixa la que esse TekCore também tem muito que se lhe diga! Como é que provas que não foi um problema ocasional?

Como diz o ditado "Faz o teu, e deixa os outros fazerem os deles".
 
Última edição:
É para rir? Primeiro dizias que o site abertura de Madrugada é de amadores e criticas, e agora dizes que a MEO "bloqueou" o DNS? Com que provas? Com traceroutes? Deixa la que esse TekCore também tem muito que se lhe diga! Como é que provas que não foi um problema ocasional?

Como diz o ditado "Faz o teu, e deixa os outros fazerem os deles".

Daí ter pedido para deixarem o vosso testemunho.
Já para não falar que sou cliente e deparei-me com a impossibilidade de conseguir abrir sites com o DNS da Google, não me baseio no que os outros dizem.
Mas já agora se queremos falar de credibilidade, onde andam os redirecionamentos para publicidade de aumento de pacote e afins? Tanto em MEO Fibra como ADSL não vejo isso seja com o DNS do MEO ou com o 1.1.1.1
 
Última edição:
Back
Topo