Dr Lou
2010-Apr-21 15:26 UTC
[crossbow-discuss] DNS BIND NAT''d within a private network - doesn''t respond on INTERNAL view
...after some experimentation, we''ve set up a private network, on its own subnet, to serve up multiple zones from one openSolaris box... One of these zones houses our name server (BIND 9.7.0); intention was to effectively ''chroot'' it in this way, while serving DNS requests via the ''real'' outward-facing NIC. Though BIND 9 has become more and more syntax-fastidious (probably a good thing, overall), we''ve worked through all syntax, and have a stable running server. Configuration is as a ''Split DNS'' with ''internal'' and ''external'' views, a configuration we''ve had up and running on a different machine for several years now. We''re using IPNAT to redirect DNS traffic from the external interface - 192.168.42.100 - to the internal vnic - 192.168.0.100 - on the DNS zone; and it seems to be working; well, almost! We''re hoping that a few more eyeballs on this may help: The PROBLEM: BIND apparently receives queries correctly on the ''internal'' view, but does not respond. Seems that recursion is not available, even though ''recursion yes'' is activated in the INTERNAL view: ---------------------------- # dig @192.168.42.100 mydomainname.com any ; <<>> DiG 9.4.2 <<>> @192.168.42.100 mydomainname.com any ... ;; WARNING: recursion requested but not available ... ;; ANSWER SECTION: mydomainname.com. 2 IN SOA ns0.mydomainname.com. hostmaster.mydomainname.com. However: # dig @192.168.42.100 apple.com any ; <<>> DiG 9.4.2 <<>> @192.168.42.100 apple.com any ; (1 server found) ... ;; WARNING: recursion requested but not available Queries my server, but does not ''recurse''... ---------------------------- Granted, don''t know if this is a BIND, zones, crossbow or ipfilter question! (BTW, Has anyone heard any rumblings about when 2010.03 might be released? I''m not that good with numbers, but I''m thinking ''03'' may have come and gone...(!) ) ipnat.conf (partial): map rge0 192.168.0.0/24 -> 0/32 portmap tcp/udp auto map rge0 192.168.0.0/24 -> 0/32 # --- DNS to zone-dns ------------------------------------------------------------------------------------------ rdr rge0 192.168.42.100/32 port 53 -> 192.168.0.100 port 53 tcp/udp # --- This does not -------------------------------------------------------------------------------------------- rdr rge0 192.168.42.100/32 port 5432 -> 192.168.0.105 port 5432 tcp/udp (Please note the above redirect to PostgreSQL seems to work AOK...) some output of ipmon: 21/04/2010 09:55:31.484521 @4 NAT:RDR 192.168.0.100,53 <- -> 192.168.42.100,53 [192.168.42.2,62986] 21/04/2010 09:55:31.485846 @4 NAT:RDR 192.168.0.100,53 <- -> 192.168.42.100,53 [192.168.42.2,62987] ... 21/04/2010 10:05:31.720008 @4 NAT:EXPIRE 192.168.0.100,53 <- -> 192.168.42.100,53 [192.168.42.2,62986] Pkts 1/1 Bytes 55/55 21/04/2010 10:05:31.720010 @4 NAT:EXPIRE 192.168.0.100,53 <- -> 192.168.42.100,53 [192.168.42.2,62987] Pkts 1/1 Bytes 72/123 -- This message posted from opensolaris.org
Bart Smaalders
2010-Apr-22 21:30 UTC
[crossbow-discuss] DNS BIND NAT''d within a private network - doesn''t respond on INTERNAL view
On 04/21/10 08:26, Dr Lou wrote:> ...after some experimentation, we''ve set up a private network, on its own subnet, to serve up multiple zones from one openSolaris box... > > One of these zones houses our name server (BIND 9.7.0); intention was to effectively ''chroot'' it in this way, while serving DNS requests via the ''real'' outward-facing NIC. Though BIND 9 has become more and more syntax-fastidious (probably a good thing, overall), we''ve worked through all syntax, and have a stable running server. Configuration is as a ''Split DNS'' with ''internal'' and ''external'' views, a configuration we''ve had up and running on a different machine for several years now. > > We''re using IPNAT to redirect DNS traffic from the external interface - 192.168.42.100 - to the internal vnic - 192.168.0.100 - on the DNS zone; and it seems to be working; well, almost! We''re hoping that a few more eyeballs on this may help: > > The PROBLEM: BIND apparently receives queries correctly on the ''internal'' view, but does not respond. Seems that recursion is not available, even though ''recursion yes'' is activated in the INTERNAL view: > > ---------------------------- > # dig @192.168.42.100 mydomainname.com any > ;<<>> DiG 9.4.2<<>> @192.168.42.100 mydomainname.com any > ... > ;; WARNING: recursion requested but not available > ... > ;; ANSWER SECTION: > mydomainname.com. 2 IN SOA ns0.mydomainname.com. hostmaster.mydomainname.com. > > However: > # dig @192.168.42.100 apple.com any > ;<<>> DiG 9.4.2<<>> @192.168.42.100 apple.com any > ; (1 server found) > ... > ;; WARNING: recursion requested but not available > Queries my server, but does not ''recurse''... > ---------------------------- > > Granted, don''t know if this is a BIND, zones, crossbow or ipfilter question! > > (BTW, Has anyone heard any rumblings about when 2010.03 might be released? I''m not that good with numbers, but I''m thinking ''03'' may have come and gone...(!) ) > > ipnat.conf (partial): > map rge0 192.168.0.0/24 -> 0/32 portmap tcp/udp auto > map rge0 192.168.0.0/24 -> 0/32 > # --- DNS to zone-dns ------------------------------------------------------------------------------------------ > rdr rge0 192.168.42.100/32 port 53 -> 192.168.0.100 port 53 tcp/udp > # --- This does not -------------------------------------------------------------------------------------------- > rdr rge0 192.168.42.100/32 port 5432 -> 192.168.0.105 port 5432 tcp/udp > (Please note the above redirect to PostgreSQL seems to work AOK...) > > some output of ipmon: > 21/04/2010 09:55:31.484521 @4 NAT:RDR 192.168.0.100,53<- -> 192.168.42.100,53 [192.168.42.2,62986] > 21/04/2010 09:55:31.485846 @4 NAT:RDR 192.168.0.100,53<- -> 192.168.42.100,53 [192.168.42.2,62987] > ... > 21/04/2010 10:05:31.720008 @4 NAT:EXPIRE 192.168.0.100,53<- -> 192.168.42.100,53 [192.168.42.2,62986] Pkts 1/1 Bytes 55/55 > 21/04/2010 10:05:31.720010 @4 NAT:EXPIRE 192.168.0.100,53<- -> 192.168.42.100,53 [192.168.42.2,62987] Pkts 1/1 Bytes 72/123I was seeing similar problems on 134, FWIW. - Bart -- Bart Smaalders Solaris Kernel Performance bart.smaalders at oracle.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."