Tema: dns
-
Alterar um registo DNS com um caminho de rollback: redução do TTL, comutação e verificação
Uma alteração de DNS só chega aos utilizadores à velocidade a que o TTL antigo expira nas caches; por isso, reduza o TTL um período completo do TTL antigo antes da alteração, mantenha o alvo antigo a responder até o novo estar confirmado em todo o lado, e tenha em conta os resolvers que servem dados desatualizados quando os servidores autoritativos ficam inacessíveis, como a RFC 8767 permite.
-
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.
Legível por máquina: JSON