Confira a segunda parte do artigo sobre DNS. Escrito por Flávio Rescia.

DNS, você sabe o que é, mas sempre tem dúvidas quando precisa hospedar uma aplicação?

Até então falamos apenas de solução de nomes para IP, porém não existe apenas esse tipo de resposta, essa é a principal função do DNS, porém não é a única.
Agora vamos entender as entradas DNS que podem ser utilizadas e quando utilizamos:

Entrada Tipo A

É a que falamos até agora, serve para resolver um nome como www.xpto.com.br para um IP como 200.200.200.1

Entrada do Tipo CNAME

Para facilitar a configuração são usadas entradas CNAME (do inglês Canonical Name, Apelido), que são entradas que apontam nomes DNS como www.xpto.com.br para outro nome como www.darede.com.br.

(Ferrou, agora babei!)

A sacada aqui é evitar a necessidade de mudar o DNS de www.xpto.com.br sempre que o IP mudar.
Imagina que o site www.xpto.com.br esteja no mesmo servidor que o www.darede.com.br que aponta para 200.1.1.1, caso tenhamos que mudar nosso provedor e trocar o IP 200.1.1.1 para outro IP, como 202.1.1.1, precisaremos trocar apenas a entrada www.darede.com.br e não o www.xpto.com.br. Uma vez que www.xpto.com.br continuará apontando para www.darede.com.br. Parece bobagem? Imagina que você tenha 1000 sites apontando para www.darede.com.br e mude a operadora 😱!

DNS

A desvantagem no uso de CNAME é que será necessário o cliente resolver duas vezes:
• www.xpto.com.br > www.darede.com.br
• www.darede.com.br > 200.1.1.1
Entradas CNAME hoje são muito utilizadas por serviços gerenciados (como AWS CloudFront, AWS ELB), uma vez que o serviço lhe oferece um nome e você cria um CNAME de seu domínio (como www.darede.com.br) e aponta para o nome oferecido pelo provedor do serviço. Caso os IPs da AWS mudem, nós não precisamos nos preocupar.

DICA:

De acordo com a RFC não é possível criar entradas do tipo CNAME para ‘naked domain’ (exemplo darede.com.br). Nesse caso temos que configurar uma entrada ‘A’ direto para o IP. Quando precisamos apontar o ‘naked domain’ para um serviço gerenciado (que não há IP fixo), temos duas opções:

1. Apontar para um servidor (esse sim com um IP fixo), e fazer um redirecionamento HTTP 301 para ele;

2. Para AWS, podemos usar uma entrada A com Alias. Alias é um recurso da AWS para criar entradas ‘A’ para serviços gerenciados AWS (como Elastic LoadBalancer, S3, CloudFront, API Gateway, etc). O AWS Route53 garante que a entrada sempre aponte para os IPs atuais do serviço gerenciado.

Entrada Tipo MX

Um e-mail é enviado para voce@seudominio.com.br certo? Qual o nome DNS do seu servidor de RECEBIMENTO de e-mails?
seudominio.com.br? NÃO. Geralmente seudominio.com.br aponta para seu site e não para seu servidor de recebimento de e-mail.
E agora? Para isso existe a entrada do tipo MX, que vem de Mail eXchange (também acho bizarro devia ser ME, kk!). O MX aponta para nossos servidores de recebimento de e-mails (SMTP/S).
Esse tipo de entrada pode apontar tanto para IP quanto para nomes, e possui uma particularidade, cada entrada possui dois valores:
• Nome ou IP do servidor de recebimento de e-mail;
• Prioridade, que é usada para redundância de servidores;

Entradas do tipo TXT

Para muitos serviços que surgiram anos após a primeira versão do protocolo HYPERLINK “https://www.ietf.org/rfc/rfc1034.txt”DNSs era preciso validar se um domínio é mesmo de propriedade de determinada pessoa/empresa. Como fazer isso?

Simples, lhe faço um desafio ao mantenedor do domínio. Crio um código de teste (como 123codigo) e peço para o mantenedor configurar uma entrada 123codigo.dominio.com.br, se essa entrada for criada, significa que realmente ele tem acesso ao SOA, logo posso confiar que ele é responsável por esse domínio.

