Demon internet in the UK used to change the TTL's of everything to 14 days otherwise their DNS servers would fall over... but that was in the late 90's. I would hope they no longer do that. Cheers, Bill From: Stuart MacIntosh [mailto:Stuart.MacIntosh(a)ngaitahu.iwi.nz] Sent: Wednesday, 12 November 2008 4:22 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] DNS TTL Hello NZNOG Quick question, hopefully. How common is it for DNS server admins to manipulate TTLs of NS records, on their recursive/customer-facing servers? Also, when seeing a reply from a caching server (query A-type) NS is returned correctly but not the A record. Why is this (typically)? Stuart MacIntosh ________________________________ This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal ________________________________ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.4/1753 - Release Date: 11/11/2008 8:59 a.m.

On Wed, 12 Nov 2008, Stuart MacIntosh wrote:

Quick question, hopefully. How common is it for DNS server admins to manipulate TTLs of NS records, on their recursive/customer-facing servers?

I would say fairly uncommon. In theory you should have some ACL , the root servers, some resource limits and maybe a rfc1918 blackhole and thats it. You can play with the TTL sometimes but it's usually a bad idea and most DNS software doesn't make it easy. Corps are more likely to do weird stuff for dumb reasons.

Also, when seeing a reply from a caching server (query A-type) NS is returned correctly but not the A record. Why is this (typically)?

If the record has changed recently then the usual reasons are: * the person who changed it forgot to update the serial number * the TTL hasn't expired. * Not all the Auth servers got updated * The .nz or .com nameservers are still pointing at the old Auth servers. * The DNS servers your are talking to used to host the domain and are still configured with the details If the records have not changed recently then the last one above is usually the cause. You will note that reasons 1-4 above are the Domain owners fault and usually reason 5 is as well. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

Stuart MacIntosh wrote:

Quick question, hopefully. How common is it for DNS server admins to manipulate TTLs of NS records, on their recursive/customer-facing servers?

As Simon said, generally it's not that common.

Also, when seeing a reply from a caching server (query A-type) NS is returned correctly but not the A record. Why is this (typically)?

Because DNS caching isn't as straightforward as it seems, especially where delegations and "additional" data are concerned. A glue record handed to a forwarding (caching) name server is not actually part of the answer, merely a hint to save the forwarder from having to explicitly ask for the glue A record in another query. As such it's returned in the additional section of the response, and not the authority section, and shouldn't really be used for anything except processing the immediate query response. There are a lot of subtleties (read: "cache poisoning vectors") in caching additional data. The safest approach is not to bother. Note that additional data may be returned if it has found its way into the cache as a response to an explicit query. -- don