rubensk

Eu acho que eles mudaram isso recentemente. De qualquer forma, para receber na hora mesmo em outros serviços costuma ser a conjugação de duas coisas: o prazo de recebimento padrão e a antecipacão de recebíveis. Antecipação nenhum emissor ou banco vai fazer antes de você ter um fluxo para saberem quanto podem te antecipar.

Na verdade, se vale a pena usar só IPv4 ou IPv4+IPv6. Ainda não dá para não suportar v4.

Faz diferença, mas não por isso. Às vezes 9 trocas de tráfego podem ser todas ruins e se das 5 IPv4 uma for boa, IPv4 vai estar melhor. Não é o que costuma acontecer, mas só para deixar claro que é qualidade e não quantidade que importa. Há dois pontos que fazem diferença entre v4 e v6: 1) Os equipamentos de controle de banda das operadoras costumam não ter suporte a IPv6, que passa sem ser afetado 2) v6 não passa pelo CGNAT que as operadoras estão usando por causa da escassez de IPv4 Você pode ver as medições que as grandes CDNs fazem e publicam, por exemplo a do Google: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption Pelos dados do Google, 27% dos usuários do Brasil tem IPv6, e eles percebem latência 50 ms menor do que os usuários IPv4.

Parece muito forte dizer que vai quebrar se fizer isso ou deixar de fazer aquilo... o mercado tende ao equilíbrio, que ainda não se sabe em que ponto será.

Para um projeto que estou considerando, o Zoop foi o que pareceu mais interessante, mas não cheguei ainda a contratar. Além do Zoop, tem - entre outras - Pagar.me, WidePay, Iugu, Braspag/Cielo, PagSeguro, WireCard e YaPay.

Possibilidade sub-ótima: deixar o endereçamento automático do IPv6 preencher o resto baseado no endereço MAC da placa de rede. Possibilidade melhor: escolher um IP fácil de lembrar dentro da faixa e usá-lo.

Só cuidado que o Google não gosta muito disso, achando que você está tentando sacanear no ranking de busca. Você pode resolver isso com tags tipo rel=canonical, como explicado em https://moz.com/learn/seo/duplicate-content .

Isso se aplica a sistemas baseado em host objects como muitos gTLDs, onde os servidores DNS são objetos distintos do domínios, mas não a sistemas host attributes como o .br, onde os servidores DNS são parte intrínseca do domínio.

Mas não é que a Hostinger esteja bloqueando a mudança, ela que não conseguiu te explicar o que você precisa fazer para conseguir mudar. Autoridade é um termo de tecnologia DNS para quando um servidor DNS responde dizendo que ele de fato tem configuração de DNS para aquele domínio. Um exemplo com o domínio registro.br num servidor DNS que tem autoridade sobre esse domínio: DOMÍNIO registro.br DNS a.dns.br STATUS Autoridade sobre o domínio VERSÃO 2019070600 TEMPO DE RESPOSTA 436.28 us Agora num servidor DNS que apesar de saber onde fica registro.br, não tem autoridade: DOMÍNIO registro.br DNS 8.8.8.8 STATUS Sem autoridade sobre o domínio VERSÃO 2019070600 TEMPO DE RESPOSTA 1.3067 ms

Muita chata a postura da Hostinger pois ela como provedor de serviços de registro é que deveria te orientar. Na hora em que você ligar para o Registro.br vai ser orientado a ligar para a Hostinger, e ficar bem chateado com isso. O .br tem uma característica diferente do .com que é só permitir alteração de DNS se os novos DNS responderem com autoridade sobre o domínio. Usando https://registro.br/tecnologia/ferramentas/verificacao-de-dns/ você pode confirmar que os DNS para os quais você quer mudar o domínio já respondem com autoridade, e se ainda não respondem, pedir para esse provedor de hospedagem fazer essa configuração.

Tentar alterar para o WHOIS porta 43 é pular da frigideira para o fogo; se você não estiver bloqueado hoje, fatalmente estará limitado ou bloqueado em breve, especialmente a partir de IPs de fora do Brasil. E como já comentei acima, muito provavelmente haja um NAT entre seu servidor e o WHOIS e aí você passa IPs que não estão bloqueados mas que não são os que chegam no servidor. Voltando ao que pode funcionar, o avail, experimente colocar isto no whois.json : (troque o extensions pelos DPNs de .br que você suporta) [ { "extensions": ".com.br,.net.br,.eco.br,.art.br,.adv.br,.eng.br", "uri": "https://registro.br/v2/ajax/avail/raw/", "available": "\"status\":0" } ]

- Essa mensagem é sim de IP bloqueado no WHOIS. - O que às vezes acontece é do seu IP estar passando por NAT antes de chegar no servidor do Registro.br, e esse IP ou bloco CIDR está bloqueado. - Aos que mencionaram a questão do avail, a mensagem dele mostra que ele está usando o WHOIS porta 43 e não o avail... e usar o avail seria de fato uma melhor solução para checagem de disponibilidade. - O avail ainda não tem um end-point fixo por ainda não ter status de API, mas é hoje o jeito mais simples e funcional para checar domínio disponível.

Aceitação de débito vai sempre depender do adquirente... Cielo, Stone, PagSeguro etc. Você já tem ou imagina ter contrato a CIelo, citada no link acima ?

De 200 a 300 ms, dependendo da rede de origem no Brasil e de destino na Alemanha. Se quiser fazer alguns traceroutes, e1.e.dns.br fica em Frankfurt, wiki.rrpproxy.net também fica na Alemanha, em St. Ingbert.

Eu acho que não é zoeira não, é real... pelo menos parece muito com o que se vê em registro de domínios.