Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

It’s amazing how fast people can fix lame delegations once email and other services stop flowing. The only reason you think it is un- winnable is that you are unwilling to remove the delegation for failing to maintain a properly working configuration. 

Start removing lame delegation after fair warnings and you will see others fixing their lame delegations on initial notice.  No system works if there are not checks and balances.
-- 
Mark Andrews

> On 4 May 2018, at 01:05, David Huberman <david.huberman@icann.org> wrote:
> 
> Ed Lewis wrote:
> 
>> (Only if you like reading history:)
> 
>> The reason was a flaw in "certain old resolvers" that followed the "upwards referral" to the root that 
>> the "predominate server code of the time" had decided to use for lameness..  The result was a lot of 
>> resolver stuck in an infinite loop, hitting the root servers.  I.e., this was an operational issue.  The 
>> solution was updating and redeploying the buggy code, not stamping out lame servers (which was 
>> the goal of the task).  FWIW, the "upwards referrals" were discontinued when it became apparent 
>> they were being used in noticeable amplification attacks.
> 
> I sat on the front lines of ARIN’s war against lame delegations for the entire war.  We spent quite a few
> years testing delegations for our definition of lameness, and then notifying the listed tech-c and admin-c.
> E-mail recipients would either ignore the email, not understand the email and move on to the next thing,
> or would write-in or call-in and speak to either me or my co-worker Jon Worley. Very few lame delegations
> were fixed, even among those who called-in or wrote-in for clarification.  rDNS worked for the user, and
> they weren’t willing to change anything.
> 
> The war was unwinnable. 
> 
> /david 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop