All, DNS Lameness Philosophy ----------------------- There are two fundamentally different philosophies about lameness in reverse DNS. The first (mine): DNS misconfiguration - lameness in this case - is bad when it causes operational problems for a human being somewhere. This may be a network administrator, or a system administrator, or an end user. The second: Lameness is bad because the maintainers of the zone data (the RIPE NCC and the administrator of the reverse domain) have a responsibility to keep this information correct. Proposals Based on Reducing User Pain ------------------------------------- Because I wrongly assumed that there was only one way to think about lameness, I made a set of proposals to how we deal with lameness in the reverse delegation at the RIPE meeting in Lisbon: 1. Stop mass-mailing to lame delegations 2. Include lameness information in an annual report to LIRs (possibly a good thing to have along with the annual bill anyway) 3. Perhaps check for the lame delegations causing the worst problems and send targeted mails based on those These suggestions were based on my philosophy that lameness is bad only inasmuch as it causes problems for actual human beings. So, that is one set of proposals. Proposal Based on DNS as a Platonic Form ---------------------------------------- I thought about it, and if we as a community decide that the 2nd philosophy is more appropriate, then our current strategy of asking people nicely to please fix the problems is ridiculous. A lame delegation is at best worthless, and often harmful. We can find lame delegations with very high certainty. The delegation is the responsibility of the parent as well as the child. 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. If having clean data is important, lets stop with these half-measures, and do it right. Speaking only if we decide that we believe in clean data as a goal, of course. :) -- Shane