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

Aidan Williams <[email protected]> Tue, 29 Mar 2005 17:16:10 +1000
Newsgroups gmane.ietf.zeroconf
Message-ID <[email protected]>
Robert Elz wrote:
> So, to keep the query rate on the in-addr.arpa servers rational, they
> should simply delegate this domain somewhere, with a lengthy TTL.
> It could delegate it to nowhere, one solution might be
> 
> 	254.169.in-addr.arpa.    2592000 IN NS ns.254.169.in-addr.arpa.
> 	ns.254.169.in-addr.arpa. 2592000 IN A  169.254.103.76 ; glue
> 
> which would get the queries off the in-addr.arpa servers for a month,
> then result in timeouts from anything actually doing lookups - help
> get people to fix implementations or configurations to avoid the lookups
> in the first place.
> 
> This is effective, even before any servers get to implement whatever
> restrictions are eventually agreed.
> 
> kre

That's a nice idea -- I think it will be more effective
than the previous suggestions.

Whilst I appreciate the sentiment of the previous
suggestions I don't think they will be very effective
for the following reasons:

   1. Most home existing home networks will NAT the
      DNS traffic to their local ISP recursive resolver
      OR use a local recursive resolver on the RG.

   2. I don't think there is a burning reason why an
      RG vendor would need to read the IPv4-LL spec
      to build a working gateway and so they would
      not know to silently discard bogus IPv4-LL
      queries or respond negatively.


How do we make an in-addr.arpa delegation happen?
A dnsop draft?

- aidan