This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/dns-wg@ripe.net/
[dns-wg] Solving lameness in the reverse zones
- Previous message (by thread): [dns-wg] Solving lameness in the reverse zones
- Next message (by thread): [dns-wg] Solving lameness in the reverse zones
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Michael Graff
mgraff at isc.org
Fri Oct 23 00:22:36 CEST 2009
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Havard Eidnes wrote: >> So, I propose we modify the current process to work something like this: >> >> 1. Tell users that their delegations are lame. >> 2. Wait, then tell them again if not fixed. >> 3. Wait, then PULL THE DELEGATION if not fixed. > > One interpretation could be "pull the delegation to the lame name > server, but leave the working ones in place". Or, notify and stop. Are lame delegations really such a problem that we need to take drastic action? How often would this be checked, and how much liability would be here in modifying what is published? I'd hate to see the papers when a large content provider lost due to a temporary outage on one name server... - --Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrg2ywACgkQ+NNi0s9NRJ2LdQCfacCLIVOMjBBMxw4anm0soiiq TgUAnRGX99ldmU3MPMn1BdIA8h+ZcLpB =GD/r -----END PGP SIGNATURE-----
- Previous message (by thread): [dns-wg] Solving lameness in the reverse zones
- Next message (by thread): [dns-wg] Solving lameness in the reverse zones
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]