Bind - question on Master/Slave configuration

mgaudette · Oct 26, 2016, 2:47 PM

Hi,

Following DynDNS's problem last week (I was one of the unlucky impacted) I decided to run my own NS servers, as slave to DynDNS - so that if they, as a known entity, are attacked again, I won't be collateral damage. The idea is that on top of the 4 DynDNS nameservers they have for me, I have one of my own. All NS-related DNS entries have a TTL of 24 hours, so I believe it protects me from collateral damage for 24 hours or so.

I'm not a DNS expert, so 2 Questions:

Does this make sense? The thinking is to be protected for a failure of less than 24 hours (see TTL above). Is this the case?
In my slave configuration, on pfSense 2.3.2, I see this : Maximum caching time in case of failed lookups (Default: 1 hour). What exactly does this refer to? Is this something I should also increase to 24 hours, or is this something else entirely?
Right now, things seem to work, BUT, I see this in my logs :

xfer-in: error: transfer of 'fakedomain.ca/IN/home_network' from 204.13.249.11#53: failed to connect: timed out
Oct 26 08:08:28 named 80206 xfer-in: info: transfer of 'fakedomain.ca/IN/home_network' from 204.13.249.11#53: Transfer status: timed out
Oct 26 08:08:28 named 80206 xfer-in: info: transfer of 'fakedomain.ca/IN/home_network' from 204.13.249.11#53: Transfer completed: 0 messages, 0 records, 0 bytes, 74.999 secs (0 bytes/sec)

…thing is, I limited updates to DynDNS servers, obviously. So it's normal that IPs in home_network ACL are blocked. BUT 204.13.249.11 has been explicitly defined in a "dyndns" ACL and a "dyndns" view, so it should match "dyndns", not "home_network". This happens only when the slave (pfSense) asks for an update, but there doesn't seem to be a problem when I push it from the master (using a NOTIFY that I can push manually from DynDNS) - in that case, the IP matches and it reports "…transfer of 'fakedomain.ca/IN/dydns". with successful

Any hint? Where can I find the bind config files on pfSense (full install 2.3.2)? That might help find the problem.

Not sure what's wrong here, any hints?

kpa · Oct 27, 2016, 10:02 AM

If you want to run a slave DNS server you must co-operate with the entity that runs the primary, in this case DynDNS. They are the ones that control if zone transfers are allowed and to whom.

Derelict · Oct 27, 2016, 10:10 AM

Despite the DDoS last week, thinking you can host DNS better than Dyn is probably folly.

You would probably be better-suited using multiple providers to host your authoritative zones. Like maybe Dyn, Route 53, and HE.net. There are others.

You might also consider hosting the zones yourself but only publishing the hosted providers in the NS records. So you are the master and they all pull the zones from you but the internet does not know the master exists or where.

mgaudette · Oct 27, 2016, 2:27 PM

Despite the DDoS last week, thinking you can host DNS better than Dyn is probably folly.

100% agreed - which is why my plan wasn't to replace DynDNS, but to add two NS servers of my own to complement theirs.

The way I see it, their servers are more reliable generally speaking, but if they are to be attacked (big targets are tempting to DDoS) then I'm not collateral damage since I've got my own puny setup to supply NS services while this is happening. I can even turn off DNS in my firewall and only open it if needed.

Not being a DNS expert, I figured this made sense - does it? Your idea of using different NS provider also makes sense, TBH, hadn't thought of it.

The rest of my question is actually answered, DynDNS documentation was misleading and I worked it out with their support team.