[dns-operations] EC2 resolver changing TTL on DNS answers?

Eli Lindsey eli at siliconsprawl.com
Tue Nov 28 16:30:01 UTC 2017


It's very likely this is just a product of their resolver architecture;
operationally it makes a lot of sense - cap the TTL in the dom0 resolver
at 60s, dom0 resolver hits a pool of resolvers per AZ or region that
respects auth TTL. That makes it much easier to eg. emergency flush bad
entries to mitigate an issue in the centralized pool of resolvers and
ensure the new values propagate quickly without needing to manage/flush
all individual dom0s.

This is not uncommon client/stub resolver behavior. Compare to certain
mobile phones, home routers, and web browsers.

-eli

On Tue, Nov 28, 2017, at 10:15 AM, Andrew Sullivan wrote:
> What's wrong with this?  The TTL isn't an instruction, it's a constraint. 
> "Don't cache longer than $ttl," not, "Cache for $ttl." Indeed, this 
> distinction is one of the factors some of us worried about with RRL.
> 
> A
> 
> -- 
> Please excuse my clumbsy thums
> 
> 
> 
> ----------
> On November 28, 2017 8:34:50 AM "Giovane C. M. Moura" 
> <giovane.moura at sidn.nl> wrote:
> 
> > Hi,
> >
> > Anyone from Amazon here? Just came across this: resolvers at EC2
> > (Northern California) seem to change the TTL of DNS records.
> >
> > Just curious about why this is happening.
> >
> > To reproduce:
> >
> > 1. Querying from my laptop:
> >
> > giovane at laptop:~$ dig ns nl
> >
> > nl.                     172800  IN      NS      ns1.dns.nl.
> > nl.                     172800  IN      NS      ns-nl.nic.fr.
> > nl.                     172800  IN      NS      ns2.dns.nl.
> > nl.                     172800  IN      NS      sns-pb.isc.org.
> > nl.                     172800  IN      NS      ns3.dns.nl.
> > nl.                     172800  IN      NS      nl1.dnsnode.net.
> > nl.                     172800  IN      NS      ns5.dns.nl.
> > nl.                     172800  IN      NS      ns4.dns.nl.
> >
> > In this query, every NS has a TTL on 172800, as in the root zone[1].
> > That's how it should be.
> >
> > 2. Querying from Amazon EC2 (Northern California):
> >
> > [ec2-user at ip-172-31-6-139 ~]$ dig ns nl
> >
> > nl.                     60      IN      NS      ns5.dns.nl.
> > nl.                     60      IN      NS      ns-nl.nic.fr.
> > nl.                     60      IN      NS      sns-pb.isc.org.
> > nl.                     60      IN      NS      nl1.dnsnode.net.
> > nl.                     60      IN      NS      ns1.dns.nl.
> > nl.                     60      IN      NS      ns2.dns.nl.
> > nl.                     60      IN      NS      ns3.dns.nl.
> > nl.                     60      IN      NS      ns4.dns.nl.
> >
> >
> > So the TLL using the local resolver from EC2 (172.31.0.2) has its TTL
> > reduced to 60s, instead of what is in [1]. You can run the same query
> > for any TLD, or even amazon.com.
> >
> >
> > Just curious why. Thanks,
> >
> > /giovane
> >
> > [1] https://www.internic.net/domain/root.zone
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-operations mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



More information about the dns-operations mailing list