Exceptional handling of glue credibility - why?

[Ladislav Vobr]

dear paul,

	thank you for your time and support, my comments below


Paul Vixie wrote:
> historically and statistically, such data is quite often wrong.  and, the
> combination of "stale out-of-zone glue" being handed out by authority
> servers, and having it be aggressively/promiscuously shared and re-used,
> led to a state of affairs where bad A RRs would cycle through the 'net
> without end.

	this is happening all the time, not providing *glue* credibility to 
recursive clients might not really help it in my opinion, you have other 
credibilities *Additional* *answer* *authority*  I guess I named it 
right and all:-) and these are provided, they are not-authoritative as 
well, are we going to do the same for them?

when my recursive server asks for www.cnn.com nobody really guarantees 
that, provided my recursive server doesn't have data already in the 
cache, it will finally get it from the only right source and this is the 
authoritative servers of cnn.com ( many, too many people :-) thinks so ) 
and it seems to be very natural requirement, but bind recursive server 
doesn't really striving to do this, any answer is satisfactory to 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.
 >
 >
 > it's a high load, but it's doing something that everybody actually does
 > need and should want and should expect.
 >
do we know the price of it, do we really expect it, when rfc itself 
doesn't. Do we really need it in every situations, all the time, under 
all circumstances. Does it really solve the problem when bind 8.3.4 
provides the non-authoritative data in the answer section and thus all 
recursive bind servers caches it under the *answer* credibility, not 
really using at all the positive effect of this "exceptional handling".

We can not really always blame the users, that their hardware is not 
enough, In my opinion, putting such a thing in place, without really 
doing rate limiting or query throttling will definitely in some 
situations use all resources/queues be it on any hardware. Public 
recursive caching servers with 1000+ req/sec will have lot of problems 
when *all* authoritative servers are unreachable and the 
recursive-clients queue will fill up very fast regardless their 
hardware. This happens in today Internet full of windows dls/cable modem 
end users unaware about their virus/trojan horses, backdoors with 
hardcoded domain names whose authoritative server are already down. And 
what's worse the frequency of these situations is increasing.

It looks like till 8.3.4 is here all this "exceptional handling" is not 
in place at all but  the "negative" effect of it are in place on every 
recent recursive bind server.

>>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?)
> 
> 
> i'd need to see specific examples before i could answer this.


if I dig against bind 8.3.4 it will provide the ns records in the answer 
section and caching server will cache it under the *answer* credibility, 
  bind 9.2.3 on the other hand will provide it in the authority section, 
which is cached as *glue* by the recursive servers.

Bind 8.3.4 slave for name.ae zone

#dig ladislav.name.ae ns

; <<>> DiG 8.3 <<>> ladislav.name.ae ns
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5
;; QUERY SECTION:
;;      ladislav.name.ae, type = NS, class = IN

;; ANSWER SECTION:
ladislav.name.ae.       3H IN NS        fake3.ladislav.name.ae.
ladislav.name.ae.       3H IN NS        fake4.ladislav.name.ae.
ladislav.name.ae.       3H IN NS        fake5.ladislav.name.ae.
ladislav.name.ae.       3H IN NS        fake1.ladislav.name.ae.
ladislav.name.ae.       3H IN NS        fake2.ladislav.name.ae.

;; ADDITIONAL SECTION:
fake3.ladislav.name.ae.  3H IN A  10.3.3.3
fake4.ladislav.name.ae.  3H IN A  10.4.4.4
fake5.ladislav.name.ae.  3H IN A  10.5.5.5
fake1.ladislav.name.ae.  3H IN A  10.1.1.1
fake2.ladislav.name.ae.  3H IN A  10.2.2.2


Bind 9.2.3 slave for the same name.ae zone

$ dig ladislav.name.ae ns

; <<>> DiG 9.2.3 <<>> ladislav.name.ae ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16780
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;ladislav.name.ae.              IN      NS

;; AUTHORITY SECTION:
ladislav.name.ae.       10800   IN      NS      fake5.ladislav.name.ae.
ladislav.name.ae.       10800   IN      NS      fake1.ladislav.name.ae.
ladislav.name.ae.       10800   IN      NS      fake2.ladislav.name.ae.
ladislav.name.ae.       10800   IN      NS      fake3.ladislav.name.ae.
ladislav.name.ae.       10800   IN      NS      fake4.ladislav.name.ae.

;; ADDITIONAL SECTION:
fake1.ladislav.name.ae. 10800   IN      A       10.1.1.1
fake2.ladislav.name.ae. 10800   IN      A       10.2.2.2
fake3.ladislav.name.ae. 10800   IN      A       10.3.3.3
fake4.ladislav.name.ae. 10800   IN      A       10.4.4.4
fake5.ladislav.name.ae. 10800   IN      A       10.5.5.5

;; Query time: 5 msec
;; SERVER: 213.42.0.226#53(213.42.0.226)
;; WHEN: Mon Aug  2 05:59:48 2004
;; MSG SIZE  rcvd: 214