Zon: “não resolvemos os problemas dos nossos clientes”

Acções

Guardar/partilhar:

PDF: guarde ou imprima
del.icio.us
DoMelhor
EuCurti

Assinar publicação:
feed RSS
e-mail diário
newsletter semanal

Relacionados

• Obrigado, Zon
• Mau começo (repetição)
• Microsoft: que futuro depois de falhar a aquisição do Yahoo?
• Tuít-o-quem?
• Cresce, cresce blogosfera

57 opiniões no artigo “Zon: “não resolvemos os problemas dos nossos clientes””

1 Daniel Marques em 6 Abr 08 17:51

Mais de 72 horas, foi o tempo que a Zon Netcabo demorou a actualizar o DNS do Mais Gasolina. Até que o problema fosse resolvido, eu não pude trabalhar no site nem os clientes Zon Netcabo tiveram acesso ao serviço.

Ah, e dei o meu número de cliente, mas que pelos vistos não resolveu nada. 72 horas!

2 António Martins Neves em 6 Abr 08 19:02

Por esta e por muitas outras é que me livrei da Netcabo quando foi possível. A PT dificultou a vida o que pôde ao operador de ADSL que escolhi, mas o dia feliz em que fui dar baixa do serviço Netcabo chegou! A seguir vai a TV Cabo também à vida.
Fora muitos anos a penar e.. a pagar bem! E eu não era (nem sou) mais do que um utilizador quase primário da Internet.
Se a ANACOM não serve para nada (além de dar uns belos empregos), que se extinga! Mas o melhor mesmo é fazer-lhes sentir nas contas, mudando de operador. É a única lei que a PT e os seus descendentes parecem conhecer.

3 Daniel Marques » ZON Netcabo: A mediocridade e os problemas nos DNS em 6 Abr 08 21:37

[...] fé no relato do Paulo Querido e na experiência que eu como cliente e membro do Mais Gasolina vivi, apesar de se oferecer um [...]

4 Wilson José em 6 Abr 08 22:24

essa queixa contra a Anacom não tem razão nenhuma de existir..

5 Paulo Querido em 6 Abr 08 22:27

Wilson, qual queixa contra a Anacom? A única queixa aqui é acerca da Zon.

6 João Silas em 6 Abr 08 23:45

Meus senhores em Portugal é o que temos. Não dá para mais.

A cumulo é mesmo se não formos clientes não podemos reclamar sendo nós webmasters, é cómico.

7 Ricardo Ramalho em 7 Abr 08 10:48

Bom…

Eu sou cliente deles há 8 anos e não tenho tido grandes quebras de serviço. Há mais gente com queixas específicas contra eles (lembro-me do Rui Carmo do Tao Of Mac, por exemplo), mas eu não tenho tido grandes ’stresses’.