Mas criar uma entrada ‘perdida’ para isso, parece uma gambiarra né? Como tudo em tecnologia que parece gambiara vira padrão. As entradas do tipo TXT surgiram para isso. É possível atribuir um texto qualquer (não apenas um nome ou IP) a essa entrada, que funciona como uma variável para qualquer finalidade.

O SPF que surgiu anos depois, é um exemplo de utilização de entrada TXT. Como o serviço de e-mail, que foi criado HYPERLINK “https://tools.ietf.org/html/rfc821” à HYPERLINK “https://tools.ietf.org/html/rfc821” HYPERLINK “https://tools.ietf.org/html/rfc821″décadas atrás, não possuía uma validação da origem do e-mail, qualquer um podia (e ainda pode) enviar e-mails em nome qualquer domínio. O SPF surgiu como um padrão para garantir o dono do domínio de origem possa informar ao servidor de recebimento (destino) os IPs que podem enviar e-mail em nome de @dominiodeorigem.com.br. Para isso era/é usada uma entrada TXT. Em 2014 foi criado um outro tipo de entrada DNS dedicada a SPF.

Um uso típico de entradas TXT é a validação de serviços cloud, como Google, AWS e Azure se você pode mesmo usar seu domínio.

Entrada Tipo PTR

É o contrário de entradas do Tipo ‘A’, usada para apontar um IP (200.1.1.1) para um nome (www.xpto.com.br).
Essa entrada causa muita confusão, uma vez que ela só pode ser usada pelo mantenedor do IP e não do domínio.
Em geral o mantenedor do IP é o provedor de seu Link de Internet ou serviço na nuvem. Assim somente o provedor poderá configurar o reverso de seu IP, caso precise, a única forma é abrir um chamado com eles.
Os usos práticos desse tipo de entrada são poucos, mas importantes:
• Identificação em caso de testes como traceroute por exemplo:

Note que alguns saltos não possuem Reverso (PTR) configurado

• Velocidade de algumas aplicações, como SSH e traceroute, uma vez que essas aplicações, de forma nativa, resolve o Reverso do IP, o que causa lentidão quando a entrada não existe por ficar tentando resolver;
• Controle SPAM, novamente o e-mail kkk! Como o SMTP foi inventado antes da invenção do SPAM, ele não previu seu uso, uma das técnicas para evitar SPAM é garantir que haja um vínculo entre o mantenedor do IP e seu utilizador, a técnica é simples. Se você está em uma LAN House, não vai conseguir pedir para configurar o reverso nele, então o servidor SMTP de recebimento espera que o IP aponte para um nome, e que esse nome aponte para o próprio IP. Caso isso não aconteça, o e-mail é considerado SPAM.

Trocando SOAs – Futuro
Tempo de replicação – Futuro

foto-flavio-rescia-dias
Flavio Rescia Dias
CTO & Co-Fundador da Darede

flavio.rescia@darede.com.br

Atuando desde 2006 no mercado de tecnologia, Flávio Rescia é um dos fundadores da Darede, empresa de consultoria de serviços de TI, na qual atua como CTO. Ele possui diversas especializações no setor, sendo a última a Certificação AWS Solutions Architect – Professional.

OUTRAS PUBLICAÇÕES

O que é Infrastructure as Code (IaC)?

A Infrastructure as Code é um modo de automatizar o provisionamento da infraestrutura de TI e aliada com a cultura DevOps pode ser de grande ajuda para as empresas. Confira o artigo do blog sobre esse conceito.

Desafios das mulheres na tecnologia

