Tema: dns
-
Cambiar un registro DNS con una vía de retroceso: reducción del TTL, corte y verificación
Un cambio de DNS llega a los usuarios solo tan rápido como caduque el TTL antiguo en las cachés, así que hay que bajar el TTL un período completo del TTL antiguo antes del cambio, mantener el destino anterior en servicio hasta confirmar el nuevo en todas partes, y tener en cuenta que algunos resolutores sirven datos caducados cuando los servidores autoritativos no están disponibles, como permite la RFC 8767.
-
DNS records a web service depends on
A, AAAA and CNAME map names to addresses, MX routes mail, TXT carries verifications and policies, CAA restricts certificate issuers, NS delegates zones; check authoritative answers, not only a cached resolver, before and after changes.
-
Domain renewal, registrar lock and DNS ownership hygiene
A domain is lost by an expired card, a registrant mailbox on the same domain, or an unlocked account, not by attackers alone: keep clientTransferProhibited and the other client locks set (RFC 5731), auto-renew for several years, use a registrant address on a different domain, read the RDAP record for expiry and status, and know that after expiry registrars must interrupt resolution before deletion and that gTLDs offer a 30-day redemption period.
-
How long did clients keep using the old address after a DNS change, and which resolvers or clients ignored the TTL?
Open question: RFC 1035 defines the TTL as the interval a record may be cached before the source is consulted again, and RFC 8767 lets resolvers serve stale data when authoritative servers are unreachable; after a real record change with a lowered TTL, how long did traffic to the old address persist, and which resolvers, libraries or long-lived processes were responsible for the tail?
-
Email authentication: SPF, DKIM and DMARC
SPF lists the servers allowed to send for a domain, DKIM signs messages with a domain key, DMARC tells receivers what to do when both fail and where to send reports; all three are DNS TXT records that must stay in place when other records change.
-
www versus apex domain: the CNAME restriction, cookie scope and which one to redirect to
The apex cannot be a CNAME because RFC 1034 forbids other data at a node that has one and the apex always carries SOA and NS records, so hosting on a provider's changing address needs A/AAAA records or a provider feature such as CNAME flattening; cookies set on the apex with a Domain attribute reach every subdomain. Pick one form, serve both in the certificate, and redirect the other permanently.
Legible por máquina: JSON