Para DNS tenho estado a usar outro DNS sem ser o da netcabo. Neste caso ando a usar o opendns ( http://www.opendns.com )

Abraços!

8 Curtas : Goodnight Moon em 7 Abr 08 11:11

[...] Ao que tudo indica, um problema técnico na Netcabo - agora ZON Multimedia - não tem permitido o acesso de alguns dos seus clientes a este e a outros blogues da rede TubarãoEsquilo. Se é um dos seus clientes nestas circustâncias, ligue para o serviço de assitência técnica a dar-lhes conhecimento. (Mais detalhes aqui) [...]

9 eduardo em 7 Abr 08 11:22

A queixa contra a ANACOM tem toda a razão de ser. Eu fiquei sem serviço de internet Clix há cerca de um ano e não foi por umas horas, foi para sempre. Uma dia tinha, no outro dia já não tinha e nunca mais voltei a ter. Tanto quanto consegui apurar, o problema deveu-se a uma incapacidade da PT para resolver um problema técnico que, tanto quanto percebi, não era lá muito difícil de resolver. Enviei o caso à ANACOM, frisando bem que não pretendia a resolução do meu problema de ligação (entretanto já tinha rescindido o contrato com a Clix/Novis), mas sim a averiguação daquilo que parecia ser uma incapacidade de um operador para fornecer o serviço contratualizado por “interferência” de outro operador. Passados três meses, a ANACOM respondeu que não era da sua competência resolver conflitos entre os consumidores e os operadores de telecomunicações. Fiquei esclarecido.

10 Daniel Marques em 7 Abr 08 15:22

Eduardo, é com esse testemunho e com outros que vivemos cada um nós pessoalmente, que percebemos que estamos entregues aos bichos.

11 Gonçalo Silva em 7 Abr 08 16:01

Mas alguém já tentou dissecar qual o motivo técnico para o sucedido ou as energias foram todas gastas no mau-dizer?
Com a escassez de informação apresentada, a culpa até pode estar do outro lado do oceano.

12 Paulo Querido em 7 Abr 08 16:13

Gonçalo, pois pode. Em vez de acrescentar mais palavreado ao assunto, uma energia sem dúvida gasta em vão porque já cá há que chegue, porque não tenta dissecar o motivo técnico pelo qual um número indeterminado de domínios, não inferior a 40, esteve interdito a um número também por determinar, mas que presumo enorme (perto da totalidade) de clientes da Zon ao longo dos últimos dias?
Uma dica que lhe permitirá poupar tempo: centre-se nos aspectos técnicos dos serviços de DNS.

13 Gonçalo Silva em 7 Abr 08 17:24

Tudo o que posso fazer é mesmo acrescentar mais palavreado ao assunto já que não possuo qualquer máquina na rede em questão, pelo que é-me dificil a reprodução do problema.
Aspectos técnicos de DNS que só se refletem em dominios que estão no mesmo AS? Quem está de fora centrava-se na rede, mas tudo o que estes sabem até ao momento é apenas os relatos das desventuras paralelas dos clientes Netcabo pelo que o diagnóstico é deveras subjectivo.

14 Paulo Querido em 7 Abr 08 20:29

Gonçalo, o que é um AS?
É evidente que o que temos — e eu próprio ecoei — são as desventuras de clientes (note: DE clientes, não ouso sequer dizer DOS clientes) da Zon. Mais subjectivo que isto, só o seu evidente desejo de passar a mensagem de que o problema, a existir para além da imaginação “dos” clientes da Netcabo, não está na infraestrutura desta mas nas máquinas, ou no datacenter, onde estão os infelizes domínios, entregues à incompetência e incúria sabe-se lá de quem…

15 Gonçalo Silva em 7 Abr 08 23:41

Paulo, não trabalho para a Zon, portanto se advêm algo destes problemas são benefícios para a empresa da qual sou colaborador.

O evidente desejo passa mais por ver traceroutes, nc, digs e afins ao invés das desventuras que nada acrescentam para, pelo menos, o diagnóstico. Mas secalhar sou eu que estou off-topic e a intenção do POST nunca foi essa, mea culpa.

Não afirmei que o problema é imaginário, nem que se devia à incompetência dos administradores dos dominios. Se há afimações neste thread não são minhas certamente.
Entre o Canadá e a netcabo existem uns tantos elementos de rede que nenhum dos intervenientes tem responsabilidade directa, era mais aí que queria chegar. Mas se forem os nichos da Netcabo a provocar o problema, ainda melhor, apenas não estou certo disso devido à falta de dados.

AS stands for autonomous system.

16 Paulo Querido em 8 Abr 08 00:39

Gonçalo: identifiquei três servidores diferentes com problemas, dois dos quais sei que são alojados pela mesma empresa canadiana, e um terceiro não faço ideia onde esteja.
Eu não sou cliente Zon, pelo que não tenho traceroutes — e se pedisse a algum dos queixosos, teria de lhes explicar primeiro o que é um traceroute.
A intenção do post foi referir que o nome mudou, mas não a atitude da empresa para com os seus clientes e o mercado e, pelo que vamos vendo, os seus diversos problemas técnicos. Isto a propósito de mais um episódio com queixas.

Indo agora mais longe. Bem sei que existem pontos de rede que ninguém controla, mas aceitarás que me incline (e não serei o único) mais depressa a pensar em apontar o dedo à estrutura da Zon quando:
a) são bem conhecidos os respectivos problemas de DNS e quebras de serviço, para ficarmos por aqui;
b) no mesmo período de tempo não houve registo de problemas de acesso através dos outros operadores, incluindo os que partilham (ainda partilham, tanto quanto fui informado) partes das redes e infraestruturas, i.e., o Sapo e o seu ADSL;
c) tanto quanto é possível inferir da leitura dos logs, do Analytics e do feedback dos leitores (e da carga de spam) o resto do mundo acedeu normalmente aos 40 domínios de que tenho conhecimento directo desta informação.

