Hi
You are right. No.54 is also for server.
But No.51 and No.52 are for resolver.
Why do you think that those are for server?
Best regards,
PRAMENDRA SINGH wrote:
> Hi
>
> thanks for your reply...
> As in your reply u said Test case 53. is optional & furthermore for
> servers....but what I could understand, not only 53, test case nos.
> 51, 52 & 54 are also for servers...
>
> please comment
>
> thanks & regards
> Prem
>
>
>
>
> On Mon, 12 Dec 2005 Nobumichi Ozoe wrote :
> >Hi,
> >
> >Well you are talking about Tet No.53 Caching of dead server indication.
> >
> >We wrote this test specification based on RFC2038 7.2 Dead /
> Unreachable Server (OPTIONAL). This function is OPTIONAL and furthermore
> for servers.
> >Then we think that we will delete this specification.
> >
> >Anyway, thanks your opinion.
> >
> >Best regards,
> >
> >PRAMENDRA SINGH wrote:
> >>Hi
> >>
> >>thanks for your reply..... :-)
> >>well the way I have tested all caching related test cases are...
> >>
> >>I'm running caching server locally....in the NUT....
> >>
> >>So, (in this test case 55) whenever I give any query (for first
> time), sends it to the TN...
> >>on receiving the reply...caches it ....now if I do the same query 2nd
> time...
> >>it wont send to the TN...will resolve from its cache itself...
> >>Now as per this test case...first time we send the query A.example.com.
> >>but the server (TN) never replies...So next time (in the 3rd step) if we
> >>give the same query.....NUT wont get any information in its cache...
> >>so it will again send it to the TN.....
> >>
> >>If it does not ...then (in general scenario) say I sent a query to
> the server
> >>& dint get any reply...again I sent the same query to the same server...
> >>then as per this test scenario...my client should not send the query
> to the saver..
> >>which I believe does not sound logical....
> >>
> >>Moreover I donno how to maintain cache in the NUT without running
> caching server....
> >>coz as per my knowledge...someone should be there who must take care
> of this
> >>cache...(say checking the TTL value)....which the dig utility can't
> do....
> >>
> >>I hope I could explain u....
> >>
> >>please comment...
> >>
> >>
> >>thanks & regards
> >>
> >>Prem
> >>
> >>
> >>
> >>
> >>On Thu, 08 Dec 2005 Nobumichi.Ozoe@jp.yokogawa.com wrote :
> >> >Hi,
> >> >
> >> >I can't understand that you said "how the NUT will cache it".
> >> >Could you teach me your opinion?
> >> >
> >> >Best regards,
> >> >
> >> >________________________________
> >> >
> >> > From: PRAMENDRA SINGH [mailto:parma_it@rediffmail.com]
> >> >Sent: 2005/12/08 (木) 13:06
> >> >To: dnstest@tahi.org
> >> >Cc: users@tahi.org
> >> >Subject: [dnstest:00029] Got an issure regarding test case no. 53
> >> >
> >> >
> >> >
> >> >Hi
> >> >
> >> >As per the new release(6th Dec) of DNS Client test cases
> >> >I got an issue regarding test case no. 53.
> >> >As per test sequence....
> >> >
> >> >1. NUT first sends query (A.example.com) to TN
> >> >2. Server (TN) does not send response within 120 seconds...
> >> >3. NUT must send query (A.example.com) to the TN..but it should
> not reach the TN...
> >> >NUT should be able to
> >> >
> >> >I got the doubt here in the 3rd step...If the server is not going
> to send
> >> >any response then how the NUT will cache it...so that in the next
> time (in the 3rd step)
> >> >definitely the packet will go to the TN...
> >> >
> >> >Please let me know whether my analysis is right or wrong...
> >> >
> >> >Your comments are always valuable for me...
> >> >
> >> >thanks & regards
> >> >
> >> >Prem
> >> >
> >> >
> >> >
> >> >
> >> >
> <http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3>
> >>
> >>
> >>
> >><http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3>
>
> >
> >
> >-- Nobumichi Ozoe
> >IPv6 Business
> >Network & Software Development Dept.
> >Yokogawa Electric Corporation
> >E-mail: Nobumichi.Ozoe@jp.yokogawa.com
> >URL: http://www.yokogawa.com/
>
>
>
> <http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3>
>
--
Nobumichi Ozoe
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation
E-mail: Nobumichi.Ozoe@jp.yokogawa.com
URL: http://www.yokogawa.com/