Re: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet

Looking at this configuration file, recursive_acl doesn't do much in
MaraDNS 2.0.06...make sure you're using Deadwood to resolve anything
remotely.

Also, if you're using Deadwood as the recursive name server, there's a
gotcha with IPs that resolve to 127.x.x.x, 172.[16-31].x.x, 10.x.x.x,
or 192.168.x.x.  Make sure to have filter_rfc1918 set to 0:

http://maradns.org/deadwood/browse-source/head/doc/Deadwood-HOWTO

Note to self: Add filter_rfc1918 note to Deadwood FAQ.  This isn't the
first time Deadwood's built-in DNSwall has confused people.

- Sam

On Wed, Jun 5, 2013 at 9:50 AM, Dave Owens <[email protected]> wrote:
> Hi Sam and list members,
>
> I have a mararc.base like this:
>
> ipv4_bind_addresses = "192.168.50.250"
> synth_soa_origin = "ns1.teamunify.net"
> maradns_uid = 65500
> maradns_gid = 65500
> chroot_dir = "/etc/maradns"
> default_rrany_set = 15
> verbose_level = 2
> hide_disclaimer = "yes"
> tcp_convert_acl = "0.0.0.0/0"
> tcp_convert_server = "192.168.50.250"
> recursive_acl = "192.168.50.0/24, 10.10.0.0/16, 127.0.0.1"
> csv2 = {}
>
> I have added a record to the teamunify.com.zone file like this:
>
> topica.%      192.168.50.141 ~
>
> I am able to get the A record returned when I query the server from the
> local subnet.  I am not able to get the A record returned when I query the
> server remotely.
>
> Logging at verbose_level = 3 shows that MaraDNS does receive the query:
> Query from: $PUBLIC_IP Atopica.teamunify.com.
> ...but there are no errors in the log related to the query.
>
> We have other private IP A records in that zone file, and all can return A
> records when queried remotely.  None of the working addresses are in the
> 192.168.50.0/24 subnet, however.
>
> Dave Owens
> TeamUnify, LLC