É evidente que nem sempre a regra faz… a regra. Mas começar pela excepção é ligar o complicómetro.

Digo eu.

17 Paulo Querido em 8 Abr 08 00:42

O resto de Portugal e do mundo, para ser mais exacto.

18 Gonçalo Silva em 8 Abr 08 01:34

No comentário anterior esqueci-me de referir que estou de acordo em relação à indignação com a “assistência técnica” prestada pela ZON.
Não é certamente a ignorarem queixas, refugiando-se em politiquices, que irão resolver os problemas quer sejam directamente ou indirectamente responsáveis pelos mesmos.

19 ZeX em 8 Abr 08 15:43

No canal de IRC onde costumo estar “estacionado” e por lá coexistirem utilizadores de varios ISPs a conclusão a que se chegou não apontava obrigatoriamente para os DNS, o que se resolveria facilmente acrescentando um OpenDNS, mas sim para as routes utilizadas. Dos testes que se fizeram na altura o dedo acabou por ser apontado a routes pela CPRM.
Com ou sem razão, e por não ter sido directamente afectado pois o meu ISP está fora do perímetro CPRM e tem ligações internacionais proprias, foi o que retive dos testes em que colaborei com uns traces para comparação.

20 Daniel Bernardo em 8 Abr 08 16:21

Zex: Tens os traces em questao que possas partilhar ? E os SOA/ NS records para os dominios em questao ?

21 Daniel Marques em 8 Abr 08 19:50

Tens os traces em questao que possas partilhar ?

“Não foi possível resolver o nome do sistema de destino pauloquerido.net”.

22 Zex em 8 Abr 08 20:13

Daniel Bernardo: Tenho uns 2 ou 3 traces meus, nos logs do IRC, que me chegavam ao destino sem problemas. O endereço que testamos não era Canadá mas sim US, embora va dar ao mesmo pois era uma route da cprm para a América do Norte que estava de “folga”.
Os que lá não chegavam era um ZON e um Telepac que, se não estou em erro, ainda usam as mesmas routes. Se achares importante posso tentar pedir-lhes os logs, quando os apanhar e se é que os guardaram

23 Daniel Bernardo em 8 Abr 08 21:37

Daniel Marques: Nao responde ‘a pergunta.

24 Paulo Querido em 8 Abr 08 21:57

Já que andam por aqui pessoas aparentemente preocupadas com isto, meto mais esta: “Mais de 72 horas, foi o tempo que a Zon Netcabo demorou a actualizar o DNS do Mais Gasolina.”
Quem já tenha lidado com domínios, sua criação e gestão sentiu isto na pele. A antiga Netcabo tem as suas “dificuldades” em aceitar as instruções de actualização emitidas pelas autoridades. Se um domínio estabelece o período de 10 minutos, ou 10 dias, para o refrescamento, supõe-se que esse período é cumprido. Ponto.

25 Gonçalo Silva em 8 Abr 08 22:15

Se a Netcabo não consegue resolver o nome pauloquerido.net, o problema cinge-se a Portugal, entre Netcabo e a NFSI.

26 Daniel Bernardo em 8 Abr 08 22:16

Nao me parece que existam tecnicos na Zon Netcabo suficientes para andaram descricionariamente a actualizar o DNS de quem seja.
Os mecanismos estao presentes e ditados pelos RFCs, os campos de SOA determinam a validade e expiracao.
Nao ha autoridades a emitir instrucoes de actualizacao pelo proprio risco que tal disposicao representaria.

27 Daniel Bernardo em 8 Abr 08 22:18

