If the dynamic DNS service you're using only allows TTL's of 3600, then your only option is to switch providers. There really isn't any way to control the TTL unless the DDNS service provider gives you an option to control it.
Checking TTL's
Incidentally to check what the TTL is for a given entry you can use dig
with the following switches.
Example
$ dig +nocmd www.google.com +noall +answer | tail -1
www.google.com. 137 IN A 74.125.225.82
$ dig +nocmd www.google.com +noall +answer | tail -1
www.google.com. 135 IN A 74.125.225.115
So the TTL for this response is 137 seconds. Waiting ~2 seconds and running it again shows 135 seconds. The TTL means how much time is left until the DNS entry expires, and we need to go query the authoritative server for the domain.
Checking Max TTL's
If we were to query the authoritative server.
$ dig @ns1.google.com +nocmd www.google.com +noall +answer | tail -1
www.google.com. 300 IN A 74.125.225.210
So the actual TTL for this entry is 300 seconds.
NOTE: The authoritative server is also known as the SOA - Start of Authority.
SOA information
You can query the domain further for SOA information.
$ dig +nocmd dyndns.org any +multiline +noall +answer
dyndns.org. 596 IN SOA ns1.dyndns.org. hostmaster.dyndns.org. (
863998266 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
600 ; minimum (10 minutes)
)
dyndns.org. 85904 IN NS ns5.dyndns.org.
dyndns.org. 85904 IN NS ns1.dyndns.org.
dyndns.org. 85904 IN NS ns2.dyndns.org.
dyndns.org. 85904 IN NS ns3.dyndns.org.
dyndns.org. 85904 IN NS ns4.dyndns.org.
dyndns.org. 12268 IN MX 10 mail.dyndns.com.
dyndns.org. 12268 IN MX 20 mx2.mailhop.org.
dyndns.org. 179 IN A 204.13.248.116
Changing TTLs
The only way to change a DNS entry's TTL (outside of some sort of API that your registrar might provide) is through the server.
Example
Within Bind you could setup your zone file like so:
;Zone file for liquidweb.com
$TTL 14400
@ 86400 IN SOA ns.liquidweb.com. admin.liquidweb.com. (
2009022402 ; serial, todays date+todays
86400 ; refresh, seconds
7200 ; retry, seconds
3600000 ; expire, seconds
86400 ) ; minimum, seconds
liquidweb.com. 86400 IN NS ns.liquidweb.com.
liquidweb.com. 86400 IN NS ns1.liquidweb.com.
liquidweb.com. IN A 209.59.139.21
localhost IN A 127.0.0.1
liquidweb.com. IN MX 0 liquidweb.com.
mail IN CNAME liquidweb.com.
www IN CNAME liquidweb.com.
ftp IN A 209.59.139.21
cpanel IN A 209.59.139.21
webmail IN A 209.59.139.21
The above macro, $TTL would set the TTL to 14400 seconds for any entries, unless it get's overridden for particular entries.
References
dig
doesn’t remember queries. But it makes use of name servers listed in /etc/resolv.conf
, unless the server to be queried is specified explicitly. Such servers normally accept recursive queries and have caches for their results. So dig
can receive records cached by (intermediate) servers.
Use
dig +trace
…
to override this behaviour, forcing it to query an authoritative server. See dig(1) for more information.
Best Answer
No; not all the way from the
.com
domain (actually I think you meant from the root domain?).The NS records for
stackoverflow.com
have a TTL of 172800, so those are cached a lot longer than the 300 seconds of thewww.stackoverflow.com
CNAME record and thestackoverflow.com
A record. So after those CNAME and A records have expired, the NS records will probably still be cached and hence those nameservers can be questioned aboutwww.stackoverflow.com
(and thenstackoverflow.com
).BTW I wouldn't have given both
www.stackoverflow.com
andstackoverflow.com
a TTL of just 300, that means twice as many DNS requests without any immediately evident advantage IMHO.