[DNSOP] Re: New Version Notification for draft-bortzmeyer-dn sop-poisonlicious-05.txt

--===============6969072994316916145==
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Petr =C5=A0pa=C4=8Dek <[email protected]> writes:

> On 05. 08. 26 17:33, Ben Schwartz wrote:
>> On Wed, Aug 5, 2026 at 10:54=E2=80=AFAM Petr =C5=A0pa=C4=8Dek <pspacek@i=
sc.org> wrote:
>>> On 04. 08. 26 22:00, Ben Schwartz wrote:
>> ...
>>>>   My question is whether we should be pursuing this
>>>> architecture (an O(N) response "broadcast" for cache sharing), as
>>>> opposed to some other architecture (such as a multilayer cache
>>>> architecture).  Are you running broadcast-style cache sharing in
>>>> production?
>>>
>>> It does not have to be broadcast, does it? Generally it is discretion of
>>> the sender to whom it will get delivered, and I would expect great
>>> variety in strategies here. E.g. not sending NXDOMAINs unless they pass
>>> some heuristic etc.
>> Filtering which responses are shared seems plausible.  Delivering
>> different responses to subsets of the fleet in a useful way seems much
>> more difficult.
>> If I were trying to use poisonlicious in a highly optimized
>> architecture, it would look like this:
>> 1. The stub issues a query.
>> 2. The query hits a dispatcher (dnsdist), which routes it to a
>> resolver instance based on hash(qname)
>> 3. The resolver starts working, encountering some cache misses along
>> the way.  On cache miss, it sends an RD=3D0 (i.e. cache snooping) query
>> back to the dispatcher, which forwards it to the responsible instance
>> by hash(qname).
>> 4. If the cache snooping query fails, the resolver queries upstream,
>> and copies the response to the dispatcher via poisonlicious.
>> 5. The dispatcher forwards the poisonlicious response to the instance
>> responsible for hash(qname), which adds it to the cache.
>> If an architecture like this is in scope for poisonlicious, then I
>> think it would be useful.  I don't see any technical impediment within
>> the present draft, but perhaps the operational considerations could be
>> expanded to note the possibility of a dispatcher and "lookaside
>> snooping" behavior.
>
> I would much prefer if we just defined what messages on the wire mean
> and left implementations to figure out what's best for them. We have
> bunch of resolvers with different strategies and there's a reason for
> it - different deployments have different requirements. DNS is nowhere
> close to one size fits all.

I agree with Petr here. I understand that implementers don't want to add
more complex logic to their implementation, and by that to introduce new
failures modes and security risks.

On the topic of broadcast: My idea setup would involve a multicast group
in a cluster, where a resolver can decide to join or leave. Like a
resolver with a cold-cache to join the group and warm up the cache,
and then leave when it reaches a certain level of cache hit ratio threshold.

BR,

=2D-=20
Babak Farrokhi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iKUEARYKAE0WIQRu+73tYCYKk7tFGWuCnEUHptH9aQUCanNeQBsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwwLDMTHGJhYmFrQGZhcnJva2hpLm5ldAAKCRCCnEUHptH9
aXUPAP9bEq0+leDQsg8bVjO/Ya2S5mVbjZET2bDUA9rro2XiYQEApGOHX3x96Qam
duv7Oh2AaV1HBW63RkJbTbVd/nMlGw0=
=97lE
-----END PGP SIGNATURE-----
--=-=-=--


--===============6969072994316916145==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK

--===============6969072994316916145==--