E aproveitando:

Server doesn’t listen/answer on port 53 for TCP protocol.

Ref: IETF RFC1035 (p.32 4.2. Transport)

=> b.ns.tuxdns.net./194.88.143.3
=> a.ns.tuxdns.net./194.88.142.3

28 Paulo Querido em 8 Abr 08 22:23

Gonçalo, no caso do meu domínio, certo.

Dos 40 domínios (que eu controlo) afectados em simultâneo, no episódio aqui aflorado, uma boa parte (não tenho de cabeça quantos) usa o serviço de NS default da Go Daddy (nem me lembro qual é).

Excluis a NFSI da equação. Sobra…?

Atenção: eu no comentário anterior falei de uma situação que é bem conhecida, e por ser bem conhecida me fez pensar antes que seria o problema do costume (DNS), mas tive o cuidado de não ser afirmativo, pois que tinha (e tenho) muito pouca informação para diagnóstico. Pelos vistos, há outras problemáticas que podem ter estado na origem do problema. Que não afectou apenas os domínios que eu controlo: afectou pelo menos dois, já aqui referidos, que nada têm a ver com os meus.

29 ZeX em 8 Abr 08 22:28

04/08/08 22:26:32 dns pauloquerido.net
Canonical name: pauloquerido.net
Addresses:
72.55.164.202

Se é problema de DNS basta o IP directo para lá chegarem.
Se, por outro lado, forem problemas de routes nem com o IP por extenso, com OpenDNS, ou no hosts lá chegam

30 Daniel Bernardo em 8 Abr 08 22:31

Caro Paulo,

Permita-me discordar, quer o tubaraoesquilo.pt quer o pauloquerido.net tem como NS records:

;; ANSWER SECTION:
tubaraoesquilo.pt. 86400 IN NS a.ns.tuxdns.net.
tubaraoesquilo.pt. 86400 IN NS b.ns.tuxdns.net.

Alojados na NFSi.

31 Paulo Querido em 8 Abr 08 22:31

Caro Daniel Bernardo, desculpe lá a maçada.

Respondendo: eu não falei em técnicos da Netcabo a interferirem no processo. Quando muito, falaria da falta de intervenção. Usei palavras de acesso à maioria dos meus leitores, quando referi as instruções de actualização emitidas pelas autoridades (em linguagem técnica, isto corresponde ao servidor de NS, que é quem determina o período de refrescamento).

Parece-me claro.

Se a ideia é continuar a sacudir a água do capote, passemos então da NFSI aos seguintes domínios afectados:
dig ns ma-schamba.com (ns21.domaincontrol.com)
dig ns uncovering.org (mns1.secureserver.net)
dig ns maisgasolina.com (ns1.titaniumsolutions.net)

Got my point?

32 Paulo Querido em 8 Abr 08 22:38

Caro Daniel Bernardo, ainda bem que mencionou o dominio tubaraoesquilo.pt

Um breve traceroute permitir-lhe-á verificar que ese domínio não está:
a) no mesmo IP do meu, pauloquerido.net
b) na mesma máquina onde está o meu e alguns dos domínios afectados
c) no mesmo datacenter
d) no mesmo país

