Introdução
DNS, ou Domain Name System (Sistema de Nomes de Domínio), costuma ser uma parte muito difícil de se entender na hora de aprender a configurar sites e servidores. Compreender como o DNS funciona ajudará você a diagnosticar problemas na configuração de acesso aos seus sites e permitirá ampliar sua compreensão do que está acontecendo nos bastidores.
Neste guia, discutiremos alguns conceitos fundamentais de DNS que o ajudarão a começar a trabalhar com sua configuração de nomes de domínio e o preparará para configurar seu nome de domínio em qualquer servidor DNS .
Antes de começarmos a configurar seus próprios servidores para resolver seu domínio, vamos repassar alguns conceitos básicos sobre como tudo isso realmente funciona.
Terminologia de Domínio
Devemos começar definindo nossos termos. Embora alguns desses tópicos sejam familiares em outros contextos, há muitos termos usados ao falar sobre nomes de domínio e DNS que não são usados com muita frequência em outras áreas da computação.
Vamos começar com calma:
Sistema de nomes de domínio
O sistema de nomes de domínio, mais comumente conhecido como “DNS”, é o sistema de rede existente que nos permite resolver nomes amigáveis para endereços IP exclusivos.
Nome do domínio
Um nome de domínio é o nome amigável que estamos acostumados a associar a um recurso da Internet. Por exemplo, “google.com” é um nome de domínio. Algumas pessoas dirão que a parte “google” é o domínio, mas geralmente podemos nos referir à forma combinada como nome de domínio.
O URL “google.com” está associado aos servidores de propriedade da Google LLC. O sistema de nomes de domínio nos permite acessar os servidores do Google quando digitamos “google.com” em nossos navegadores.
Endereço de IP
Um endereço IP é o que chamamos de local endereçável de rede. Cada endereço IP deve ser exclusivo em sua rede. Quando falamos de sites, essa rede é toda a internet.
IPv4, a forma mais comum de endereço, é escrito como quatro conjuntos de números, cada conjunto com até três dígitos, separados por um ponto. Por exemplo, “111.222.111.222” pode ser um endereço IP IPv4 válido. Com o DNS, mapeamos um nome para esse endereço para que você não precise se lembrar de um conjunto complicado de números para cada lugar que deseja visitar em uma rede.
Domínio de nível superior
Um domínio de nível superior, ou TLD (Top-Level Domain), é a parte mais geral do domínio. O domínio de nível superior é a parte mais à direita (separada por um ponto). Domínios de nível superior comuns são “com”, “net”, “org”, “gov”, “edu” e “io”.
Os domínios de nível superior estão no topo da hierarquia em termos de nomes de domínio. Certas partes recebem controle de gerenciamento sobre domínios de primeiro nível pela ICANN (Internet Corporation for Assigned Names and Numbers). Essas partes podem então distribuir nomes de domínio no TLD, geralmente por meio de um registrador de domínios.
Hosts
Dentro de um domínio, o proprietário do domínio pode definir hosts individuais, que se referem a computadores ou serviços separados acessíveis através de um domínio. Por exemplo, a maioria dos proprietários de domínios tornam seus servidores web acessíveis através do domínio simples (example.com) e também através da definição de host “www” ( www.example.com).
Você pode ter outras definições de host no domínio geral. Você pode ter acesso à API por meio de um host “api” (api.example.com) ou pode ter acesso ftp definindo um host chamado “ftp” ou “arquivos” (ftp.example.com ou arquivos.example.com). Os nomes de host podem ser arbitrários, desde que sejam exclusivos para o domínio.
Subdomínio
Um assunto relacionado a hosts são os subdomínios.
O DNS funciona em uma hierarquia. Os TLDs podem ter muitos domínios abaixo deles. Por exemplo, o TLD “com” tem “google.com” e “ubuntu.com” abaixo dele. Um subdomínio refere-se a qualquer domínio que faça parte de um domínio maior. Neste caso, “ubuntu.com” pode ser considerado um subdomínio de “com”. Isso normalmente é chamado apenas de domínio ou a parte “ubuntu” é chamada de SLD (Second Level Domain), que significa domínio de segundo nível.
Da mesma forma, cada domínio pode controlar subdomínios localizados abaixo dele. Geralmente é isso que queremos dizer com subdomínios. Por exemplo, você poderia ter um subdomínio para o departamento de história da sua escola em “www.historia.escola.edu”. A parte “historia” é um subdomínio de “escola”.
A diferença entre um nome de host e um subdomínio é que um host define um computador ou recurso, enquanto um subdomínio estende o domínio pai. É um método de subdividir o próprio domínio.
Seja falando sobre subdomínios ou hosts, você pode começar a ver que as partes mais à esquerda de um domínio são as mais específicas. É assim que o DNS funciona: do mais específico para o menos específico conforme você lê da esquerda para a direita.
Nome de domínio totalmente qualificado
Um nome de domínio totalmente qualificado, geralmente chamado de FQDN (Fully Qualified Domain Name), é o que chamamos de nome de domínio absoluto. Os domínios no DNS podem ser fornecidos uns em relação aos outros e, como tal, podem ser um tanto ambíguos. Um FQDN é um nome absoluto que especifica sua localização em relação à raiz absoluta do sistema de nomes de domínio.
Isso significa que ele especifica cada domínio pai, incluindo o TLD. Um FQDN adequado termina com um ponto, indicando a raiz da hierarquia DNS. Um exemplo de FQDN é “mail.google.com.”. Às vezes, o software que faz um chamado pelo FQDN não exige o ponto final, mas o ponto final é necessário para estar em conformidade com os padrões da ICANN.
Servidor de nomes
Um servidor de nomes é um computador designado para traduzir nomes de domínio em endereços IP. Esses servidores fazem a maior parte do trabalho no sistema DNS. Como o número total de traduções de domínio é muito grande para qualquer servidor, cada servidor pode redirecionar a solicitação para outros servidores de nomes ou delegar responsabilidade por um subconjunto de subdomínios pelos quais são responsáveis.
Os servidores de nomes podem ser “autoritários”, o que significa que fornecem respostas a consultas sobre domínios sob seu controle. Caso contrário, eles poderão apontar para outros servidores ou servir cópias em cache dos dados de outros servidores de nomes.
Arquivo de zona
Um arquivo de zona é um arquivo de texto simples que contém os mapeamentos entre nomes de domínio e endereços IP. É assim que o sistema DNS finalmente descobre qual endereço IP deve ser contatado quando um usuário solicita um determinado nome de domínio.
Os arquivos de zona residem em servidores de nomes e geralmente definem os recursos disponíveis em um domínio específico ou o local onde se pode ir para obter essas informações.
Registros
Dentro de um arquivo de zona, os registros são mantidos. Na sua forma mais simples, um registro é basicamente um mapeamento único entre um recurso e um nome. Eles podem mapear um nome de domínio para um endereço IP, definir os servidores de nomes do domínio, definir os servidores de correio do domínio, etc.
Como funciona o DNS
Agora que você está familiarizado com parte da terminologia envolvida no DNS, veremos como o sistema realmente funciona.
O sistema é muito simples em uma visão geral de alto nível, mas é muito complexo quando você olha os detalhes. No geral, porém, é uma infraestrutura muito confiável que tem sido essencial para a adoção da Internet como a conhecemos hoje.
Servidores Raiz
Como dissemos acima, o DNS é, em sua essência, um sistema hierárquico. No topo deste sistema estão os chamados “servidores raiz”. Esses servidores são controlados por várias organizações e têm autoridade delegada pela ICANN.
Existem atualmente 13 servidores raiz em operação. Porém, como há um número incrível de nomes para resolver a cada minuto, cada um desses servidores é, na verdade, espelhado. O interessante dessa configuração é que cada um dos espelhos de um único servidor raiz compartilha o mesmo endereço IP. Quando solicitações são feitas para um determinado servidor raiz, a solicitação será roteada para o espelho mais próximo desse servidor raiz.
O que esses servidores raiz fazem? Os servidores raiz tratam de solicitações de informações sobre domínios de nível superior. Portanto, se chegar uma solicitação de algo que um servidor de nomes de nível inferior não possa resolver, uma consulta será feita ao servidor raiz para o domínio.
Os servidores raiz não saberão realmente onde o domínio está hospedado. Eles poderão, no entanto, direcionar o solicitante para os servidores de nomes que tratam do domínio de nível superior especificamente solicitado.
Portanto, se uma solicitação para “www.wikipedia.org” for feita ao servidor raiz, o servidor raiz não encontrará o resultado em seus registros. Ele verificará seus arquivos de zona em busca de uma listagem que corresponda a “www.wikipedia.org”. Não encontrará um.
Em vez disso, ele encontrará um registro para o TLD “org” e fornecerá à entidade solicitante o endereço do servidor de nomes responsável pelos endereços “org”.
Servidores TLD
O solicitante então envia uma nova solicitação ao endereço IP (fornecido pelo servidor raiz) que é responsável pelo domínio de nível superior da solicitação.
Então, para continuar nosso exemplo, ele enviaria uma solicitação ao servidor de nomes responsável por saber sobre os domínios “org” para ver se sabe onde “www.wikipedia.org” está localizado.
Mais uma vez, o solicitante procurará “www.wikipedia.org” em seus arquivos de zona. Ele não encontrará esse registro em seus arquivos.
Porém, encontrará um registro listando o endereço IP do servidor de nomes responsável por “wikipedia.org”. Isso está cada vez mais próximo da resposta que desejamos.
Servidores de nomes em nível de domínio
Neste ponto, o solicitante possui o endereço IP do servidor de nomes responsável por saber o endereço IP real do recurso. Envia uma nova solicitação ao servidor de nomes perguntando, mais uma vez, se consegue resolver “www.wikipedia.org”.
O servidor de nomes verifica seus arquivos de zona e descobre que possui um arquivo de zona associado a “wikipedia.org”. Dentro deste arquivo, existe um registro para o host “www”. Este registro informa o endereço IP onde este host está localizado. O servidor de nomes retorna a resposta final ao solicitante.
O que é um servidor de resolução de nomes?
No cenário acima, nos referimos a um “solicitante”. Qual é o solicitante nesta situação?
Em quase todos os casos, o solicitante será o que chamamos de “servidor de resolução de nomes”. Um servidor de resolução de nomes é aquele configurado para fazer perguntas a outros servidores. É basicamente um intermediário para um usuário que armazena em cache os resultados de consultas anteriores para melhorar a velocidade e conhece os endereços dos servidores raiz para poder “resolver” solicitações feitas para coisas que ele ainda não conhece.
Basicamente, um usuário normalmente terá alguns servidores de nomes de resolução configurados em seu sistema de computador. Os servidores de nomes de resolução geralmente são fornecidos por um ISP ou outras organizações. Por exemplo , o Google fornece servidores DNS de resolução que você pode consultar. Eles podem ser configurados em seu computador de forma automática ou manual.
Quando você digita um URL na barra de endereço do seu navegador, seu computador primeiro verifica se consegue descobrir localmente onde o recurso está localizado. Ele verifica o arquivo “hosts” no computador e em alguns outros locais. Em seguida, ele envia a solicitação ao servidor de nomes de resolução e aguarda para receber o endereço IP do recurso.
O servidor de nomes de resolução então verifica seu cache em busca da resposta. Se não encontrar, ele seguirá as etapas descritas acima.
A resolução de servidores de nomes basicamente comprime o processo de solicitação para o usuário final. Os clientes simplesmente precisam saber perguntar aos servidores de nomes onde um recurso está localizado e ter certeza de que eles investigarão e retornarão a resposta final.
Arquivos de zona
Mencionamos no processo acima a ideia de “arquivos de zona” e “registros”.
Os arquivos de zona são a forma como os servidores de nomes armazenam informações sobre os domínios que conhecem. Cada domínio que um servidor de nomes conhece é armazenado em um arquivo de zona. A maioria das solicitações que chegam ao servidor de nomes intermediário não são algo para o qual o servidor terá arquivos de zona.
Se estiver configurado para lidar com consultas recursivas, como um servidor de resolução de nomes, ele descobrirá a resposta e a retornará. Caso contrário, dirá à parte requerente onde procurar a seguir.
Quanto mais arquivos de zona um servidor de nomes tiver, mais solicitações ele poderá responder com autoridade.
Um arquivo de zona descreve uma “zona” DNS, que é basicamente um subconjunto de todo o sistema de nomenclatura DNS. Geralmente é usado para configurar apenas um único domínio. Ele pode conter vários registros que definem onde estão os recursos para o domínio em questão.
O parâmetro $ORIGIN de uma zona é igual ao nível de autoridade mais alto da zona, por padrão.
Portanto, se um arquivo de zona for usado para configurar o domínio example.com., o parâmetro $ORIGIN seria definido como example.com..
Isso pode ser configurado na parte superior do arquivo de zona ou pode ser definido no arquivo de configuração do servidor DNS que faz referência ao arquivo de zona. De qualquer forma, este parâmetro descreve para que a zona terá autoridade.
Da mesma forma, $TTLconfigura o “tempo de vida” das informações que fornece. É basicamente um temporizador. Um servidor de nomes de cache pode usar resultados consultados anteriormente para responder perguntas até que o valor TTL se esgote.
Tipos de registro
Dentro do arquivo de zona, podemos ter muitos tipos de registros diferentes. Veremos alguns dos tipos mais comuns (ou obrigatórios) aqui.
Registros SOA
O registro Start of Authority, ou SOA, é um registro obrigatório em todos os arquivos de zona. Deve ser o primeiro registro real em um arquivo (embora as especificações de $ORIGIN e $TTL possam aparecer acima). É também um dos mais complexos de entender.
O início do registro de autoridade é mais ou menos assim:
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
Vamos explicar para que serve cada parte:
domain.com.: Esta é a raiz da zona. Isto especifica que o arquivo de zona é para o domíniodomain.com.. Frequentemente, você verá isso ser substituído por@, que é apenas um espaço reservado que substitui o conteúdo da variável$ORIGINque vimos acima.IN SOA : A parte “IN” significa internet (e estará presente em muitos registros). O SOA é o indicador de que este é um registro de Início de Autoridade.
ns1.domain.com.: Isso define o servidor de nomes primário para este domínio. Os servidores de nomes podem ser primários ou secundários e, se o DNS dinâmico estiver configurado, um servidor precisa ser “primário” aqui. Se você não configurou o DNS dinâmico, então este é apenas um dos seus servidores de nomes primários.admin.domain.com.: Este é o endereço de e-mail do administrador desta zona. O “@” é substituído por um ponto no endereço de e-mail. Se a parte do nome do endereço de e-mail normalmente tiver um ponto, substitua-o por “\” nesta parte ([email protected]torna-seseu\nome.domain.com).12083 : Este é o número de série do arquivo de zona. Cada vez que você edita um arquivo de zona, você deve incrementar esse número para que o arquivo de zona seja propagado corretamente. Os servidores secundários verificarão se o número de série do servidor primário de uma zona é maior do que o número existente em seu sistema. Se for, solicita o novo arquivo de zona; caso contrário, continua servindo o arquivo original.
3h : Este é o intervalo de atualização da zona. Este é o tempo que o secundário aguardará antes de sondar o primário para alterações no arquivo de zona.
30m : Este é o intervalo de novas tentativas para esta zona. Se o secundário não puder se conectar ao primário quando o período de atualização terminar, ele aguardará esse período de tempo e tentará sondar novamente o primário.
3w : Este é o prazo de validade. Se um servidor de nomes secundário não conseguir contatar o primário durante esse período de tempo, ele não retornará mais respostas como uma fonte autorizada para esta zona.
1h : Este é o tempo que o servidor de nomes armazenará em cache um erro de nome se não conseguir encontrar o nome solicitado neste arquivo.
Registros A e AAAA
Ambos os registros mapeiam um host para um endereço IP. O registro “A” é usado para mapear um host para um endereço IP IPv4, enquanto os registros “AAAA” são usados para mapear um host para um endereço IPv6.
O formato geral desses registros é este:
host IN A IPv4_address
host IN AAAA IPv6_address
Portanto, como nosso registro SOA chamou um servidor primário em “ns1.domain.com”, teríamos que mapear isso para um endereço IP, já que “ns1.domain.com” está dentro da zona “domain.com” que este arquivo está definindo.
O registro poderia ser algo assim:
ns1 IN A 111.222.111.222
Observe que não precisamos fornecer o nome completo. Podemos apenas fornecer o host, sem o FQDN e o servidor DNS preencherá o restante com o valor $ORIGIN. No entanto, poderíamos facilmente usar todo o FQDN se quisermos ser semânticos:
ns1.domain.com. IN A 111.222.111.222
Na maioria dos casos, é aqui que você definirá seu servidor web como “www”:
www IN A 222.222.222.222
Devemos também dizer para onde o domínio base é resolvido. Podemos fazer isso assim:
domain.com. IN A 222.222.222.222
Poderíamos ter usado o “ @” para nos referir ao domínio base:
@ IN A 222.222.222.222
Também temos a opção de resolver qualquer coisa neste domínio que não esteja definida explicitamente para este servidor. Podemos fazer isso com o curinga “*”:
* IN A 222.222.222.222
Isso funciona da mesma forma com registros AAAA para endereços IPv6.
Registros CNAME
Os registros CNAME definem um alias (apelido) para o nome canônico do seu servidor (definido por um registro A ou AAAA).
Por exemplo, poderíamos ter um registro de nome A definindo o host “server1” e então usar “www” como um alias para este host:
server1 IN A 111.111.111.111
www IN CNAME server1
Esteja ciente de que esses aliases apresentam algumas perdas de desempenho porque exigem uma consulta adicional ao servidor. Na maioria das vezes, o mesmo resultado poderia ser alcançado usando registros A ou AAAA adicionais.
Um caso em que um CNAME é recomendado seria quando precisamos fornecer um alias para um recurso fora da zona atual.
Registros MX
Os registros MX são usados para definir as trocas de correio usadas para o domínio. Isso ajuda as mensagens de e-mail a chegarem corretamente ao seu servidor de e-mail.
Ao contrário de muitos outros tipos de registro, os registros de correio geralmente não mapeiam um host para algo, porque se aplicam a toda a zona. Como tal, eles geralmente se parecem com isto:
IN MX 10 mail.domain.com.
Se o pacote solicitado exigir dependências adicionais, elas serão impressas na saída padrão e você será solicitado a confirmar o procedimento. Vai parecer algo assim:
#exemplo
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
Neste exemplo, o host “mail1” é o servidor de troca de e-mail preferencial.
Também poderíamos escrever assim:
#exemplo
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
Registros NS
Este tipo de registro define os servidores de nomes usados para esta zona.
Você pode estar se perguntando: “se o arquivo de zona reside no servidor de nomes, por que ele precisa fazer referência a si mesmo?”. Parte do que torna o DNS tão bem-sucedido são seus múltiplos níveis de cache. Uma razão para definir servidores de nomes dentro do arquivo de zona é que o arquivo de zona pode estar sendo servido a partir de uma cópia em cache em outro servidor de nomes. Existem outras razões para a necessidade de servidores de nomes definidos no próprio servidor de nomes, mas não entraremos nisso aqui.
Assim como os registros MX, esses são parâmetros que abrangem toda a zona e, portanto, também não aceitam hosts. Em geral, eles são assim:
#exemplo
IN NS ns1.domain.com.
IN NS ns2.domain.com.
Você deve ter pelo menos dois servidores de nomes definidos em cada arquivo de zona para operar corretamente se houver algum problema com um servidor. A maioria dos softwares de servidor DNS considera um arquivo de zona inválido se houver apenas um único servidor de nomes.
Como sempre, inclua o mapeamento para os hosts com registros A ou AAAA:
#exemplo
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
Existem alguns outros tipos de registro que você pode usar, mas esses são provavelmente os tipos mais comuns que você encontrará.
Registros PTR
Os registros PTR são usados para definir um nome associado a um endereço IP. Os registros PTR são o inverso de um registro A ou AAAA. Os registros PTR são únicos porque começam na raiz .arpa e são delegados aos proprietários dos endereços IP. Os Registros Regionais da Internet (RIRs – Regional Internet Registries) gerenciam a delegação de endereços IP para organizações e provedores de serviços. Os Registros Regionais da Internet incluem APNIC, ARIN, RIPE NCC, LACNIC e AFRINIC.
Aqui está um exemplo de um registro PTR onde o IPv4 111.222.333.444 seria semelhante a:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Este exemplo de registro PTR para um endereço IPv6 mostra o formato nibble do reverso do servidor DNS IPv6 do Google 2001:4860:4860::8888.
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400 IN PTR google-public-dns-a.google.com.
A ferramenta de linha de comando digcom o -xsinalizador pode ser usada para procurar o nome DNS reverso de um endereço IP.
Aqui está um exemplo de um comando dig. O +shorté anexado para reduzir a saída para o nome DNS reverso.
dig -x 8.8.4.4 +short
A saída do comando dig acima será o nome de domínio no registro PTR do endereço IP:
dns.google.
Os servidores na Internet usam registros PTR para colocar nomes de domínio em entradas de log, tomar decisões sobre o tratamento de spam e exibir detalhes fáceis de ler acerca de outros dispositivos.
Os servidores de e-mail mais comumente usados pesquisarão o registro PTR de um endereço IP do qual recebe e-mail. Se o endereço IP de origem não tiver um registro PTR associado a ele, os e-mails enviados poderão ser tratados como spam e rejeitados. Não é importante que o FQDN no PTR corresponda ao nome de domínio do email que está sendo enviado. O que é importante é que exista um registro PTR válido com um registro A de encaminhamento correspondente e apropriado.
Normalmente, os roteadores de rede na Internet recebem registros PTR que correspondem à sua localização física. Por exemplo, você pode ver referências a ‘NYC’ ou ‘CHI’ para um roteador na cidade de Nova York ou Chicago. Isso é útil ao executar um traceroute ou MTR e revisar o caminho que o tráfego da Internet está seguindo.
A maioria dos provedores que oferecem servidores dedicados ou serviços VPS dará aos clientes a capacidade de definir um registro PTR para seu endereço IP.
Nota: É importante que o FQDN no registro PTR tenha um registro A de encaminhamento correspondente e apropriado. Exemplo:
111.222.333.444tem um PTR deserver.example.comeserver.example.comé um registro A que aponta para111.222.333.444.
Registros CAA
Os registros CAA são usados para especificar quais autoridades de certificação (CAs – Certificate Authorities) têm permissão para emitir certificados SSL/TLS para o seu domínio. A partir de 8 de setembro de 2017, todas as CAs são obrigadas a verificar esses registros antes de emitir um certificado. Se nenhum registro estiver presente, qualquer CA poderá emitir um certificado. Caso contrário, apenas as CAs especificadas poderão emitir certificados. Os registros CAA podem ser aplicados a hosts únicos ou a domínios inteiros.
Segue um exemplo de registro CAA:
example.com. IN CAA 0 issue "letsencrypt.org"
O host, IN, e o tipo de registro (CAA) são campos DNS comuns. As informações específicas do CAA acima são a parte 0 issue "letsencrypt.org". São três partes: flag (0), tags (issue) e valores ("letsencrypt.org").
- Flags são um número inteiro que indica como uma CA deve lidar com tags que não entende. Se a flag for
0, o registro será ignorado. Se1, a CA deverá recusar a emissão do certificado. - Tags são strings que denotam a finalidade de um registro CAA. Atualmente, elas podem ser
issuepara autorizar uma CA a criar certificados para um nome de host específico,issuewildpara autorizar certificados curinga ouiodefpara definir uma URL onde as CAs possam relatar violações de política. - Os valores são uma string associada à tag do registro . Para
issueeissuewildnormalmente será o domínio da CA à qual você está concedendo permissão. Paraiodefisso pode ser o URL de um formulário de contato ou um linkmailto:para enviar feedback por e-mail.
Você pode usar dig para buscar registros CAA usando as seguintes opções:
dig example.com type257
Para obter informações mais detalhadas sobre registros CAA, você pode ler a RFC 6844.
Conclusão
Agora você deve ter uma boa noção de como o DNS funciona. Embora a ideia geral seja relativamente fácil de entender, isso ainda é algo que pode ser difícil para administradores inexperientes colocarem em prática. Mas a prática é o que vai te ajudar a fixar os conhecimentos e aprofundar no entendimento.
Este artigo foi traduzido e adaptado para o Português pelo autor do post. O artigo original pode ser lido aqui.
