Renovación de dominios, bloqueo del registrador e higiene de la propiedad DNS

Objetivo

No perder nunca un dominio por un fallo administrativo, y poder demostrar y ejercer la propiedad cuando cambian un registrador, una persona empleada o un método de pago.

Requisitos previos

Una lista de todos los dominios que usa la organización (incluidos los de errores tipográficos y los heredados), acceso a cada cuenta de registrador, y un buzón que no dependa de ninguno de esos dominios.

Pasos

1. Inventario: para cada dominio, registrar el registrador, la fecha de caducidad, el contacto de registrante, los servidores de nombres y quién posee el acceso. Leer la vista autoritativa desde RDAP; RFC 9083 define la respuesta de dominio con un arreglo events cuyos valores de eventAction incluyen registration, expiration y last changed, y un arreglo status.
2. Fijar los bloqueos del lado del cliente. RFC 5731 define los valores de estado EPP: con clientTransferProhibited o serverTransferProhibited, las solicitudes de transferencia del objeto deben rechazarse; clientUpdateProhibited y clientDeleteProhibited rechazan actualizaciones y eliminación; clientHold impide que se publique la delegación. Los registradores exponen los del lado del cliente como interruptores de «bloqueo»; mantener activados los bloqueos de transferencia, actualización y eliminación, y desbloquear solo para un cambio planificado.
3. Trasladar el contacto de registrante y el de cuenta a una dirección en un dominio distinto, y añadir un segundo contacto; un recordatorio enviado a admin@example.com después de que example.com deja de resolver no le llega a nadie.
4. Activar la renovación automática con un método de pago que tenga una persona propietaria y una fecha de caducidad en el inventario, y renovar por varios años donde el registro lo permita.
5. Poner las fechas de caducidad en un calendario que sea propiedad del equipo, independiente del correo del registrador. La Expired Registration Recovery Policy de ICANN exige a los registradores enviar recordatorios aproximadamente un mes y una semana antes de la caducidad, pero la política también permite a los registradores eliminar los registros después de la caducidad, y les exige interrumpir antes la vía de resolución DNS: desde la caducidad hasta la eliminación si la eliminan dentro de los ocho días, o de lo contrario durante al menos los últimos ocho días consecutivos en que el nombre todavía se puede renovar. Un sitio que deja de resolver cerca de su fecha de caducidad es, por tanto, la última advertencia, no un fallo de DNS. Los registros de gTLD deben ofrecer un Período de Gracia de Recuperación (Redemption Grace Period) de 30 días inmediatamente después de la eliminación, durante el cual el registro eliminado puede restaurarse.
6. Proteger la cuenta del registrador: una contraseña del almacén de secretos, autenticación de dos factores y una lista de acceso revisada cuando alguien se va.
7. Trimestralmente, releer RDAP para cada dominio y comparar caducidad, estado y servidores de nombres con el inventario.

Resultado esperado

Todos los dominios tienen una fecha de caducidad conocida con suficiente antelación, bloqueos activados, contactos que sobreviven a una caída del dominio mismo y un registro de quién puede actuar sobre él.

Límites y base de verificación

Las citas de política se aplican a los gTLD bajo contratos de ICANN; los registros de código de país tienen sus propias reglas y períodos de gracia. Las tarifas y los términos contractuales quedan fuera de alcance. No se afirma ningún incidente ni ninguna cifra.