É facto que os clientes que não viam os domínios aqui já referidos viam perfeitamente tanto o tubaraoesquilo.pt como o único dos nossos blogues que não está na máquina do Canadá (o que nada tem de especial, embora baralhe alguns dos nossos autores com menos paciência para isto, para quem um servidor é um servidor é um servidor.

Donde me permito concluir que não se trata de um problema do NS da NFSI — nem sequer de um problema ENTRE o vosso sistema e a rede da NFSI.

33 Paulo Querido em 8 Abr 08 22:42

Zex, certo — mas na altura ninguém fez esse tipo de queries. Os autores da TubarãoEsquilo não são propriamente letrados em TCP/IP.

Nm sequer eu sou, embora me pudesse ter ocorrido realizar testes para tentar apurar a origem do problema. Mas eu não sou cliente Zon — razão pela qual, aliás, este post foi escrito, aproveito para recordar.

34 Gonçalo Silva em 8 Abr 08 22:42

Daniel Bernardo, DNS é UDP e não TCP e como é obvio o a.ns.tuxdns.net tem a 53 UDP open.

O RFC diz que o TTL é uma opção e que o pode ser ou não interpretado. Não sei se a Netcabo força o valor do TTL para um numero pré definido pelos mesmos, o Sapo fá-lo.

35 Daniel Bernardo em 8 Abr 08 22:48

Actually… no…

O MEU sistema nao tem problema nenhum.

Os outros, cada um que responda pelo seu.

Quantos aos dominios afectados, estao afectados ? Porque senao e’ irrelevante a sua inumeracao, os dados que importariam seriam de quando estivessem afectados.

36 Paulo Querido em 8 Abr 08 22:57

Gonçalo, não sabia que o TTL era opcional. Conheço poucos casos em que não seja respeitado. Ou dizendo de outra maneira, nunca tive problemas com nenhum TTL excepto no caso da Netcabo. Costumo usar valores de defeito (1 hora) excepto quando estou em vias de mudar alguma coisa, e coloco os 300 ou os 600 segundos, conforme.
Se o Sapo o faz, é com valores aceitáveis — ao ponto de nunca ter tido problemas de acesso por ter mudado algum coisa no DNS.

Caro Daniel Bernardo, errado: o SEU sistema teve um problema durante uma grande parte do fim de semana, os MEUS sistemas estiveram operacioais e disponíveis para o mundo em geral EXCEPTO PARA CLIENTES DO SEU SISTEMA.

Se não quer ou não pode assumir culpas, é consigo.

Quanto aos domínios afectados, isto é, que não foram visíveis aos MEUS LEITORES que tiveram este fim de semana o azar de serem SEUS CLIENTES, neste momento parecem estar acessíveis aos SEUS clientes, sim. Logo, nada mais importa, não é?

37 ZeX em 8 Abr 08 22:58

Como bem desconfiei os logs não foram guardados mas deixo um quote directo, pedido à uns minutos, de um dos afectados para os US e que gastou os 5 minutos necessários a procurar a raiz do problema.

“não tinha nada a ver com os DNS”
“era no ams da cprm :)”

38 Paulo Querido em 8 Abr 08 22:59

Quando era cliente Netcabo, e até perceber melhor estas coisas, perdi horas a pensar que tinha um problema algures, no meu computador ou no meu servidor. Não tinha. O problema estava ENTRE o meu computador e o meu servidor.
Só tenho a agradecer à Netcabo: graças a essas horas de desespero que gentilmente me proporcionou, aprendi a mexer no meu hosts e um pouco mais sobre o funcionamento da Internet.

39 Paulo Querido em 8 Abr 08 23:04

ZeX, o DNS era a minha pista, mas não tenho problema algum, pelo contrário, ficarei satisfeito quando souber em concreto o que se passou.
Mas a sua como explicação é ainda pouca. Porque podiam os clientes dos outros operadores nacionais aceder? Ou não dependem da CPRM?

40 Gonçalo Silva em 8 Abr 08 23:10

Eu confirmo que a CPRM teve problemas este sabado no peering em Amsterdão. Notei quando não consegui aceder à wikipedia pela rede da TMN e não tinha qualquer problema pela VIANETWORKS.

41 Gonçalo Silva em 8 Abr 08 23:12

Paulo, a maioria dos ISPs nacionais não tem a Marconi como link internacional, essa é uma das explicações

42 ZeX em 8 Abr 08 23:17

Paulo: Para despistar um problema de DNS basta fazer o que lhe disse acima. Ip numérico para cima dele e se assim lá chegar é por que o DNS está a falhar.
No caso do meu operador, e tal como tb já disse, não depende da CPRM pois tem link internacional próprio.
No caso de outros que por lá passem depende das routes que têm configuradas/contratadas com os peers internacionais. Ou seja, podem seguir à mesma pela CPRM mas não estar configuradas para a maquina que falhou.

Está melhor assim?

43 Paulo Querido em 8 Abr 08 23:19

