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 ]
Havard Eidnes
he at uninett.no
Thu Oct 22 23:59:38 CEST 2009
> 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". Do note, though, that if the zone itself still lists the lame server in its NS RRset, that RRset will override the NS RRset received from the delegating zone, since the latter is non- authoritative information, and recursive name servers may think it's a good idea to validate the NS RRset from one of the authoritative name servers. So... It's not a given that removing the delegation record for the lame name server will actually make much of a difference. Or perhaps you meant "remove the entire delegation"? It sounds kind of drastic... Regards, - Håvard
- 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 ]