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.