Gonçalo, ouvi/li mais casos de grandes marcas como a Wikipedia sem acesso, o que bate certo com isso.

Quanto ao link da Marconi — há que tempos que até eu, que não conto neste totobola, procurei um datacenter que me desse garantias de dispersão de links internacionais. Há que anos que celebrei o facto de não depender da infraestrutura da PT nem para um bit. Em boa hora — sei que não teria chegado aqui sem esse passo.

Por isso, não compreendo que um Grande ISP tenha uma dependência dessas. Não há lógica de grupo (a explicação que sempre me deram na Netcabo quando eu lá fiz uns serviçozecos de consultoria) que justifique uma má opção estratégica.

44 Paulo Querido em 8 Abr 08 23:29

ZeX, está melhor assim.

Se eu, no domingo, tivesse podido, acredite que tinha despistado o DNS. Era mesmo a segunda coisa que fazia.

A vocês é capaz de não fazer diferença, mas a mim irrita-me que tenham de ser os clientes e até os não-clientes a tentar perceber o que se passou, com a empresa que podia esclarecer tudo num segundo a cortar-se.

Bem sei que é a web social e essas coisas, e já somos nós os nossos caixas bancários, a caminho de sermos também os operadores de caixa de supermercado — mas daí até sermos nós a ter de explicar as falhas de serviço dos nossos ISP vai uma distância que ainda calculo grande.

Ou não?

45 Daniel Marques em 8 Abr 08 23:30

Pegando no caso do maisgasolina.com

Sábado de madrugada o site foi mudado para uma máquina dedicada. No Domingo tinha acesso ao site via Sapo, Telepac, Clix, Novis, Kanguru e Vodafone.

Na terça-feira o site continuava sem abrir na Netcabo.

# é preciso o meu número de cliente para o operador se mexer
# só resolvem problemas perante um número de cliente

Eu apresentei o meu número de cliente e não vi mais resultado por isso. Disseram que me ligavam. De facto ligaram-me, mas para me tentarem vender mais um pacote de canais.

Na segunda-feira tinha o AEIOU a mandar-me mails, porque eu tinha sido avisado que o site ia para destaque na página principal deles, mas o site não estava a abrir.

46 Daniel Marques em 8 Abr 08 23:35

Na quarta-feira o maisgasolina.com começou a abrir na Netcabo, mas o blog.maisgasolina.com continuava sem abrir.

47 Daniel Bernardo em 9 Abr 08 00:21

Goncalo Silva: Por favor le o RFC.

Como e’ obvio DNS NAO E’ apenas UDP. E’ uma das “pre concepcoes” mais erradas que pode haver.

Extraido do RFC:

4.2. Transport

The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be
used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance. Zone refresh activities
must use virtual circuits because of the need for reliable transfer.

The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
port 53 (decimal).

48 Gonçalo Silva em 9 Abr 08 00:56

Daniel Bernardo: Por favor relê o RFC

UDP é o protocol preferido para querys, TCP para transferências de zonas. O teu nameserver faz um query, não uma transfência de zona (nem deverá ter acesso a tal se o ns tiver bem configurado). Como só o slave deve fazer a transferência a 53 TCP está cortada para os outros.

Mas explica-me lá, chegaste a esta página via IP? È que segundo a tua teoria o hostname pauloquerido.net não devia resolver porque o porto 53 TCP do a.ns.tuxdns.net está cortado.

Essas concepções…

49 Daniel Bernardo em 9 Abr 08 08:07

Caro Paulo,

Nao tenho agua para sacudir, nao tenho clientes, nao faco revenda do meu acesso internet, expresso uma opiniao pessoal baseada em informacao totalmente publica e disponivel a todos.
Reitero, o MEU sistema nao tem problema nenhum, nao percebo a sua insistencia.
Nao tenho que justificar nada, nao fiz acusacao ou presuncao nenhuma, revi os factos que transcrevi nos quais baseei as minhas afirmacoes.

Esta a falar-se muito mas a unica coisa factual que ate’ agora pude ver aqui escrita e’ que ontem, pelo menos, os servidores DNS indicados nao cumpriam com os RFCs o que pode dificultar o servico de DNS, e que isso e’ tido por alguns como comportamento normal e por omissao.

