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