weird transfer-source problems with one DNS node

[Ian Veach]

Negative Ghostrider...:

[root at foo:~]# iptables -t raw -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination

[root at foo:~]# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination


You might be on to something general though:  Maybe this is more of an OS
issue than a BIND issue?  BIND at least seems to think it's correct!




cheers and thanks,

Ian Veach, Senior Systems Analyst
System Computing Services, Nevada System of Higher Education


On Mon, Jul 18, 2016 at 4:11 PM, Browne, Stuart <Stuart.Browne at neustar.biz>
wrote:

> What about the mangle or raw tables?
>
> iptables -t raw -nvL
> iptables -t mangle -nvL
>
> Both tables have the ability to modify the packets as they pass through.
>
> Stuart
>
> ------------------------------------------------------------------------
> From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of
> Ian Veach
> Sent: Tuesday, 19 July 2016 8:09 AM
> To: Barry Margolin; comp-protocols-dns-bind at isc.org
> Subject: Re: weird transfer-source problems with one DNS node
>
>
> I don't think my earlier response to this has made it past moderation, but
> an update:
>
> iptables looks pretty benign to me...:
>
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             anywhere            state
> RELATED,ESTABLISHED
> ACCEPT     icmp --  anywhere             anywhere
> ACCEPT     all  --  anywhere             anywhere
> ACCEPT     all  --  anywhere             anywhere
> ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp
> dpt:ssh
> ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp
> dpt:domain
> ACCEPT     udp  --  anywhere             anywhere            state NEW udp
> dpt:domain
> (... other rules for allowed ports)
> ACCEPT     ospf --  anywhere             anywhere            state NEW
> REJECT     all  --  anywhere             anywhere            reject-with
> icmp-host-prohibited
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             anywhere            PHYSDEV match
> --physdev-is-bridged
> ACCEPT     all  --  anywhere             anywhere            state
> RELATED,ESTABLISHED
> ACCEPT     icmp --  anywhere             anywhere
> ACCEPT     all  --  anywhere             anywhere
> ACCEPT     all  --  anywhere             anywhere
> ACCEPT     all  --  anywhere             anywhere
> REJECT     all  --  anywhere             anywhere            reject-with
> icmp-host-prohibited
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
>
>
>
>
>
> cheers and thanks,
>
> Ian Veach, Senior Systems Analyst
> System Computing Services, Nevada System of Higher Education
>
>
> On Mon, Jul 18, 2016 at 1:27 PM, ian_veach at nshe.nevada.edu <
> ian_veach at nshe.nevada.edu> wrote:
>
> I suppose, but doubt it.   I will look when I get back in office.  We do
> pretty benign ip tables though - a few firewall exceptions,  etc., and no
> Translations or any fancy stuff.  For anycast, we do use quagga and zebra
> for the ospf, but that's only for the service addresses on the loop back
> device
>
> Thanks!
>
> Sent via the Samsung Galaxy Note® 4, an AT&T 4G LTE smartphone
>
>
> -------- Original message --------
> From: Barry Margolin <barmar at alum.mit.edu>
> Date: 07/18/2016 12:12 (GMT-08:00)
> To: comp-protocols-dns-bind at isc.org
> Subject: Re: weird transfer-source problems with one DNS node
>
> In article <mailman.111.1468862922.15653.bind-users at lists.isc.org>,
> Ian Veach <ian_veach at nshe.nevada.edu> wrote:
>
> > So unless I'm crazy (possible, regardless)... named is reporting using
> 230,
> > but OS is showing 240 (and remote host logs confirm 240)!?
>
> Could something in iptables be transforming it at a lower level?
>
> --
> Barry Margolin
> Arlington, MA
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and
> responses, unless otherwise made confidential by law, may be subject to the
> Nevada Public Records laws and may be disclosed to the public upon request.
>

-- 
PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and 
responses, unless otherwise made confidential by law, may be subject to the 
Nevada Public Records laws and may be disclosed to the public upon request.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160718/dbf0a3f5/attachment-0001.html>