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
for a:b::beef.
We're looking for the status of
f.e.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
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
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
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:
f.e.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 domain
e.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 domain
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
domain
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
domain
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 response
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
messages.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg