Re: Issue: PTR RR queries for 254.169.in-addr.arpa

"Phillip Remaker" <[email protected]> Mon, 28 Mar 2005 22:54:27 -0800
Newsgroups gmane.ietf.zeroconf
Message-ID <05aa01c5342c$262ac630$647ba8c0@premakerpc>
I would be inclined to support Stuart's view.  Non-compliant zeroconf 
implementations that inapprorpiately unicast bogus rDNS lookups should be 
punished by a DNS server stonewalling them.  The timeouts are a feature, not 
a problem.  Local admins can address noncompliant hosts as they see fit, but 
I would not think that a best practice that improperly burdens top level DNS 
servers is a good idea, especially given the overwhelmingly slow response of 
vendors of typial ZeroConf devices.  Think offshore ODMs with little 
incentive to ever patch code, and home users with even less incentive to 
apply the patch if an issue is asymptomatic to them.

Look no futher than the Netgear NTP fiasco to see how an ignorant coding 
problem on a cheap appliance device can have disastrous consequences. 
<Google> NTP Netgear </Google>

Others will argue that the specification should be designed to accomodate 
brokenness.  I think Stuart's approach is much better:  Punish the poor 
implementations in order to incent proper behavior.