50 Daniel Bernardo em 9 Abr 08 08:46

Caro Gonçalo,

Estas a afirmar por mim algo que nao fiz.

Como tu mesmo dizes: “UDP é o protocol preferido para querys”, preferido, nao apenas. Posso garantir-te que existem queries que apenas sao respondidas em TCP; Estas nao sao o caso.

Essa teoria nao e’ minha.

Quanto o mais, parece cada vez mais, esbocar-se a teoria essa sim, de que o problema estaria em peering realizado fora de Portugal.

De concepcoes… resultam acusacoes faceis.

51 Gonçalo Silva em 9 Abr 08 10:56

Caro Daniel,

Quem é que afirmou isto?

“Posso garantir-te que existem queries que apenas sao respondidas em TCP; Estas nao sao o caso.”

Quem é que fez este cometário?
“Server doesn’t listen/answer on port 53 for TCP protocol.

Ref: IETF RFC1035 (p.32 4.2. Transport)

=> b.ns.tuxdns.net./194.88.143.3
=> a.ns.tuxdns.net./194.88.142.3″

Portanto, você sabe que o query que o nameserver da netcabo faz ao tuxdns é por UDP, mas para despitar o problema faz uma conexão ao 53 TCP.
Não me tem de garantir que existem queries que são respondias via TCP quando já lhe disse anteriormente que é a AXFR e que este apenas deve ser feito pelo Slave.
Vou-me repetir, o porto 53 TCP não tem de estar open para a internet para que o nameserver cumpra o RFC.

52 Daniel Bernardo em 9 Abr 08 11:32

Caro Goncalo,

Sei o que digo e quando o digo, e tambem nao me vou repetir. Nao tem razao e ainda nao leu, nao compreende ou nao quer compreender o que esta’ dito no RFC.

in: http://www.cert.org/archive/pdf/dns.pdf

“Note that it is a common misconception that that only 53/udp is used for DNS queries and that 53/tcp is only used for zone transfers. However, 53/tcp may be used for longer query responses that won’t fit into a single UDP packet. Thus it is necessary to allow traffic to both 53/udp and 53/tcp. Zone transfers via 53/tcp can be further restricted within the name server configuration itself. Furthermore, name servers that are configured to forward unresolved queries to another name server will appear as clients to the server they forward to.”

Espero que nao faca disto a sua actividade profissional.

53 Gonçalo Silva em 9 Abr 08 11:49

Caro Daniel, quer-me elucidar qual o query que a netcabo faz ao tuxdns que exceda os 512 bytes de datagram? Eu respondo-lhe.. nenhum. È por isso que na prática se diz que o 53 TCP apenas serve para transferências de zonas pois não existem mais nenhum query que exceda esse valor.

Deixe a minha actividade profissional em paz, não lhe diz respeito nem lhe admito.

54 Paulo Querido em 9 Abr 08 12:33

Caro Daniel Bernardo, vou confessar: agora irritou-me solenemente. O que, vindo de alguém da Netcabo nos tempos que correm, é demais para mim, um luxo ao qual nõ me posso entregar. Vou ser claro uma vez e calar-me em seguida, porque o seu comportamento aqui não passa de uma tentativa de intoxicar o assunto e desviar as atenções do que está em causa.

O que, de resto, cola bem com a imagem pública da marca Netcabo: arrogância e prepotência. Adiante.

“Esta a falar-se muito mas a unica coisa factual que ate’ agora pude ver aqui escrita e’ que ontem, pelo menos, os servidores DNS indicados nao cumpriam com os RFCs o que pode dificultar o servico de DNS, e que isso e’ tido por alguns como comportamento normal e por omissao”

Uma dupla mentira, destinada a desviar as atenções.

É mentira porque o que aqui sempre esteve em causa foi uma quebra de serviço da Netcabo por um período de tempo que não fomos capazes de determinar, NEM COM A SUA COLABORAÇÃO, e que mereceu da sua empresa o mais completo desprezo quando fiz uma simples pergunta ao help-desk técnico.