A porcentagem de mulheres no mundo da tecnologia ainda é pequeno, mas o futuro empolga! Veja o artigo da nossa #cloudspecialist Jessica Cardozo sobre o cenário do espaço feminino na TI! Apesar do crescimento, as mulheres ainda continuam sendo minoria em tecnologia. No entanto, felizmente encontramos cada vez mais projetos para capacitação e inserção de mulheres e mães na área de TI. Não é novidade que a mão de obra feminina sempre foi desvalorizada nessa área, mas nos últimos anos percebemos uma movimentação para mudar esse cenário. Mesmo com o aumento da presença feminina no mercado de tecnologia, ainda percebemos que é muito difícil uma mulher se firmar nessa área. De acordo com uma pesquisa da Associação das Empresas de Tecnologia da Informação e de Tecnologias Digitais (Brasscom), o Brasil deve chegar em 2025 com um déficit de quase 800 mil profissionais do setor. As mulheres são mais capacitadas e o maior público com graduação, e mesmo assim elas representam apenas 25% dos profissionais da área de tecnologia no Brasil. Segundo a pesquisa da Aliança Mundial de Informação sobre Tecnologia e Serviços, se houvessem mais mulheres na indústria tecnológica, cerca de 9 trilhões de euros poderiam ser gerados no PIB global! É nítido a falta que as mulheres estão fazendo no mercado de tecnologia, e perturbador saber quantos desafios elas enfrentam para atuar nessa área. Mas o que está acontecendo? Quais são as barreiras que essas mulheres estão enfrentando ao escolher o caminho tech? O primeiro desafio enfrentado pelas mulheres que desejam o mundo da tecnologia é a crença limitante de que o setor é apenas para homens, esse é um pensamento antigo, mas que infelizmente ainda continua enraizado na sociedade. O segundo desafio é o ambiente de trabalho, que por ser majoritariamente masculino, muitas vezes se torna desagradável, hostis e machistas para as mulheres trabalharem. Esse tipo de ambiente atrapalha o desenvolvimento, crescimento profissional e algumas vezes expõe essas mulheres ao temido assédio moral. O terceiro desafio é a desigualdade salarial entre homens e mulheres que atuam na mesma função. Segundo estudo da Revelo, plataforma de recrutamento em tecnologia, homens ganham em média R$ 1.000 a mais que as mulheres, mesmo exercendo a mesma função. Em média, enquanto um homem recebe R$ 7.300, uma mulher tem uma remuneração de R$ 5.900 exercendo a mesma função dentro da empresa. O quarto desafio enfrentando por mulheres de todos os segmentos do mercado é uma outra crença imposta pela sociedade de que os filhos são responsabilidades da mãe. Onde um homem quando é pai é intitulado um bom candidato por ser um “pai de família responsável”, já uma mulher quando é mãe é intitulada uma candidata ruim, pois “tende a faltar muito ao trabalho por causa dos filhos”. Veja o quão injusta é a sociedade e o mercado em vários sentidos se tratando de igualdade entre homens e mulheres. Mais um ponto a se refletir é a questão da licença maternidade, onde muitas empresas desprezam a contratação de mão de obra feminina porque em algum momento aquela mulher pode se ausentar para se dedicar ao filho. Mas um filho é responsabilidade só da mãe? Os primeiros meses de um filho é tão importante para um pai quanto para mãe. Por que não oferecer a licença paternidade por um período igual? Essa ação já quebraria a barreira infeliz de que “uma mulher que planeja filhos não é boa para o mercado”. Esses dados mostram que apesar de ser extremamente importante a presença feminina na tecnologia, os desafios enfrentados por elas ainda são muitos. Precisamos nos movimentar em busca de um cenário mais justo para mulheres que anseiam não só pelo sucesso pessoal, mas também pelo profissional. Não podemos mais fazer divisões de “trabalhos de homens e trabalhos de mulheres”. As oportunidades devem ser dadas a todos, sem distinção de raça, cor ou sexo. As mulheres merecem mais respeito, inclusão e menos preconceito no mercado de trabalho como o todo e principalmente no de tecnologia. Atualmente temos várias empresas com iniciativas que oferecem oportunidades de trabalho exclusivas para mulheres de TI. Isso é incrível! As organizações estão finalmente compreendendo a necessidade de ter uma empresa mais diversa em todos os aspectos, e a diversidade em tecnologia é alcançada por meio de projetos focados na inclusão de mulheres em TI e espaços de trabalho mais saudáveis com oportunidades e remunerações iguais para todos. É preciso mudar a realidade nas organizações, o olhar igualitário independente do sexo. Essa mudança deve começar dentro das organizações e ir avançando como raiz sedenta por água pela sociedade. O acesso a informações de qualidade, qualificações e o apoio de iniciativas voltadas para mulheres vão trazer as profissionais que o mercado de TI tanto carece. Mulher é sinônimo de força e determinação, e na tecnologia temos grandes mulheres que contribuíram muito com a tecnologia. Mulheres na história da tecnologia Augusta Ada King — Foi uma matemática e escritora inglesa. Hoje é reconhecida principalmente por escrever o primeiro algoritmo para ser processado por uma máquina, a máquina analítica, o mais próximo do que seria um computador do século XIX. Ela desenvolveu os algoritmos que permitiriam à máquina computar os valores de funções matemáticas, além de publicar uma coleção de notas sobre a máquina analítica. Por esse trabalho é considerada a primeira programadora de toda a história. A contribuição e representação das mulheres na tecnologia se tornaram imensuráveis desde então. Fonte Wikipedia Grace Hopper – Foi almirante e analista de sistemas da Marinha dos Estados Unidos nas décadas de 1940 e 1950, criadora da linguagem de programação de alto nível Flow-Matic  – base para a criação do COBOL. Em 1954, Grace Hopper foi nomeada a primeira diretora de programação automática da empresa. Seu departamento foi responsável por promover algumas das primeiras linguagens de programação baseadas em compiladores. Fonte Wikipedia Hedy Lamarr – ‘Mãe’ da internet sem fio escapou do regime nazista e ficou famosa em Hollywood. Fez uma importante contribuição tecnológica durante a Segunda Guerra Mundial, uma co-invenção, com o compositor George Antheil, um sistema de comunicações para as Forças Armadas dos Estados Unidos que serviu de base para a atual telefonia celular. Em 1997, ela e George

