Re: [Add] My single use case

[Steffen Nurpmeso <[e-mail]>]

Daniel Migault wrote in
 <CADZyTknjg+47Rk1+a4B2DZT_0NSX=0vaAu7NBuxprr=[e-mail]>:
 |Hi Martin,
 |
 |Discovering and selecting are from my point of view, separate processes,
 |and learning that one resolver performs qname should be learnt during the
 |discovery, while the decision should be part of the selection process.

Definitely my last post here.
But in the meantime i have looked around because i have these
tremendous woes regarding the use of JSON in things a (caching)
stub resolver has to work with, and whereas i have found jsmn
(jasmine), which is just a few kilobytes and can easily be
included both because it is header-only, even stdlib-free and
zero-copy, and freely licensed, primitive though and difficulties
are up to you, but well, there is something with a user base so
that error detection is distributed and there is no need to do it
yourself (hmm) or to use these very, very big libraries like even
json-c is.

What i meant is, i would expect that the RESINFO structure is
filled with several types of data, like single addresses, or
address+mask tuples, and of course hostnames (with and without
wildcards, as in RFC 2818 and RFC 6125), it could very well
include pointers to other encrypted resolvers which should be
contacted for targets which do not match what this RESINFO
defines.  It even has to, since the special .ARPA lookup was
responded with this RESINFO.

This more or less implies that, once you got a RESINFO with only
the reference to the encrypted resolver via DHCP or so, you have
to contact the encrypted resolver and ask for a real RESINFO,
then.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)