Sorry, I was travelling and could not answer in a timely fashion...
1.)
> what is the default value of "TTL" time??
This is set by the administrator of each DNS zone. Even each DNS record can have a customized TTL value if necessary, but usually the entire zone has similar TTL values.
Some DNS servers may have "factory default" TTL values, others do not. It is impossible to give a complete answer. But "common" TTL values for static DNS data might be in the range of 10 min - 2 hours.
If a DNS record is allocated dynamically (DDNS), then a long TTL value may be inappropriate.
> So until the TTL expires the system wont get the new correct address
I would say "is not guaranteed to get the new address". Maybe the last time the cache had to get fresh data just happens to be so far in the past that the old data expires soon enough anyway. But that is just luck. The worst case happens if the cache must refresh the old data at the last possible moment before the change.
If a DNS zone has long TTL values and an important IP address change is planned, the DNS admin must understand the effect of the TTL.
If the IP address change must happen fast, it may be necessary to prepare by shortening the TTL of the records effected by the planned change.
Example:
The IP address of a well-known web service is 10.11.12.13, and it has a TTL of 2 hours. At some point, the boss says it must be changed to 10.11.12.88, and the change must be completed within a window of 5 minutes. Let the planned time of the beginning of the IP change operation be called "time T".
If the change operation is well planned, the DNS admin will be notified of the upcoming change well before the time (T - 2 hours), say, at time (T - 1 day). That allows the DNS admin to change the TTL to a small value (like 30 seconds). This will increase the load of the DNS server, but because the DNS server is not an ancient 386 PC, it will handle it just fine.
If the TTL change happens at or before (T - 2 hours), the operation is possible to be executed as planned. At time T, the DNS admin can replace the old IP in the DNS record with the new one; at time (T + 30 s), the obsolete data is guaranteed to have been purged from all DNS caches. Even if the server admin reports at (T + 4 minutes) that there is a problem and the change must be rolled back, the DNS admin can still do it.
At some later date, the DNS admin can then restore the TTL value of these records to normal.
If the DNS admin is not told until (T - 1 hour) and the TTL is first changed at that point, then between time T and time (T + 1 hour) there may be caches somewhere on the Internet that still have the old data with the old TTL and consider it valid.
If we're talking about internal DNS, where the organization that owns the DNS zone also controls all the caching DNS servers that may access the problematic record, the organization boss may ask all DNS cache admins to flush their caches. This is a work-around to a problem that could be avoided entirely by proper preparations.
(This might mean that the change manager owes a beer [or other preferred beverage] to the DNS/cache admins that had to do rushed/extra work.)
If the change affects public services, this workaround is not available: the DNS caches are all over the Internet and nobody can manage them all.
2.)
If the answer comes from a cache, nslookup will prefix the answer with a text "Non-authoritative answer:".
If this text is not present, the answer was retrieved from an authoritative DNS server of that particular zone and therefore is correct by definition.
MK
MK
