Re: Issue: PTR RR queries for 254.169.in-addr.arpa
Robert Elz <[email protected]> Tue, 29 Mar 2005 14:01:05 +0700
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
Date: Mon, 28 Mar 2005 20:05:09 -0800
From: Stuart Cheshire <[email protected]>
Message-ID: <[email protected]>
| My prediction is that if we have recursive DNS servers return valid DNS
| response packets in answer to those invalid DNS queries, then we
| legitimize the bad behaviour.
I wouldn't go quite that far, but I appreciate your argument, and think
your suggestion is probably the best solution.
For ...
| Having recursive DNS servers stonewall those queries meets our goal of
| reducing the burden imposed on top-level name servers.
we should probably notice that what kills the upper level servers is
requests for data that doesn't exist. When the server can answer,
rational caching is generally fairly effective, whereas negative
caching isn't (even when implemented, the TTL is generally severely
limited).
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