Exceptional handling of glue credibility - why?

[Ladislav Vobr]

I have posted several posts about the above, but still I feel there is 
no consistency in it. Of course most possibly I am wrong, and I am 
bothering you still with the same questions and I am sorry if it is so, 
but I am really trying my best to understand this behavior to be able to 
troubleshoot daily customer cases.

Why recent binds doesn't provide the glue credibility cache records out 
of it's cache to the recursive clients? Why does it put such an 
incredible headache to get an authoritative answer for the recursive 
client at the moment the client asks, while before when it was fetching 
the data through some other requests it really doesn't care which 
credibility it is, just simply cache it.

This puts a big load on the server, and creates unexplainable 
situations, when although the data are in the cache bind gets very busy 
doing something nobody really needs and wants and expect.

saying that as long as the data are cached there is really no need to 
fetch them again and bind should be able to answer from the cache is 
really untrue and the real life is quite different.

saying that if there is a local failure, but the data is cached, it 
should not affect the bind performance is untrue as well, since bind 
retries incredibly even for the cached names be it glue credibility.

can any body shed some light on this and the logic behind it?

One more question, why some binds treats exactly the same data different 
way -(delegation ns and a records are sometimes in the answer section, 
sometimes in the additional section, sometimes cached as glue, sometimes 
as an answer, and some times the glue credibility is not provided to the 
clients but answer credibility always is.... simple isn't it?)


Ladislav