-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I don't follow. Are you saying you are saving the SOURCE > PREFIX-LENGTH from the original query (responsible for the cache > entry) alongside the cache entry?
Yes. > If so, I don't follow why this is required. Can you explain? Certainly! Suppose I query for 128.0.0.0/4 and get the response is 128.0.0.0/4/8. And suppose I would cache it like: A) 128.0.0.0/?/8 That is, discard the SOURCE PREFIX-LENGTH. Maybe I also ask for 129.0.0.0/8 for which the authority replies with the same SCOPE. My cache now contains: A) 128.0.0.0/?/8 B) 129.0.0.0/?/8 Suppose again I want to have an answer for 128.0.0.0/4. Which cache entry would be correct - if any? Do I need to requery the authority? Do I need to consider the bits from the client address that where masked? Or would I pretend the mask bits are 0? I can't decide, but I sure like to use my cache rather than asking the authority! If I had saved this in my cache: A) 128.0.0.0/4/8 B) 129.0.0.0/8/8 The answer should be obvious: "A". The server wants to receive 8 bits information but this is the answer I would have got when I would provide just 4. As said before, at this point I could also decide to requery and disclose more bits. But it'll be my choice. I'm not giving up my privacy just because someone asks nicely. > Or do you mean the use of SOURCE PREFIX-LENGTH from a subsequent > query when looking into the cache? I did not mean that. Though the SOURCE PREFIX-LENGTH I'm working with might limit me how far down the tree I will look for an answer. //Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlazVzgACgkQI3PTR4mhavgUbwCbBnYEQ/p+2C1JoM728+lXXW3m QMkAn1JNB0QOOhqpGZaW0z4JVtGwhACq =/QK1 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
