Negative Ghostrider...: [root@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@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.bro...@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-boun...@lists.isc.org] On Behalf Of > Ian Veach > Sent: Tuesday, 19 July 2016 8:09 AM > To: Barry Margolin; comp-protocols-dns-b...@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_ve...@nshe.nevada.edu < > ian_ve...@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 <bar...@alum.mit.edu> > Date: 07/18/2016 12:12 (GMT-08:00) > To: comp-protocols-dns-b...@isc.org > Subject: Re: weird transfer-source problems with one DNS node > > In article <mailman.111.1468862922.15653.bind-us...@lists.isc.org>, > Ian Veach <ian_ve...@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@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.
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
