Re[4]: How to resolve the DNS zone in Deadwood?

[test24]

Wed, 3 Nov 2010 08:25:13 -0600 письмо от Sam Trenholme <strenholme.usenet at gmail.com>:

> Thank you for the detailed information.
> 
> > filter_rfc1918 = 1
> 
> This (which is enabled by default) tells Deadwood to never resolve
> private 192.168.x.x, 172.16-31.x.x, and 10.x.x.x IP addresses (which
> are described in RFC1918, hence the name).  This is a security
> feature; if we allow a DNS server used on the real-world Internet to
> resolve these kinds of IPs, it opens us up to certain kinds of
> attacks:
> 
> http://crypto.stanford.edu/dns/
> 
> If you have a need to resolve these kinds of IPs, please have filter_rfc1918 =
> 0

But if I set

recursive_acl = "127.0.0.1/16,"
recursive_acl += "192.168.55.1/24,"		# Local Network
recursive_acl += "192.168.56.1/24,"		# WiFi  Network
recursive_acl += "10.10.1.1/24"		        # Users Network

ONLY to allow connections from Local network and does not allow DNS connections from the Internet to Deadwood what do you think about that ?

> > ;; AUTHORITY SECTION:
> > my.tv.                 0       IN      SOA     z.my.tv. y.my.tv. 1 1 1 1
> 1
> 
> Whenever Deadwood generates a reply it looks like this, it indicates
> that Deadwood is generating a synthetic "this host does not exist"
> reply.
> 
> This can be done under a variety of circumstances.  For example:
> 
> * If reject_aaaa is set and someone asks for an AAAA (IPv6 address) record
> 
> * If Deadwood gets a response from an upstream server which is blank
> and the RCODE isn't SERVER FAIL
> 
> * If an IP specified in ip_blacklist is seen in the upstream reply
> (this feature exists to counteract NXDOMAIN redirection)
> 
> * If, as happened in your case, a 192.168.x.x, 172.16-32.x.x, or
> 10.x.x.x IP is seen in the reply and filter_rfc1918 is not 0.
> 
> > Proposition:
> > Cached NS (Deadwood) together with Authoritative server (MaraDNS) = new
> version of GOOD NS named DeadDNS
> > (from DEADwood+maraDNS=DeadDNS) ;)
> 
> Thank you for the kind words.
> 
> - Sam