Date: Wed, 30 Nov 2005 13:24:00 +0900
From: Hideshi Enokihara <Hideshi.Enokihara@jp.yokogawa.com>
Subject: [dnstest:00016] Re: Issue regarding test case no. 47
To: "PRAMENDRA  SINGH" <parma_it@rediffmail.com>
Cc: dnstest@tahi.org
Message-Id: <20051130132400.1cbc4b8e.Hideshi.Enokihara@jp.yokogawa.com>
In-Reply-To: <20051129141453.25895.qmail@webmail10.rediffmail.com>
References: <20051129141453.25895.qmail@webmail10.rediffmail.com>
X-Mail-Count: 00016

Hi,

Thanks for your report.

Your understanding is right.

This test specification is wrong about treatment of the most significant bit of the TTL.
If the most significant bit is set, TTL value should be zero.
But, test specification expect only the most significant bit should be zero.

We will fix this issue in next release.

Best Regards,

On 29 Nov 2005 14:14:53 -0000
"PRAMENDRA  SINGH" <parma_it@rediffmail.com> wrote:

> Hi
> I also have an issue regarding test case no. 47....
> the NUT receives response where the most significant bit of the TTL
> is set. So that NUT should consider it as zero....Now in the next step
> NUT is supossed to send query within 10 secs...& that should not reach to
> the TN...that means it should be able to reply from its cache itself....
> Now the most surprising thing is that how can the NUT reply from
> its cache coz it got the response with TTL as zero...& as per all 
> RFCs(1034, 1035), the data with TTL value zero should not be cached
> (Reference RFC1035, 3.2.1, RFC1034, 3.6, RFC2065 4.4)... if the TTL value is zero..
> Please comment....
> 
> thanks & regards
> 
> Prem __> 


-- 
*************************************
Hideshi Enokihara
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation