Re: weird transfer-source problems with one DNS node
Thank you, Phil - that might be the answer. I'm not super knowledgeable about iptables, and I certainly didn't configure it this way (specifically), but the one problematic node does seem to have a postrouting chain. I'll have to investigate how this came about and how to remove, but perhaps this is it: [root@foo:~]# iptables -t nat -nvL Chain PREROUTING (policy ACCEPT 155M packets, 15G bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 270K packets, 15M bytes) pkts bytes target prot opt in out source destination 105M 13G MASQUERADE all -- * eth+0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 105M packets, 13G bytes) pkts bytes target prot opt in out source destination cheers and thanks, Ian Veach, Senior Systems Analyst System Computing Services, Nevada System of Higher Education On Tue, Jul 19, 2016 at 3:10 AM, Phil Mayers wrote: > On 19/07/16 00:38, Ian Veach wrote: > >> >> Negative Ghostrider...: >> >> [root@foo:~]# iptables -t raw -nvL >> > > Might want to check "-t nat" as well. > > ___ > 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. ___ 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
Re: weird transfer-source problems with one DNS node
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 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 anywherestate > RELATED,ESTABLISHED > ACCEPT icmp -- anywhere anywhere > ACCEPT all -- anywhere anywhere > ACCEPT all -- anywhere anywhere > ACCEPT tcp -- anywhere anywherestate NEW tcp > dpt:ssh > ACCEPT tcp -- anywhere anywherestate NEW tcp > dpt:domain > ACCEPT udp -- anywhere anywherestate NEW udp > dpt:domain > (... other rules for allowed ports) > ACCEPT ospf -- anywhere anywherestate NEW > REJECT all -- anywhere anywherereject-with > icmp-host-prohibited > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT all -- anywhere anywherePHYSDEV match > --physdev-is-bridged > ACCEPT all -- anywhere anywherestate > 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 > 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 , > Ian Veach 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 > bin
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 anywherestate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywherestate NEW tcp dpt:domain ACCEPT udp -- anywhere anywherestate NEW udp dpt:domain (... other rules for allowed ports) ACCEPT ospf -- anywhere anywherestate NEW REJECT all -- anywhere anywherereject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywherePHYSDEV match --physdev-is-bridged ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywherereject-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 > 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 , > Ian Veach 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. ___ 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
Re: weird transfer-source problems with one DNS node
Der, sorry. Machines are all RHEL 6.8, running the BIND provided by RH: 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6 Restarting BIND (or even the OS) doesn't seem to change anything. I don't seem to have scan as an option for rndc. I assume it's in a newer version that RH doesn't yet provide for RHEL 6. Logs are confusing. I tailed the general log and xfer log, while running tcpdump. The xfer log and general log indicate that the CORRECT address is being used: 18-Jul-2016 10:13:18.120 general: zone 153.10.10.IN-ADDR.ARPA/IN/internal-in: Transfer started. 18-Jul-2016 10:13:18.121 transfer of '153.10.10.IN-ADDR.ARPA/IN/internal-in' from 10.10.153.225#53: connected using 10.10.205.230#46673 However, I also ran tcpdump during that time (tcpdump -n host 10.10.153.225): 10:13:18.121138 IP 10.10.205.240.46673 > 10.10.153.225.domain: Flags [S], seq 1847532073, win 14600, options [mss 1460,sackOK,TS val 255805503 ecr 0,nop ,wscale 7], length 0 10:13:18.121911 IP 10.10.153.225.domain > 10.10.205.240.46673: Flags [S.], seq 1696697219, ack 1847532074, win 8192, options [mss 1380,nop,wscale 8,sack OK,TS val 329780493 ecr 255805503,nop,Unknown Option 1403], length 0 10:13:18.121937 IP 10.10.205.240.46673 > 10.10.153.225.domain: Flags [.], ack 1, win 115, options [nop,nop,TS val 255805503 ecr 329780493], length 0 [me@foo:/var/named/log]# host foo foo.scsr.nevada.edu has address 10.10.205.240 [me@foo:/var/named/log]# host foo-xfer foo-xfer.scsr.nevada.edu has address 10.10.205.230 So unless I'm crazy (possible, regardless)... named is reporting using 230, but OS is showing 240 (and remote host logs confirm 240)!? Thanks!! cheers and thanks, Ian Veach, Senior Systems Analyst System Computing Services, Nevada System of Higher Education On Mon, Jul 18, 2016 at 9:28 AM, Tony Finch wrote: > Ian Veach wrote: > > > > So, any ideas on why I would see that slave initiate transfers on it's OS > > IP versus the transfer-source IP... especially when the other three work > > fine? > > What does the log say about interface addresses? Which version of BIND are > you running? Has the xfer interface been reconfigured on the problematic > host? Does `rndc scan` or restarting named help? > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h > punycode > Biscay: East 3 or 4, becoming cyclonic 4 or 5. Slight or moderate. Showers > later. Good, occasionally moderate. > -- 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
weird transfer-source problems with one DNS node
I'm having a weird problem where one of our DNS servers is not communicating on the expected transfer-source IPs (but the rest are). They're generally configured exact/similar, but there's obviously something causing a difference on the one node. We run four slave DNS as public NS (with private masters for mgmt.). Two nodes per physical site (two sites). All run OSPF to provide anycast addresses as service addresses. All have an IP for the server/OS itself (each), and all have an IP dedicated for xfers only. So, for example (taking one location, obfuscating servers "foo" and "bar") 10.10.205.240/25 foo (OS IP, eth0) 10.10.205.230/25 foo-xfer (xfer, eth0:1) 10.10.205.1/32 service-ns1 (anycast IP, lo:1) 10.11.205.1/32 service-ns2 (anycast IP, lo:2) 10.10.205.239/25 bar 10.10.205.229/25 bar-xfer 10.10.205.1/32 service-ns1 10.11.205.1/32 service-ns2 So, on bar, everything works fine. And when I do a tcpdump on bar-xfer, I see the xfers occurring (connections to/from master). However, on foo, I see no traffic on the xfer IP. When I tcpdump the main OS IP (or the NS master address), I see that communication occurring on the OS IP, and not the transfer-source IP. And yet, here's the config line in named.conf: transfer-source 10.10.205.230; So, any ideas on why I would see that slave initiate transfers on it's OS IP versus the transfer-source IP... especially when the other three work fine? Same OS, same OS level, same (theoretical) config except for the IP differences between machines... Thanks for any pointers! cheers and thanks, Ian Veach, Senior Systems Analyst System Computing Services, Nevada System of Higher Education -- 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
certain records not being returned from cache?
Greetings and thanks for any help - I'm running into what seems like a strange problem. On our bind (9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3, but patched to latest), we seem to be having some domains [we aren't auth for] that aren't returning expected information from cache (although thousand of other domains resolve just fine). Digs on/from other providers (with other recursing servers outside our networks) seem to work correctly. To me, it seems like all information at least to the gTLD (and the ns of the domain?) is correct. So the problem seems to be us, but I'm not sure why. It seems that bind has the correct info in it's cache db (see below), and yet it will not return the data. Details below, happy to provide more upon request! An example is carsoncityschools.com. A dig +trace from two of our (different) networks works fine until after retrieving NS records: carsoncityschools.com. 172800 IN NS ns1.carsoncityschools.com. carsoncityschools.com. 172800 IN NS ns2.carsoncityschools.com. That's fine. But then [a packet sniff reveals that] the local resolver hits our server to look up (e.g.) ns1.carsoncityschools.com, and our servers (all) respond back with SERVFAIL. A dig @GTLD (any) of ns1 returns correct results with glue, and a dig, from one of our name servers directly to @50.23.15.156, return correct results: ;; QUESTION SECTION: ;ns1.carsoncityschools.com. IN A ;; AUTHORITY SECTION: carsoncityschools.com. 172800 IN NS ns1.carsoncityschools.com. carsoncityschools.com. 172800 IN NS ns2.carsoncityschools.com. ;; ADDITIONAL SECTION: ns1.carsoncityschools.com. 172800 INA 50.23.15.156 ns2.carsoncityschools.com. 172800 INA 50.23.28.180 However, a dig direct to @OURDNS (tried three distinct systems/networks) for, e.g. ns1.carsoncityschools.com, yields poor results: ; <<>> DiG 9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3 <<>> @OURDNS ns1.carsoncityschools.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32117 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns1.carsoncityschools.com. IN A So, if I'm on the right track here, it seems like perhaps our server is not caching the information or retrieving the info, because everything else seems fine. A restart of named does not fix the problem. I then ran a rndc dumpdb, and looked at the file (after attempting a dig again). The (internal cache db) dumpdb yields this: carsoncityschools.com. 172791 NS ns1.carsoncityschools.com. 172791 NS ns2.carsoncityschools.com. ; glue ns1.carsoncityschools.com. 172791 A 50.23.15.156 ; glue ns2.carsoncityschools.com. 172791 A 50.23.28.180 and in the ; ns2.carsoncityschools.com [v4 TTL 1] [v4 success] [v6 unexpected] ; 50.23.28.180 [srtt 1] [flags ] ; ns1.carsoncityschools.com [v4 TTL 1] [v4 success] [v6 unexpected] ; 50.23.15.156 [srtt 14] [flags ] Not knowing the db structure in detail, I can't be sure, but doesn't it look like the cache has correct data in it. If that's the case, why does a local dig @OURDNS return a value? Does anyone have other suggestions to try? THANK YOU! -- cheers and thanks, Ian Veach, Systems Analyst System Computing Services, Nevada System of Higher Education ___ 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
