Wiki BPF - Contribuições do(a) usuário(a) [pt-br]

Porque usar um DNS local e algumas dicas para isto

2022-08-15T14:43:08Z

Canton:

==Introdução==
É bastante comum vermos usuários de internet ou até alguns provedores inteiros usando servidores DNS públicos, como o 8.8.8.8.

Os principais motivos para que usem um DNS público ao invés de um servidor local são a falta de instrução técnica sobre como instalar e configurar seu próprio servidor e o desconhecimento dos problemas causados por esta prática.

O objetivo deste artigo é explicar porquê você não deve usar um DNS público em sua rede ou sua casa e mostrar algumas alternativas gratuitas e simples para que você tenha seu próprio servidor DNS localmente.

Como material de apoio também recomendamos [https://www.youtube.com/watch?v=h_o7zeKMabA este vídeo], que explica de forma direta e sucinta sobre este assunto.

== Problemas da utilização de um DNS público ==
'''Diminuição da velocidade de download de alguns conteúdos'''

Diversos sites que possuem seus conteúdos hospedados em uma rede de CDN, como Netflix, Google e Facebook, podem prover o seu conteúdo através de centenas de servidores espalhados por todo o mundo. Para determinar a partir de qual servidor eles irão te enviar conteúdo, eles utilizam a geolocalização do DNS Recursivo utilizado por você. Como podemos consultar na [https://www.maxmind.com/en/geoip-demo Maxmind,] a maioria dos servidores públicos de DNS (como 8.8.8.8, 4.2.2.2 e 1.1.1.1) estão localizados em outros países, e muitas vezes até em outros continentes. Como resultado, quando você utiliza um DNS Público como os mencionados acima, estes provedores de conteúdo podem optar por te enviar dados a partir de um servidor muito distante de onde você se encontra, aumentando a latência e consequentemente diminuindo as velocidades máximas que você poderia atingir em seus downloads. Isto é explicado pelo próprio Google [https://developers.google.com/speed/public-dns/faq?authuser=1&pageId=106568075635932514862#cdn neste artigo.]Veja um trecho da explicação traduzido: ''Muitos sites que provém streaming ou conteúdos para download hospedam seus conteúdos com redes de distribuição de conteúdo (CDNs) de terceiros baseadas em DNS, como a Akamai. Quando um DNS Resolver consulta um servidor de nomes autoritativo pelo endereço IP de um CDN, o servidor de nomes retorna o endereço mais próximo (em distância de rede) ao DNS Resolver, não ao usuário. Em alguns casos (...), como o DNS público do Google, o resolvedor pode não estar muito próximo dos usuários. Nestes casos, a experiência de navegação pode ser reduzida um pouco.''

'''Não há garantia de funcionamento'''

Por serem serviços fornecidos gratuitamente, é de se esperar que eles não tenham qualquer obrigação contratual sobre disponibilidade dos serviços. Apesar de serem conhecidos por sua grande disponibilidade, os servidores de DNS Públicos também podem sofrer indisponibilidades, como a mencionada [https://tecnoblog.net/216855/dns-google-caiu-fora-do-ar/ nesta notícia]. Nestes casos, pode não haver qualquer previsão de retorno destes servidores públicos e tampouco uma justificativa para os problemas.

'''Suas consultas podem ser limitadas sem aviso prévio'''

A depender de suas configurações de NAT, alguns DNSs podem entender que o excesso de consultas originadas de sua rede são um ataque, e nestes casos podem limitar suas consultas sem qualquer aviso prévio. Estes limites causam problemas intermitentes, que muitas vezes podem ser difíceis de serem diagnosticados. Um DNS público que utiliza-se destes limites é o 4.2.2.2.

'''A sua privacidade pode ser violada'''

Como é sabido, em nosso mercado nenhum serviço gratuito é oferecido sem um propósito, geralmente. Um dos objetivos de algumas empresas em fornecer um serviço DNS gratuito e público é de otimizar seus mecanismos de marketing. Sempre que você utiliza um DNS público e/ou não confiável, todas as suas requisições podem ser lidas pelo provedor do DNS, de forma com que ele consiga adquirir uma enorme quantidade de informações sobre seus hábitos na internet e fora dela. Isto é geralmente usado para otimizar mecanismos de anúncios na internet, mas também pode ser usado para fins maliciosos, visto que você não terá qualquer controle destas informações. Ou seja, muitas vezes o serviço não é gratuito. O preço são informações sobre você.

'''Você pode estar sujeito à ataques cibernéticos'''

Novamente, por serem serviços públicos e gratuitos, muitas vezes sem uma política de uso clara, não há qualquer garantia de funcionamento e segurança dos servidores utilizados. Caso um destes DNSs seja infectado, a resposta de suas consultas pode te direcionar para páginas falsas (''phishing''), fazendo com que dados como logins e senhas possam ser roubados.

Você, usuário, pode se questionar se alguns desses problemas também não poderiam acontecer em um DNS local de seu provedor, e neste caso a resposta é sim. Em contrapartida, as organizações que mantém um DNS local tendem a ter um zelo ainda maior por seus próprios servidores. Uma falha ou indisponibilidade em seus servidores pode gerar centenas ou milhares de reclamações, além de prejuízos financeiros para a empresa. Além disso, o funcionamento do DNS provido pelo seu provedor é mandatório, de forma com que você poderá se queixar diretamente à ele caso tenha algum problema. O mesmo não acontece com um DNS público.

Mais pra frente neste artigo também falaremos sobre como você, provedor de internet, pode utilizar um DNS local em sua rede.

== Softwares gratuitos para DNS ==
Selecionamos abaixo uma lista de alguns softwares gratuitos e de fácil instalação para DNSs recursivos:
{| class="wikitable"
|+
!Nome
!Compatível com Linux
!Compatível com Windows
!URL do projeto
!Tutorial de instalação
|-
|Unbound
|Sim
|Sim
|https://nlnetlabs.nl/projects/unbound/about/
|https://nlnetlabs.nl/documentation/unbound/howto-setup/ ,
|-
|Bind
|Sim
|Sim
|https://www.isc.org/downloads/bind/
|
|-
|Dnsmasq
|Sim
|Não
|<nowiki>http://thekelleys.org.uk/dnsmasq/doc.html</nowiki>
|
|
|-
|PowerDNS Recursor
|Sim
|Não
|<nowiki>https://doc.powerdns.com/recursor/index.html</nowiki>
|<nowiki>https://www.debiantutorials.com/installing-powerdns-recursor/</nowiki>
|}
Caso você conheça outra alternativa gratuita e de fácil instalação, ou queira adicionar a URL de algum tutorial oficial de instalação, fique à vontade para complementar a tabela acima.

== Recomendações para instalar, configurar e gerenciar seus recursivos locais ==
'''Assegure-se que seu servidor possui o DNSSec habilitado'''

Por padrão grande parte dos servidores já possuem o DNSSec habilitado. Mas sempre que instalar um servidor local, certifique-se de que ele possua o protocolo habilitado e em pleno funcionamento. Através [https://dnssec.vs.uni-due.de/ deste link] você pode testar se o seu DNS Recursivo está utilizando DNSSec, além de encontrar tutoriais sobre como configurar o protocolo em servidores Unbound e Bind.

'''Sempre mantenha mais de um servidor local'''

Um dos motivos de se ter um servidor DNS Recursivo local é garantir a disponibilidade do serviço. Entretanto, caso você tenha apenas um servidor em sua rede não poderá assegurar que ele esteja sempre disponível. Sendo assim, sempre tenha dois ou mais servidores em sua rede.

'''Garanta que seus recursivos realmente sejam redundantes'''

Ter mais de um servidor nem sempre será efetivo caso eles não estejam em locais e redes distintas. Caso seus recursivos estejam em máquinas virtuais num mesmo servidor físico, uma falha de energia ou de hardware indisponibilizará todas as resoluções de nome em sua rede. Sendo assim, busque garantir que seus servidores estejam em ''servidores diferentes'', ''em redes diferentes'' e preferencialmente em ''datacenters também distintos''.

'''Utilize IPv6 em seus servidores'''

Ainda que por padrão seus software responda requisições IPv6 em consultas IPv4, garanta que seus servidores também possuam um endereço IPv6 e respondam consultas IPv6 only. Caso contrário, durante uma indisponibilidade de IPv4 em sua rede, você deixará de utilizar IPv6 em todo seu provedor apenas por não ter o protocolo habilitado em seus recursivos.

'''Restrinja as consultas ao seu servidor apenas à sua rede e à seus clientes'''

Diferente dos servidores públicos, o objetivo de seus servidores é apenas servir à sua rede e à seus clientes. Portanto sempre restrinja as consultas apenas aos IPs públicos e privados utilizados em sua rede. Este procedimento é fácil e geralmente é feito no arquivo de configuração do DNS. Caso não localize como fazê-lo, consulte a documentação do software.

'''Mantenha seu DNS atualizado'''

Leia periodicamente os changelogs das novas versões do software que estiver utilizando, e, caso haja uma atualização que corrija alguma falha de segurança, atualize a chave DNSSEC ou implemente algum novo recurso importante, atualize seu servidor. Tendo dois ou mais servidores, como recomendado acima, você pode fazer estas atualizações sem qualquer parada em sua rede.

'''Não hesite em contratar um profissional para executar o serviço, se necessário'''

Apesar de não ser uma tarefa demasiadamente complexa, caso você não saiba como instalar e configurar devidamente seu servidor, não hesite em contatar uma empresa ou profissional capacitado para isto. Geralmente instalação e manutenção de servidores de DNS oferecem um custo baixo.

Artigo por [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]
[[Categoria:DNS]]
[[Categoria:BCOPs]]
[[Categoria:Capacitação]]

CDN Peering e PNI - Brasil

2021-07-27T21:53:44Z

Canton: /* CloudFlare */ Alterações solicitadas por Ticiane da Cloudflare

===Introdução===
Esta página contém informações úteis para operadores de redes e ISPs com relação à solicitação de servidores de CDNs, estabelecimento de uma sessão Bilateral em algum dos IXs ou para a solicitação de PNIs nos Datacenters aonde ASNs, geralmente grandes geradores de conteúdos, estão presentes.

É importante destacar que as informações aqui apresentadas (ex: tráfego necessário para solicitar servidores de CDN) mudam de forma bastante dinâmica e de acordo com as regras próprias estabelecidas pelos próprios geradores de conteúdo, portanto este guia serve como referência para o momento que ele foi escrito ou atualizado pela última vez.

Um recomendação importante a ser feita é que antes de fazer a solicitação de servidores de CDN ou de um PNI por exemplo, é importante realizar uma avaliação detalhada do tráfego que o seu ASN troca com os ASNs desses geradores de conteúdo. Ferramentas como NetFlow e [https://www.peeringdb.com/ PeeringDB] auxiliam bastante. Cerifique-se que você atende à TODOS os requisitos antes de fazer a solicitação, principalmente se possui a quantidade de mínima de tráfego para ser elegível. Esses servidores somente são enviados aos ISPs no caso das empresas de CDN verificarem que eles trazem benefícios para ambos CDN e ISP, caso contrário dificilmente serão enviados. Hospedar e manter um servidor de CDN é algo que demanda recursos do provedor como espaço em rack, portas de switch e principalmente um consumo razoável de energia elétrica por isso uma avaliação criteriosa é bastante importante antes de realizar a solicitação.

Outro detalhe imprescindível na hora de solicitar um servidor de CDN, Peering por Sessão Bilateral ou PNI é o IPv6. Devido à crescente importância deste protocolo algumas CDNs hoje em dia tem colocado restrições caso você não seja capaz de estabelecer uma sessão IPv6 com eles.Além disso caso você possua IPv6 em seu backbone porém ainda não está distribuindo para os usuários residencias e possui apenas CGNAT44 a maioria das grandes CDNs já possuem suporte completo à IPv6 portanto uma parte significativa do seu tráfego poderia estar fluindo preferencialmente em IPv6 ao invés de estar passando por equipamentos que fazem o GGNAT a um custo computacional maior além de ter a identificação do usuário facilitada em caso de uma solicitação baseada no Marco Civil da Internet.

A maioria das CDNs exigem que as informações sobre o ASN solicitante estejam atualizadas no PeeringDB portanto antes de solicitar é uma boa prática conferi-las.

Você pode acessar a URL a seguir para entender melhor o funcionamento de sessões Peering: [[Modelos_Interconexão]]

''Última atualização - '''25/06/2021'''''

=== Informações importantes sobre termos de contrato, NDA, propriedade intelectual, uso impróprio de logomarcas, e outras práticas que devem ser abolidas pelo ISP ===
Atenção senhores provedores de acesso à Internet (ISP). Esta seção do presente documento visa esclarecer algumas informações importantes sobre a legitimidade de certas práticas que tem sido detectadas entre os ISPs, generalizando aqui, em particular no que diz respeito ao uso impróprio de recursos providos pelas redes de fornecimento de conteúdo (CDN), e também de algumas violações graves dos termos estabelecidos em regime de contrato entre a detentora da tecnologia (empresa de conteúdo que fornece a CDN) e o ISP. Mas, antes, permita-nos explicar-lhes o que são CDNs, suas características e benefícios gerais:

Como é de conhecimento comum entre os ISPs, há basicamente dois tipos de arquiteturas ou abordagens no que diz respeito às CDNs: ''Bring-Home'' e ''Enter-Deep Cache''. Foquemos no segundo caso (''Enter-Deep''), que é o tipo que mais se assemelha às CDNs que os ISPs qualificados podem solicitar e receber. A arquitetura ''Enter-Deep Cache'' possui como estratégia estar profundamente fincada dentro do ambiente de redes do ISP, geralmente sendo adotados na forma de clusters. Os benefícios proporcionados pelas CDNs são indiscutíveis:
* Fornecimento de conteúdo de baixa latência, o que, por sua vez, promove uma experiência bem fluída de navegação e interação dos usuários/clientes do ISP.
* Em combinação com sessões de peering privado (PNI) e peering público (IX), a arquitetura Enter-Deep promove economias bastante significativas nos custos operacionais do ISP, e em diversas áreas, especialmente o dimensionamento de recursos e manutenção de custos recorrentes com a contratação de links de trânsito IP.
* Combinada com outras boas práticas de engenharia de redes, engenharia de tráfego, e segurança geral do ASN, as redes de fornecimento de conteúdo contribuem muito substancialmente para aprimoramentos de diversos KPIs do negócio.
* O assinante (cliente) é beneficiado por contar com uma Internet "mais fluida", e o ISP é beneficiado por poder fornecer uma experiência mais atraente de interação de seus clientes com a Internet, além da redução de custos aliada ao aprimoramento de indicadores-chave importantes do negócio.
No entanto, o ISP precisa entender uma realidade: apesar dos benefícios mútuos para cliente e ISP, e até mesmo para a detentora da tecnologia (empresa de conteúdo), que consegue engajar e monetizar melhor seus (também) clientes, ter uma CDN é na verdade um '''privilégio'''. O que muitos ISPs fazem é tratar a CDN como um "direito" deles, e isto é completamente equivocado. Mesmo que o ISP reúna os requisitos para a solicitação e obtenção de CDN - aliás, mal sabem, a solicitação não é para "obter uma CDN", e sim para participar do programa de afiliados da empresa de conteúdo - a resposta/decisão será sempre por conta da detentora da tecnologia, que avaliará diversas métricas para determinar se é vantajoso ou não para ela disponibilizar a sua tecnologia para aquele ISP. Ou seja, há uma relação mútua entre os beneficiados diretos "ISP e CDN" (generalizando o termo aqui); assim como é vantajoso (e sempre será!) para o ISP, tem que ser vantajoso, também, para a empresa dona daquela CDN. Repetindo: CDN não é direito, é privilégio.

'''Práticas ilegais exercitadas por alguns ISPs:'''
* Amplificar e manipular artificialmente o tráfego via práticas escusas, recheadas de alguns desvios éticos, com o intuito de atingir o requerimento mínimo de consumo exigido pela detentora da CDN.
* Promover abertamente na sua cesta de produtos e soluções que aquele ISP "vende tráfego de CDNs". O ISP não pode vender tráfego de CDN direta ou abertamente, mas poderá costurar um produto que contemple isto de forma correta e legítima. O ISP poderá fornecer tráfego de CDNs dentro de um produto de "Trânsito IP Parcial" ou nome qualquer, desde que não divulgue que "vende CDN" e muito menos expondo logomarcas, fotos dos servidores, etc.
* Não somente vender abertamente o tráfego de CDNs, as vezes usando nomes um tanto criativos, como "IP Confinado" e similares, mas ainda expor as logomarcas das empresas (ex: Netflix, Facebook, Google, Akamai, etc.). Isto é completamente ilegal.
* Publicam fotos de seus data centers com o propósito de expor aos seus clientes e prospecções que possuem "servidores de CDN da empresa X, Y e Z". Isto é igualmente não permitido.
Com a exceção do primeiro caso (manipulação artificial do tráfego), os demais casos não tem relação com aspectos mais técnicos envolvendo redes, e sim com outras questões que passam completamente despercebidas por estes indivíduos e empresas. Os contratos que são estabelecidos entre empresas fornecedoras de conteúdo e os ISPs vão um tanto além das questões puramente técnicas, pois há uma preocupação enorme envolvendo uma cadeia inteira de partes interessadas no capital que flui com estes conteúdos, do produtor, passando pelo distribuidor, depois pelo ISP, e, por último, para os clientes. Ou seja, questões relacionadas à proteção de marcas (branding), uso inadequado de logomarcas e afins, propriedade intelectual, pagamento de royalties, e os acordos milionários entre as produtoras de conteúdos e as distribuidoras de conteúdo. A questão toda vai bem além do "tequiniquês".

Quando um ISP viola estes termos, ele estará desafiando uma cadeia inteira de partes interessadas que podem tomar ações contra o ISP. Na melhor das hipóteses, o ISP é alertado. Frequentemente, o ISP perde e tem as CDNs recolhidas de sua rede, além de ser banido permanentemente do programa. Há ainda o risco de outras ações serem executadas contra o ISP por uso indevido de imagem, violação de direitos autorais e/ou de propriedade intelectual.

Esperamos que estas informações sejam úteis para todos vocês, e colocamo-nos à disposição para esclarecermos suas dúvidas. Utilizem as nossas listas de discussão!

===CDNs===
As CDNs, baseadas em critérios próprios, definem condições em que um servidor pode ser enviado para ser instalado dentro do backbone de um ISP para otimizar a entrega de conteúdo para o usuário final. Isso é vantajoso para a CDN que melhora a qualidade na entrega do conteúdo, para o usuário final e também para ISP pois além de economizar no uso dos links de upstream são capazes de prover uma melhor experiência para seus usuários.

O tráfego atual de referência para solicitação de servidores de algumas CDN está na faixa dos 2 a 5 Gbps, porém existem condições que isso pode ser flexibilizado à depender da região e da disponibilidade de outros Trânsitos IP presentes serem capazes de distribuir aquele conteúdo. Via de regra em uma grande cidade ou região populosa com acesso à IX que já possui servidores de cache ou uma quantidade razoável de Trânsitos IP é bastante provável que o valor de referência não seja flexibilizado pelas CDNs.
====Akamai (AANP)====
*Banda mínima: 10 Gbps
*Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
*Documentação: https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf
*PeeringDB: https://www.peeringdb.com/net/2
====Apple====
*Banda mínima: 25 Gbps
*Informações: https://cache.edge.apple/
*Solicitação: https://cache.edge.apple/inquire
*PeeringDB: https://peeringdb.com/asn/714
*Nota: Como exigem uma quantidade de banda alta para o cache, evite entrar em contato caso seu tráfego não esteja ao menos com previsão de chegar ao mínimo nos próximos 12 meses. Como a Apple ainda não está no IX.Br SP, dê preferencia por entrar em contato sugerindo que eles mantenham pontos de presença no Brasil, será muito mais eficiente.
====Facebook (FNA)====
*Banda mínima: 5 Gbps
*Email: fna@fb.com
*PeeringDB: https://www.peeringdb.com/net/979
*Nota: O Facebook analisa apenas o tráfego trocado com o ASN solicitante e não de seus respectivos clientes de trânsito (demais ASNs). Também não considera possibilidade da soma do tráfego trocado com os ASNs desejando compartilhar um FNA em um IX Privado ou interconexão bilateral, independente de um contrato existente entre as partes.
*Prefixos CGNAT: Não suportados oficialmente. Considere uso de IPv6.
====Google (GGC)====
*Banda mínima maior que: 3 Gbps - 95 percentil por pelo menos 3 meses.
*Informações: https://peering.google.com/#/options/google-global-cache
*Solicitação: http://isp.google.com/iwantpeering
*Instalação: https://www.gstatic.com/isp/docs/ggc-installation.pdf
*Troubleshooting: https://cloud.google.com/cdn/docs/support
*Portal: https://isp.google.com/dashboard/
* PeeringDB: https://www.peeringdb.com/net/433<nowiki/>https://www.peeringdb.com/net/4319
* Necessário ter registrado em IRR, todos os p<nowiki/>refixos anunciados para o Google. https://support.google.com/interconnect#topic=9326690
* Prefixos CGNAT: Aceitos com community. Acess<nowiki/>e a documentação no portal.

====Edgecast Verizon Digital Media (EC)====
*Banda mínima: 10 Gbps
*Email: peering@verizondigitalmedia.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/
*Solicitação: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>

*
====Netflix (OCA)====
*Banda mínima: 5 Gbps (Todos os estados)
*Solicitação: https://openconnect.netflix.com/en/request/
*Instalação: https://openconnect.netflix.com/deploymentguide.pdf
*Troubleshooting: https://openconnect.netflix.com/en/faq/
*Portal: https://my.oc.netflix.com/
*PeeringDB: https://www.peeringdb.com/net/457
*Prefixos CGNAT: Não suportado oficialmente. Considere uso de IPv6.

==== Azion (ANA) ====
* Banda mínima: 15 Gbps (Seletiva)
* Email: cdn@azion.com
* Informações: https://www.azion.com.br/developers/peering/
* PeeringDB: https://www.peeringdb.com/net/14511

==== SourceForge.Net ====
* Banda mínima: 150Mbps
* Hardware por conta do provedor, com 8TB de disco no mínimo.
* Email: staff@sourceforge.net
* Informações: https://sourceforge.net/p/forge/documentation/Join%20as%20a%20Mirror/

==== Microsoft ====
* Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo)
* Email: ispnode@microsoft.com
* Informações: https://peering.azurewebsites.net/Peering/Caching
* PeeringDB: http://as8075.peeringdb.com/

==== CloudFlare ====
* Hardware fornecido pela CloudFlare.
* Conexão para os equipamentos em 40GbE ou 100GbE.
* Espaço em rack para acomodação dos equipamentos.
* Conectividade para fazer o cache-fill dos servidores de cache.
* Conectividade para gerência remota da CloudFlare.
* Banda mínima: em revisão junto ao planejamento da nova geração dos servidores, avaliação caso a caso no momento (edição solicitada por Ticiane da Cloudflare).
* PeeringDB: https://www.peeringdb.com/net/4224
* Informações: ticiane@cloudflare.com

===Peerings - Sessões Bilaterais===
É possível também solicitar diretamente à alguns ASNs o estabelecimento de uma sessão bilateral através de algum dos IX onde ambos os ASNs estejam presentes (para saber mais consulte [[Modelos_Interconexão]]). Em alguns casos existe um tráfego mínimo para estabelecimento desta sessão, portanto sempre que possível verifique através de sistemas de monitoramento internos a quantidade de tráfego trocada entre ambos ASNs antes de fazer contato para solicitação de peering.

Na maioria dos casos os prefixos anunciados para os Route Servers são os mesmos anunciados na sessão bilateral, porém existem também casos onde isso pode ser diferente o que justifica o estabelecimento da sessão ou ainda para permitir ao ASN um melhor controle sobre os anúncios para cada um desses ASNs.Por padrão a sessão é estabelecida na mesma VLAN do ATM v4 e v6, a não ser que exista alguma motivação para que seja estabelecida através de uma VLAN Bilateral.

Também existem casos de conteúdos como a Microsoft que anunciou recentemente a saída dos Route Servers, portanto em casos como esses é necessário estabelecer uma sessão bilateral para que exista troca de tráfego direta entre ambos os ASNs.

Antes de solicitar o estabelecimento de uma sessão bilateral através do IX recomenda-se deixar a configuração pronta no seu roteador para agilizar o processo.

A listagem não exaustiva abaixo apresenta alguns ASNs que são conhecidos por estabelecerem sessões bilaterais no IX-SP:
====Akamai====
*Email: peering@akamai.com e peering-tix@akamai.com
*PeeringDB: https://www.peeringdb.com/net/2
====Edgecast Verizon Digital Media====
*Email: peering@verizondigitalmedia.com
*Solicitação: peering@verizondigitalmedia.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>
====Microsoft====
*Email: peering@microsoft.com
*Solicitação: http://www.microsoft.com/peering
*PeeringDB: [https://www.peeringdb.com/net/694 http://as8075.peeringdb.com/]

==== Hurricane Electric ====
* Email: peering@he.net
* Email NOC: noc@he.net (após sessão estar ativada)
* Informações: http://he.net/peering.html
* PeeringDB: https://www.peeringdb.com/net/291
A Hurricane Electric oferece também Trânsito IPv6 gratuito através de sessão bilateral. Para solicitar envie um email para ipv6@he.net

====LinkedIn====
*Email: peering@linkedin.com
*PeeringDB: https://www.peeringdb.com/net/4231
====CloudFlare====
*Email: peering@cloudflare.com
*PeeringDB: https://www.peeringdb.com/net/4224
====CDNetworks====
*Email: peering@cdnetworks.com
*PeeringDB: https://www.peeringdb.com/net/1372

==== Azion ====
* Banda mínima: 5 Gbps (Seletiva)
* Email: peering@azion.com
* PeeringDB: https://www.peeringdb.com/net/14511

==== Twitch TV ====
* Email: peering@twitch.tv
* Contato: https://noc.twitch.tv/
* PeeringDB: https://www.peeringdb.com/asn/46489
* Política: Seletiva

==== Oath/Yahoo ====
* Email: peering-requests@oath.com
* Informações: https://peering.oath.com/policy
* PeeringDB: https://www.peeringdb.com/asn/10310/
* Política: Seletiva

==== Netflix ====
* Banda Minima: 3Gbps
* Email: peering@netflix.com
* PeeringDB: https://www.peeringdb.com/net/457
* Nota: De acordo com informação publicada no PeeringDB o Netflix anuncia os mesmos prefixos para os Route Servers do ATM e para as Sessões Bilaterais. Por isso não costumam fechar Sessões Bilaterais via IX a não ser em casos complexos de engenharia de tráfego e orientam os participantes a utilizarem as communities disponibilizadas pelo IX.br para manobrarem o tráfego.

==== Google ====
* Email: noc@google.com
* Solicitação: <nowiki>https://isp.google.com/iwantpeering</nowiki>
* PeeringDB: https://www.peeringdb.com/net/433
* Necessário ter registrado em IRR, todos os prefixos anunciados para o Google. https://support.google.com/interconnect#topic=9326690

==== Facebook ====
* Email: peering@fb.com
* Informação e Solicitar (on-line): https://www.facebook.com/peering/
* PeeringDB: https://www.peeringdb.com/net/979
* Política: Seletiva
* Nota: O estabelecimento das sessões bilaterais é sempre através da Vlan do ATM.

==== Amazon ====
* Email: peering@amazon.com
* PeeringDB: https://www.peeringdb.com/net/1418
* Política: Seletiva

==== SoftLayer ====
* Email: peering@softlayer.com
* PeeringDB: https://www.peeringdb.com/asn/36351
* Política: Seletiva

==== RiotGames ====
* Email: peering@riotgames.com
* PeeringDB: https://www.peeringdb.com/asn/6507
* Política: Seletiva

==== i3D.net / Ubisoft ====
* Email: peering@i3d.net
* PeeringDB: https://www.peeringdb.com/asn/49544
* Política: Seletiva

==== Twitter ====
* Banda mínima: 100 Mbps
* Email: peering@twitter.com
* PeeringDB: https://www.peeringdb.com/asn/13414
* Política: Seletiva

==== Globo ====
* Email: peering@peering.globo
* Informações: https://peering.globo
* PeeringDB: https://www.peeringdb.com/net/5703
* Locais: https://peering.globo
* Troubleshooting: https://browserreport.globo.com/isp

==== Tencent ====
* Email: peering@tencent.com
* Informações: [https://peering.tencent.com/peering/peering_form <nowiki>https://peering.tencent.com/peering/</nowiki>peering_form]
* PeeringDB: https://www.peeringdb.com/asn/132203

===PNIs - Private Network Interconnection===
PNIs são interconexões privadas realizadas diretamente entre dois ASNs sem o intermédio de um terceiro (entenda PNI em: [[Modelos_Interconexão]]). Geralmente é um ''cross-connect'' ou ''golden-jumper'' entre os racks das duas empresas em um mesmo Datacenter onde ambas estejam presentes.No [https://www.peeringdb.com/ PeeringDB] é possível verificar os Datacenters que as CDNs estão presentes e onde existe possibilidade de solicitar um PNI olhando na seção "Private Peering Facilities".

Uma das vantagens de um PNI é a de por se tratar de uma conexão direta não esta suscetível à possíveis problemas causados por exemplo na matriz de um IX aonde ambos ASN já trocam tráfego. Além disso por se tratar de uma conexão dedicada a banda toda disponível na porta é dedicada àquele tráfego entre os dois ASNs aliviando assim outras portas de peering para outros tipos de tráfegos.

Algumas CDNs embora grandes optam por não disponibilizar a modalidade de interconexão através de PNI restringindo assim à troca de tráfego através do IX ou através de um servidor de CDN que é instalado dentro do backbone do ISP.

Normalmente envolve um custo que é o do ''cross-connect'' ou ''golden-jumper'' que pode ser pago por uma das partes ou dividido igualmente entre ambas. Para que o parceiro ou você possa solicitar este cross, será necessário o envio de um LoA (Letter of Authorization) indicando que a parte remota está autorizando a passado do cabeamento em sua rack, caso você não saiba como criar esse LoA, verifique a sessão download do portal do parceiro ou solicite a seu parceiro um modelo, você também pode se basear neste exemplo fornecido pelo Google https://isp.google.com/static/downloads/LOA.pdf.

A listagem abaixo contém as informações em quais Datacenters é possível ter um PNI com algumas dessas CDNs:
====Facebook====
*Banda mínima: 1 Gbps
*Email: peering@fb.com
*Datacenters: Equinix-SP2, Equinix-SP4 e Equinix-RJ1
*PeeringDB: https://www.peeringdb.com/net/979
*Informações: https://wiki.brasilpeeringforum.org/images/4/4e/Peer-pni-parameters-facebook.pdf
====Google====
*Informações: https://peering.google.com/#/options/peering
*Solicitação: http://isp.google.com/iwantpeering
*Datacenters: Equinix-SP2 (através de transporte), Equinix-SP4, Level 3 - Cotia e Level 3 - Rio de Janeiro.
*PeeringDB: https://www.peeringdb.com/net/433<nowiki/>https://www.peeringdb.com/net/4319
*Necessário ter registrado em IRR, todos os p<nowiki/>refixos anunciados para o Google. https://support.google.com/interconnect#topic=9326690
*Modelo LoA: [https://isp.google.com/static/downloads/LOA.pdf https://isp.google.com/static/do]<nowiki/>[https://isp.google.com/static/downloads/LOA.pdf wnloads/LOA.pdf]
====Edgecast Verizon Digital Media====
*Banda mínima: 1 Gbps
*Email: peering@verizondigitalmedia.com
*Solicitação: peering@verizondigitalmedia.com / CarrierRelations@edgecast.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>
*Datacenters: Equinix-SP4, Equinix-RJ2
==== Netflix ====
* Banda Mínima: 3 Gbps
* Email: peering@netflix.com
* Informações: https://openconnect.netflix.com/en/guidelines/
* Datacenters: Equinix-SP2, Equinix-RJ1, NIC-JD, Commcorp Porto Alegre-PAE1, ETICE-Fortaleza
* PeeringDB: https://www.peeringdb.com/net/457

==== Akamai ====
* Banda Mínima: 5 Gbps
* Email: netsupport-tix@akamai.com
* Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
*PeeringDB: https://www.peeringdb.com/net/2
*Datacenters: Equinix-SP4, Teleporto-RJ

==== Azion ====
* Banda mínima: 20 Gbps
* Email: peering@azion.com / noc@azion.com
* Informações: https://www.azion.com.br/developers/peering/
* Datacenters: Ascenty Campinas, Commcorp-BSA2, Commcorp-FNS1, Commcorp-PAE1, Equinix-SP3, Level 3 - Cotia, GVT - Curitiba, Globenet - Fortaleza, NIC-JD, PIX Adylnet-PAE, PIX G8 - São Paulo, PIX Vogel - Porto Alegre, Tascom - Salvador
* PeeringDB: https://www.peeringdb.com/net/14511
==== Twitch TV ====
* Banda mínima: 2.5 Gbps
* Email: interconnection@twitch.tv
* Contato: https://noc.twitch.tv/
* Datacenters: Equinix-SP2, Level 3 - Cotia, Level 3 - Rio de Janeiro
* PeeringDB: https://www.peeringdb.com/asn/46489
==== Globo ====
* Banda mínima: Não aplicável
* Requisitos: Conexões com fibras apagada de 10Gbps ou 100Gbps, fornecimento dos cordões necessários na localidade.
* Email: peering@peering.globo
* Informações: https://peering.globo
* PeeringDB: https://www.peeringdb.com/net/5703
* Locais: https://peering.globo
* Troubleshooting: https://browserreport.globo.com/isp
[[Categoria:Interconexão]]

CDN Peering e PNI - Brasil

2021-04-29T20:46:12Z

Canton: Retirado contatos de NOC das áreas de peering e CDN, pois não deveriam estar listados ali.

===Introdução===
Esta página contém informações úteis para operadores de redes e ISPs com relação à solicitação de servidores de CDNs, estabelecimento de uma sessão Bilateral em algum dos IXs ou para a solicitação de PNIs nos Datacenters aonde ASNs, geralmente grandes geradores de conteúdos, estão presentes.

É importante destacar que as informações aqui apresentadas (ex: tráfego necessário para solicitar servidores de CDN) mudam de forma bastante dinâmica e de acordo com as regras próprias estabelecidas pelos próprios geradores de conteúdo, portanto este guia serve como referência para o momento que ele foi escrito ou atualizado pela última vez.

Um recomendação importante a ser feita é que antes de fazer a solicitação de servidores de CDN ou de um PNI por exemplo, é importante realizar uma avaliação detalhada do tráfego que o seu ASN troca com os ASNs desses geradores de conteúdo. Ferramentas como NetFlow e [https://www.peeringdb.com/ PeeringDB] auxiliam bastante. Cerifique-se que você atende à TODOS os requisitos antes de fazer a solicitação, principalmente se possui a quantidade de mínima de tráfego para ser elegível. Esses servidores somente são enviados aos ISPs no caso das empresas de CDN verificarem que eles trazem benefícios para ambos CDN e ISP, caso contrário dificilmente serão enviados. Hospedar e manter um servidor de CDN é algo que demanda recursos do provedor como espaço em rack, portas de switch e principalmente um consumo razoável de energia elétrica por isso uma avaliação criteriosa é bastante importante antes de realizar a solicitação.

Outro detalhe imprescindível na hora de solicitar um servidor de CDN, Peering por Sessão Bilateral ou PNI é o IPv6. Devido à crescente importância deste protocolo algumas CDNs hoje em dia tem colocado restrições caso você não seja capaz de estabelecer uma sessão IPv6 com eles.Além disso caso você possua IPv6 em seu backbone porém ainda não está distribuindo para os usuários residencias e possui apenas CGNAT44 a maioria das grandes CDNs já possuem suporte completo à IPv6 portanto uma parte significativa do seu tráfego poderia estar fluindo preferencialmente em IPv6 ao invés de estar passando por equipamentos que fazem o GGNAT a um custo computacional maior além de ter a identificação do usuário facilitada em caso de uma solicitação baseada no Marco Civil da Internet.

A maioria das CDNs exigem que as informações sobre o ASN solicitante estejam atualizadas no PeeringDB portanto antes de solicitar é uma boa prática conferi-las.

Você pode acessar a URL a seguir para entender melhor o funcionamento de sessões Peering: [[Modelos_Interconexão]]

''Última atualização - '''01/07/2020'''''

=== Informações importantes sobre termos de contrato, NDA, propriedade intelectual, uso impróprio de logomarcas, e outras práticas que devem ser abolidas pelo ISP ===
Atenção senhores provedores de acesso à Internet (ISP). Esta seção do presente documento visa esclarecer algumas informações importantes sobre a legitimidade de certas práticas que tem sido detectadas entre os ISPs, generalizando aqui, em particular no que diz respeito ao uso impróprio de recursos providos pelas redes de fornecimento de conteúdo (CDN), e também de algumas violações graves dos termos estabelecidos em regime de contrato entre a detentora da tecnologia (empresa de conteúdo que fornece a CDN) e o ISP. Mas, antes, permita-nos explicar-lhes o que são CDNs, suas características e benefícios gerais:

Como é de conhecimento comum entre os ISPs, há basicamente dois tipos de arquiteturas ou abordagens no que diz respeito às CDNs: ''Bring-Home'' e ''Enter-Deep Cache''. Foquemos no segundo caso (''Enter-Deep''), que é o tipo que mais se assemelha às CDNs que os ISPs qualificados podem solicitar e receber. A arquitetura ''Enter-Deep Cache'' possui como estratégia estar profundamente fincada dentro do ambiente de redes do ISP, geralmente sendo adotados na forma de clusters. Os benefícios proporcionados pelas CDNs são indiscutíveis:
* Fornecimento de conteúdo de baixa latência, o que, por sua vez, promove uma experiência bem fluída de navegação e interação dos usuários/clientes do ISP.
* Em combinação com sessões de peering privado (PNI) e peering público (IX), a arquitetura Enter-Deep promove economias bastante significativas nos custos operacionais do ISP, e em diversas áreas, especialmente o dimensionamento de recursos e manutenção de custos recorrentes com a contratação de links de trânsito IP.
* Combinada com outras boas práticas de engenharia de redes, engenharia de tráfego, e segurança geral do ASN, as redes de fornecimento de conteúdo contribuem muito substancialmente para aprimoramentos de diversos KPIs do negócio.
* O assinante (cliente) é beneficiado por contar com uma Internet "mais fluida", e o ISP é beneficiado por poder fornecer uma experiência mais atraente de interação de seus clientes com a Internet, além da redução de custos aliada ao aprimoramento de indicadores-chave importantes do negócio.
No entanto, o ISP precisa entender uma realidade: apesar dos benefícios mútuos para cliente e ISP, e até mesmo para a detentora da tecnologia (empresa de conteúdo), que consegue engajar e monetizar melhor seus (também) clientes, ter uma CDN é na verdade um '''privilégio'''. O que muitos ISPs fazem é tratar a CDN como um "direito" deles, e isto é completamente equivocado. Mesmo que o ISP reúna os requisitos para a solicitação e obtenção de CDN - aliás, mal sabem, a solicitação não é para "obter uma CDN", e sim para participar do programa de afiliados da empresa de conteúdo - a resposta/decisão será sempre por conta da detentora da tecnologia, que avaliará diversas métricas para determinar se é vantajoso ou não para ela disponibilizar a sua tecnologia para aquele ISP. Ou seja, há uma relação mútua entre os beneficiados diretos "ISP e CDN" (generalizando o termo aqui); assim como é vantajoso (e sempre será!) para o ISP, tem que ser vantajoso, também, para a empresa dona daquela CDN. Repetindo: CDN não é direito, é privilégio.

'''Práticas ilegais exercitadas por alguns ISPs:'''
* Amplificar e manipular artificialmente o tráfego via práticas escusas, recheadas de alguns desvios éticos, com o intuito de atingir o requerimento mínimo de consumo exigido pela detentora da CDN.
* Promover abertamente na sua cesta de produtos e soluções que aquele ISP "vende tráfego de CDNs". O ISP não pode vender tráfego de CDN direta ou abertamente, mas poderá costurar um produto que contemple isto de forma correta e legítima. O ISP poderá fornecer tráfego de CDNs dentro de um produto de "Trânsito IP Parcial" ou nome qualquer, desde que não divulgue que "vende CDN" e muito menos expondo logomarcas, fotos dos servidores, etc.
* Não somente vender abertamente o tráfego de CDNs, as vezes usando nomes um tanto criativos, como "IP Confinado" e similares, mas ainda expor as logomarcas das empresas (ex: Netflix, Facebook, Google, Akamai, etc.). Isto é completamente ilegal.
* Publicam fotos de seus data centers com o propósito de expor aos seus clientes e prospecções que possuem "servidores de CDN da empresa X, Y e Z". Isto é igualmente não permitido.
Com a exceção do primeiro caso (manipulação artificial do tráfego), os demais casos não tem relação com aspectos mais técnicos envolvendo redes, e sim com outras questões que passam completamente despercebidas por estes indivíduos e empresas. Os contratos que são estabelecidos entre empresas fornecedoras de conteúdo e os ISPs vão um tanto além das questões puramente técnicas, pois há uma preocupação enorme envolvendo uma cadeia inteira de partes interessadas no capital que flui com estes conteúdos, do produtor, passando pelo distribuidor, depois pelo ISP, e, por último, para os clientes. Ou seja, questões relacionadas à proteção de marcas (branding), uso inadequado de logomarcas e afins, propriedade intelectual, pagamento de royalties, e os acordos milionários entre as produtoras de conteúdos e as distribuidoras de conteúdo. A questão toda vai bem além do "tequiniquês".

Quando um ISP viola estes termos, ele estará desafiando uma cadeia inteira de partes interessadas que podem tomar ações contra o ISP. Na melhor das hipóteses, o ISP é alertado. Frequentemente, o ISP perde e tem as CDNs recolhidas de sua rede, além de ser banido permanentemente do programa. Há ainda o risco de outras ações serem executadas contra o ISP por uso indevido de imagem, violação de direitos autorais e/ou de propriedade intelectual.

Esperamos que estas informações sejam úteis para todos vocês, e colocamo-nos à disposição para esclarecermos suas dúvidas. Utilizem as nossas listas de discussão!

===CDNs===
As CDNs, baseadas em critérios próprios, definem condições em que um servidor pode ser enviado para ser instalado dentro do backbone de um ISP para otimizar a entrega de conteúdo para o usuário final. Isso é vantajoso para a CDN que melhora a qualidade na entrega do conteúdo, para o usuário final e também para ISP pois além de economizar no uso dos links de upstream são capazes de prover uma melhor experiência para seus usuários.

O tráfego atual de referência para solicitação de servidores de algumas CDN está na faixa dos 2 a 5 Gbps, porém existem condições que isso pode ser flexibilizado à depender da região e da disponibilidade de outros Trânsitos IP presentes serem capazes de distribuir aquele conteúdo. Via de regra em uma grande cidade ou região populosa com acesso à IX que já possui servidores de cache ou uma quantidade razoável de Trânsitos IP é bastante provável que o valor de referência não seja flexibilizado pelas CDNs.
====Akamai (AANP)====
*Banda mínima: 10 Gbps
*Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
*Documentação: https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf
*PeeringDB: https://www.peeringdb.com/net/2
====Apple====
*Banda mínima: 25 Gbps
*Informações: https://cache.edge.apple/
*Solicitação: https://cache.edge.apple/inquire
*PeeringDB: https://peeringdb.com/asn/714
*Nota: Como exigem uma quantidade de banda alta para o cache, evite entrar em contato caso seu tráfego não esteja ao menos com previsão de chegar ao mínimo nos próximos 12 meses. Como a Apple ainda não está no IX.Br SP, dê preferencia por entrar em contato sugerindo que eles mantenham pontos de presença no Brasil, será muito mais eficiente.
====Facebook (FNA)====
*Banda mínima: 5 Gbps
*Email: fna@fb.com
*PeeringDB: https://www.peeringdb.com/net/979
*Nota: O Facebook analisa apenas o tráfego trocado com o ASN solicitante e não de seus respectivos clientes de trânsito (demais ASNs). Também não considera possibilidade da soma do tráfego trocado com os ASNs desejando compartilhar um FNA em um IX Privado ou interconexão bilateral, independente de um contrato existente entre as partes.
*Prefixos CGNAT: Não suportados oficialmente. Considere uso de IPv6.
====Google (GGC)====
*Banda mínima: 3 Gbps
*Informações: https://peering.google.com/#/options/google-global-cache
*Solicitação: http://isp.google.com/iwantpeering
*Instalação: https://www.gstatic.com/isp/docs/ggc-installation.pdf
*Troubleshooting: https://cloud.google.com/cdn/docs/support
*Portal: https://isp.google.com/dashboard/
* PeeringDB: https://www.peeringdb.com/net/433<nowiki/>https://www.peeringdb.com/net/4319
* Prefixos CGNAT: Aceitos com community. Acess<nowiki/>e a documentação no portal.

====Edgecast Verizon Digital Media (EC)====
*Banda mínima: 10 Gbps
*Email: peering@verizondigitalmedia.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/
*Solicitação: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>

*
====Netflix (OCA)====
*Banda mínima: 5 Gbps (SP, RJ, RS ,CE e BA) e 2 Gbps (Demais Estados)
*Solicitação: https://openconnect.netflix.com/en/request/
*Instalação: https://openconnect.netflix.com/deploymentguide.pdf
*Troubleshooting: https://openconnect.netflix.com/en/faq/
*Portal: https://my.oc.netflix.com/
*PeeringDB: https://www.peeringdb.com/net/457
*Prefixos CGNAT: Não suportado oficialmente. Considere uso de IPv6.

==== Azion (ANA) ====
* Banda mínima: 15 Gbps (Seletiva)
* Email: cdn@azion.com
* Informações: https://www.azion.com.br/developers/peering/
* PeeringDB: https://www.peeringdb.com/net/14511

==== SourceForge.Net ====
* Banda mínima: 150Mbps
* Hardware por conta do provedor, com 8TB de disco no mínimo.
* Email: staff@sourceforge.net
* Informações: https://sourceforge.net/p/forge/documentation/Join%20as%20a%20Mirror/

==== Microsoft ====
* Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo)
* Email: ispnode@microsoft.com
* Informações: https://peering.azurewebsites.net/Peering/Caching
* PeeringDB: http://as8075.peeringdb.com/

===Peerings - Sessões Bilaterais===
É possível também solicitar diretamente à alguns ASNs o estabelecimento de uma sessão bilateral através de algum dos IX onde ambos os ASNs estejam presentes (para saber mais consulte [[Modelos_Interconexão]]). Em alguns casos existe um tráfego mínimo para estabelecimento desta sessão, portanto sempre que possível verifique através de sistemas de monitoramento internos a quantidade de tráfego trocada entre ambos ASNs antes de fazer contato para solicitação de peering.

Na maioria dos casos os prefixos anunciados para os Route Servers são os mesmos anunciados na sessão bilateral, porém existem também casos onde isso pode ser diferente o que justifica o estabelecimento da sessão ou ainda para permitir ao ASN um melhor controle sobre os anúncios para cada um desses ASNs.Por padrão a sessão é estabelecida na mesma VLAN do ATM v4 e v6, a não ser que exista alguma motivação para que seja estabelecida através de uma VLAN Bilateral.

Também existem casos de conteúdos como a Microsoft que anunciou recentemente a saída dos Route Servers, portanto em casos como esses é necessário estabelecer uma sessão bilateral para que exista troca de tráfego direta entre ambos os ASNs.

Antes de solicitar o estabelecimento de uma sessão bilateral através do IX recomenda-se deixar a configuração pronta no seu roteador para agilizar o processo.

A listagem não exaustiva abaixo apresenta alguns ASNs que são conhecidos por estabelecerem sessões bilaterais no IX-SP:
====Akamai====
*Email: peering@akamai.com e peering-tix@akamai.com
*PeeringDB: https://www.peeringdb.com/net/2
====Edgecast Verizon Digital Media====
*Email: peering@verizondigitalmedia.com
*Solicitação: peering@verizondigitalmedia.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>
====Microsoft====
*Email: peering@microsoft.com
*Solicitação: http://www.microsoft.com/peering
*PeeringDB: [https://www.peeringdb.com/net/694 http://as8075.peeringdb.com/]

==== Hurricane Electric ====
* Email: peering@he.net
* Email NOC: noc@he.net (após sessão estar ativada)
* Informações: http://he.net/peering.html
* PeeringDB: https://www.peeringdb.com/net/291
A Hurricane Electric oferece também Trânsito IPv6 gratuito através de sessão bilateral. Para solicitar envie um email para ipv6@he.net

====LinkedIn====
*Email: peering@linkedin.com
*PeeringDB: https://www.peeringdb.com/net/4231
====CloudFlare====
*Email: peering@cloudflare.com
*PeeringDB: https://www.peeringdb.com/net/4224
====CDNetworks====
*Email: peering@cdnetworks.com
*PeeringDB: https://www.peeringdb.com/net/1372

==== Azion ====
* Banda mínima: 5 Gbps (Seletiva)
* Email: peering@azion.com
* PeeringDB: https://www.peeringdb.com/net/14511

==== Twitch TV ====
* Email: peering@twitch.tv
* Contato: https://noc.twitch.tv/
* PeeringDB: https://www.peeringdb.com/asn/46489
* Política: Seletiva

==== Oath/Yahoo ====
* Email: peering-requests@oath.com
* Informações: https://peering.oath.com/policy
* PeeringDB: https://www.peeringdb.com/asn/10310/
* Política: Seletiva

==== Netflix ====
* Banda Minima: 3Gbps
* Email: peering@netflix.com
* PeeringDB: https://www.peeringdb.com/net/457
* Nota: De acordo com informação publicada no PeeringDB o Netflix anuncia os mesmos prefixos para os Route Servers do ATM e para as Sessões Bilaterais. Por isso não costumam fechar Sessões Bilaterais via IX a não ser em casos complexos de engenharia de tráfego e orientam os participantes a utilizarem as communities disponibilizadas pelo IX.br para manobrarem o tráfego.

==== Google ====
* Email: noc@google.com
* Solicitação: <nowiki>https://isp.google.com/iwantpeering</nowiki>
* PeeringDB: https://www.peeringdb.com/net/433

==== Facebook ====
* Email: peering@fb.com
* Informação e Solicitar (on-line): https://www.facebook.com/peering/
* PeeringDB: https://www.peeringdb.com/net/979
* Política: Seletiva
* Nota: O estabelecimento das sessões bilaterais é sempre através da Vlan do ATM.

==== Amazon ====
* Email: peering@amazon.com
* PeeringDB: https://www.peeringdb.com/net/1418
* Política: Seletiva

==== SoftLayer ====
* Email: peering@softlayer.com
* PeeringDB: https://www.peeringdb.com/asn/36351
* Política: Seletiva

==== RiotGames ====
* Email: peering@riotgames.com
* PeeringDB: https://www.peeringdb.com/asn/6507
* Política: Seletiva

==== i3D.net / Ubisoft ====
* Email: peering@i3d.net
* PeeringDB: https://www.peeringdb.com/asn/49544
* Política: Seletiva

==== Twitter ====
* Banda mínima: 100 Mbps
* Email: peering@twitter.com
* PeeringDB: https://www.peeringdb.com/asn/13414
* Política: Seletiva

==== Globo ====
* Email: peering@peering.globo
* Informações: https://peering.globo
* PeeringDB: https://www.peeringdb.com/net/5703

==== Tencent ====
* Email: peering@tencent.com
* Informações: [https://peering.tencent.com/peering/peering_form <nowiki>https://peering.tencent.com/peering/</nowiki>peering_form]
* PeeringDB: https://www.peeringdb.com/asn/132203

===PNIs - Private Network Interconnection===
PNIs são interconexões privadas realizadas diretamente entre dois ASNs sem o intermédio de um terceiro (entenda PNI em: [[Modelos_Interconexão]]). Geralmente é um ''cross-connect'' ou ''golden-jumper'' entre os racks das duas empresas em um mesmo Datacenter onde ambas estejam presentes.No [https://www.peeringdb.com/ PeeringDB] é possível verificar os Datacenters que as CDNs estão presentes e onde existe possibilidade de solicitar um PNI olhando na seção "Private Peering Facilities".

Uma das vantagens de um PNI é a de por se tratar de uma conexão direta não esta suscetível à possíveis problemas causados por exemplo na matriz de um IX aonde ambos ASN já trocam tráfego. Além disso por se tratar de uma conexão dedicada a banda toda disponível na porta é dedicada àquele tráfego entre os dois ASNs aliviando assim outras portas de peering para outros tipos de tráfegos.

Algumas CDNs embora grandes optam por não disponibilizar a modalidade de interconexão através de PNI restringindo assim à troca de tráfego através do IX ou através de um servidor de CDN que é instalado dentro do backbone do ISP.

Normalmente envolve um custo que é o do ''cross-connect'' ou ''golden-jumper'' que pode ser pago por uma das partes ou dividido igualmente entre ambas. Para que o parceiro ou você possa solicitar este cross, será necessário o envio de um LoA (Letter of Authorization) indicando que a parte remota está autorizando a passado do cabeamento em sua rack, caso você não saiba como criar esse LoA, verifique a sessão download do portal do parceiro ou solicite a seu parceiro um modelo, você também pode se basear neste exemplo fornecido pelo Google https://isp.google.com/static/downloads/LOA.pdf.

A listagem abaixo contém as informações em quais Datacenters é possível ter um PNI com algumas dessas CDNs:
====Facebook====
*Banda mínima: 1 Gbps
*Email: peering@fb.com
*Datacenters: Equinix-SP2, Equinix-SP4 e Equinix-RJ1
*PeeringDB: https://www.peeringdb.com/net/979
*Informações: https://wiki.brasilpeeringforum.org/images/4/4e/Peer-pni-parameters-facebook.pdf
====Google====
*Informações: https://peering.google.com/#/options/peering
*Solicitação: http://isp.google.com/iwantpeering
*Datacenters: Equinix-SP2 (através de transporte), Equinix-SP4, Level 3 - Cotia e Level 3 - Rio de Janeiro.
*PeeringDB: https://www.peeringdb.com/net/433<nowiki/>https://www.peeringdb.com/net/4319
*Modelo LoA: [https://isp.google.com/static/downloads/LOA.pdf https://isp.google.com/static/do]<nowiki/>[https://isp.google.com/static/downloads/LOA.pdf wnloads/LOA.pdf]
====Edgecast Verizon Digital Media====
*Banda mínima: 1 Gbps
*Email: peering@verizondigitalmedia.com
*Solicitação: peering@verizondigitalmedia.com / CarrierRelations@edgecast.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>
*Datacenters: Equinix-SP4, Equinix-RJ2
==== Netflix ====
* Banda Mínima: 3 Gbps
* Email: peering@netflix.com
* Informações: https://openconnect.netflix.com/en/guidelines/
* Datacenters: Equinix-SP2, Equinix-RJ1, NIC-JD, Commcorp Porto Alegre-PAE1, ETICE-Fortaleza
* PeeringDB: https://www.peeringdb.com/net/457

==== Akamai ====
* Banda Mínima: 5 Gbps
* Email: netsupport-tix@akamai.com
* Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
*PeeringDB: https://www.peeringdb.com/net/2
*Datacenters: Equinix-SP4, Teleporto-RJ

==== Azion ====
* Banda mínima: 20 Gbps
* Email: peering@azion.com / noc@azion.com
* Informações: https://www.azion.com.br/developers/peering/
* Datacenters: Ascenty Campinas, Commcorp-BSA2, Commcorp-FNS1, Commcorp-PAE1, Equinix-SP3, Level 3 - Cotia, GVT - Curitiba, Globenet - Fortaleza, NIC-JD, PIX Adylnet-PAE, PIX G8 - São Paulo, PIX Vogel - Porto Alegre, Tascom - Salvador
* PeeringDB: https://www.peeringdb.com/net/14511
==== Twitch TV ====
* Banda mínima: 2.5 Gbps
* Email: interconnection@twitch.tv
* Contato: https://noc.twitch.tv/
* Datacenters: Equinix-SP2, Level 3 - Cotia, Level 3 - Rio de Janeiro
* PeeringDB: https://www.peeringdb.com/asn/46489
==== Globo ====
* Email: peering@peering.globo
* Informações: https://peering.globo
* PeeringDB: https://www.peeringdb.com/net/5703
* Locais: Rio de Janeiro: Jacarepaguá, São Paulo: Alameda Santos, Fortaleza: Datacenter Angola Cables e TV Verdes Mares, Brasília: Asa Norte, Belo Horizonte: Caiçaras, Recife: Santo Amaro
[[Categoria:Interconexão]]

CDN Peering e PNI - Brasil

2021-04-29T20:39:07Z

Canton: /* Facebook */ Solicitação do Facebook feita ao Rogério Mariano para remoção do endereço de noc da sessão de peering

===Introdução===
Esta página contém informações úteis para operadores de redes e ISPs com relação à solicitação de servidores de CDNs, estabelecimento de uma sessão Bilateral em algum dos IXs ou para a solicitação de PNIs nos Datacenters aonde ASNs, geralmente grandes geradores de conteúdos, estão presentes.

É importante destacar que as informações aqui apresentadas (ex: tráfego necessário para solicitar servidores de CDN) mudam de forma bastante dinâmica e de acordo com as regras próprias estabelecidas pelos próprios geradores de conteúdo, portanto este guia serve como referência para o momento que ele foi escrito ou atualizado pela última vez.

Um recomendação importante a ser feita é que antes de fazer a solicitação de servidores de CDN ou de um PNI por exemplo, é importante realizar uma avaliação detalhada do tráfego que o seu ASN troca com os ASNs desses geradores de conteúdo. Ferramentas como NetFlow e [https://www.peeringdb.com/ PeeringDB] auxiliam bastante. Cerifique-se que você atende à TODOS os requisitos antes de fazer a solicitação, principalmente se possui a quantidade de mínima de tráfego para ser elegível. Esses servidores somente são enviados aos ISPs no caso das empresas de CDN verificarem que eles trazem benefícios para ambos CDN e ISP, caso contrário dificilmente serão enviados. Hospedar e manter um servidor de CDN é algo que demanda recursos do provedor como espaço em rack, portas de switch e principalmente um consumo razoável de energia elétrica por isso uma avaliação criteriosa é bastante importante antes de realizar a solicitação.

Outro detalhe imprescindível na hora de solicitar um servidor de CDN, Peering por Sessão Bilateral ou PNI é o IPv6. Devido à crescente importância deste protocolo algumas CDNs hoje em dia tem colocado restrições caso você não seja capaz de estabelecer uma sessão IPv6 com eles.Além disso caso você possua IPv6 em seu backbone porém ainda não está distribuindo para os usuários residencias e possui apenas CGNAT44 a maioria das grandes CDNs já possuem suporte completo à IPv6 portanto uma parte significativa do seu tráfego poderia estar fluindo preferencialmente em IPv6 ao invés de estar passando por equipamentos que fazem o GGNAT a um custo computacional maior além de ter a identificação do usuário facilitada em caso de uma solicitação baseada no Marco Civil da Internet.

A maioria das CDNs exigem que as informações sobre o ASN solicitante estejam atualizadas no PeeringDB portanto antes de solicitar é uma boa prática conferi-las.

Você pode acessar a URL a seguir para entender melhor o funcionamento de sessões Peering: [[Modelos_Interconexão]]

''Última atualização - '''01/07/2020'''''

=== Informações importantes sobre termos de contrato, NDA, propriedade intelectual, uso impróprio de logomarcas, e outras práticas que devem ser abolidas pelo ISP ===
Atenção senhores provedores de acesso à Internet (ISP). Esta seção do presente documento visa esclarecer algumas informações importantes sobre a legitimidade de certas práticas que tem sido detectadas entre os ISPs, generalizando aqui, em particular no que diz respeito ao uso impróprio de recursos providos pelas redes de fornecimento de conteúdo (CDN), e também de algumas violações graves dos termos estabelecidos em regime de contrato entre a detentora da tecnologia (empresa de conteúdo que fornece a CDN) e o ISP. Mas, antes, permita-nos explicar-lhes o que são CDNs, suas características e benefícios gerais:

Como é de conhecimento comum entre os ISPs, há basicamente dois tipos de arquiteturas ou abordagens no que diz respeito às CDNs: ''Bring-Home'' e ''Enter-Deep Cache''. Foquemos no segundo caso (''Enter-Deep''), que é o tipo que mais se assemelha às CDNs que os ISPs qualificados podem solicitar e receber. A arquitetura ''Enter-Deep Cache'' possui como estratégia estar profundamente fincada dentro do ambiente de redes do ISP, geralmente sendo adotados na forma de clusters. Os benefícios proporcionados pelas CDNs são indiscutíveis:
* Fornecimento de conteúdo de baixa latência, o que, por sua vez, promove uma experiência bem fluída de navegação e interação dos usuários/clientes do ISP.
* Em combinação com sessões de peering privado (PNI) e peering público (IX), a arquitetura Enter-Deep promove economias bastante significativas nos custos operacionais do ISP, e em diversas áreas, especialmente o dimensionamento de recursos e manutenção de custos recorrentes com a contratação de links de trânsito IP.
* Combinada com outras boas práticas de engenharia de redes, engenharia de tráfego, e segurança geral do ASN, as redes de fornecimento de conteúdo contribuem muito substancialmente para aprimoramentos de diversos KPIs do negócio.
* O assinante (cliente) é beneficiado por contar com uma Internet "mais fluida", e o ISP é beneficiado por poder fornecer uma experiência mais atraente de interação de seus clientes com a Internet, além da redução de custos aliada ao aprimoramento de indicadores-chave importantes do negócio.
No entanto, o ISP precisa entender uma realidade: apesar dos benefícios mútuos para cliente e ISP, e até mesmo para a detentora da tecnologia (empresa de conteúdo), que consegue engajar e monetizar melhor seus (também) clientes, ter uma CDN é na verdade um '''privilégio'''. O que muitos ISPs fazem é tratar a CDN como um "direito" deles, e isto é completamente equivocado. Mesmo que o ISP reúna os requisitos para a solicitação e obtenção de CDN - aliás, mal sabem, a solicitação não é para "obter uma CDN", e sim para participar do programa de afiliados da empresa de conteúdo - a resposta/decisão será sempre por conta da detentora da tecnologia, que avaliará diversas métricas para determinar se é vantajoso ou não para ela disponibilizar a sua tecnologia para aquele ISP. Ou seja, há uma relação mútua entre os beneficiados diretos "ISP e CDN" (generalizando o termo aqui); assim como é vantajoso (e sempre será!) para o ISP, tem que ser vantajoso, também, para a empresa dona daquela CDN. Repetindo: CDN não é direito, é privilégio.

'''Práticas ilegais exercitadas por alguns ISPs:'''
* Amplificar e manipular artificialmente o tráfego via práticas escusas, recheadas de alguns desvios éticos, com o intuito de atingir o requerimento mínimo de consumo exigido pela detentora da CDN.
* Promover abertamente na sua cesta de produtos e soluções que aquele ISP "vende tráfego de CDNs". O ISP não pode vender tráfego de CDN direta ou abertamente, mas poderá costurar um produto que contemple isto de forma correta e legítima. O ISP poderá fornecer tráfego de CDNs dentro de um produto de "Trânsito IP Parcial" ou nome qualquer, desde que não divulgue que "vende CDN" e muito menos expondo logomarcas, fotos dos servidores, etc.
* Não somente vender abertamente o tráfego de CDNs, as vezes usando nomes um tanto criativos, como "IP Confinado" e similares, mas ainda expor as logomarcas das empresas (ex: Netflix, Facebook, Google, Akamai, etc.). Isto é completamente ilegal.
* Publicam fotos de seus data centers com o propósito de expor aos seus clientes e prospecções que possuem "servidores de CDN da empresa X, Y e Z". Isto é igualmente não permitido.
Com a exceção do primeiro caso (manipulação artificial do tráfego), os demais casos não tem relação com aspectos mais técnicos envolvendo redes, e sim com outras questões que passam completamente despercebidas por estes indivíduos e empresas. Os contratos que são estabelecidos entre empresas fornecedoras de conteúdo e os ISPs vão um tanto além das questões puramente técnicas, pois há uma preocupação enorme envolvendo uma cadeia inteira de partes interessadas no capital que flui com estes conteúdos, do produtor, passando pelo distribuidor, depois pelo ISP, e, por último, para os clientes. Ou seja, questões relacionadas à proteção de marcas (branding), uso inadequado de logomarcas e afins, propriedade intelectual, pagamento de royalties, e os acordos milionários entre as produtoras de conteúdos e as distribuidoras de conteúdo. A questão toda vai bem além do "tequiniquês".

Quando um ISP viola estes termos, ele estará desafiando uma cadeia inteira de partes interessadas que podem tomar ações contra o ISP. Na melhor das hipóteses, o ISP é alertado. Frequentemente, o ISP perde e tem as CDNs recolhidas de sua rede, além de ser banido permanentemente do programa. Há ainda o risco de outras ações serem executadas contra o ISP por uso indevido de imagem, violação de direitos autorais e/ou de propriedade intelectual.

Esperamos que estas informações sejam úteis para todos vocês, e colocamo-nos à disposição para esclarecermos suas dúvidas. Utilizem as nossas listas de discussão!

===CDNs===
As CDNs, baseadas em critérios próprios, definem condições em que um servidor pode ser enviado para ser instalado dentro do backbone de um ISP para otimizar a entrega de conteúdo para o usuário final. Isso é vantajoso para a CDN que melhora a qualidade na entrega do conteúdo, para o usuário final e também para ISP pois além de economizar no uso dos links de upstream são capazes de prover uma melhor experiência para seus usuários.

O tráfego atual de referência para solicitação de servidores de algumas CDN está na faixa dos 2 a 5 Gbps, porém existem condições que isso pode ser flexibilizado à depender da região e da disponibilidade de outros Trânsitos IP presentes serem capazes de distribuir aquele conteúdo. Via de regra em uma grande cidade ou região populosa com acesso à IX que já possui servidores de cache ou uma quantidade razoável de Trânsitos IP é bastante provável que o valor de referência não seja flexibilizado pelas CDNs.
====Akamai (AANP)====
*Banda mínima: 10 Gbps
*Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
*Documentação: https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf
*PeeringDB: https://www.peeringdb.com/net/2
====Apple====
*Banda mínima: 25 Gbps
*Informações: https://cache.edge.apple/
*Solicitação: https://cache.edge.apple/inquire
*PeeringDB: https://peeringdb.com/asn/714
*Nota: Como exigem uma quantidade de banda alta para o cache, evite entrar em contato caso seu tráfego não esteja ao menos com previsão de chegar ao mínimo nos próximos 12 meses. Como a Apple ainda não está no IX.Br SP, dê preferencia por entrar em contato sugerindo que eles mantenham pontos de presença no Brasil, será muito mais eficiente.
====Facebook (FNA)====
*Banda mínima: 5 Gbps
*Email: fna@fb.com
*PeeringDB: https://www.peeringdb.com/net/979
*Nota: O Facebook analisa apenas o tráfego trocado com o ASN solicitante e não de seus respectivos clientes de trânsito (demais ASNs). Também não considera possibilidade da soma do tráfego trocado com os ASNs desejando compartilhar um FNA em um IX Privado ou interconexão bilateral, independente de um contrato existente entre as partes.
*Prefixos CGNAT: Não suportados oficialmente. Considere uso de IPv6.
====Google (GGC)====
*Banda mínima: 3 Gbps
*Informações: https://peering.google.com/#/options/google-global-cache
*Solicitação: http://isp.google.com/iwantpeering
*Instalação: https://www.gstatic.com/isp/docs/ggc-installation.pdf
*Troubleshooting: https://cloud.google.com/cdn/docs/support
*Portal: https://isp.google.com/dashboard/
* PeeringDB: https://www.peeringdb.com/net/433<nowiki/>https://www.peeringdb.com/net/4319
* Prefixos CGNAT: Aceitos com community. Acess<nowiki/>e a documentação no portal.

====Edgecast Verizon Digital Media (EC)====
*Banda mínima: 10 Gbps
*Email: peering@verizondigitalmedia.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/
*Solicitação: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>

*
====Netflix (OCA)====
*Banda mínima: 5 Gbps (SP, RJ, RS ,CE e BA) e 2 Gbps (Demais Estados)
*Solicitação: https://openconnect.netflix.com/en/request/
*Instalação: https://openconnect.netflix.com/deploymentguide.pdf
*Troubleshooting: https://openconnect.netflix.com/en/faq/
*Portal: https://my.oc.netflix.com/
*PeeringDB: https://www.peeringdb.com/net/457
*Prefixos CGNAT: Não suportado oficialmente. Considere uso de IPv6.

==== Azion (ANA) ====
* Banda mínima: 15 Gbps (Seletiva)
* Email: cdn@azion.com / peering@azion.com
* Informações: https://www.azion.com.br/developers/peering/
* PeeringDB: https://www.peeringdb.com/net/14511

==== SourceForge.Net ====
* Banda mínima: 150Mbps
* Hardware por conta do provedor, com 8TB de disco no mínimo.
* Email: staff@sourceforge.net
* Informações: https://sourceforge.net/p/forge/documentation/Join%20as%20a%20Mirror/

==== Microsoft ====
* Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo)
* Email: ispnode@microsoft.com
* Informações: https://peering.azurewebsites.net/Peering/Caching
* PeeringDB: http://as8075.peeringdb.com/

===Peerings - Sessões Bilaterais===
É possível também solicitar diretamente à alguns ASNs o estabelecimento de uma sessão bilateral através de algum dos IX onde ambos os ASNs estejam presentes (para saber mais consulte [[Modelos_Interconexão]]). Em alguns casos existe um tráfego mínimo para estabelecimento desta sessão, portanto sempre que possível verifique através de sistemas de monitoramento internos a quantidade de tráfego trocada entre ambos ASNs antes de fazer contato para solicitação de peering.

Na maioria dos casos os prefixos anunciados para os Route Servers são os mesmos anunciados na sessão bilateral, porém existem também casos onde isso pode ser diferente o que justifica o estabelecimento da sessão ou ainda para permitir ao ASN um melhor controle sobre os anúncios para cada um desses ASNs.Por padrão a sessão é estabelecida na mesma VLAN do ATM v4 e v6, a não ser que exista alguma motivação para que seja estabelecida através de uma VLAN Bilateral.

Também existem casos de conteúdos como a Microsoft que anunciou recentemente a saída dos Route Servers, portanto em casos como esses é necessário estabelecer uma sessão bilateral para que exista troca de tráfego direta entre ambos os ASNs.

Antes de solicitar o estabelecimento de uma sessão bilateral através do IX recomenda-se deixar a configuração pronta no seu roteador para agilizar o processo.

A listagem não exaustiva abaixo apresenta alguns ASNs que são conhecidos por estabelecerem sessões bilaterais no IX-SP:
====Akamai====
*Email: peering@akamai.com e peering-tix@akamai.com
*PeeringDB: https://www.peeringdb.com/net/2
====Edgecast Verizon Digital Media====
*Email: peering@verizondigitalmedia.com
*Solicitação: peering@verizondigitalmedia.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>
====Microsoft====
*Email: peering@microsoft.com
*Solicitação: http://www.microsoft.com/peering
*PeeringDB: [https://www.peeringdb.com/net/694 http://as8075.peeringdb.com/]

==== Hurricane Electric ====
* Email: peering@he.net
* Email NOC: noc@he.net (após sessão estar ativada)
* Informações: http://he.net/peering.html
* PeeringDB: https://www.peeringdb.com/net/291
A Hurricane Electric oferece também Trânsito IPv6 gratuito através de sessão bilateral. Para solicitar envie um email para ipv6@he.net

====LinkedIn====
*Email: peering@linkedin.com
*PeeringDB: https://www.peeringdb.com/net/4231
====CloudFlare====
*Email: peering@cloudflare.com
*PeeringDB: https://www.peeringdb.com/net/4224
====CDNetworks====
*Email: peering@cdnetworks.com
*PeeringDB: https://www.peeringdb.com/net/1372

==== Azion ====
* Banda mínima: 5 Gbps (Seletiva)
* Email: peering@azion.com / noc@azion.com
* PeeringDB: https://www.peeringdb.com/net/14511

==== Twitch TV ====
* Email: noc@twitch.tv / peering@twitch.tv
* Contato: https://noc.twitch.tv/
* PeeringDB: https://www.peeringdb.com/asn/46489
* Política: Seletiva

==== Oath/Yahoo ====
* Email: peering-requests@oath.com
* Informações: https://peering.oath.com/policy
* PeeringDB: https://www.peeringdb.com/asn/10310/
* Política: Seletiva

==== Netflix ====
* Banda Minima: 3Gbps
* Email: peering@netflix.com
* PeeringDB: https://www.peeringdb.com/net/457
* Nota: De acordo com informação publicada no PeeringDB o Netflix anuncia os mesmos prefixos para os Route Servers do ATM e para as Sessões Bilaterais. Por isso não costumam fechar Sessões Bilaterais via IX a não ser em casos complexos de engenharia de tráfego e orientam os participantes a utilizarem as communities disponibilizadas pelo IX.br para manobrarem o tráfego.

==== Google ====
* Email: noc@google.com
* Solicitação: <nowiki>https://isp.google.com/iwantpeering</nowiki>
* PeeringDB: https://www.peeringdb.com/net/433

==== Facebook ====
* Email: peering@fb.com
* Informação e Solicitar (on-line): https://www.facebook.com/peering/
* PeeringDB: https://www.peeringdb.com/net/979
* Política: Seletiva
* Nota: O estabelecimento das sessões bilaterais é sempre através da Vlan do ATM.

==== Amazon ====
* Email: peering@amazon.com
* PeeringDB: https://www.peeringdb.com/net/1418
* Política: Seletiva

==== SoftLayer ====
* Email: peering@softlayer.com
* PeeringDB: https://www.peeringdb.com/asn/36351
* Política: Seletiva

==== RiotGames ====
* Email: peering@riotgames.com
* PeeringDB: https://www.peeringdb.com/asn/6507
* Política: Seletiva

==== i3D.net / Ubisoft ====
* Email: peering@i3d.net
* PeeringDB: https://www.peeringdb.com/asn/49544
* Política: Seletiva

==== Twitter ====
* Banda mínima: 100 Mbps
* Email: peering@twitter.com
* PeeringDB: https://www.peeringdb.com/asn/13414
* Política: Seletiva

==== Globo ====
* Email: peering@peering.globo
* Informações: https://peering.globo
* PeeringDB: https://www.peeringdb.com/net/5703

==== Tencent ====
* Email: peering@tencent.com
* Informações: [https://peering.tencent.com/peering/peering_form <nowiki>https://peering.tencent.com/peering/</nowiki>peering_form]
* PeeringDB: https://www.peeringdb.com/asn/132203

===PNIs - Private Network Interconnection===
PNIs são interconexões privadas realizadas diretamente entre dois ASNs sem o intermédio de um terceiro (entenda PNI em: [[Modelos_Interconexão]]). Geralmente é um ''cross-connect'' ou ''golden-jumper'' entre os racks das duas empresas em um mesmo Datacenter onde ambas estejam presentes.No [https://www.peeringdb.com/ PeeringDB] é possível verificar os Datacenters que as CDNs estão presentes e onde existe possibilidade de solicitar um PNI olhando na seção "Private Peering Facilities".

Uma das vantagens de um PNI é a de por se tratar de uma conexão direta não esta suscetível à possíveis problemas causados por exemplo na matriz de um IX aonde ambos ASN já trocam tráfego. Além disso por se tratar de uma conexão dedicada a banda toda disponível na porta é dedicada àquele tráfego entre os dois ASNs aliviando assim outras portas de peering para outros tipos de tráfegos.

Algumas CDNs embora grandes optam por não disponibilizar a modalidade de interconexão através de PNI restringindo assim à troca de tráfego através do IX ou através de um servidor de CDN que é instalado dentro do backbone do ISP.

Normalmente envolve um custo que é o do ''cross-connect'' ou ''golden-jumper'' que pode ser pago por uma das partes ou dividido igualmente entre ambas. Para que o parceiro ou você possa solicitar este cross, será necessário o envio de um LoA (Letter of Authorization) indicando que a parte remota está autorizando a passado do cabeamento em sua rack, caso você não saiba como criar esse LoA, verifique a sessão download do portal do parceiro ou solicite a seu parceiro um modelo, você também pode se basear neste exemplo fornecido pelo Google https://isp.google.com/static/downloads/LOA.pdf.

A listagem abaixo contém as informações em quais Datacenters é possível ter um PNI com algumas dessas CDNs:
====Facebook====
*Banda mínima: 1 Gbps
*Email: peering@fb.com
*Datacenters: Equinix-SP2, Equinix-SP4 e Equinix-RJ1
*PeeringDB: https://www.peeringdb.com/net/979
*Informações: https://wiki.brasilpeeringforum.org/images/4/4e/Peer-pni-parameters-facebook.pdf
====Google====
*Informações: https://peering.google.com/#/options/peering
*Solicitação: http://isp.google.com/iwantpeering
*Datacenters: Equinix-SP2 (através de transporte), Equinix-SP4, Level 3 - Cotia e Level 3 - Rio de Janeiro.
*PeeringDB: https://www.peeringdb.com/net/433<nowiki/>https://www.peeringdb.com/net/4319
*Modelo LoA: [https://isp.google.com/static/downloads/LOA.pdf https://isp.google.com/static/do]<nowiki/>[https://isp.google.com/static/downloads/LOA.pdf wnloads/LOA.pdf]
====Edgecast Verizon Digital Media====
*Banda mínima: 1 Gbps
*Email: peering@verizondigitalmedia.com
*Solicitação: peering@verizondigitalmedia.com / CarrierRelations@edgecast.com
*Informações: https://www.verizondigitalmedia.com/our-network/network-overview/peering-with-us/
*PeeringDB: <nowiki>http://as15133.peeringdb.com/</nowiki>
*Datacenters: Equinix-SP4, Equinix-RJ2
==== Netflix ====
* Banda Mínima: 3 Gbps
* Email: peering@netflix.com
* Informações: https://openconnect.netflix.com/en/guidelines/
* Datacenters: Equinix-SP2, Equinix-RJ1, NIC-JD, Commcorp Porto Alegre-PAE1, ETICE-Fortaleza
* PeeringDB: https://www.peeringdb.com/net/457

==== Akamai ====
* Banda Mínima: 5 Gbps
* Email: netsupport-tix@akamai.com
* Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
*PeeringDB: https://www.peeringdb.com/net/2
*Datacenters: Equinix-SP4, Teleporto-RJ

==== Azion ====
* Banda mínima: 20 Gbps
* Email: peering@azion.com / noc@azion.com
* Informações: https://www.azion.com.br/developers/peering/
* Datacenters: Ascenty Campinas, Commcorp-BSA2, Commcorp-FNS1, Commcorp-PAE1, Equinix-SP3, Level 3 - Cotia, GVT - Curitiba, Globenet - Fortaleza, NIC-JD, PIX Adylnet-PAE, PIX G8 - São Paulo, PIX Vogel - Porto Alegre, Tascom - Salvador
* PeeringDB: https://www.peeringdb.com/net/14511
==== Twitch TV ====
* Banda mínima: 2.5 Gbps
* Email: noc@twitch.tv / interconnection@twitch.tv
* Contato: https://noc.twitch.tv/
* Datacenters: Equinix-SP2, Level 3 - Cotia, Level 3 - Rio de Janeiro
* PeeringDB: https://www.peeringdb.com/asn/46489
==== Globo ====
* Email: peering@peering.globo
* Informações: https://peering.globo
* PeeringDB: https://www.peeringdb.com/net/5703
* Locais: Rio de Janeiro: Jacarepaguá, São Paulo: Alameda Santos, Fortaleza: Datacenter Angola Cables e TV Verdes Mares, Brasília: Asa Norte, Belo Horizonte: Caiçaras, Recife: Santo Amaro
[[Categoria:Interconexão]]

Dns flag day 2020

2020-09-09T16:02:51Z

Canton: /* 2020-10-01 (1º de outubro de 2020) */

==A data exata==
2020-10-01 (1º de outubro de 2020)

==DNS Flag Day 2020==
A comunidade DNS tem discutido problemas persistentes de interoperabilidade e desempenho com o sistema DNS em listas de mala direta do setor e em conferências como o painel de discussão DNS-OARC 30 ( vídeo , slides ).

O plano proposto para o DNS Flag Day 2020 foi anunciado em outubro de 2019 em RIPE78 por Petr Špaček, CZ.NIC e Ondřej Surý, ISC ( vídeo , slides ). Este ano, estamos nos concentrando em problemas com fragmentação de IP de pacotes DNS.

A fragmentação de IP não é confiável na Internet hoje e pode causar falhas de transmissão quando grandes mensagens de DNS são enviadas via UDP. Mesmo quando a fragmentação funciona, ela pode não ser segura; é teoricamente possível falsificar partes de uma mensagem DNS fragmentada, sem fácil detecção na extremidade receptora.

Bonica R. et al, " IP Fragmentation Considered Fragile ", Work in Progress, July 2018 Huston G., " IPv6, Large UDP Packets and the DNS ", agosto de 2017 Fujiwara K., “ Measures against cache poisoning attack using IP fragmentation in DNS ”, maio de 2019 Fujiwara K. et al, " Avoid IP fragmentation in DNS ", setembro de 2019 Recentemente, houve um artigo e uma apresentação Desfragmentando DNS - Determinando o tamanho de resposta UDP máximo ideal para DNS por Axel Koolhaas e Tjeerd Slokker em colaboração com NLnet Labs que explorou os dados do mundo real usando as sondas RIPE Atlas e os pesquisadores sugeriram diferentes valores para IPv4 e IPv6 e em diferentes cenários. Isso é prático para os operadores de servidor que conhecem seu ambiente, e os padrões no software DNS devem refletir o tamanho mínimo seguro que é 1232 .

Esses problemas podem ser resolvidos a) configurando servidores para limitar as mensagens DNS enviadas por UDP a um tamanho que não acione a fragmentação em links de rede típicos e b) garantindo que os servidores DNS possam mudar de UDP para TCP quando uma resposta DNS for muito grande para caber neste tamanho de buffer limitado.
==Considerações sobre o tamanho da mensagem==
O tamanho ideal da mensagem DNS para evitar a fragmentação de IP e, ao mesmo tempo, minimizar o uso de TCP dependerá da Unidade Máxima de Transmissão (MTU) dos links de rede física que conectam dois terminais de rede. Infelizmente, ainda não existe um mecanismo padrão para que os implementadores de servidor DNS acessem essas informações. Até que tal padrão exista, recomendamos que o tamanho do buffer EDNS seja, por padrão , definido como um valor pequeno o suficiente para evitar a fragmentação na maioria dos links de rede em uso hoje.

Um tamanho de buffer EDNS de 1232 bytes evitará a fragmentação em quase todas as redes atuais. Isso é baseado em um MTU de 1280, que é exigido pela especificação IPv6, menos 48 bytes para os cabeçalhos IPv6 e UDP e a pesquisa mencionada.

Observe que esta recomendação é para um valor padrão , a ser usado quando melhores informações não estiverem disponíveis. Os operadores ainda podem configurar valores maiores se suas redes suportarem quadros de dados maiores e eles tiverem certeza de que não há risco de fragmentação de IP. Os fornecedores de servidor DNS podem usar tamanhos de pacote maiores (ou menores) se melhores informações sobre o MTU estiverem disponíveis no kernel.
==Ações==
===Operadores de DNS Autoritativo:===
#Garantir que a porta TCP 53 esteja disponível e respondendo em seu servidor, livre de qualquer firewall.
#Configurar o buffer EDNS para no máximo de 1232 bytes.
#O servidor não deve enviar respostas maiores do que o buffer definido.
Para testar seu servidor execute o comando a seguir, inserindo o IP do seu equipamento:
====Autoritativo do seu domínio====
<pre>
dig seudominio.tld. TXT @IP_SERVER_AUTORITATIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp seudominio.tld. TXT @IP_SERVER_AUTORITATIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.

Todas as consultas DNS devem ser bem-sucedidas e os comandos devem retornar os mesmos resultados com e sem a opção +tcp.
====Recursão para seu domínio====
<pre>
dig seudominio.tld. TXT @IP_SERVER_RECURSIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp seudominio.tld. TXT @IP_SERVER_RECURSIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.

Todas as consultas DNS devem ser bem-sucedidas e os comandos devem retornar os mesmos resultados com e sem a opção +tcp.
===Operadores de DNS Recursivo:===
#Garantir que a porta TCP 53 esteja disponível e respondendo em seu servidor, livre de qualquer firewall.
#Configurar o buffer EDNS para no máximo de 1232 bytes.
#O servidor não deve enviar respostas maiores do que o buffer definido.
#Consultas UDP devem retornar "truncated" (com TC = 1), no caso ele deve retentar em TCP
Para testar seu servidor execute o comando a seguir, inserindo o IP do seu equipamento:<pre>
dig test.knot-resolver.cz. TXT @IP_SERVER_RECURSIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp test.knot-resolver.cz. TXT @IP_SERVER_RECURSIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.
==Como configurar o EDNS Buffer==
*BIND
<pre>
options {
edns-udp-size 1232;
max-udp-size 1232;
};
</pre>
*Knot DNS
<pre>
server:
max-udp-payload: 1232
</pre>
*Knot Resolver
<pre>
net.bufsize(1232)
</pre>
*PowerDNS Authoritative
<pre>
udp-truncation-threshold=1232
</pre>
*PowerDNS Recursor
<pre>
edns-outgoing-bufsize=1232
udp-truncation-threshold=1232
</pre>
*Unbound
<pre>
server:
edns-buffer-size: 1232
</pre>
*NSD
<pre>
server:
ipv4-edns-size: 1232
ipv6-edns-size: 1232
</pre>Para mais informações, visite: https://dnsflagday.net/2020/

Dns flag day 2020

2020-09-09T16:01:38Z

Canton: Criou página com ' ==A data exata== ====2020-10-01 (1º de outubro de 2020)==== ==DNS Flag Day 2020== A comunidade DNS tem discutido problemas persistentes de interoperabilidade e desempenho co...'

==A data exata==
====2020-10-01 (1º de outubro de 2020)====
==DNS Flag Day 2020==
A comunidade DNS tem discutido problemas persistentes de interoperabilidade e desempenho com o sistema DNS em listas de mala direta do setor e em conferências como o painel de discussão DNS-OARC 30 ( vídeo , slides ).

O plano proposto para o DNS Flag Day 2020 foi anunciado em outubro de 2019 em RIPE78 por Petr Špaček, CZ.NIC e Ondřej Surý, ISC ( vídeo , slides ). Este ano, estamos nos concentrando em problemas com fragmentação de IP de pacotes DNS.

A fragmentação de IP não é confiável na Internet hoje e pode causar falhas de transmissão quando grandes mensagens de DNS são enviadas via UDP. Mesmo quando a fragmentação funciona, ela pode não ser segura; é teoricamente possível falsificar partes de uma mensagem DNS fragmentada, sem fácil detecção na extremidade receptora.

Bonica R. et al, " IP Fragmentation Considered Fragile ", Work in Progress, July 2018 Huston G., " IPv6, Large UDP Packets and the DNS ", agosto de 2017 Fujiwara K., “ Measures against cache poisoning attack using IP fragmentation in DNS ”, maio de 2019 Fujiwara K. et al, " Avoid IP fragmentation in DNS ", setembro de 2019 Recentemente, houve um artigo e uma apresentação Desfragmentando DNS - Determinando o tamanho de resposta UDP máximo ideal para DNS por Axel Koolhaas e Tjeerd Slokker em colaboração com NLnet Labs que explorou os dados do mundo real usando as sondas RIPE Atlas e os pesquisadores sugeriram diferentes valores para IPv4 e IPv6 e em diferentes cenários. Isso é prático para os operadores de servidor que conhecem seu ambiente, e os padrões no software DNS devem refletir o tamanho mínimo seguro que é 1232 .

Esses problemas podem ser resolvidos a) configurando servidores para limitar as mensagens DNS enviadas por UDP a um tamanho que não acione a fragmentação em links de rede típicos e b) garantindo que os servidores DNS possam mudar de UDP para TCP quando uma resposta DNS for muito grande para caber neste tamanho de buffer limitado.
==Considerações sobre o tamanho da mensagem==
O tamanho ideal da mensagem DNS para evitar a fragmentação de IP e, ao mesmo tempo, minimizar o uso de TCP dependerá da Unidade Máxima de Transmissão (MTU) dos links de rede física que conectam dois terminais de rede. Infelizmente, ainda não existe um mecanismo padrão para que os implementadores de servidor DNS acessem essas informações. Até que tal padrão exista, recomendamos que o tamanho do buffer EDNS seja, por padrão , definido como um valor pequeno o suficiente para evitar a fragmentação na maioria dos links de rede em uso hoje.

Um tamanho de buffer EDNS de 1232 bytes evitará a fragmentação em quase todas as redes atuais. Isso é baseado em um MTU de 1280, que é exigido pela especificação IPv6, menos 48 bytes para os cabeçalhos IPv6 e UDP e a pesquisa mencionada.

Observe que esta recomendação é para um valor padrão , a ser usado quando melhores informações não estiverem disponíveis. Os operadores ainda podem configurar valores maiores se suas redes suportarem quadros de dados maiores e eles tiverem certeza de que não há risco de fragmentação de IP. Os fornecedores de servidor DNS podem usar tamanhos de pacote maiores (ou menores) se melhores informações sobre o MTU estiverem disponíveis no kernel.
==Ações==
===Operadores de DNS Autoritativo:===
#Garantir que a porta TCP 53 esteja disponível e respondendo em seu servidor, livre de qualquer firewall.
#Configurar o buffer EDNS para no máximo de 1232 bytes.
#O servidor não deve enviar respostas maiores do que o buffer definido.
Para testar seu servidor execute o comando a seguir, inserindo o IP do seu equipamento:
====Autoritativo do seu domínio====
<pre>
dig seudominio.tld. TXT @IP_SERVER_AUTORITATIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp seudominio.tld. TXT @IP_SERVER_AUTORITATIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.

Todas as consultas DNS devem ser bem-sucedidas e os comandos devem retornar os mesmos resultados com e sem a opção +tcp.
====Recursão para seu domínio====
<pre>
dig seudominio.tld. TXT @IP_SERVER_RECURSIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp seudominio.tld. TXT @IP_SERVER_RECURSIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.

Todas as consultas DNS devem ser bem-sucedidas e os comandos devem retornar os mesmos resultados com e sem a opção +tcp.
===Operadores de DNS Recursivo:===
#Garantir que a porta TCP 53 esteja disponível e respondendo em seu servidor, livre de qualquer firewall.
#Configurar o buffer EDNS para no máximo de 1232 bytes.
#O servidor não deve enviar respostas maiores do que o buffer definido.
#Consultas UDP devem retornar "truncated" (com TC = 1), no caso ele deve retentar em TCP
Para testar seu servidor execute o comando a seguir, inserindo o IP do seu equipamento:<pre>
dig test.knot-resolver.cz. TXT @IP_SERVER_RECURSIVO
</pre>A resposta esperada deverá ter a mensagem ";; Truncated, retrying in TCP mode."<pre>
dig +tcp test.knot-resolver.cz. TXT @IP_SERVER_RECURSIVO
</pre>Não pode ocorrer falhas.

Para ambos espera-se ver algo como "udp: 1232" na resposta.
==Como configurar o EDNS Buffer==
*BIND
<pre>
options {
edns-udp-size 1232;
max-udp-size 1232;
};
</pre>
*Knot DNS
<pre>
server:
max-udp-payload: 1232
</pre>
*Knot Resolver
<pre>
net.bufsize(1232)
</pre>
*PowerDNS Authoritative
<pre>
udp-truncation-threshold=1232
</pre>
*PowerDNS Recursor
<pre>
edns-outgoing-bufsize=1232
udp-truncation-threshold=1232
</pre>
*Unbound
<pre>
server:
edns-buffer-size: 1232
</pre>
*NSD
<pre>
server:
ipv4-edns-size: 1232
ipv6-edns-size: 1232
</pre>Para mais informações, visite: https://dnsflagday.net/2020/

Redes que descartam RPKI Invalidos

2020-04-24T18:12:06Z

Canton: /* Lista de redes que implementam descarte de rotas inválidas */ Adicionado Link para https://isbgpsafeyet.com/ que possui uma lista com mais ASN de todo o mundo.

Nesse artigo temos uma introdução rápida ao RPKI além de listar as operadoras e provedores de trânsito Internet que já implementam o descarte de prefixos identificados como '''inválidos''' pela validação de origem RPKI.

=== Introdução ===

O RPKI (''Resource Public Key Infrastructure''), utiliza certificados de chaves públicas para promover a segurança no roteamento da Internet, permitindo que roteadores BGP validem a origem de cada prefixo recebido, classificando cada um deles como '''Válido, Inválido''' ou '''Desconhecido''' e garantindo assim uma proteção contra sequestro de prefixos por uma rede ou ASN não detentor daquelas rotas.
* '''Válido''' = O estado válido significa que há um ROA correspondente ao prefixo e ao número AS usado para originar o prefixo.
* '''Inválido''' = Inválido significa que existe um ROA, mas o número do AS ou a máscara de rede do prefixo não corresponde ao ROA.
* '''Desconhecido''' = Desconhecido significa que não há ROA que cubra o prefixo.
.
=== Como o roteador faz a validação de origem ===
Os detentores de endereços IP geram ROAs (Route Origination Authorizations) que associam um prefixo a um ASN, dando a ele permissão para originar o prefixo em questão. O detentor do endereço assina o ROA com a chave privada do certificado. O ROA também contém um comprimento máximo da máscara de rede e uma data de validade. Por exemplo, se o AS 1111 assinar um ROA para 143.205.0.0/16 com um comprimento máximo de prefixo de /22, o AS 1111 poderá originar 143.205.0.0/16, 143.205.0.0/22 e 143.205.248.0/22, mas não 143.205.0.0/23 ou 143.205.0.0/24. No entanto, ele pode gerar um ROA adicional para permitir que o AS 1111 (ou outro ASN!) origine os prefixos mais longos a qualquer momento, pois os ROAs podem se sobrepor.

Certificados e ROAs são publicados em repositórios acessíveis publicamente, onde podem ser baixados e usados para gerar listas de quais prefixos podem ser originados por quais ASNs. Nesse ponto, as assinaturas e a data de validade dos certificados e ROAs são verificadas. Se a data de início de um ROA (e todos os certificados na cadeia do certificado raiz) estiver no futuro ou sua data final estiver no passado, as assinaturas forem inválidas ou foram revogadas, o ROA será ignorado.

A partir desse ponto, os softwares que validam são usados para criar um "cache validado". Este é um processo que toda rede executa independentemente utilizando de aplicações ou softwares para gerar o "cache" (exemplos:.

Em seguida, o "cache validado" é usado para gerar um filtro que é carregado nos roteadores através do protocolo "RPKI to Router protocol (RFC 6810)"
.

=== Garantindo a segurança ===
Uma abordagem mais segura é rejeitar prefixos para os quais um ROA está presente, mas o anúncio no BGP não está valido, ou seja, descartar os '''inválidos'''.

Você pode pensar que, se um certificado ou ROA expirar antes da instalação de um novo, a conectividade for perdida e, sem a conectividade, pode ser difícil gerar e fazer upload de novos certificados e ROAs e isso pode gerar problemas para o detentor do recurso. Mas certificados expirados (ou ainda não válidos) e seus ROAs são simplesmente ignorados; portanto, os prefixos em questão voltam a ser '''desconhecidos''' e não '''inválidos''' e, portanto, permanecem acessíveis a toda Internet.

.

=== Software para validar e gerar "cache validado" ===
Alguns dos software de validação são:
* Projeto FORT de NIC Mexico e LACNIC: https://fortproject.net/
* RIPE NCC http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources
* OctoRPKI https://github.com/cloudflare/cfrpki#octorpki/ (exige o GoRTR para a função de servidor RTR)
* Routinator https://nlnetlabs.nl/projects/rpki/routinator/
.
=== Como verificar se meus prefixos estão corretamente validados? ===
Para verificar que seus prefixos tenham sido assinados corretamente e que não existem erros que marquem rotas como invalidas pode visitar a ferramenta de validação de origem de LACNIC:
* http://localcert.ripe.net:8088/bgp-preview
* No looking glass da Telia: https://lg.telia.net/
.
=== Quais roteadores suportam validação de origem? ===
Para poder gerar certificados e ROA não é necessário que os roteadores suportem RPKI. No entanto, para que os roteadores possam tomar decisões de roteamento baseadas na autenticidade das rotas baseadas no RPKI, e de preferência descartem os '''inválidos''', é preciso suporte RPKI no sistema operacional do mesmo.

A maioria dos fabricantes já suportam validação de origem, entre eles Cisco, Juniper, Nokia, e Huawei.
* Cisco IOS – disponível a partir da versão 15.2
* Cisco IOS/XR –disponível a partir da versão 4.3.2
* Juniper –disponível a partir da versão 12.2
* Nokia –disponível a partir da versão R12.0R4
* Huawei –disponível a partir da versão V800R009C10
* FRR –disponível a partir da versão 4.0
* BIRD –disponível a partir da versão 1.6
* OpenBGPD–available from OpenBSD release 6.4
.
== Lista de redes que implementam descarte de rotas '''inválidas''' ==

Última atualização: Mar/20
{| class="wikitable" style="margin-left: auto; margin-right: auto;"
|+
!ASN
!Nome
!Inválidos
!Observações
|-
|13335
|'''CloudFlare'''
| ''Drop'' 
|
|-
|7018
|'''ATT'''
| ''Drop'' 
|Sessões de peering
|-
|
|'''DE-CIX'''
| ''Drop'' 
|Apenas nos Route Servers
|-
|1299
|'''Telia'''
| ''Drop'' 
|
|-
|
|'''IX.br'''
| ''Drop'' 
|Apenas nos Route Servers de SP
|-
|174
|'''Cogent'''
| ''Drop'' 
|Sessões de peering
|-
|3491
|'''PCCW'''
| ''Drop'' 
|Sessões de peering
|-
|286
|'''KPN'''
| ''Drop'' 
|
|-
|28329
|'''G8'''
| ''Drop'' 
|
|-
|6453
|'''Tata'''
| ''Drop'' 
|
|-
|6939
|'''Hurricane Eletric'''
| ''Drop'' 
|
|-
|2914
|'''NTT'''
| ''Drop'' 
|
|-
|262659
|'''Ultrawave Telecom'''
| ''Drop'' 
|
|}
Você pode acompanhar uma lista ofertada pela CloudFlare em: <nowiki>https://isbgpsafeyet.com/</nowiki>
[[Categoria:Roteamento]]

CDN Peering e PNI - Brasil

2020-01-23T17:22:38Z

Canton: Adicionado informações da Apple e CGNAT para algumas CDNs

Tutorial DNS Hyperlocal

2019-09-06T04:50:22Z

Canton: Adicionada configuração para Unbound 1.6 com NSD.

=== Introdução ===
A Zona Raiz do Sistema de Nomes de Domínios (DNS) é servida por 12 organizações que operam instâncias ''anycast'' de servidores de nomes autoritativos provendo respostas para a raiz do DNS. Estas instâncias estão distribuídas em mais de [https://root-servers.org/ 1000 localidades ao redor do mundo]. Apesar deste grande número de servidores e alta capacidade provisionada para a resolução da raiz de nomes, ainda existe a possibilidade de que um grande ataque coordenado de negação de serviço (DDoS) possa comprometer o acesso à internet para muitos usuários.

Para minimizar e prevenir esta ameaça, existe a possibilidade de adicionar um fator de resiliência na configuração dos servidores recursivos do provedor de internet através do uso de uma cópia local da zona raiz, chamada de '''Hyperlocal'''. Hyperlocal é apresentado em detalhes na [[rfc:7706/|RFC7706]] e, resumidamente, consiste em executar uma cópia da zona raiz no mesmo servidor de serviços de resolução recursiva. Desta forma, as consultas à zona raiz dos clientes são respondidas localmente sem necessidade comunicação externa entre os servidores. Isso resulta em maior robustez do serviço em caso de ataques e ganhos na velocidade de provimento de respostas às consultas ao DNS dos usuários.

Este tutorial foi criado para compartilhar a prática de implementação de um sistema Hyperlocal para a configuração de servidores de DNS do tipo BIND9, Unbound e NSD. Outras configurações e softwares mencionados na <nowiki>RFC 7706</nowiki> podem não serem abordados neste tutorial.

=== Implementação - BIND (CentOS) ===
[[Arquivo:Bind dns logo.png|borda|direita|semmoldura]]
Requisitos para instalação do Hyperlocal:
* Instalação básica CentOS Linux 7
* 1vCPU
* 1GB de RAM
* 20GB de Disco
Baixe o ISO do Sistema Operacional no link http://isoredirect.centos.org/centos/7/isos/x86_64/

Sistema operacional instalado e atualizado, agora devemos instalar o Bind9 com o comando:
<pre>
yum install bind bind-utils
</pre>

A configuração para o funcionamento da zona raiz é bem simples como podemos ver abaixo.

Os arquivos de configuração do Bind no Centos7 por padrão estão no arquivo /etc/named.conf.

No exemplo de configuração abaixo, o servidor Hyperlocal foi configurado com o IPv4 198.51.100.1 e IPv6 2001:db8::1 em sua interface de rede. No caso do servidor Hyperlocal ser instalado como uma instância adicional no mesmo servidor que o Recursivo é recomendado que ele escute apenas no endereço de Looopback, (127.0.0.1 e ::1) e permita apenas consultas locais. Para isso será necessário alterar o match-destinations e as partes de acl "ServidorRecursivo_A" e B não serão necessárias.
<pre>
view root {
<nowiki>#</nowiki> IPs das interfaces onde chegarão as requisições para cópia loca da zona raiz
match-destinations { 198.51.100.1; 2001:db8::1; };
 zone "." {
 type slave;
 file "rootzone.db";
 notify no;
 masters {
 192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net
192.5.5.241; # f.root-servers.net
192.112.36.4; # g.root-servers.net
193.0.14.129; # k.root-servers.net
192.0.47.132; # xfr.cjr.dns.icann.org
192.0.32.132; # xfr.lax.dns.icann.org
2001:500:84::b; # b.root-servers.net
2001:500:2f::f; # f.root-servers.net
2001:7fd::1; # k.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org
2620:0:2d0:202::132; # xfr.lax.dns.icann.org
 };
 };
};
</pre>

Obs: Os servidores utilizados devem permitir transferência de zona (axfr), como nem todos os root server permitem o axfr, sendo assim deve ser verificada na versão atual da RFC no link a seguir <nowiki>https://tools.ietf.org/html/rfc7706</nowiki> os root servers que estão preparados para a sincronização do Hyperlocal.

O processo de atualização acontece uma vez ao dia, e ela requer que seja baixada toda a zona raiz que atualmente chega a ~1.5Mb.

Iniciando o serviço do Bind você pode conferir a criação da base com o comando:
<pre>
ls /var/named/rootzone.db
</pre>

Segue abaixo um exemplo de arquivo de configuração para o BIND já contendo as configurações de Hyperlocal e de recursividade .

É possível melhorar de diversas formas esse exemplo de configuração.

O configuração padrão do Bind com o adicional de views no exemplo seguinte já é bem funcional.
<pre>
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};

logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

acl "MinhaRede_v4" {
127.0.0.0/8;
198.51.100.0/24;
};

acl "MinhaRede_v6" {
::1;
2001:db8::/32;
};

acl "ServidorRecursivo_A" {
203.0.113.10;
2001:db8::10;
};

acl "ServidorRecursivo_B" {
203.0.113.20;
2001:db8::20;
};

view root {
<nowiki>#</nowiki> Como exemplo, especificamos abaixo os dois servidores recursivos autorizados a fazer consulta na copia local de zona Raiz
match-clients { 127.0.0.1; ServidorRecursivo_A; ServidorRecursivo_B; } ;
zone "." {
type slave;
file "rootzone.db";
notify no;
masters {
 192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net
192.5.5.241; # f.root-servers.net
192.112.36.4; # g.root-servers.net
193.0.14.129; # k.root-servers.net
192.0.47.132; # xfr.cjr.dns.icann.org
192.0.32.132; # xfr.lax.dns.icann.org
2001:500:84::b; # b.root-servers.net
2001:500:2f::f; # f.root-servers.net
2001:7fd::1; # k.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org
2620:0:2d0:202::132; # xfr.lax.dns.icann.org
 };
};
};

view "externa" {
match-clients { any; };
recursion no;
};

view clientes-recursivos {
<nowiki>#</nowiki> Esta é a view que permite que clientes façam consultas recursivas a este servidor
dnssec-validation auto;
allow-recursion { MinhaRede_v4; MinhaRede_v6; };
recursion yes;
<nowiki>#</nowiki> Esta é parte aonde instruímos o Bind sobre os servidores a serem utilizados para consulta de zona Raiz.
zone "." {
type static-stub;
server-addresses { 127.0.0.1; ::1; };
<nowiki>#</nowiki> Aqui definimos o IP do servidor Hyperlocal aonde serão feitas as consultas recursivas da zona Raiz.
<nowiki>#</nowiki> Como neste exemplo o Hyperlocal roda neste mesmo servidor, especificamos o endereço de Loopback. No caso das consultas serem feitas desde um servidor diferente outro IP deverá ser especificado no lugar.

};
};
</pre>

Com essa configuração é possível já sentir os benefícios do Hyperlocal em sua rede, no exemplo acima, configuramos o Hyperlocal e o servidor recursivo na mesma instancia do Bind, para usuários do '''Unbound''' é possível fazer a consulta na instância Hyperlocal Bind com um pequeno ajuste na configuração, adicione ao final do arquivo de configuração do "unbound.conf" o seguinte trecho para que ele consulte o Hyperlocal:
stub-zone:
name: "."
stub-prime: no
stub-addr: 198.51.100.1
stub-addr: 2001:db8::1

==== '''Bind 9.14''' ====
Na versão do Bind 9.14 que ainda é release futuro é possível configurar um mirror local da zona raíz com uma configuração bem menor e mais simples. Isso é possível porque nesta versão a configuração "type mirror" porque o Bind incorporou a lista de servidores raiz da IANA. Este exemplo é válido para a zona raiz. Para qualquer outra zona é necessário especificar a lista dos servidores primários. Para qualquer outro detalhe relacionado consulte a documentação do Bind 9.14 quando lançado oficialmente.

O exemplo de configuração para o o Bind 9.14 é:
<pre>
zone "." {
type mirror;
};
</pre>

=== Implementação - Unbound ===
[[Arquivo:Unbound-dns-logo.png|borda|direita|semmoldura]]
Para que o Unbound possa ser utilizado para replicar a zona raiz sem a utilização de nenhum outro software de DNS é necessário utilizar a '''versão 1.7 ou mais nova'''. No caso da utilização de versões anteriores é necessário haver uma instância separada do BIND sendo executada com o Unbound para ser consultada conforme as instruções acima. As versões padrão do Unbound disponibilizadas por algumas das distribuições mais utilizadas atualmente como Ubuntu, CentOS e Debian '''são até a 1.6'''. Para utilizar uma versão superior é necessário compilar manualmente a versão mais nova ou então utilizar alguma técnica de containers como docker.

Para rodar o Hyperlocal utilizando '''Unbound 1.7, 1.8 e 1.9''' na mesma instância do Unbound adicione a seguinte configuração à existente do Unbound.

'''Unbound'''

<pre>
auth-zone:
name: "."
master: 192.228.79.201 # b.root-servers.net
master: 192.33.4.12 # c.root-servers.net
master: 192.5.5.241 # f.root-servers.net
master: 192.112.36.4 # g.root-servers.net
master: 193.0.14.129 # k.root-servers.net
master: 192.0.47.132 # xfr.cjr.dns.icann.org
master: 192.0.32.132 # xfr.lax.dns.icann.org
master: 2001:500:84::b # b.root-servers.net
master: 2001:500:2f::f # f.root-servers.net
master: 2001:7fd::1 # k.root-servers.net
master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org
master: 2620:0:2d0:202::132 # xfr.lax.dns.icann.org
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "root.zone"
</pre>

=== '''Implementação - Unbound + NSD''' ===
[[Arquivo:NSDNLL.png|borda|direita|semmoldura]]
Se você estiver utilizando uma versão empacotada com sua distribuição como Ubuntu, CentOS e Debian, tenha em mente que você encontrará '''o Unbound até a 1.6''', para que você possa operar com hyperlocal será necessário um autoritativo externo, seja ele o BIND ou NSD, iremos apresentar as configurações necessárias para operar com NSD.

==== '''NSD''' ====
Instalação.
* CentOS<pre>
yum install nsd
</pre>
* Debian<pre>
apt-get install nsd
</pre>
Crie o arquivo /etc/nsd/nsd.conf.d/hyperlocal.conf com o conteúdo a seguir.<pre>
server:
ip-address: 127.12.12.12
zone:
name: "."
request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.org
</pre>

==== '''Unbound''' ====
Edite o arquivo /etc/unbound/unbound.conf, localize a linha do parâmetro abaixo e comente-a<pre>
root-hints: "/var/unbound/etc/root.hints"
</pre>Agora adicione <pre>
stub-zone:
name: "."
stub-prime: no
stub-addr: 127.12.12.12
</pre>Salve o arquivo, inicie o NSD e reinicie o Unbound.<pre>
services nsd start
unbound-control stop
unbound-control start
</pre>

=== Implementação - Microsoft Windows Server 2012 ===
[[Arquivo:Microsoft-dns-logo.png|borda|direita|semmoldura]]
O Windows Server 2012 contém um servidor DNS dentro do componente DNS Manager. Quando ativado este componente atua como servidor Recursivo e pode também atuar como servidor Autoritativo.

Utilizando os passos abaixo é possível reproduzir o Hyperlocal para este cenário.
# Abre o "DNS Manager GUI". É possível abrir utilizando também a linha de comando através do comando dnsmgmt.msc
# Na hierarquia abaixo do serviço, clique com o botão direito em "Forward Lookup Zones" e selecione "New Zone". Isso mostrará uma sucessão opções para preencher.
# Em "Zone Type" selecione "Secondary Zone"
# Em "Zone Name" digite ".".
# Em "Master DNS Server" digite "b.root-servers.net". O sistema irá validar que é possível fazer a transferência da zona daquele servidor. Após este configuração ser finalizada o DNS Manager irá tentar transferir a zona desde todos servidores raiz.
# Em "Completing the New Zone Wizard" clique em "Finish"
# Verifique que o DNS Manager está atuando como um resolver recursivo. Clique com o botão direito no servidor na parte de hierarquia, selecione a tab "Advanced". Veja se "Disable recursion (also disabled forwarders)" não está selecionada e que "Enable DNSSEC validation for remote responses" está selecionada.

=== Conclusão ===
Em testes o desempenho ficou muito bom. Abaixo algumas comparações consultando domínios inválidos para forçar o recursivo a procurar nos Root Servers.
<pre>
// Teste 1 servidor público Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 29 msec

// Teste 2 servidor publico Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 27 msec

// Teste 1 no Unbound recursivo sem o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 21 msec

// Teste 2 (cached) no Unbound recursivo sem o hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 2 (cached) direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 2 msec

// Teste 2 (cached) no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec
</pre>

É possível portanto visualizar o melhor desempenho quando feitas consultas utilizando o Hyperlocal, sendo essa uma ótima implementação para manter no provedor.

É importante lembrar que em '''caso haver somente um Hyperlocal''' na rede, o recomendado é '''deixar somente o servidor primário''' apontando para o mesmo afim de '''evitar ponto único de falha''', ou fazer dupla implementação um para cada servidor recursivo.

=== Referências ===
https://www.isc.org/docs/Apricot2017.pdf

https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis

'''Autores''': Fabio Ortlieb e Daniel Fink

'''Adaptações:''' Fernando Frediani e Diego Canton
[[Categoria:Infraestrutura]]
[[Categoria:DNS]]

Arquivo:NSDNLL.png

2019-09-06T04:10:38Z

Canton:

CDN Peering e PNI - Brasil

2019-03-01T12:15:22Z

Canton: Inserção de informações sobre LoA e link de exemplo fornecido pelo Google.