O que você precisa, Office 365 ou Exchange Server? – Parte 2

Confira a segunda parte do artigo sobre o uso do Office 365 e o Exchange Server. Escrito por Flávio Rescia. Levantamos os custos de cada um dos itens envolvidos em uma solução de Exchange Server e montamos uma planilha que pode ser baixada sem custo aqui. Dessa forma conseguimos uma estimativa do custo inicial (lembrando que o ideal é trabalhar com depreciação total em 36 meses) de ambas as soluções conforme imagem abaixo: Assim conseguimos comparar os planos para pequenas e médias empresas (Business) onde chegamos ao comparativo abaixo, como esses planos são limitados a 300 contas, limitamos dessa forma: Para fazer o comparativo acima, dividimos o investimento inicial por 36 (número de meses até a necessidade de troca dos equipamentos e licenças). Agora para planos Enterprise (E1,E3 e E5) não há limite de contas, caso você não precise do pacote Office Offline, temos o ponto de encontro próximo há 300 contas. Coincidência, não? Agora se você precisa do pacote Office Offline temos duas opções: • Exchange Server + Pacote Office (em nosso exemplo usamos o standard) • Office 365 Business ou >E3 Assim fizemos uma comparativo para essas opções, com o valor do Office Standard mentalizado (valor dividido por 36 meses) lembrando que o Business Essentials permite apenas 300 contas: Considerações Não consideramos custo com backup para solução com Exchange Server por entender que uma possível contingência e o de recursos do próprio Exchange Server (como archive e journaling) se equiparam a funcionalidades do Office 365. O valor com Microsoft Windows foi considerado no valor do servidor. Conclusão Dessa forma, conseguimos chegar às seguinte conclusões: • Do ponto de vista de funcionalidades, ambas as soluções possuem suas vantagens e desvantagens; • Os custos iniciais com Exchange Server são sempre muito elevados; • Para empresas com poucos usuários, o uso de Exchange não possuí um bom custo vs benefício; • Os planos Business do Office 365 se mostram sempre com melhor custo que as soluções com Exchange Server. Flavio Rescia Dias CTO & Co-Fundador da Darede flavio.rescia@darede.com.br Atuando desde 2006 no mercado de tecnologia, Flávio Rescia é um dos fundadores da Darede, empresa de consultoria de serviços de TI, na qual atua como CTO. Ele possui diversas especializações no setor, sendo a última a Certificação AWS Solutions Architect – Professional.

Nós usamos cookies para garantir e oferecer a melhor experiência de navegação em nosso site! Mais informações