[Pdns-users] Some PowerDNS Recursor oddities

Darren Gamble darren.gamble at sjrb.ca
Tue May 16 15:55:56 UTC 2006


Hi everyone,

Just a few things to add to this already big conversation- while I'm
probably not as fluent in the RFCs as many users here, I can certainly
provide some real-world experience from a large provider.

> Interesting coincidence. The IETF DNS mailinglist DNSOP has been
> discussing
> this exact issue for the past few weeks:
> http://www.mail-archive.com/dnsop@lists.uoregon.edu/msg01185.html
> 
> If I understand correctly, it is unclear what the 'best' behaviour is,
and
> the IETF people are pondering writing a document about it.
> 
> It is not considered an interesting problem as it does not cause
problems
> either way.

Well, it certainly does cause problems.  If I set my TTL values for 1H,
I would like to ensure no one caches them longer than that, even if a
higher-level server says otherwise.  It may be my records frequently
change.  Or, it may be that I just want to do a migration and want to
reduce my downtime.  As to the problems it would cause "the other way",
well, I'm really not sure how bad the impact is.
 
> Well, depending on this behaviour is not supported by the RFCs. The
reason
> PowerDNS does not lower its TTL is because believing the newer lower
TTLs
> causes worse resolving behaviour in the common case, where nobody is
> migrating.

Just out of curiosity, is this reason just to reduce load and query
times?

Or, is it to ensure that the TTL records for the NS records will
eventually expire?  dnscache and Microsoft's DNS server have a, uh,
"feature", that can cause the caches to get into a cycle where it will
never go back to a parent DNS server for NS records, as it continually
updates its cache from the Authoritative section of queries it is
receiving from clients.  If someone changes their name servers with
their registrar and don't/can't stop the old server from being
authoritative, then the new server won't be contacted.  PowerDNS'
methodology implicitly makes it immune to this, while BIND, MaraDNS, and
to some extent Network Registrar, are "smart" in updating their records
to prevent this from occurring.  But, should you decide to change this
behavior, keep this in mind.

> I'm pretty sure that the strategy you describe to migrate to new
servers
> by
> using NS records with low TTL does not in fact work very well - DNS
> records
> are cached for far longer than that in practice.

The practice of lowering TTLs to perform a migration to new IP
names/addresses is both a very common and a recommended strategy.  If
anything, this is because nearly every cache server will use NS records
in the way that I described here.  BIND, dnscache, MaraDNS, and
Microsoft's DNS server work in the "ideal" way, and the lesser-used
PowerDNS and Network Registrar don't.  As such, you can see that
people's expectations are that it will work in a certain way as a
result- like many other inconsistencies between products on the
Internet- whether we all like it or not.  Alas.

> Let me know if it is important to you. PowerDNS does pick up
additional
> nameservers from lower zones btw.

This is "pretty important" to us.  It may or may not be a "show-stopper"
for deployment.  Again, one issue is that of expectation.  If Admin Foo
on the Internet expects things to work a certain way, and sees that our
competitors ISPX, ISPY and ISPZ have DNS caches that work in the
expected way, but not ours, then the impression is that our caches are
"broken".  Sometimes "broken" means "DNS can work that way, sorry!".  In
this case, I feel that the "broken" behavior is really "Behavior that
might be technically correct, but is pretty undesirable and can be more
prone to problems".

> Let me know if it is important to you. PowerDNS does pick up
additional
> nameservers from lower zones btw.

OK, to confirm, it just "specially" treats tld and 2ld servers then?  We
do have a delegated environment under many of our domains- although we
use the same NS/ttl information for the same names on different servers,
so we would not really have noticed this.
 
Thanks again for everyone's time!

============================
Darren Gamble
Planner, Regional Services
Shaw Cablesystems GP
630 - 3rd Avenue SW
Calgary, Alberta, Canada
T2P 4L4
(403) 781-4948



More information about the Pdns-users mailing list