Tocava una posada al dia al Droplet que tinc a DigitalOcean, que em serveix algunes webs entre elles aquest blog. Ja està vell i l'Ubuntu 18.04 es queixa sovint. He creat un segon Droplet amb Debian 11 i he migrat sel.lectivament. Ara toca presentar-ho en societat...
Ai l'as, el DNS, la seva propagació i les cache a tants nivells, inclús a casa!
En aquest article intento explicar com funciona la resolució de noms, la seva propagació a través dels servidors de noms a internet, i algunes èines i estratègies que ens puguin ajudar a actualitzar un parell nom-adreça.
He dividit l'article en les següents seccions:
Què és un DNS?
Què és la cache i el TTL?
Nivells de DNS i les seves cache
Èines per comprobar qui resol quina IP
Conclusió
Referències
DNS significa realment Domain Name System en anglès. A part de la explicació que dona la Wikipedia, la gent acostuma a referir-se al DNS com a Domain Name Server, un servidor de noms. Per què?
Simplificant-ho molt i expressament, internet funciona a base de d'adreces IP. Tenen forma de 4 blocs de números del 0 al 255 separats per punts, per exemple 1.2.3.4
. A aquesta fisonomia se li diu IPv4, busqueu la nova IPv6 si us pica la curiositat.
Així, cada ordinador conectat a internet té una adreça i és oblicatori usar-la per comunicar-se amb ell.
Nosaltres els mortals no tenim cap per tant de número, i preferim usar noms per identificar ordinadors a internet. I ha un servei que es dedica a mantenir un diccionari de noms d'ordinador amb la seva respectiva adreça a l'estil guia de telèfons. Nosaltres introduïm ca.wikipedia.org
i aquest servei ens retorna 208.80.154.224
. Això és un Servidor de Noms de Domini, un Domain Name Server.
Aquest servei és a nivell mundial, imagina totes les màquines del món preguntant a un sol servidor totes i cadascuna de les adreces. Impossible. Així que cal una xarxa jeràrquica de servidors de noms que mantenen un llistat de noms i quan reben una petició que no poden respondre, la pregunten al servidor que tenen per sobre.
El fet de respondre amb una adreça la petició d'un nom se li diu resolució de noms, així un servidor de noms resol una adreça.
Nosaltres, com a clients d'aquesta xarxa, normalment utilitzarem el servidor de noms que ens proporciona el nostre proveïdor d'internet, o potser hem configurat algun altre (The Best Free and Public DNS Servers (June 2023)), i els hi deixarem aquesta complexitat per a ells.
Ara que veus com funciona el diccionari de noms de domini, veuràs que com que el servidor ha de resoldre totes les peticions que se li demanen, aniria molt lent si ha de re-preguntar cadascuna al seu servidor superior i fer-nos esperar per la resposta. El que fa és guardar-se les peticions que ja ha demanat per si algú les torna a demanar, ja que molt probablement la resposta sigui la mateixa.
La cache és la "base de dades" volàtil que es guarda en memòria per a resoldre inmediatament una resposta, i el TTL (Time-To-Live) és el temps que una entrada es guardarà en cache abans de ser borrada i re-preguntada al servidor superior.
I aquí entrem al tema. Tot el sistema és molt maco fins que un nom canvia d'adreça. Imaginem que migrem la nostra pàgina web de servidor. El nou servidor té una nova adreça IP, però tots els servidors de noms del món segueixen apuntant al nostre servidor antic. Vaja per Déu.
No hi ha cap èina per dir-li als servidors de noms que han d'actualitzar el parell nom-adreça. Només podem deixar morir la cache, esperant el temps fixat en el TTL, seure en una cadira o fer una becaina.
El concepte de propagació significa que, després d'haver anat al registre més alt que tenim que indica el parell nom-adreça, el registrador del domini, i canviat l'adreça IP vella per la nova, tota la xarxa de servidors de nom aniran actualitzant els seus registres a mesura que la seva cache vagi morint, definit en el TTL que tindran ells, i això triga vàries hores.
Com que aquestes coses volen temps, el millor és organitzar-nos nosaltres per avançat. La estratègia és ser capaços de servir la web des del servidor vell i nou, i al mateix temps definir un TTL per al nostre domini el més baix possible
Quan haguem canviat l'adreça al registre de domini, la propagació començarà i veurem que durant unes hores els nostres servidors web vell i nou reben peticions, provinents dels servidors de noms que encara no s'han actualitzat i dels que ja ho han fet.
El millor que podem fer és assegurar-nos que el nou servidor funciona, o com a mínim mostra una pàgina de servei per tal que els usuaris que hi arribin entenguin que estem de manteniment.
Si el que triga més és la propagació, el que podem fer és configurar uns dies abans l'actual parell nom-adreça per a que mori ràpid, amb un TTL baix. Aquest canvi trigarà unes hores a propagar-se, el mateix que trigaria el canvi d'adreça, però no afecta al servei (l'adreça no canvia) i només li estem dient a la xarxa de servidors de nom que redueixin al mínim la vida de la cache.
Així, quan editem realment l'adreça al registrador i la propagació del canvi comenci, els servidors al món ja tindran configurat que han de deixar morir la cache més abans i llavors el canvi del servidor vell al nou és més ràpid a ulls dels usuaris.
Bé, doncs hem canviat l'adreça d'un domini i ja han passat unes hores, i jo encara veig l'antiga pàgina web al meu navegador. Per què?
Des del registrador de noms fins al teu navegador hi ha tot un munt de nivells on el parell nom-adreça queda en cache i cal esperar a que acabi el TTL.
A un nivell més baix, quan estem parlant ja de màquines a les que ens podem conectar, en molts casos podem netejar manualment la cache de forma que la màquina pregunti al servidor de noms superior quina és l'adraça per aquest nom.
Aquest és el nivell més alt al que podem arribar. Quan registrem un domini o hi apliquem algun canvi, aquest hauria de comunicar-se amb els servidors de domini més alts. És una mica més complicat, però ho podem entendre així.
En el meu cas, Directnic em manté per defecte un TTL als dominis de 3600 segons, 1 hora. Aquí és on he d'anar per a modificar l'adreça del meu servidor, i també on puc canviar uns dies abans el TTL del domini.
Un a un els servidors DNS del món aniràn perdent el parell nom-adreça i preguntaran al seu nivell superior, fins arribar al capdamunt que tindrà l'adreça actualitzada.
Aquests també haurien de llegir i aplicar el TTL que hem definit al registrador de noms, però molts d'aquests s'ho passen pel forro.
No queda cap altra que esperar. Jo tinc obertes un parell de pestanyes amb èines online de propagació, que consulten diversos servidors de noms al món i ens donen quina és la IP que tenen:
Independentment de qui resolgui el parell nom-adreça, l'adreça és d'un hosting, normalment un servidor ubicat en algun punt del planeta des d'on servim l'aplicació web.
En la majoria dels casos, el hosting també ofereix alguns serveis de DNS, de forma que si configurem els servidors de nom del hosting en el DNS, el hosting llavors és l'encarregat de manejar la configuració de DNS del domini, permetent-nos setar subdominis, emails i demés en un entorn més integrat.
Jo estic ara a DigitalOcean i també ofereixen aquests serveis, però només hi faig ús en alguns dels dominis que mantinc. Si és el cas, apliqueu aquí el mateix que pel registrador: el TTL defineix el temps de vida que l'actual configuració té en les caches dels servidors del món.
Aquí ja entrem en el terreny que nosaltres podem manipular.
El router és la màquina que ens comunica amb internet. Té definits els servidors DNS que usarem, siguin uns que haguem configurat nosaltres o els que venen per defecte del proveïdor.
Sigui com sigui, molt probablement manté alguna mena de cache que hem de tenir en compte. En el meu cas, el TTL ja havia passat però els meus ordinadors de casa encara resolien l'adreça antiga. Cal buscar per internet com refresca la cache cada router específicament.
Cal tenir en compte que alguns routers, especialment aquells que distribueixen els proveidors d'internet, venen prou tancats i no es deixen configurar massa. Si és així, només ens quedarà esperar o simplement provar de reiniciar-lo per a que perdi la cache i pregunti el parell nom-adreça al servidor superior.
El router que tinc és un Fritz!Box 7590 AX, molt content amb ell. He trobat com netejar la cache sense reiniciar el router: desactivant i reactivant el DHCP!
TIL: Flush the FRITZ!Box DNS Cache:
Entrar al Router via web. Autenticar-se.
Navegar a Home Network (menú lateral) > Network Settings (pestanya) > IP Settings (secció)
Clicar al botó IPv4 Settings
Desmarcar Enable DHCP server
Clicar al botó Apply
Repetir la operació tornant a marcar Enable DHCP server
En el meu cas particular, tinc un servidor DNS local en una altra Raspberry Pi (com vaig explicar a Quick DNS server on a Raspberry Pi | Xavier.Arnaus.net). Bàsicament és un Linux corrent un dnsmasq.
Podem netejar la cache reiniciant el servei o enviant-li una senyal SIG.
Per reiniciar el servei:
SSH al host:
ssh xavi@dagobah
Reinicia el servei:
sudo /etc/init.d/dnsmasq restart
Per a l'estratègia d'enviar-li una senyal SIG, cal que el dnsmasq estigui corrent amb el paràmetre de configuració clear-on-reload
configurat a /etc/dnsmasq.conf
, que no ve per defecte activat. Si ho està, podem:
Netejar la cache disparant un reload, enviant-li una senyal HUP
:
pkill -HUP dnsmasq
Aquí entrem als dominis de l'usuari. El nostre ordinador tindrà també cert nivell de cache per als parells nom-adreça.
Cada sistema operatiu tindrà la seva forma de netejar la cache.
Executa la següent comanda al terminal. Et demanarà la contrasenya del teu usuari:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Executa la següent comanda al terminal / consola:
ipconfig /flushdns
Aquí la cosa varia molt depenent de la teva distribució. En general hi han 2 majors formes de resoldre els noms: amb dnsmasq o systemd-resolve.
Per a dnsmasq és el mateix que he explicat per al meu servidor DNS local, executada a la nostra terminal.
Per a systemd-resolve executarem les següents comandes al terminal:
sudo systemd-resolve --flush-caches
sudo resolvectl flush-caches
Per últim tenim el nivell d'aplicació. Parlo aquí de navegadors, però potencialment tota aplicació que faci ús massiu de resolució de noms tindrà un cert nivell de cache.
Els següents punts expliquen com netejar la cache en els navegadors principals, però val a dir que jo només ho he probat a Chrome i Safari.
Visitar la web interna: chrome://net-internals/#dns
Clicar sobre el botó Clear host cache
Visitar la web interna: about.config
. El més segur és que haurem d'acceptar el risk clicant I accept the risk!
Busca les configuracions network.dnsCacheExpiration i network.dnsCacheExpirationGracePeriod. Tindràn un valor per defecte de 60
.
Canvia el valor a 0
, Clica en Accept i torna'ls a posar al valor anterior.
Si les configuracions no existeixen, crea-les amb valor 60
i repeteix la operació anterior.
Cal activar primer el Develop menu:
Ves a Settings > Advanced
Clica sobre el checkbox Show Develop menu in menu bar
Ara tenim una opció més al menú superior anomenat Develop. Per netejar la cache clica sobre el menú Develop > Empty Caches
Quan estem a plena propagació, el que ens interessa és saber com va la cosa, quins servidors de noms tenen ja la nova adreça i quins encara tenen la vella.
Com he mencionat més amunt, tinc un parell de pestanyes obertes amb les següents èines de comprobació de propagació. N'hi han més, i cadascuna té llistats diferents servidors de noms a cada país.
A cada nivell on poguem entrar via terminal (un servidor DNS, el hosting o el nostre ordinador), tenim algunes èines per poder veure què i qui ens resol, i llavors actuar en conseqüencia.
dig
- dig (command) - WikipediaResol l'adreça IP del nom de domini donat. Per defecte consulta el servidor de noms que estigui definit en el nostre sistema operatiu.
Consulta per defecte al DNS definit al nostre SO:
$ dig xavier.arnaus.net
; <<>> DiG 9.16.37-Raspbian <<>> xavier.arnaus.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58792
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xavier.arnaus.net. IN A
;; ANSWER SECTION:
xavier.arnaus.net. 40613 IN A 161.35.212.106
;; Query time: 9 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 15 08:08:50 CEST 2023
;; MSG SIZE rcvd: 62
;; ANSWER SECTION:
Resolució per al nom de domini donat.
SERVER:
Quin servidor DNS ens proporciona aquesta resolució. Aquí és el servidor DNS que hi ha a la mateixa màquina, ja que l'he executat des del servidor DNS local.
Consulta a un servidor DNS definit:
$ dig xavier.arnaus.net @8.8.8.8
; <<>> DiG 9.16.37-Raspbian <<>> xavier.arnaus.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52520
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;xavier.arnaus.net. IN A
;; ANSWER SECTION:
xavier.arnaus.net. 21600 IN A 161.35.212.106
;; Query time: 189 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jun 15 08:08:36 CEST 2023
;; MSG SIZE rcvd: 62
;; ANSWER SECTION:
Resolució per al nom de domini donat.
SERVER:
En aquest cas és el servidor DNS que hem definit a la consulta 8.8.8.8
Consultes curtes (limitant la info només a la resolució):
$ dig xavier.arnaus.net +short
161.35.212.106
$ dig xavier.arnaus.net @8.8.8.8 +short
161.35.212.106
nslookup
- nslookup - WikipediaUna èina similar, que molts estan acostumats a usar. Hi ha controvèrsia, ja que en un principi el programa es va marcar com deprecat i després es van desdir.
Consulta per defecte:
$ nslookup xavier.arnaus.net
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: xavier.arnaus.net
Address: 161.35.212.106
Consulta a un servidor DNS definit:
$ nslookup xavier.arnaus.net 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: xavier.arnaus.net
Address: 161.35.212.106
ping
- ping (networking utility) - WikipediaUna èina bàsica que s'utilitza per preguntar a un host si està viu (respondrà si ho està). Primer prova de resoldre l'arxiu /etc/hosts
, i després tira del servidor de noms definit al sistema operatiu.
Ens va bé per que ens assegura que el host està viu, a comparació amb les altres utilitats que només ens resolen el nom de domini.
Enviar un sol paquet al host:
$ ping -c1 xavier.arnaus.net
PING xavier.arnaus.net (161.35.212.106) 56(84) bytes of data.
64 bytes from digitalocean (161.35.212.106): icmp_seq=1 ttl=57 time=13.9 ms
--- xavier.arnaus.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 13.898/13.898/13.898/0.000 ms
host
- host (Unix) - WikipediaUna altra èina bàsica per resoldre noms i adreces.
Resoldre un nom:
$ host xavier.arnaus.net
xavier.arnaus.net has address 161.35.212.106
Cada cop que em toca fer algun canvi que impliqui actualitzar el parell nom-adreça sé que passaré el dia enganxat a les consultes als servidors de noms, i preguntant-me si m'estic deixant alguna cosa. El fet que un estigui obligat a esperar fa que, si ets insegur de mena, estiguis amb l'angoixa d'estar perdent el temps amb l'espera.
Amb aquest article espero haver mostrat que:
La resolució de noms és un registre a escala mundial. Els canvis volen temps i cal paciéncia.
Organitza l'acció amb previsió. Reduir el TTL del domini uns dies abans farà que quan executis el canvi tot esdevingui més inmediat. No t'oblidis a tornar-ho al valor anterior un cop la propagació hagi acabat.
La cache és quelcom present a tots els nivells. Hem de ser conscients de totes les capes que tenim entre el registrador de noms i el nostre navegador, per a saber quina d'elles ens està fent la punyeta i si podem netejar la seva cache.
Salut!