of course, NXDOMAIN is supposed to mask by the domain, which is the thing
that we get by adding the dots -- we don't have separation of administrative
control, but we can pretend we do, so the glue for each additional portion
-- with one nibble per section, as per the current RFC, that amounts to
masking as the four-bit search level, and the problem is that the
representation works great as long as the empty ranges don't give us any
information except "this is an empty range."
So. A RFC-5782 compatible protocol that can tell us something more
interesting about the ranges without points can be created by having some
records at the top of the missing trees.
Given a list containing a:b::1 and examining searches for a:b::2 through
a:b::ffff, we would have something like the following, resolving a search
We're looking for the status of
and there is data for a:b::1, which is different from a:b::2 through
a:b::ffff which are all the same, and there is something we wish to
communicate about all those points, as a range.
we get a NXDOMAIN for the
domain, while acquiring glue to resolve the query, which stops the query.
Here's where we diverge:
instead of just giving up, the client library starts dropping portions from
the beginning of the query until it gets an A record:
e.b.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.0.a.0.example no such
b.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.0.a.0.example no such
indicating the general state of the range
the majority of the traffic is between the query library and the cache; if
the cache and the query library (a query library that is its own resolver)
would be able to do that all in-memory instead of as query/response
Asrg mailing list