<div dir="ltr"><div><br></div><div>Negative Ghostrider...:</div><div><br></div><div><font face="monospace,monospace">[root@foo:~]# iptables -t raw -nvL<br>Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)<br> pkts bytes target prot opt in out source destination</font></div><div><font face="monospace,monospace">Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br> pkts bytes target prot opt in out source destination</font></div><div><br><font face="monospace,monospace">[root@foo:~]# iptables -t mangle -nvL<br>Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)<br> pkts bytes target prot opt in out source destination</font></div><div><font face="monospace,monospace">Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br> pkts bytes target prot opt in out source destination</font></div><div><font face="monospace,monospace">Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)<br> pkts bytes target prot opt in out source destination</font></div><div><font face="monospace,monospace">Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br> pkts bytes target prot opt in out source destination</font></div><div><font face="monospace,monospace">Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)<br> pkts bytes target prot opt in out source destination</font></div><div><br></div><div><br></div><div>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!</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div><br></div><div>cheers and thanks,</div><div><br></div>Ian Veach, Senior Systems Analyst<div>System Computing Services, Nevada System of Higher Education</div><div><br></div></div></div>
<br><div class="gmail_quote">On Mon, Jul 18, 2016 at 4:11 PM, Browne, Stuart <span dir="ltr"><<a href="mailto:Stuart.Browne@neustar.biz" target="_blank">Stuart.Browne@neustar.biz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What about the mangle or raw tables?<br>
<br>
iptables -t raw -nvL<br>
iptables -t mangle -nvL<br>
<br>
Both tables have the ability to modify the packets as they pass through.<br>
<br>
Stuart<br>
<br>
------------------------------------------------------------------------<br>
From: bind-users [mailto:<a href="mailto:bind-users-bounces@lists.isc.org">bind-users-bounces@lists.isc.org</a>] On Behalf Of Ian Veach<br>
Sent: Tuesday, 19 July 2016 8:09 AM<br>
To: Barry Margolin; <a href="mailto:comp-protocols-dns-bind@isc.org">comp-protocols-dns-bind@isc.org</a><br>
<div><div class="h5">Subject: Re: weird transfer-source problems with one DNS node<br>
<br>
<br>
I don't think my earlier response to this has made it past moderation, but an update:<br>
<br>
iptables looks pretty benign to me...:<br>
<br>
Chain INPUT (policy ACCEPT)<br>
target prot opt source destination<br>
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED<br>
ACCEPT icmp -- anywhere anywhere<br>
ACCEPT all -- anywhere anywhere<br>
ACCEPT all -- anywhere anywhere<br>
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh<br>
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:domain<br>
ACCEPT udp -- anywhere anywhere state NEW udp dpt:domain<br>
(... other rules for allowed ports)<br>
ACCEPT ospf -- anywhere anywhere state NEW<br>
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited<br>
Chain FORWARD (policy ACCEPT)<br>
target prot opt source destination<br>
ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-is-bridged<br>
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED<br>
ACCEPT icmp -- anywhere anywhere<br>
ACCEPT all -- anywhere anywhere<br>
ACCEPT all -- anywhere anywhere<br>
ACCEPT all -- anywhere anywhere<br>
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited<br>
Chain OUTPUT (policy ACCEPT)<br>
target prot opt source destination<br>
<br>
<br>
<br>
<br>
<br>
cheers and thanks,<br>
<br>
Ian Veach, Senior Systems Analyst<br>
System Computing Services, Nevada System of Higher Education<br>
<br>
<br>
On Mon, Jul 18, 2016 at 1:27 PM, <a href="mailto:ian_veach@nshe.nevada.edu">ian_veach@nshe.nevada.edu</a> <<a href="mailto:ian_veach@nshe.nevada.edu">ian_veach@nshe.nevada.edu</a>> wrote:<br>
<br>
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<br>
<br>
Thanks! <br>
<br>
Sent via the Samsung Galaxy Note® 4, an AT&T 4G LTE smartphone<br>
<br>
<br>
-------- Original message --------<br>
From: Barry Margolin <<a href="mailto:barmar@alum.mit.edu">barmar@alum.mit.edu</a>><br>
Date: 07/18/2016 12:12 (GMT-08:00)<br>
To: <a href="mailto:comp-protocols-dns-bind@isc.org">comp-protocols-dns-bind@isc.org</a><br>
Subject: Re: weird transfer-source problems with one DNS node<br>
<br>
In article <<a href="mailto:mailman.111.1468862922.15653.bind-users@lists.isc.org">mailman.111.1468862922.15653.bind-users@lists.isc.org</a>>,<br>
Ian Veach <<a href="mailto:ian_veach@nshe.nevada.edu">ian_veach@nshe.nevada.edu</a>> wrote:<br>
<br>
> So unless I'm crazy (possible, regardless)... named is reporting using 230,<br>
> but OS is showing 240 (and remote host logs confirm 240)!?<br>
<br>
Could something in iptables be transforming it at a lower level?<br>
<br>
--<br>
Barry Margolin<br>
Arlington, MA<br>
_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank" rel="noreferrer">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank" rel="noreferrer">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
<br>
<br>
</div></div>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.<br>
</blockquote></div><br></div>
<br>
<span style="font-family:Arial,sans-serif;font-size:small;background-color:rgb(255,255,255)">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.</span>