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

[Dave Owens]

Hi Sam,

Thank you for the reply.

I removed the recursive_acl config.  We don't want to offer recursive DNS
for queries against our NS, so need for Deadwood...

I'm still running up against the problem... rfc1918 addresses within the
server's connected subnets will not resolve, other rfc1918 adresses resolve
with no issue.  The logs show normal 'processing query' message, but no
response is sent... client that sent the query eventually times out.  I'd
be happy to help test this if you'd like.

I plan to work around this such that I will advertise rfc1918 addresses
that MaraDNS *can* resolve for these new hosts.  This turns out to be the
Right Thing with regard to our topology anyway...

Thank you,

Dave Owens
TeamUnify, LLC





On Mon, Jun 10, 2013 at 1:42 AM, Sam Trenholme <maradns at gmail.com> wrote:

> 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 <dave at teamunify.com> 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
>