A quebra de serviço aqui referida foi mencionada por diversas pessoas em correspondência trocada comigo. O Daniel Bernardo em vez de procurar explicá-la tem-se limitado a disparar para todos os lados, apontando o dedo de formas esclarecedoras — nalguns casos, eloquentes do seu desespero, como foi o caso, a que continua a agarrar-se, do NS da NFSI, o qual, como já demonstrei usando os seu próprios exemplos, não é de todo me todo um caso, nem teve a minima interferência na quebra de serviço aqui falada.

Repito, usando o seu exemplo:
pauloquerido.net usa o NS da NFSI e esteve indisponível
tubaraoesquilo.pt usa o NS da NFSI e esteve disponível

Recordo, uma vez mais:
pauloquerido.net está alojado no Canadá e esteve indisponível
tubaraoesquilo.pt está alojado em Portugal (na NFSI, por sinal) e esteve sempre disponível.

Outros factos que continua a ignorar:
ma-schamba.com (ns21.domaincontrol.com)
uncovering.org (mns1.secureserver.net)
maisgasolina.com (ns1.titaniumsolutions.net)

são domínios que estiveram indisponíveis a um número indeterminado, mas que se supõe elevado, de clientes da Netcabo/Zon e que NADA TÊM A VER com a estrutura da NFSI.

Levar a discussão para detalhes técnicos pode ajudar ao seu ego (embora eu não compreenda como, a menos que se explique pelo masoquismo), mas não vai esclarecer os leitores sobre o que se passou, só piorando a relação com a sua empresa, que continua a mostrar-se incapaz de “descer” à comunicação efectiva com os clientes, directos e indirectos.

Da minha parte, passe bem. Sugiro ao Gonçalo Silva que faça o mesmo: /dev/null consigo.

55 Mario Andrade em 11 Abr 08 14:15

Ainda ontem fiz o pedido para aderir a outro ISP. Agora resta-me aguardar a confirmação para marcarem a instalação para desistir do serviço da Zon.
Existem melhores alternativas com melhores preços e serviços identicos.

56 Sofia em 4 Jun 08 12:33

Isto é incrível. A Zon anda a enganar meio mundo com promoções, novos contratos com ofertas e descontos, onde se supõe pagar apenas “x” por mês, mas depois sai-lhe “y” na factura. E não é só a mim. O próprio Leonel Moura fala do assunto num jornal recente, porque lhe aconteceu a mesma coisa. O problema é que os clientes reclamam dúzias de vezes, todos ouvem e prometem a resolução do problema, mas a situação mantém-se, mês após mês. Afinal estamos ou não a ser enganados? O serviço é mau (vezes seguidas sem sinal, que significam horas sem serviço), publicidade enganosa a torto e a direito, falta de cumprimento de prazos e promessas. Pagar pagamos todos, e ai de quem não pague ou se atrase. Cumprir é que nem todos cumprem.

57 Kikas em 4 Jun 08 13:11

Deco! Qual Anacom! Queixe-se na Deco e para os jornais!
Ah, pois é…
A Zon, ex-TV Cabo, já é ex em muitas mais coisas. Não passa de hoje e vai passar a ser a minha ex-empresa-que-fornece-TV-por-cabo. Então não é que os ex-qualquer-coisa andam a enganar os clientes com promessas fictícias? São as promoções, novos contratos com ofertas e descontos, onde se supõe pagar apenas “x” por mês, mas depois sai-lhe “y” na factura, e agora publicidade enganosa: as 200 horas de gravação anunciadas significam apenas 90?!?!?! 90 HORAS!!! Leram bem!
Reclama-se, reclama-se e fazem orelhas moucas. Todos ouvem e prometem a resolução, mas mais uma vez a situação vai estender-se por meses. E antes que isso aconteça eu e, certamente, muitos mais clientes teremos todo o prazer de sermos os ex-clientes da Zon-ex-Tv-Cabo. Felizmente a DECO já pegou no assunto e já saiu nos jornais. Felizmente há concorrência, que é como-quem-diz- há vida para além da Zon. Viva o Meo!

Deixe a sua opinião