Re: BIND server; dig vs dig +trace on failing lookup.
dig +trace +all and it stood out. > On 3 Mar 2021, at 13:20, Gregory Sloop wrote: > > Would you mind showing me how you got there? > [The answer is fab, obviously. But give a man a fish...and all that. :) ] > > -Greg > > > > MA> The COM servers have stale glue > > MA> srvns.pacifier.com. 172800 IN A 216.65.128.5 > MA> webns.pacifier.com. 172800 IN A 216.65.128.1 > > MA> vs > > MA> srvns.pacifier.com. 86400 IN A 64.255.237.241 > MA> webns.pacifier.com. 86400 IN A 64.255.237.240 > > MA> The later set of servers are what you query when you run dig +trace. > MA> If you prime the cache the plain lookup should work. Report the out > MA> of date glue to the zone administrator. > > MA> Mark > > >> On 3 Mar 2021, at 13:06, Gregory Sloop wrote: > > >> I've got a case, (and I see several other similar reports) where BIND is > >> failing to find an A record for a domain. > >> Yet a dig +trace does. > > >> (I'm doing the dig on the BIND server. It's set to be a root resolving > >> server, not a forwarder.) > > >> As I understand this, +trace will also involve resolve.conf options. And > >> in this case, I've got Google DNS as one of the resolve.conf entries. > >> So, I can see how +trace would deliver different results than simply > >> dig-ing - provided that +trace does involve resolve.conf. > > >> Here's a plain dig, using the BIND server itself - from the console. > >> --- > >> dig cistus.com @10.8.20.5 > > >> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5 > >> ;; global options: +cmd > >> ;; Got answer: > >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786 > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > >> ;; OPT PSEUDOSECTION: > >> ; EDNS: version: 0, flags:; udp: 4096 > >> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good) > >> ;; QUESTION SECTION: > >> ;cistus.com.IN A > > >> ;; Query time: 0 msec > >> ;; SERVER: 10.8.20.5#53(10.8.20.5) > >> ;; WHEN: Fri Feb 26 12:18:24 PST 2021 > >> ;; MSG SIZE rcvd: 67 > > >> --- > > >> I could post the dig +trace, if it adds any information, but I suspect it > >> doesn't. > > >> So, what methods or steps might I take to figure out why the above > >> lookup/dig fails? > >> [I intended +trace to do that, but since it's not doing the same thing a > >> plain dig does, it's not very useful as a diagnostic tool.] > > >> I've done some searching to see how to accomplish this, but it's a > >> difficult question to frame without a ton of worthless hits. > >> So, can someone point me at a good source for a how-to/walk-through? A > >> previous list posting? > > >> Again, the question is; what methods or steps (best practices) might I > >> take to figure out why the above lookup/dig fails? > > >> TIA > >> -Greg > >> ___ > >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to > >> unsubscribe from this list > > >> ISC funds the development of this software with paid support > >> subscriptions. Contact us at https://www.isc.org/contact/ for more > >> information. > > > >> bind-users mailing list > >> bind-users@lists.isc.org > >> https://lists.isc.org/mailman/listinfo/bind-users > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND server; dig vs dig +trace on failing lookup.
Let me take a swing at it. If I'm wrong, someone correct me. 1) dig the name servers for the 1st level domain. (In this case, it's a .com.) # dig +short com. NS c.gtld-servers.net. f.gtld-servers.net. j.gtld-servers.net. l.gtld-servers.net. k.gtld-servers.net. d.gtld-servers.net. g.gtld-servers.net. i.gtld-servers.net. a.gtld-servers.net. e.gtld-servers.net. m.gtld-servers.net. b.gtld-servers.net. h.gtld-servers.net. --- 2) How, ask one of those name servers for the NS for the target domain. (cistus.com. in this case.) # dig +norec @i.gtld-servers.net. cistus.com. NS ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> +norec @i.gtld-servers.net. cistus.com. NS ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49843 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cistus.com.IN NS ;; AUTHORITY SECTION: cistus.com. 172800 IN NS srvns.pacifier.com. cistus.com. 172800 IN NS webns.pacifier.com. ;; ADDITIONAL SECTION: srvns.pacifier.com. 172800 IN A 216.65.128.5 webns.pacifier.com. 172800 IN A 216.65.128.1 --- 3) Finally, query the records in the additional section to see if they match the glue records. # dig srvns.pacifier.com. ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> srvns.pacifier.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17445 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d16ea0cbd520a81cea1154c1603ef7e13d586e8adc0e75f3 (good) ;; QUESTION SECTION: ;srvns.pacifier.com.IN A ;; ANSWER SECTION: srvns.pacifier.com. 85728 IN A 64.255.237.241 ;; AUTHORITY SECTION: pacifier.com. 172126 IN NS ns2.iinet.com. pacifier.com. 172126 IN NS ns4.iinet.com. pacifier.com. 172126 IN NS ns1.iinet.com. pacifier.com. 172126 IN NS ns3.iinet.com. (glue) srvns.pacifier.com. 172800 IN A 216.65.128.5 vs (regular lookup) srvns.pacifier.com. 85728 IN A 64.255.237.241 And they don't - so we know the glue is stale. Is that right? :) -Greg Would you mind showing me how you got there? [The answer is fab, obviously. But give a man a fish...and all that. :) ] -Greg MA> The COM servers have stale glue MA> srvns.pacifier.com. 172800 IN A 216.65.128.5 MA> webns.pacifier.com. 172800 IN A 216.65.128.1 MA> vs MA> srvns.pacifier.com. 86400 IN A 64.255.237.241 MA> webns.pacifier.com. 86400 IN A 64.255.237.240 MA> The later set of servers are what you query when you run dig +trace. MA> If you prime the cache the plain lookup should work. Report the out MA> of date glue to the zone administrator. MA> Mark >> On 3 Mar 2021, at 13:06, Gregory Sloop wrote: >> I've got a case, (and I see several other similar reports) where BIND is >> failing to find an A record for a domain. >> Yet a dig +trace does. >> (I'm doing the dig on the BIND server. It's set to be a root resolving >> server, not a forwarder.) >> As I understand this, +trace will also involve resolve.conf options. And in >> this case, I've got Google DNS as one of the resolve.conf entries. >> So, I can see how +trace would deliver different results than simply dig-ing >> - provided that +trace does involve resolve.conf. >> Here's a plain dig, using the BIND server itself - from the console. >> --- >> dig cistus.com @10.8.20.5 >> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good) >> ;; QUESTION SECTION: >> ;cistus.com.IN A >> ;; Query time: 0 msec >> ;; SERVER: 10.8.20.5#53(10.8.20.5) >> ;; WHEN: Fri Feb 26 12:18:24 PST 2021 >> ;; MSG SIZE rcvd: 67 >> --- >> I could post the dig +trace, if it adds any information, but I suspect it >> doesn't. >> So, what methods or steps might I take to figure out why the above >> lookup/dig fails? >> [I intended +trace to do that, but since it's not doing the same thing a >> plain dig does, it's not very useful as a diagnostic tool.] >> I've done some searching to see how to accomplish this, but it's a difficult >> question to frame without a ton of worthless hits. >> So, can someone point me at a good source for a how-to/walk-through? A >> previous list posting? >> Again, the question is; what methods or steps (best practices) might I take >> to figure
Re: BIND server; dig vs dig +trace on failing lookup.
Would you mind showing me how you got there? [The answer is fab, obviously. But give a man a fish...and all that. :) ] -Greg MA> The COM servers have stale glue MA> srvns.pacifier.com. 172800 IN A 216.65.128.5 MA> webns.pacifier.com. 172800 IN A 216.65.128.1 MA> vs MA> srvns.pacifier.com. 86400 IN A 64.255.237.241 MA> webns.pacifier.com. 86400 IN A 64.255.237.240 MA> The later set of servers are what you query when you run dig +trace. MA> If you prime the cache the plain lookup should work. Report the out MA> of date glue to the zone administrator. MA> Mark >> On 3 Mar 2021, at 13:06, Gregory Sloop wrote: >> I've got a case, (and I see several other similar reports) where BIND is >> failing to find an A record for a domain. >> Yet a dig +trace does. >> (I'm doing the dig on the BIND server. It's set to be a root resolving >> server, not a forwarder.) >> As I understand this, +trace will also involve resolve.conf options. And in >> this case, I've got Google DNS as one of the resolve.conf entries. >> So, I can see how +trace would deliver different results than simply dig-ing >> - provided that +trace does involve resolve.conf. >> Here's a plain dig, using the BIND server itself - from the console. >> --- >> dig cistus.com @10.8.20.5 >> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good) >> ;; QUESTION SECTION: >> ;cistus.com.IN A >> ;; Query time: 0 msec >> ;; SERVER: 10.8.20.5#53(10.8.20.5) >> ;; WHEN: Fri Feb 26 12:18:24 PST 2021 >> ;; MSG SIZE rcvd: 67 >> --- >> I could post the dig +trace, if it adds any information, but I suspect it >> doesn't. >> So, what methods or steps might I take to figure out why the above >> lookup/dig fails? >> [I intended +trace to do that, but since it's not doing the same thing a >> plain dig does, it's not very useful as a diagnostic tool.] >> I've done some searching to see how to accomplish this, but it's a difficult >> question to frame without a ton of worthless hits. >> So, can someone point me at a good source for a how-to/walk-through? A >> previous list posting? >> Again, the question is; what methods or steps (best practices) might I take >> to figure out why the above lookup/dig fails? >> TIA >> -Greg >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://www.isc.org/contact/ for more information. >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND server; dig vs dig +trace on failing lookup.
The COM servers have stale glue srvns.pacifier.com. 172800 IN A 216.65.128.5 webns.pacifier.com. 172800 IN A 216.65.128.1 vs srvns.pacifier.com. 86400 IN A 64.255.237.241 webns.pacifier.com. 86400 IN A 64.255.237.240 The later set of servers are what you query when you run dig +trace. If you prime the cache the plain lookup should work. Report the out of date glue to the zone administrator. Mark > On 3 Mar 2021, at 13:06, Gregory Sloop wrote: > > I've got a case, (and I see several other similar reports) where BIND is > failing to find an A record for a domain. > Yet a dig +trace does. > > (I'm doing the dig on the BIND server. It's set to be a root resolving > server, not a forwarder.) > > As I understand this, +trace will also involve resolve.conf options. And in > this case, I've got Google DNS as one of the resolve.conf entries. > So, I can see how +trace would deliver different results than simply dig-ing > - provided that +trace does involve resolve.conf. > > Here's a plain dig, using the BIND server itself - from the console. > --- > dig cistus.com @10.8.20.5 > > ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good) > ;; QUESTION SECTION: > ;cistus.com.IN A > > ;; Query time: 0 msec > ;; SERVER: 10.8.20.5#53(10.8.20.5) > ;; WHEN: Fri Feb 26 12:18:24 PST 2021 > ;; MSG SIZE rcvd: 67 > > --- > > I could post the dig +trace, if it adds any information, but I suspect it > doesn't. > > So, what methods or steps might I take to figure out why the above lookup/dig > fails? > [I intended +trace to do that, but since it's not doing the same thing a > plain dig does, it's not very useful as a diagnostic tool.] > > I've done some searching to see how to accomplish this, but it's a difficult > question to frame without a ton of worthless hits. > So, can someone point me at a good source for a how-to/walk-through? A > previous list posting? > > Again, the question is; what methods or steps (best practices) might I take > to figure out why the above lookup/dig fails? > > TIA > -Greg > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND server; dig vs dig +trace on failing lookup.
I've got a case, (and I see several other similar reports) where BIND is failing to find an A record for a domain. Yet a dig +trace does. (I'm doing the dig on the BIND server. It's set to be a root resolving server, not a forwarder.) As I understand this, +trace will also involve resolve.conf options. And in this case, I've got Google DNS as one of the resolve.conf entries. So, I can see how +trace would deliver different results than simply dig-ing - provided that +trace does involve resolve.conf. Here's a plain dig, using the BIND server itself - from the console. --- dig cistus.com @10.8.20.5 ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good) ;; QUESTION SECTION: ;cistus.com.IN A ;; Query time: 0 msec ;; SERVER: 10.8.20.5#53(10.8.20.5) ;; WHEN: Fri Feb 26 12:18:24 PST 2021 ;; MSG SIZE rcvd: 67 --- I could post the dig +trace, if it adds any information, but I suspect it doesn't. So, what methods or steps might I take to figure out why the above lookup/dig fails? [I intended +trace to do that, but since it's not doing the same thing a plain dig does, it's not very useful as a diagnostic tool.] I've done some searching to see how to accomplish this, but it's a difficult question to frame without a ton of worthless hits. So, can someone point me at a good source for a how-to/walk-through? A previous list posting? Again, the question is; what methods or steps (best practices) might I take to figure out why the above lookup/dig fails? TIA -Greg___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind9 forwarding reverse dns resolution
You should immediately stop using other people's IP ranges. This won’t ever do any good. There’s plenty of IP addresses in RFC1918 ranges or even better use ULA IPv6 range. When you fix the IP address abuse, there’s a KB article on the topic: https://kb.isc.org/docs/aa-00800 Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 2. 3. 2021, at 21:22, Chechu wrote: > > which happens to be in a public range that seems to be owned by SoftBank... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind9 forwarding reverse dns resolution
hey guys, I'm running a kubernetes cluster which is getting wrong hostnames, apparently cause my Bind9 is forwarding to a pubic DNS the reverse resolution of my private network IPs...which happens to be in a public range that seems to be owned by SoftBankis there. a way to preventing the DNS to forward the DNS resolution for that specific network? -- Chechu Web: www.notesfromchechu.com Twitter: http://twitter.com/chechuironman LinkdIn: http://es.linkedin.com/in/jesusarteche ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnstap shows little logging at debug 10
Greetings. On Tue, 2 Mar 2021, Adam Augustine wrote: # ncat -l -U /var/opt/isc/scls/isc-bind/log/named/dnstap.sock I "chown named.named ./dnstap.sock" : But regardless I don't get anything from the pipe when using the normal "systemctl start isc-bind-named.service" followed by some "dig" commands to test (but see below). I was previously using fstrm_capture like this: [...] And I do suddenly get "protobuf:dnstap.Dnstap" on the pipe, but nothing further. So my root problem seems to be with how systemd is managing the process (maybe a user ID problem with the pipe). But my grepping the strace didn't catch anything opening the "dnstap.sock" pipe. The way they did framestream initialization it requires the "optional" handshake. I documented it (pydoc) here: https://github.com/m3047/shodohflo/blob/master/shodohflo/fstrm.py -- Fred Morris ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnstap shows little logging at debug 10
Well, I don't know what I have done exactly, but now when I start named as root it seems to be working properly, as far as the pipe goes. I am getting data via the fstrm_capture process written to the "example.dnstap" file. I see a number of startup queries when I decode the file. I can't get it to do the same when I start it with "systemctl start isc-bind-named.service" though. So it is clearly a problem with the environment named is running in when launched by systemd. My procedure so far (not production worthy, obviously) looks like this for those who may see this in the future: 1) run '/opt/isc/isc-bind/root/usr/bin/fstrm_capture -t protobuf:dnstap.Dnstap -u /var/opt/isc/scls/isc-bind/log/named/dnstap.sock -w /var/tmp/example.dnstap" 2) "chown named.named /var/opt/isc/scls/isc-bind/log/named/dnstap.sock" 3) run "/opt/isc/isc-bind/root/usr/sbin/named -u named" from a root shell 4) go look at "example.dnstap" and see queries. Following that process but replacing step #3 with "systemctl start isc-bind-named.service" results in everything otherwise working properly, but nothing getting added to "example.dnstap". "ps aux | grep named" shows the same user owning the "named" process in both cases. here is the output when run in by root: # ps auwwwxZ | grep named unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7606 0.0 0.0 11060 1104 pts/0 S+ 10:05 0:00 /opt/isc/isc-bind/root/usr/bin/fstrm_capture -t protobuf:dnstap.Dnstap -u /var/opt/isc/scls/isc-bind/log/named/dnstap.sock -w /var/tmp/example.dnstap unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 named 7745 0.0 1.0 531520 41720 ? Ssl 10:23 0:00 /opt/isc/isc-bind/root/usr/sbin/named -u named unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7757 0.0 0.0 12116 972 pts/3 S+ 10:24 0:00 grep --color=auto named And here is the output when run by "systemctl start isc-bind-named.service": # ps auwwwxZ | grep named unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7606 0.0 0.0 11060 1104 pts/0 S+ 10:05 0:00 /opt/isc/isc-bind/root/usr/bin/fstrm_capture -t protobuf:dnstap.Dnstap -u /var/opt/isc/scls/isc-bind/log/named/dnstap.sock -w /var/tmp/example.dnstap system_u:system_r:named_t:s0named 7781 0.0 1.0 531516 40860 ? Ssl 10:25 0:00 /opt/isc/isc-bind/root/usr/sbin/named -u named unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7793 0.0 0.0 12116 1084 pts/3 S+ 10:26 0:00 grep --color=auto named m_capture -t protobuf:dnstap.Dnstap -u /var/opt/isc/scls/isc-bind/log/named/dnstap.sock -w /var/tmp/example.dnstap unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 named 7745 0.0 1.0 531520 41720 ? Ssl 10:23 0:00 /opt/isc/isc-bind/root/usr/sbin/named -u named unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7757 0.0 0.0 12116 972 pts/3 S+ 10:24 0:00 grep --color=auto named So clearly it is an SELinux permissions problem. And now I am seeing denies in the /var/log/audit/audit.log grrr. I know there was nothing there before, so it must have been hung up on regular unix permissions or something and once I fixed that it was the SELinux permissions issue. Sorry for wasting everyone's time. I appreciate you being there as a sounding board though. Thanks Mark for looking beyond my initial concern. I would like to see that sort of permissions error get logged in the dnstap logs at some severity level though. I am still not clear what I am doing wrong on that front. Thanks again. On Tue, Mar 2, 2021 at 9:32 AM Adam Augustine wrote: > Sorry, I replied to just Mark rather than the list. > > Yes, here is the command I am using: > > # ncat -l -U /var/opt/isc/scls/isc-bind/log/named/dnstap.sock > I "chown named.named ./dnstap.sock" : > > 0 srwxr-xr-x. 1 named named unconfined_u:object_r:named_log_t:s0 0 > Mar 2 09:23 dnstap.sock > > But regardless I don't get anything from the pipe when using the normal > "systemctl start isc-bind-named.service" followed by some "dig" commands to > test (but see below). I was previously using fstrm_capture like this: > > # /opt/isc/isc-bind/root/usr/bin/fstrm_capture -t protobuf:dnstap.Dnstap > -u /var/opt/isc/scls/isc-bind/log/named/dnstap.sock -w > /var/tmp/example.dnstap > > But I was only seeing 46 bytes in the "example.dnstap" and nothing decoded > when I run "dnstap-read ./example.dnstap". After "systemctl stop > isc-bind-named.service" and stopping the "fstrm_capture" process the file > increased to 54 bytes, but "dnstap-read" still doesn't decode anything. > > I am reasonably confident that I am doing something boneheaded somewhere, > likely a typo in my config or bad permission somewhere, but I admit I can't > see it and without any error messages or debug information I am struggling. > The config is pretty simple, just the option stanza below and logging > settings (mostly copy-pasted from the ISC website just in case). > > In an effort to figure out the problem I went so far as to: > > # strace -a 120
Re: dnstap shows little logging at debug 10
Sorry, I replied to just Mark rather than the list.
Yes, here is the command I am using:
# ncat -l -U /var/opt/isc/scls/isc-bind/log/named/dnstap.sock
I "chown named.named ./dnstap.sock" :
0 srwxr-xr-x. 1 named named unconfined_u:object_r:named_log_t:s0 0
Mar 2 09:23 dnstap.sock
But regardless I don't get anything from the pipe when using the normal
"systemctl start isc-bind-named.service" followed by some "dig" commands to
test (but see below). I was previously using fstrm_capture like this:
# /opt/isc/isc-bind/root/usr/bin/fstrm_capture -t protobuf:dnstap.Dnstap -u
/var/opt/isc/scls/isc-bind/log/named/dnstap.sock -w /var/tmp/example.dnstap
But I was only seeing 46 bytes in the "example.dnstap" and nothing decoded
when I run "dnstap-read ./example.dnstap". After "systemctl stop
isc-bind-named.service" and stopping the "fstrm_capture" process the file
increased to 54 bytes, but "dnstap-read" still doesn't decode anything.
I am reasonably confident that I am doing something boneheaded somewhere,
likely a typo in my config or bad permission somewhere, but I admit I can't
see it and without any error messages or debug information I am struggling.
The config is pretty simple, just the option stanza below and logging
settings (mostly copy-pasted from the ISC website just in case).
In an effort to figure out the problem I went so far as to:
# strace -a 120 /opt/isc/isc-bind/root/usr/sbin/named -f -u named 2>&1 |
tee temp.file
And I do suddenly get "protobuf:dnstap.Dnstap" on the pipe, but nothing
further. So my root problem seems to be with how systemd is managing the
process (maybe a user ID problem with the pipe). But my grepping the strace
didn't catch anything opening the "dnstap.sock" pipe.
I admit I don't know what I am doing wrong or how to get better
information, short of maybe stepping through with GDB to try to see where
it is failing.
Running named with this in the options:
dnstap-output file "/var/opt/isc/scls/isc-bind/log/named/dnstap.log";
Does work just fine with lots of wonderful data, so it isn't a problem with
dnstap per se, it is something with how I am setting up the pipe or
environment named is running in.
On Mon, Mar 1, 2021 at 6:53 PM Mark Andrews wrote:
> Do you have something reading the pipe?
>
>
> > On 2 Mar 2021, at 10:30, Adam Augustine wrote:
> >
> > I can't seem to get any debug information out of BIND for
> troubleshooting a dnstap problem I am having.
> >
> > I have a CentOS 8.3.2011 VM with the COPR packages installed.
> >
> > My /etc/opt/isc/scls/isc-bind/named.conf :
> > options {
> > directory "/var/opt/isc/scls/isc-bind/named/data";
> > listen-on { any; };
> > listen-on-v6 { any; };
> > dnssec-validation auto;
> > dnstap {all;};
> > // dnstap-output unix
> "/var/opt/isc/scls/isc-bind/run/named/dnstap.sock";
> > dnstap-output unix
> "/var/opt/isc/scls/isc-bind/log/named/dnstap.sock";
> > dnstap-identity "dnstap01.ldschurch.org";
> > dnstap-version "bind-9.16.12";
> > };
> >
> > logging {
> > [SNIP]
> > channel dnstap_log {
> > file "/var/opt/isc/scls/isc-bind/log/named/dnstap" versions 3
> size 20m;
> > print-time yes;
> > print-category yes;
> > print-severity yes;
> > severity debug 10;
> > };
> > [SNIP]
> > category dnstap { dnstap_log; default_debug; };
> > };
> >
> > On startup, the /var/opt/isc/scls/isc-bind/log/named/dnstap file is
> created, but no information is logged:
> >
> > 4 -rw-r--r--. 1 named named system_u:object_r:named_log_t:s054
> Mar 1 16:23 dnstap
> >
> > This is despite /var/log/messages having the following line:
> >
> > opening dnstap destination
> '/var/opt/isc/scls/isc-bind/log/named/dnstap.sock'
> >
> > Which I would have expected to see logged in
> /var/opt/isc/scls/isc-bind/log/named/dnstap . On shutdown, this single
> entry is logged in /var/opt/isc/scls/isc-bind/log/named/dnstap:
> >
> > 01-Mar-2021 16:23:31.597 dnstap: info: closing dnstap
> >
> > There is nothing relevant in /var/log/audit/audit.log, so I don't think
> it is SELinux related, especially since there is successful log entry on
> shutdown.
> >
> > I have tried changing the severity level from "info", to "debug 1", to
> "debug 3", and then to "debug 10", but I can't seem to get any more
> information out other than the single message about "closing dnstap".
> >
> > Any idea what I am doing wrong?
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61
Re: TXT & SPF Record Syntax
On 2021-02-28 17:52, Mark Andrews wrote: Domain names without a trailing period are relative to the current origin. Domain names with a trailing period are absolute. snip On 1 Mar 2021, at 10:41, Tim Daneliuk via bind-users wrote: I am trying to understand when the LHS of a TXT record needs to be terminated with '.'. For example, I see this one of the machines I am managing. The server in question is the zone authority for foo.com: foo.com. IN TXT "v=spf1 ... foo.com. IN SPF "v=spf1 ... something._domainkey IN TXT "v=DKIM1 ... _dmark.foo.com. IN TXT "v=DMARC1 ... Could some kind soul explain why the DKIM key name does not require the trailing period, but why all the foo.com entries do? In addition to what Mark said, you might be interested in "@". In a zone file "@" is shorthand for the current $ORIGIN, so you could have it like this: ;$ORIGIN example.com. ; $ORIGIN can be explicitly set anywhere in the zone file, as above, or ; if not set, it takes the value of the zone name from named.conf(5) @ NS ns @ SOA"..." @ A 192.0.2.2 @ MX 0 mail @ TXT"v=spf1 ..." mail A 192.0.2.25 ns A 192.0.2.53 ns A 192.0.2.35 sel._domainkey TXT"v=DKIM1 ..." Each of the @ is read as "example.com.", and each unqualified name has ".example.com." appended. That applies on LHS and RHS, when a record's RDATA includes a hostname (NS and MX in the example given.) I should also point out that your question had nothing at all to do with TXT nor SPF; it was simply about zone file syntax. Trailing dot applies to all records of all types. And another nitpick, the SPF record type is deprecated. It has been reverted to the original method of using TXT. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
