On Sun, Dec 12, 2010 at 1:52 PM, Matthias Leisi <matthias(_at_)leisi(_dot_)net>
wrote:
What happens if a resolver enumerates all /128 in a whole /64? There
is nothing an intermediary resolver / cache or an authoritative server
can do than to rate-limit a "dumb" resolver. The above draft (or a
useful / corrected variation thereof) will allow an "intelligent"
resolver to limit the number of requests without globally limiting
lookups to an arbitrary limit.
-- Matthias
I'm certainly not going to respond to an assertion that I don't
understand DNS caching.
It seems to me that an extended DNSxL protocol that addresses the
identified weakness in John Levine's RFC5782 concerning ranges:
2.1: If a range of addresses is listed in the DNSxL, the DNSxL MUST
contain an A record (or a pair of A and TXT records) for every
address in the DNSxL. Conversely, if an IP address is not listed in
the DNSxL, there MUST NOT be any records for the address.
2.4: there is no way to specify the length of the name that a wildcard matches
is possible using A record responses only, with TXT reserved for
verbose, human-intended reason codes, as with the 5782 protocol.
Mr Levine recommends DNSSEC wildcarding as the answer. The required
semantics can however be provided within a framework of A records, as
there are plenty of bits. Including dealing with dumb/misconfigrued
clients that make requests at too fine of a granualrity.
An extended non-5782 DNSxL protocol could provide a mechanism for
specifying ranges, and would then of course no longer include the
requirement for full enumeration. The exactl syntax of this mechanism,
and if it includes TXT records for carrying the granularity
information or not, is othogonal to the point that it is possible,
using traditional simple DNS, to provide cacheable wildcard length
data.
I don't know if I included or implied this bit in what I wrote
earlier, but the way I see it, a too-fine query would get a corrective
response too, just like a too-coarse query, and after several too-fine
responses, a client would get their access denied at a firewall for a
while, like any other DOS attack. That would go for my A-records-only
protocol extension or another scheme involving TXT records, which are
of course attractive because the response doesn't have to be packed
into 24 bits (23, after the bit indicating that it's a grain size
error instead of a response) and could be made human-readable and
machine-parsable ASCII.
Furthermore, a non-DNSSEC approach could coexist with DNSSEC
wildcarding just fine, until such time as DNSSEC wildcarding support
is universal.
David Nicol, armchair engineer and at-large crank
--
“The aeroplane is fatally defective. It is merely a toy—a sporting
play-thing. It can never become commercially practical." -- Nikola
Tesla
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg