hi all, any dns pros in the house??
i am trying to debug a split view dns. i am using F32 & bind9 where i have internal & external views.
internal network 10.0.0.0/24, external 108.220.213.120/29
what i think i am seeing is a refusal of query, but Why??
where can i find a query_log print-severity definition?
dig shows, ...
dig ws.linuxlighthouse.com ns
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> ws.linuxlighthouse.com ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45484 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ws.linuxlighthouse.com. IN NS
;; Query time: 355 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Thu Nov 12 22:53:45 PST 2020 ;; MSG SIZE rcvd: 51
dig 108.220.213.121
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> 108.220.213.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46338 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;108.220.213.121. IN A
;; ANSWER SECTION: 108.220.213.121. 0 IN A 108.220.213.121
;; Query time: 1 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Thu Nov 12 22:54:52 PST 2020 ;; MSG SIZE rcvd: 60
suggestions?
tia, jackc...
my named.conf
/* top of file */
acl slaves { 108.220.213.122; };
acl internals { 10.0.0.0/24; 127.0.0.0/8; };
/* 108.220.213.120/29; */
options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // "Working" directory dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing";
listen-on port 53 { localhost; }; listen-on-v6 port 53 { any; };
allow-query { internals; }; allow-query-cache { any; }; allow-transfer { 108.220.213.120/29; };
recursion yes;
forwarders { 8.8.8.8; 8.8.4.4; };
/* DNSSEC related options. See information about keys ("Trusted keys", bellow) */
/* Enable serving of DNSSEC related data - enable on both authoritative and recursive servers DNSSEC aware servers */ dnssec-enable yes;
/* Enable DNSSEC validation on recursive servers */ dnssec-validation yes;
/* In Fedora we use /run/named instead of default /var/run/named so we have to configure paths properly. */ pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key";
managed-keys-directory "/var/named/dynamic";
/* In Fedora we use system-wide Crypto Policy */ /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config";
/* use querylog all the time rndc */ querylog yes; };
logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; print-category yes; print-severity yes; }; default.log:12-Nov-2020 22:16:58.021 query-errors: info: client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for ws.linuxlighthouse.com/IN/AAAA at ../../../bin/named/query.c:7270 default.log:12-Nov-2020 22:16:58.503 query-errors: info: client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for ws.linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 default.log:12-Nov-2020 22:16:59.036 query-errors: info: client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for ws.linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270
channel security_file { severity debug 2; file "/var/log/named/security.log" versions 3 size 5m; print-time yes; print-category yes; print-severity yes; }; security.log:12-Nov-2020 22:16:58.021 client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/AAAA/IN' denied security.log:12-Nov-2020 22:16:58.503 client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/A/IN' denied security.log:12-Nov-2020 22:16:59.036 client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/A/IN' denied
channel queries_file { file "/var/log/named/queries.log" versions 3 size 5m; severity debug 3; print-time yes; print-category yes; print-severity yes; }; queries.log:12-Nov-2020 22:16:58.021 queries: info: client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN AAAA -E(0)DC (10.0.0.101) queries.log:12-Nov-2020 22:16:58.503 queries: info: client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN A -E(0)DC (10.0.0.101) queries.log:12-Nov-2020 22:16:59.036 queries: info: client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: *query: ws.linuxlighthouse.com http://ws.linuxlighthouse.com IN A -E(0)DC (10.0.0.101)*
category default { default_file; }; category general { general_file; }; category database { database_file; }; category security { security_file; }; category config { config_file; }; category resolver { resolver_file; }; category xfer-in { xfer-in_file; }; category xfer-out { xfer-out_file; }; category notify { notify_file; }; category client { client_file; }; category unmatched { unmatched_file; }; category queries { queries_file; }; category network { network_file; }; category update { update_file; }; category dispatch { dispatch_file; }; category dnssec { dnssec_file; }; category lame-servers { lame-servers_file; }; };
include "/etc/rndc.key";
controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; }; };
/* This view will contain zones you want to serve only to "internal" clients that connect via your directly attached LAN interfaces - "localnets" . */
view "internal-lan-view" { match-clients { internals; }; recursion yes;
zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; }; };
/* This view will contain zones you want to serve only to "external" clients that have addresses that are not match any above view: */
view "external-wan-view" { match-clients { any; }; recursion no;
zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-query { any; }; /* allow-transfer { slaves; }; */ };
zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; allow-query { any; }; }; };
; Authoritative data for linuxlighthouse.com zone ; ; $ORIGIN linuxlighthouse.com. $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 86400 ) ; minimum ; ;jack.craig.aptos@gmail.com ; @ IN NS ws IN MX 10 mail IN A 108.220.213.121
ws IN A 108.220.213.121 www IN A 108.220.213.121 mail IN A 108.220.213.121
; cname later ;ws2 IN A 68.94.157.1 ;dns157r8.sbcglobal.net. IN A 68.94.157.8
; ; DNSSEC/CAA setup ; example.org. CAA 128 issue "letsencrypt.org"
; linuxlighthouse.com. CAA 128 issue "letsencrypt.org"
; $include "/var/named/linuxlighthouse.com.db"
@ IN A 10.0.0.1 ws IN A 10.0.0.101 www IN A 10.0.0.101 ws2 IN A 10.0.0.102
[jackc@ws ~$
On Thu, 2020-11-12 at 23:02 -0800, Jack Craig wrote:
listen-on port 53 { localhost; }; listen-on-v6 port 53 { any; };
Unless I missed something, elsewhere, your IPv4 connections can only come from localhost.
On Fri, Nov 13, 2020 at 1:55 AM Tim via users users@lists.fedoraproject.org wrote:
On Thu, 2020-11-12 at 23:02 -0800, Jack Craig wrote:
listen-on port 53 { localhost; }; listen-on-v6 port 53 { any; };
Unless I missed something, elsewhere, your IPv4 connections can only come from localhost.
i am sure i am the one missing something. you are suggesting listen on external ip?
- listen-on port 53 { localhost; 108.220.213.121; };*
also, do you know where to look up the below query log entry for this failing request.
13-Nov-2020 02:18:51.600 queries: info: client @0x7fa3f41c9760 172.253.1.1#54405 (linuxlighthouse.com):* view external-wan-view: query: linuxlighthouse.com http://linuxlighthouse.com IN A -E(0)DC (10.0.0.101)*
thanks to both replies, jackc...
--
uname -rsvp Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Jack Craig:
listen-on port 53 { localhost; }; listen-on-v6 port 53 { any; };
Tim:
Unless I missed something, elsewhere, your IPv4 connections can only come from localhost.
Jack Craig:
i am sure i am the one missing something. you are suggesting listen on external ip?
listen-on port 53 { localhost; 108.220.213.121; };
If you want to allow a query from outside, you have to allow a connection to listen to the outside world. You can specify networks, or even a specific to listen on. That's the IP it will listen on, not some IP out on the world for it to listen to.
You've set your named to listen to *any* IPv6 interface. You can do the same with IPv4.
That's *IF* you want connections from outside through to your server. And, your firewall has to let them through, too.
also, do you know where to look up the below query log entry for this failing request.
13-Nov-2020 02:18:51.600 queries: info: client @0x7fa3f41c9760 172.253.1.1#54405 (linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com IN A -E(0)DC (10.0.0.101)
Elsewhere in your config, you had this parameter:
file "/var/log/named/default.log"
That's the file to look through.
Confusingly, you seem to have log entries pasted in the middle of your configuration file.
That log line suggests on that date and time a query from the 172... IP address was answered using the data for the external-wan-view of the DNS record.
You can find out more data about that IP using "dig -x 172.253.1.1" and "whois 172.253.1.1" commands.
Hi Jack,
On 11/13/20 8:02 AM, Jack Craig wrote:
hi all, any dns pros in the house??
i am trying to debug a split view dns. i am using F32 & bind9 where i have internal & external views.
internal network 10.0.0.0/24, external 108.220.213.120/29
what i think i am seeing is a refusal of query, but Why??
where can i find a query_log print-severity definition?
dig shows, ...
dig ws.linuxlighthouse.com ns
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> ws.linuxlighthouse.com ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45484 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ws.linuxlighthouse.com. IN NS
;; Query time: 355 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Thu Nov 12 22:53:45 PST 2020 ;; MSG SIZE rcvd: 51
dig 108.220.213.121
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> 108.220.213.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46338 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;108.220.213.121. IN A
;; ANSWER SECTION: 108.220.213.121. 0 IN A 108.220.213.121
;; Query time: 1 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Thu Nov 12 22:54:52 PST 2020 ;; MSG SIZE rcvd: 60
suggestions?
tia, jackc...
my named.conf
/* top of file */
acl slaves { 108.220.213.122; };
acl internals { 10.0.0.0/24; 127.0.0.0/8; };
/* 108.220.213.120/29; */
options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // "Working" directory dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing";
listen-on port 53 { localhost; };
Localhost usually has only 127.0.0.0/8 and ::1 addresses. Without both internal address and external or any; Outside IPv4 packet would never reach bind.
listen-on-v6 port 53 { any; };
allow-query { internals; };
Move this to views. allow-query includes recursive and non-recursive queries. Kind of firewall equivalent. Just let it inside or not.
allow-query-cache { any; };
Unless you override this in view, this would make your (internal) cache open to outside world. It it would act authoritative for outside and recursive for inside clients, I would recommend removing these two and using just allow-recursion { internals; }; allow-recursion-on { internals };
in specific view.
allow-transfer { 108.220.213.120/29; };
It is better to use keys to authenticate. Check tsig-keygen(8) manual page.
recursion yes;
Remove this one ^^. Instead, configure it only per view
forwarders { 8.8.8.8; 8.8.4.4; };/* DNSSEC related options. See information about keys ("Trusted keys", bellow) */
/* Enable serving of DNSSEC related data - enable on both authoritative and recursive servers DNSSEC aware servers */ dnssec-enable yes;
/* Enable DNSSEC validation on recursive servers */ dnssec-validation yes;
/* In Fedora we use /run/named instead of default /var/run/named so we have to configure paths properly. */ pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key";
managed-keys-directory "/var/named/dynamic";
/* In Fedora we use system-wide Crypto Policy */ /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config"; /* use querylog all the time rndc */ querylog yes;};
logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; print-category yes; print-severity yes; }; default.log:12-Nov-2020 22:16:58.021 query-errors: info: client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for ws.linuxlighthouse.com/IN/AAAA at ../../../bin/named/query.c:7270 default.log:12-Nov-2020 22:16:58.503 query-errors: info: client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for ws.linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 default.log:12-Nov-2020 22:16:59.036 query-errors: info: client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for ws.linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270
Client 60.215.138.163 does not match allow-query, so it is refused.
channel security_file { severity debug 2; file "/var/log/named/security.log" versions 3 size 5m; print-time yes; print-category yes; print-severity yes; };security.log:12-Nov-2020 22:16:58.021 client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/AAAA/IN' denied security.log:12-Nov-2020 22:16:58.503 client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/A/IN' denied security.log:12-Nov-2020 22:16:59.036 client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/A/IN' denied
channel queries_file { file "/var/log/named/queries.log" versions 3 size 5m; severity debug 3; print-time yes; print-category yes; print-severity yes; };queries.log:12-Nov-2020 22:16:58.021 queries: info: client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN AAAA -E(0)DC (10.0.0.101) queries.log:12-Nov-2020 22:16:58.503 queries: info: client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN A -E(0)DC (10.0.0.101) queries.log:12-Nov-2020 22:16:59.036 queries: info: client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: *query: ws.linuxlighthouse.com http://ws.linuxlighthouse.com IN A -E(0)DC (10.0.0.101)*
category default { default_file; }; category general { general_file; }; category database { database_file; }; category security { security_file; }; category config { config_file; }; category resolver { resolver_file; }; category xfer-in { xfer-in_file; }; category xfer-out { xfer-out_file; }; category notify { notify_file; }; category client { client_file; }; category unmatched { unmatched_file; }; category queries { queries_file; }; category network { network_file; }; category update { update_file; }; category dispatch { dispatch_file; }; category dnssec { dnssec_file; }; category lame-servers { lame-servers_file; };};
include "/etc/rndc.key";
controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; }; };
/* This view will contain zones you want to serve only to "internal" clients that connect via your directly attached LAN interfaces - "localnets" . */
view "internal-lan-view" { match-clients { internals; }; recursion yes;
zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; }; };
/* This view will contain zones you want to serve only to "external" clients that have addresses that are not match any above view: */
view "external-wan-view" { match-clients { any; }; recursion no;
zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-query { any; }; /* allow-transfer { slaves; }; */ };
zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; allow-query { any; }; };};
; Authoritative data for linuxlighthouse.com zone ; ; $ORIGIN linuxlighthouse.com. $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 86400 ) ; minimum ; ;jack.craig.aptos@gmail.com ; @ IN NS ws IN MX 10 mail IN A 108.220.213.121
ws IN A 108.220.213.121 www IN A 108.220.213.121 mail IN A 108.220.213.121
; cname later ;ws2 IN A 68.94.157.1 ;dns157r8.sbcglobal.net. IN A 68.94.157.8
; ; DNSSEC/CAA setup ; example.org. CAA 128 issue "letsencrypt.org"
; linuxlighthouse.com. CAA 128 issue "letsencrypt.org"
; $include "/var/named/linuxlighthouse.com.db"
@ IN A 10.0.0.1 ws IN A 10.0.0.101 www IN A 10.0.0.101 ws2 IN A 10.0.0.102
[jackc@ws ~$
first, a hearty Thanks for your responses to date.
I have tried to apply the suggested changes, but it's not changed the initial behaviour. so i am still missing something...
additional suggestions. i am going to look at host, who,w hois, nslookup for more info, thx, jackc...
*default.log:13-Nov-2020 13:30:43.484 query-errors: info: client @0x7f98541abfc0 40.69.104.72#54502 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/A http://linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270default.log:13-Nov-2020 13:30:49.778 query-errors: info: client @0x7f98541abfc0 40.69.104.77#49493 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/A http://linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270*
*queries.log:13-Nov-2020 13:30:43.484 queries: info: client @0x7f98541abfc0 40.69.104.72#54502 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com http://linuxlighthouse.com IN A -E(0)D (10.0.0.101)queries.log:13-Nov-2020 13:30:49.778 queries: info: client @0x7f98541abfc0 40.69.104.77#49493 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com http://linuxlighthouse.com IN A -E(0)D (10.0.0.101)*
*security.log:13-Nov-2020 13:30:43.484 client @0x7f98541abfc0 40.69.104.72#54502 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query 'linuxlighthouse.com/A/IN http://linuxlighthouse.com/A/IN' denied*
*security.log:13-Nov-2020 13:30:49.778 client @0x7f98541abfc0 40.69.104.77#49493 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query 'linuxlighthouse.com/A/IN http://linuxlighthouse.com/A/IN' denied*
current named.conf
options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // "Working" directory dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing";
listen-on port 53 { any; }; listen-on-v6 port 53 { any; };
allow-transfer { 108.220.213.120/29; };
forwarders { 8.8.8.8; 8.8.4.4; };
/* DNSSEC related options. See information about keys ("Trusted keys", bellow) */ /* Enable serving of DNSSEC related data - enable on both authoritative and recursive servers DNSSEC aware servers */ dnssec-enable yes;
/* Enable DNSSEC validation on recursive servers */ dnssec-validation yes;
/* In Fedora we use /run/named instead of default /var/run/named so we have to configure paths properly. */ pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; managed-keys-directory "/var/named/dynamic";
/* In Fedora we use system-wide Crypto Policy */ /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config";
/* use querylog all the time rndc */ querylog yes; };
controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; }; };
view "internal-lan-view" { match-clients { internals; };
allow-recursion { internals; }; allow-recursion-on { internals; };
zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; allow-query { internals; }; }; };
view "external-wan-view" { match-clients { any; }; recursion no;
allow-query { any; }; allow-transfer { 108.220.213.120/29; };
zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; };
zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; }; };
On Fri, Nov 13, 2020 at 6:10 AM Petr Menšík pemensik@redhat.com wrote:
Hi Jack,
On 11/13/20 8:02 AM, Jack Craig wrote:
hi all, any dns pros in the house??
i am trying to debug a split view dns. i am using F32 & bind9 where i have internal & external views.
internal network 10.0.0.0/24, external 108.220.213.120/29
what i think i am seeing is a refusal of query, but Why??
where can i find a query_log print-severity definition?
dig shows, ...
dig ws.linuxlighthouse.com ns
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> ws.linuxlighthouse.com ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45484 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ws.linuxlighthouse.com. IN NS
;; Query time: 355 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Thu Nov 12 22:53:45 PST 2020 ;; MSG SIZE rcvd: 51
dig 108.220.213.121
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> 108.220.213.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46338 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;108.220.213.121. IN A
;; ANSWER SECTION: 108.220.213.121. 0 IN A 108.220.213.121
;; Query time: 1 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Thu Nov 12 22:54:52 PST 2020 ;; MSG SIZE rcvd: 60
suggestions?
tia, jackc...
my named.conf
/* top of file */
acl slaves { 108.220.213.122; };
acl internals { 10.0.0.0/24; 127.0.0.0/8; };
/* 108.220.213.120/29; */
options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // "Working" directory dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing";
listen-on port 53 { localhost; };
Localhost usually has only 127.0.0.0/8 and ::1 addresses. Without both internal address and external or any; Outside IPv4 packet would never reach bind.
listen-on-v6 port 53 { any; };
allow-query { internals; };Move this to views. allow-query includes recursive and non-recursive queries. Kind of firewall equivalent. Just let it inside or not.
allow-query-cache { any; };
Unless you override this in view, this would make your (internal) cache open to outside world. It it would act authoritative for outside and recursive for inside clients, I would recommend removing these two and using just allow-recursion { internals; }; allow-recursion-on { internals };
in specific view.
allow-transfer { 108.220.213.120/29; };It is better to use keys to authenticate. Check tsig-keygen(8) manual page.
recursion yes;
Remove this one ^^. Instead, configure it only per view
forwarders { 8.8.8.8; 8.8.4.4; };/* DNSSEC related options. See information about keys ("Trusted keys", bellow) */
/* Enable serving of DNSSEC related data - enable on both authoritative and recursive servers DNSSEC aware servers */ dnssec-enable yes;
/* Enable DNSSEC validation on recursive servers */ dnssec-validation yes;
/* In Fedora we use /run/named instead of default /var/run/named so we have to configure paths properly. */ pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key";
managed-keys-directory "/var/named/dynamic";
/* In Fedora we use system-wide Crypto Policy */ /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config"; /* use querylog all the time rndc */ querylog yes;};
logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; print-category yes; print-severity yes; }; default.log:12-Nov-2020 22:16:58.021 query-errors: info: client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for
ws.linuxlighthouse.com/IN/AAAA
at ../../../bin/named/query.c:7270 default.log:12-Nov-2020 22:16:58.503 query-errors: info: client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for
ws.linuxlighthouse.com/IN/A
at ../../../bin/named/query.c:7270 default.log:12-Nov-2020 22:16:59.036 query-errors: info: client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for
ws.linuxlighthouse.com/IN/A
at ../../../bin/named/query.c:7270
Client 60.215.138.163 does not match allow-query, so it is refused.
channel security_file { severity debug 2; file "/var/log/named/security.log" versions 3 size 5m; print-time yes; print-category yes; print-severity yes; };security.log:12-Nov-2020 22:16:58.021 client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/AAAA/IN' denied security.log:12-Nov-2020 22:16:58.503 client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/A/IN' denied security.log:12-Nov-2020 22:16:59.036 client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/A/IN' denied
channel queries_file { file "/var/log/named/queries.log" versions 3 size 5m; severity debug 3; print-time yes; print-category yes; print-severity yes; };queries.log:12-Nov-2020 22:16:58.021 queries: info: client
@0x7f99e01bab90
60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN AAAA -E(0)DC (10.0.0.101) queries.log:12-Nov-2020 22:16:58.503 queries: info: client
@0x7f99e01bab90
60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN A -E(0)DC (10.0.0.101) queries.log:12-Nov-2020 22:16:59.036 queries: info: client
@0x7f99e01bab90
60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view:
*query:
ws.linuxlighthouse.com http://ws.linuxlighthouse.com IN A -E(0)DC (10.0.0.101)*
category default { default_file; }; category general { general_file; }; category database { database_file; }; category security { security_file; }; category config { config_file; }; category resolver { resolver_file; }; category xfer-in { xfer-in_file; }; category xfer-out { xfer-out_file; }; category notify { notify_file; }; category client { client_file; }; category unmatched { unmatched_file; }; category queries { queries_file; }; category network { network_file; }; category update { update_file; }; category dispatch { dispatch_file; }; category dnssec { dnssec_file; }; category lame-servers { lame-servers_file; };};
include "/etc/rndc.key";
controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; }; };
/* This view will contain zones you want to serve only to "internal"
clients
that connect via your directly attached LAN interfaces - "localnets" . */
view "internal-lan-view" { match-clients { internals; }; recursion yes;
zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; }; };
/* This view will contain zones you want to serve only to "external"
clients
that have addresses that are not match any above view: */
view "external-wan-view" { match-clients { any; }; recursion no;
zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-query { any; }; /* allow-transfer { slaves; }; */ };
zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; allow-query { any; }; };};
; Authoritative data for linuxlighthouse.com zone ; ; $ORIGIN linuxlighthouse.com. $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 86400 ) ; minimum ; ;jack.craig.aptos@gmail.com ; @ IN NS ws IN MX 10 mail IN A 108.220.213.121
ws IN A 108.220.213.121 www IN A 108.220.213.121 mail IN A 108.220.213.121
; cname later ;ws2 IN A 68.94.157.1 ;dns157r8.sbcglobal.net. IN A 68.94.157.8
; ; DNSSEC/CAA setup ; example.org. CAA 128 issue "letsencrypt.org"
; linuxlighthouse.com. CAA 128 issue "letsencrypt.org"
; $include "/var/named/linuxlighthouse.com.db"
@ IN A 10.0.0.1 ws IN A 10.0.0.101 www IN A 10.0.0.101 ws2 IN A 10.0.0.102
[jackc@ws ~$
-- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
On Fri, 2020-11-13 at 13:38 -0800, Jack Craig wrote:
current named.conf
options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // "Working" directory dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing";
listen-on port 53 { any; }; listen-on-v6 port 53 { any; }; allow-transfer { 108.220.213.120/29; }; forwarders { 8.8.8.8; 8.8.4.4; };
I found when I tried using forwarders, that all queries went to them, not just the ones that the server couldn't answer for itself.
controls {
inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };};
view "internal-lan-view" { match-clients { internals; };
allow-recursion { internals; }; allow-recursion-on { internals; }; zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; allow-query { internals; }; };};
Above, you've used "match-clients," but haven't defined what "internals" means (and I can't see "internals" listed as a predefined term in the BIND docs).
e.g. acl "internals" { localhost; 192.168/16; 10.0/16; };
NB: "acl" needs to be defined outside of the views clause.
I believe "localhost" and/or "localnets" are predefined terms that could be useful to you.
see: https://bind9.readthedocs.io/en/v9_16_6/reference.html
4.2.2. acl Statement Definition and Usage
The acl statement assigns a symbolic name to an address match list. It gets its name from a primary use of address match lists: Access Control Lists (ACLs).
The following ACLs are built-in:
"any" Matches all hosts.
"none" Matches no hosts.
"localhost" Matches the IPv4 and IPv6 addresses of all network interfaces on the system. When addresses are added or removed, the localhost ACL element is updated to reflect the changes.
"localnets" Matches any host on an IPv4 or IPv6 network for which the system has an interface. When addresses are added or removed, the localnets ACL element is updated to reflect the changes. Some systems do not provide a way to determine the prefix lengths of local IPv6 addresses; in such a case, localnets only matches the local IPv6 addresses, just like localhost.
(Their definition of localhost goes beyond the "localhost simply means 127.0.0.1" that we're used to with hostnames.)
view "external-wan-view" { match-clients { any; }; recursion no;
allow-query { any; }; allow-transfer { 108.220.213.120/29; }; zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; }; zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; };};
Since you've used "any" as a match, here, something else has to match it before this clause, else this clause will always match it.
i.e. Your internal rules have to be first.
On Fri, Nov 13, 2020 at 10:12 PM Tim via users < users@lists.fedoraproject.org> wrote:
On Fri, 2020-11-13 at 13:38 -0800, Jack Craig wrote:
current named.conf
options { // Put files that named is allowed to write in the data/
directory:
directory "/var/named"; // "Working"directory
dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing"; listen-on port 53 { any; }; listen-on-v6 port 53 { any; }; allow-transfer { 108.220.213.120/29; }; forwarders { 8.8.8.8; 8.8.4.4; };I found when I tried using forwarders, that all queries went to them, not just the ones that the server couldn't answer for itself.
controls {
inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };};
view "internal-lan-view" { match-clients { internals; };
allow-recursion { internals; }; allow-recursion-on { internals; }; zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; allow-query { internals; }; };};
Above, you've used "match-clients," but haven't defined what "internals" means (and I can't see "internals" listed as a predefined term in the BIND docs).
e.g. acl "internals" { localhost; 192.168/16; 10.0/16; };
NB: "acl" needs to be defined outside of the views clause.
I believe "localhost" and/or "localnets" are predefined terms that could be useful to you.
see: https://bind9.readthedocs.io/en/v9_16_6/reference.html
4.2.2. acl Statement Definition and Usage
The acl statement assigns a symbolic name to an address match list. It gets its name from a primary use of address match lists: Access Control Lists (ACLs).
The following ACLs are built-in:
"any" Matches all hosts.
"none" Matches no hosts.
"localhost" Matches the IPv4 and IPv6 addresses of all network interfaces on the system. When addresses are added or removed, the localhost ACL element is updated to reflect the changes.
"localnets" Matches any host on an IPv4 or IPv6 network for which the system has an interface. When addresses are added or removed, the localnets ACL element is updated to reflect the changes. Some systems do not provide a way to determine the prefix lengths of local IPv6 addresses; in such a case, localnets only matches the local IPv6 addresses, just like localhost.
(Their definition of localhost goes beyond the "localhost simply means 127.0.0.1" that we're used to with hostnames.)
view "external-wan-view" { match-clients { any; }; recursion no;
allow-query { any; }; allow-transfer { 108.220.213.120/29; }; zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; }; zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; };};
Since you've used "any" as a match, here, something else has to match it before this clause, else this clause will always match it.
i.e. Your internal rules have to be first.
apologiese for cllipping the file,...
*/* LinuxLightHouse named.conf BIND DNS server 'named' configuration file for the Red Hat BIND distribution. */acl internals { 10.0.0.0/24 http://10.0.0.0/24; 127.0.0.0/8 http://127.0.0.0/8;};*
options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // "Working" directory dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing";
listen-on port 53 { any; }; listen-on-v6 port 53 { any; };
allow-transfer { 108.220.213.120/29; };
allow-recursion { 10.0.0.0/24; };
/* DNSSEC related options. See information about keys ("Trusted keys", bellow) */ /* Enable serving of DNSSEC related data - enable on both authoritative and recursive servers DNSSEC aware servers */ dnssec-enable yes;
/* Enable DNSSEC validation on recursive servers */ dnssec-validation yes;
/* In Fedora we use /run/named instead of default /var/run/named so we have to configure paths properly. */ pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; managed-keys-directory "/var/named/dynamic";
/* In Fedora we use system-wide Crypto Policy */ /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config";
/* use querylog all the time rndc */ querylog yes; };
include "/etc/rndc.key";
controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; }; };
view "internal-lan-view" { match-clients { internals; };
allow-recursion { internals; }; allow-recursion-on { internals; }; allow-query { internals; };
zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; }; };
view "external-wan-view" { match-clients { any; }; match-destinations { any; }; recursion no;
allow-query { any; }; allow-transfer { 108.220.213.120/29; };
zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; };
zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; };14-Nov-2020 05:04:11.931 query-errors: info: client @0x7f52380dc520 ::1#47114 (linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/NS at ../../../bin/named/query.c:7270 14-Nov-2020 05:06:54.149 query-errors: info: client @0x7f52381c9760 137.226.113.35#18392 (linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/ANY at ../../../bin/named/query.c:7270 14-Nov-2020 05:07:16.323 query-errors: info: client @0x7f52381c9760 184.94.241.121#52528 (linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 14-Nov-2020 05:07:16.354 query-errors: info: client @0x7f52381c9760 184.94.241.121#10468 (linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 14-Nov-2020 05:07:16.520 query-errors: info: client @0x7f52381c9760 184.94.241.121#33732 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for ws.linuxlighthouse.com/IN/AAAA at ../../../bin/named/query.c:7270 14-Nov-2020 05:07:25.119 query-errors: info: client @0x7f52381c9760 184.94.241.121#11455 (www.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for www.linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 14-Nov-2020 05:03:32.658 general: info: managed-keys-zone/internal-lan-view: loaded serial 0 14-Nov-2020 05:03:32.658 general: info: managed-keys-zone/external-wan-view: loaded serial 0 14-Nov-2020 05:03:32.658 general: info: zone linuxlighthouse.com/IN/internal-lan-view: loaded serial 2020101601 14-Nov-2020 05:03:32.658 general: info: zone 213.220.108.in-addr.arpa/IN/external-wan-view: loaded serial 2020101601 14-Nov-2020 05:03:32.658 general: info: zone linuxlighthouse.com/IN/external-wan-view: loaded serial 2020101601 14-Nov-2020 05:03:32.658 general: notice: all zones loaded 14-Nov-2020 05:03:32.658 general: notice: running 14-Nov-2020 05:04:11.931 queries: info: client @0x7f52380dc520 ::1#47114 ( linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com IN NS +E(0)K (::1) 14-Nov-2020 05:06:54.149 queries: info: client @0x7f52381c9760 137.226.113.35#18392 (linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com IN ANY -E(0)D (10.0.0.101) 14-Nov-2020 05:07:16.323 queries: info: client @0x7f52381c9760 184.94.241.121#52528 (linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com IN A -E(0)D (10.0.0.101) 14-Nov-2020 05:07:16.354 queries: info: client @0x7f52381c9760 184.94.241.121#10468 (linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com IN A -E(0)D (10.0.0.101) 14-Nov-2020 05:07:16.520 queries: info: client @0x7f52381c9760 184.94.241.121#33732 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN AAAA -E(0)DC (10.0.0.101) 14-Nov-2020 05:07:25.119 queries: info: client @0x7f52381c9760 184.94.241.121#11455 (www.linuxlighthouse.com): view external-wan-view: query: www.linuxlighthouse.com IN A -E(0)D (10.0.0.101) 14-Nov-2020 05:04:11.931 client @0x7f52380dc520 ::1#47114 ( linuxlighthouse.com): view external-wan-view: query ' linuxlighthouse.com/NS/IN' denied 14-Nov-2020 05:06:54.149 client @0x7f52381c9760 137.226.113.35#18392 ( linuxlighthouse.com): view external-wan-view: query ' linuxlighthouse.com/ANY/IN' denied 14-Nov-2020 05:07:16.323 client @0x7f52381c9760 184.94.241.121#52528 ( linuxlighthouse.com): view external-wan-view: query ' linuxlighthouse.com/A/IN' denied 14-Nov-2020 05:07:16.354 client @0x7f52381c9760 184.94.241.121#10468 ( linuxlighthouse.com): view external-wan-view: query ' linuxlighthouse.com/A/IN' denied 14-Nov-2020 05:07:16.520 client @0x7f52381c9760 184.94.241.121#33732 ( ws.linuxlighthouse.com): view external-wan-view: query ' ws.linuxlighthouse.com/AAAA/IN' denied 14-Nov-2020 05:07:25.119 client @0x7f52381c9760 184.94.241.121#11455 ( www.linuxlighthouse.com): view external-wan-view: query ' www.linuxlighthouse.com/A/IN' denied
???
logging { channel default_debug { file "/var/log/named/named.run" versions 3 size 5m; ...
*bind.x86_64 :9.11.23-1.fc32 *
On Fri, Nov 13, 2020 at 11:13 PM Tim via users < users@lists.fedoraproject.org> wrote:
On Fri, 2020-11-13 at 13:38 -0800, Jack Craig wrote:
forwarders { 8.8.8.8; 8.8.4.4; };I found when I tried using forwarders, that all queries went to them, not just the ones that the server couldn't answer for itself.
That should only happen if the "forward only" option is used. That's how it worked when I used to run DNS for a medium-sized organization, and it's still documented that way in named.conf(5).
--Greg
Wait, what is BIND version you are trying to use?
http://linuxlighthouse.com should never show in a DNS, or I did not ever seen it in bind logs. What is exactly command used for the query? URL should not be there, only most recent development version should have support for DNS over HTTPS. I admit I have not tried it yet. For any current Fedora packages or COPR package, no URL with http should ever appear. It can do DNS only, 9.16 might be able to do DNS over TLS. But not HTTPS.
It should work with this: dig @localhost -t A linuxlighthouse.com
# For external view, use correct external IP for outside interface. dig @40.69.104.72 -b 40.69.104.72 -t A linuxlighthouse.com
Remember, only hostnames without URL prefix must be used in DNS queries.
Cheers, Petr
On 11/13/20 10:38 PM, Jack Craig wrote:
first, a hearty Thanks for your responses to date.
I have tried to apply the suggested changes, but it's not changed the initial behaviour. so i am still missing something...
additional suggestions. i am going to look at host, who,w hois, nslookup for more info, thx, jackc...
*default.log:13-Nov-2020 13:30:43.484 query-errors: info: client @0x7f98541abfc0 40.69.104.72#54502 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/A http://linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270default.log:13-Nov-2020 13:30:49.778 query-errors: info: client @0x7f98541abfc0 40.69.104.77#49493 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/A http://linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270*
*queries.log:13-Nov-2020 13:30:43.484 queries: info: client @0x7f98541abfc0 40.69.104.72#54502 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com http://linuxlighthouse.com IN A -E(0)D (10.0.0.101)queries.log:13-Nov-2020 13:30:49.778 queries: info: client @0x7f98541abfc0 40.69.104.77#49493 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query: linuxlighthouse.com http://linuxlighthouse.com IN A -E(0)D (10.0.0.101)*
*security.log:13-Nov-2020 13:30:43.484 client @0x7f98541abfc0 40.69.104.72#54502 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query 'linuxlighthouse.com/A/IN http://linuxlighthouse.com/A/IN' denied*
*security.log:13-Nov-2020 13:30:49.778 client @0x7f98541abfc0 40.69.104.77#49493 (linuxlighthouse.com http://linuxlighthouse.com): view external-wan-view: query 'linuxlighthouse.com/A/IN http://linuxlighthouse.com/A/IN' denied*
current named.conf
options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // "Working" directory dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing";
listen-on port 53 { any; }; listen-on-v6 port 53 { any; }; allow-transfer { 108.220.213.120/29; }; forwarders { 8.8.8.8; 8.8.4.4; }; /* DNSSEC related options. See information about keys ("Trustedkeys", bellow) */ /* Enable serving of DNSSEC related data - enable on both authoritative and recursive servers DNSSEC aware servers */ dnssec-enable yes;
/* Enable DNSSEC validation on recursive servers */ dnssec-validation yes; /* In Fedora we use /run/named instead of default /var/run/named so we have to configure paths properly. */ pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; managed-keys-directory "/var/named/dynamic"; /* In Fedora we use system-wide Crypto Policy */ /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config"; /* use querylog all the time rndc */ querylog yes;};
controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; }; };
view "internal-lan-view" { match-clients { internals; };
allow-recursion { internals; }; allow-recursion-on { internals; }; zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; allow-query { internals; }; };};
view "external-wan-view" { match-clients { any; }; recursion no;
allow-query { any; }; allow-transfer { 108.220.213.120/29; }; zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; }; zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; };};
On Fri, Nov 13, 2020 at 6:10 AM Petr Menšík pemensik@redhat.com wrote:
Hi Jack,
On 11/13/20 8:02 AM, Jack Craig wrote:
hi all, any dns pros in the house??
i am trying to debug a split view dns. i am using F32 & bind9 where i have internal & external views.
internal network 10.0.0.0/24, external 108.220.213.120/29
what i think i am seeing is a refusal of query, but Why??
where can i find a query_log print-severity definition?
dig shows, ...
dig ws.linuxlighthouse.com ns
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> ws.linuxlighthouse.com ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45484 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ws.linuxlighthouse.com. IN NS
;; Query time: 355 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Thu Nov 12 22:53:45 PST 2020 ;; MSG SIZE rcvd: 51
dig 108.220.213.121
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> 108.220.213.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46338 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;108.220.213.121. IN A
;; ANSWER SECTION: 108.220.213.121. 0 IN A 108.220.213.121
;; Query time: 1 msec ;; SERVER: 10.0.0.1#53(10.0.0.1) ;; WHEN: Thu Nov 12 22:54:52 PST 2020 ;; MSG SIZE rcvd: 60
suggestions?
tia, jackc...
my named.conf
/* top of file */
acl slaves { 108.220.213.122; };
acl internals { 10.0.0.0/24; 127.0.0.0/8; };
/* 108.220.213.120/29; */
options { // Put files that named is allowed to write in the data/ directory: directory "/var/named"; // "Working" directory dump-file "data/cache_dump.db"; statistics-file "data/named_stats.txt"; memstatistics-file "data/named_mem_stats.txt"; secroots-file "data/named.secroots"; recursing-file "data/named.recursing";
listen-on port 53 { localhost; };
Localhost usually has only 127.0.0.0/8 and ::1 addresses. Without both internal address and external or any; Outside IPv4 packet would never reach bind.
listen-on-v6 port 53 { any; };
allow-query { internals; };Move this to views. allow-query includes recursive and non-recursive queries. Kind of firewall equivalent. Just let it inside or not.
allow-query-cache { any; };
Unless you override this in view, this would make your (internal) cache open to outside world. It it would act authoritative for outside and recursive for inside clients, I would recommend removing these two and using just allow-recursion { internals; }; allow-recursion-on { internals };
in specific view.
allow-transfer { 108.220.213.120/29; };It is better to use keys to authenticate. Check tsig-keygen(8) manual page.
recursion yes;
Remove this one ^^. Instead, configure it only per view
forwarders { 8.8.8.8; 8.8.4.4; };/* DNSSEC related options. See information about keys ("Trusted keys", bellow) */
/* Enable serving of DNSSEC related data - enable on both authoritative and recursive servers DNSSEC aware servers */ dnssec-enable yes;
/* Enable DNSSEC validation on recursive servers */ dnssec-validation yes;
/* In Fedora we use /run/named instead of default /var/run/named so we have to configure paths properly. */ pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key";
managed-keys-directory "/var/named/dynamic";
/* In Fedora we use system-wide Crypto Policy */ /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */ include "/etc/crypto-policies/back-ends/bind.config"; /* use querylog all the time rndc */ querylog yes;};
logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; print-category yes; print-severity yes; }; default.log:12-Nov-2020 22:16:58.021 query-errors: info: client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for
ws.linuxlighthouse.com/IN/AAAA
at ../../../bin/named/query.c:7270 default.log:12-Nov-2020 22:16:58.503 query-errors: info: client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for
ws.linuxlighthouse.com/IN/A
at ../../../bin/named/query.c:7270 default.log:12-Nov-2020 22:16:59.036 query-errors: info: client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for
ws.linuxlighthouse.com/IN/A
at ../../../bin/named/query.c:7270
Client 60.215.138.163 does not match allow-query, so it is refused.
channel security_file { severity debug 2; file "/var/log/named/security.log" versions 3 size 5m; print-time yes; print-category yes; print-severity yes; };security.log:12-Nov-2020 22:16:58.021 client @0x7f99e01bab90 60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/AAAA/IN' denied security.log:12-Nov-2020 22:16:58.503 client @0x7f99e01bab90 60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/A/IN' denied security.log:12-Nov-2020 22:16:59.036 client @0x7f99e01bab90 60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view: query 'ws.linuxlighthouse.com/A/IN' denied
channel queries_file { file "/var/log/named/queries.log" versions 3 size 5m; severity debug 3; print-time yes; print-category yes; print-severity yes; };queries.log:12-Nov-2020 22:16:58.021 queries: info: client
@0x7f99e01bab90
60.215.138.163#62853 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN AAAA -E(0)DC (10.0.0.101) queries.log:12-Nov-2020 22:16:58.503 queries: info: client
@0x7f99e01bab90
60.215.138.163#48181 (ws.linuxlighthouse.com): view external-wan-view: query: ws.linuxlighthouse.com IN A -E(0)DC (10.0.0.101) queries.log:12-Nov-2020 22:16:59.036 queries: info: client
@0x7f99e01bab90
60.215.138.163#52399 (ws.linuxlighthouse.com): view external-wan-view:
*query:
ws.linuxlighthouse.com http://ws.linuxlighthouse.com IN A -E(0)DC (10.0.0.101)*
category default { default_file; }; category general { general_file; }; category database { database_file; }; category security { security_file; }; category config { config_file; }; category resolver { resolver_file; }; category xfer-in { xfer-in_file; }; category xfer-out { xfer-out_file; }; category notify { notify_file; }; category client { client_file; }; category unmatched { unmatched_file; }; category queries { queries_file; }; category network { network_file; }; category update { update_file; }; category dispatch { dispatch_file; }; category dnssec { dnssec_file; }; category lame-servers { lame-servers_file; };};
include "/etc/rndc.key";
controls { inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; }; };
/* This view will contain zones you want to serve only to "internal"
clients
that connect via your directly attached LAN interfaces - "localnets" . */
view "internal-lan-view" { match-clients { internals; }; recursion yes;
zone "linuxlighthouse.com" { type master; file "/var/named/internal.db"; }; };
/* This view will contain zones you want to serve only to "external"
clients
that have addresses that are not match any above view: */
view "external-wan-view" { match-clients { any; }; recursion no;
zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-query { any; }; /* allow-transfer { slaves; }; */ };
zone "213.220.108.in-addr.arpa" { type master; file "/var/named/213.220.108.in-addr.arpa"; allow-query { any; }; };};
; Authoritative data for linuxlighthouse.com zone ; ; $ORIGIN linuxlighthouse.com. $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 86400 ) ; minimum ; ;jack.craig.aptos@gmail.com ; @ IN NS ws IN MX 10 mail IN A 108.220.213.121
ws IN A 108.220.213.121 www IN A 108.220.213.121 mail IN A 108.220.213.121
; cname later ;ws2 IN A 68.94.157.1 ;dns157r8.sbcglobal.net. IN A 68.94.157.8
; ; DNSSEC/CAA setup ; example.org. CAA 128 issue "letsencrypt.org"
; linuxlighthouse.com. CAA 128 issue "letsencrypt.org"
; $include "/var/named/linuxlighthouse.com.db"
@ IN A 10.0.0.1 ws IN A 10.0.0.101 www IN A 10.0.0.101 ws2 IN A 10.0.0.102
[jackc@ws ~$
-- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
On Sat, 2020-11-14 at 14:16 +0100, Petr Menšík wrote:
Wait, what is BIND version you are trying to use?
http://linuxlighthouse.com should never show in a DNS, or I did not ever seen it in bind logs. What is exactly command used for the query? URL should not be there, only most recent development version should have support for DNS over HTTPS. I admit I have not tried it yet. For any current Fedora packages or COPR package, no URL with http should ever appear. It can do DNS only, 9.16 might be able to do DNS over TLS. But not HTTPS.
I didn't see "http://" in his post. It might be an artefact of him sending an HTML email.
well, if its not my config file it must be in these ...
internal.db linuxlighthouse.com.db 213.220.108.in-addr.arpa ; $include "/var/named/linuxlighthouse.com.db"
@ IN A 10.0.0.1 ws IN A 10.0.0.101 www IN A 10.0.0.101 ws2 IN A 10.0.0.102 ; Authoritative data for linuxlighthouse.com zone ; $ORIGIN ws.linuxlighthouse.com. $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 86400 ) ; minimum ; ;jack.craig.aptos@gmail.com ; @ IN NS ws IN MX 10 mail IN A 108.220.213.121
ws IN A 108.220.213.121 www IN A 108.220.213.121 mail IN A 108.220.213.121
; cname later ;ws2 IN A 68.94.157.1 ;dns157r8.sbcglobal.net. IN A 68.94.157.8
; ; DNSSEC/CAA setup ; example.org. CAA 128 issue "letsencrypt.org"
; linuxlighthouse.com. CAA 128 issue "letsencrypt.org" ; Authoritative data for linuxlighthouse.com reverse zone ; $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum
@ IN NS ws.linuxlighthouse.com.
121 IN PTR ws.linuxlighthouse.com. 122 IN PTR ws2.linuxlighthouse.com.
gives me zones like,...
zone: /var/named/linuxlighthouse.com (external)
linuxlighthouse.com. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 linuxlighthouse.com. 86400 IN NS ws.linuxlighthouse.com. linuxlighthouse.com. 86400 IN A 108.220.213.121 linuxlighthouse.com. 86400 IN MX 10 mail.linuxlighthouse.com. mail.linuxlighthouse.com. 86400 IN A 108.220.213.122 ws.linuxlighthouse.com. 86400 IN A 108.220.213.121 www.linuxlighthouse.com. 86400 IN A 108.220.213.121
zone: /var/named/213.220.108.in-addr.arpa (external reverse)
213.220.108.in-addr.arpa. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 10800 213.220.108.in-addr.arpa. 86400 IN NS ws.linuxlighthouse.com. 121.213.220.108.in-addr.arpa. 86400 IN PTR ws.linuxlighthouse.com. 122.213.220.108.in-addr.arpa. 86400 IN PTR ws2.linuxlighthouse.com.
zone: /var/named/internal
internal. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 internal. 86400 IN NS ws.internal. internal. 86400 IN A 108.220.213.121 internal. 86400 IN A 10.0.0.1 internal. 86400 IN MX 10 mail.internal. mail.internal. 86400 IN A 108.220.213.122 ws.internal. 86400 IN A 108.220.213.121 ws.internal. 86400 IN A 10.0.0.101 ws2.internal. 86400 IN A 10.0.0.102 www.internal. 86400 IN A 108.220.213.121 www.internal. 86400 IN A 10.0.0.101
zone: /var/named/0.0.10.in-addr.arpa (internal reverse)
0.0.10.in-addr.arpa. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 10800 0.0.10.in-addr.arpa. 86400 IN NS ws.linuxlighthouse.com. 0.0.10.in-addr.arpa. 86400 IN A 10.0.0.101 101.0.0.10.in-addr.arpa. 86400 IN PTR ws.linuxlighthouse.com. 102.0.0.10.in-addr.arpa. 86400 IN PTR ws2.linuxlighthouse.com.
On Sat, Nov 14, 2020 at 6:24 AM Jack Craig jack.craig.aptos@gmail.com wrote:
well, if its not my config file it must be in these ...
internal.db linuxlighthouse.com.db 213.220.108.in-addr.arpa ; $include "/var/named/linuxlighthouse.com.db"
@ IN A 10.0.0.1 ws IN A 10.0.0.101 www IN A 10.0.0.101 ws2 IN A 10.0.0.102 ; Authoritative data for linuxlighthouse.com zone ; $ORIGIN ws.linuxlighthouse.com. $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 86400 ) ; minimum ; ;jack.craig.aptos@gmail.com ; @ IN NS ws IN MX 10 mail IN A 108.220.213.121
ws IN A 108.220.213.121 www IN A 108.220.213.121 mail IN A 108.220.213.121
; cname later ;ws2 IN A 68.94.157.1 ;dns157r8.sbcglobal.net. IN A 68.94.157.8
; ; DNSSEC/CAA setup ; example.org. CAA 128 issue "letsencrypt.org"
; linuxlighthouse.com. CAA 128 issue "letsencrypt.org" ; Authoritative data for linuxlighthouse.com reverse zone ; $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum
@ IN NS ws.linuxlighthouse.com.
121 IN PTR ws.linuxlighthouse.com. 122 IN PTR ws2.linuxlighthouse.com.
this part looked ok to me, but i am not sure.
On Sat, Nov 14, 2020 at 6:32 AM Jack Craig jack.craig.aptos@gmail.com wrote:
gives me zones like,...
zone: /var/named/linuxlighthouse.com (external)
linuxlighthouse.com. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 linuxlighthouse.com. 86400 IN NS ws.linuxlighthouse.com. linuxlighthouse.com. 86400 IN A 108.220.213.121 linuxlighthouse.com. 86400 IN MX 10 mail.linuxlighthouse.com. mail.linuxlighthouse.com. 86400 IN A 108.220.213.122 ws.linuxlighthouse.com. 86400 IN A 108.220.213.121 www.linuxlighthouse.com. 86400 IN A 108.220.213.121
zone: /var/named/213.220.108.in-addr.arpa (external reverse)
213.220.108.in-addr.arpa. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 10800 213.220.108.in-addr.arpa. 86400 IN NS ws.linuxlighthouse.com. 121.213.220.108.in-addr.arpa. 86400 IN PTR ws.linuxlighthouse.com. 122.213.220.108.in-addr.arpa. 86400 IN PTR ws2.linuxlighthouse.com.
zone: /var/named/internal
internal. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 internal. 86400 IN NS ws.internal. internal. 86400 IN A 108.220.213.121 internal. 86400 IN A 10.0.0.1 internal. 86400 IN MX 10 mail.internal. mail.internal. 86400 IN A 108.220.213.122 ws.internal. 86400 IN A 108.220.213.121 ws.internal. 86400 IN A 10.0.0.101 ws2.internal. 86400 IN A 10.0.0.102 www.internal. 86400 IN A 108.220.213.121 www.internal. 86400 IN A 10.0.0.101
zone: /var/named/0.0.10.in-addr.arpa (internal reverse) *Not used...*
0.0.10.in-addr.arpa. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 10800 0.0.10.in-addr.arpa. 86400 IN NS ws.linuxlighthouse.com. 0.0.10.in-addr.arpa. 86400 IN A 10.0.0.101 101.0.0.10.in-addr.arpa. 86400 IN PTR ws.linuxlighthouse.com. 102.0.0.10.in-addr.arpa. 86400 IN PTR ws2.linuxlighthouse.com.
On Sat, Nov 14, 2020 at 11:33 AM Jack Craig jack.craig.aptos@gmail.com wrote:
this part looked ok to me, but i am not sure.
now seeing higher throughput, but still got...
14-Nov-2020 11:28:20.993 query-errors: info: client @0x7fc8601c9760 52.183.97.231#63450 (linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 14-Nov-2020 11:28:21.030 query-errors: info: client @0x7fc8601c9760 20.190.57.96#61806 (www.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for www.linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 14-Nov-2020 11:28:21.047 query-errors: info: client @0x7fc8601c9760 51.143.102.160#49893 (www.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for www.linuxlighthouse.com/IN/NS at ../../../bin/named/query.c:7270
how can i see/test a query's processing between default.log & security.log ? i can see the query, if i could see why it's failing, i'd query this list less. ;)
* www.linuxlighthouse.com/IN/NS http://www.linuxlighthouse.com/IN/NS at ../../../bin/named/query.c:7270*
*i looked at the query.c @7270 but was unable to gleen any useful insight.*
*WRT networking, my block of static ip's is from att.com http://att.com*
*i have cascaded routers from att's pace unit to a netgear night hawk that does* * port fwding for 53, 80 443 to the 10.0.0.101 sever.* *i use the firewall on the att rtr limiting to the above ports to pass through.*
*the NH logs show connects to 53,80, & 443*
*i also cranked debug to 10 in named logging, but so far,...*
*lastly, as F32 comes w/iptables, i migrated to nftables.*
is there an easier way to verify a port access to internal host besides wireshark & tcpdump?
On Sat, Nov 14, 2020 at 11:51 AM Jack Craig jack.craig.aptos@gmail.com wrote:
On Sat, Nov 14, 2020 at 11:33 AM Jack Craig jack.craig.aptos@gmail.com wrote:
this part looked ok to me, but i am not sure.
now seeing higher throughput, but still got...
14-Nov-2020 11:28:20.993 query-errors: info: client @0x7fc8601c9760 52.183.97.231#63450 (linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 14-Nov-2020 11:28:21.030 query-errors: info: client @0x7fc8601c9760 20.190.57.96#61806 (www.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for www.linuxlighthouse.com/IN/A at ../../../bin/named/query.c:7270 14-Nov-2020 11:28:21.047 query-errors: info: client @0x7fc8601c9760 51.143.102.160#49893 (www.linuxlighthouse.com): view external-wan-view: query failed (REFUSED) for www.linuxlighthouse.com/IN/NS at ../../../bin/named/query.c:7270
how can i see/test a query's processing between default.log & security.log ? i can see the query, if i could see why it's failing, i'd query this list less. ;)
- www.linuxlighthouse.com/IN/NS http://www.linuxlighthouse.com/IN/NS at
../../../bin/named/query.c:7270*
*i looked at the query.c @7270 but was unable to gleen any useful insight.*
*WRT networking, my block of static ip's is from att.com http://att.com*
*i have cascaded routers from att's pace unit to a netgear night hawk that does*
- port fwding for 53, 80 443 to the 10.0.0.101 sever.*
*i use the firewall on the att rtr limiting to the above ports to pass through.*
*the NH logs show connects to 53,80, & 443*
*i also cranked debug to 10 in named logging, but so far,...*
*lastly, as F32 comes w/iptables, i migrated to nftables.*
On Sat, 2020-11-14 at 11:33 -0800, Jack Craig wrote:
zone: /var/named/internal
internal. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 internal. 86400 IN NS ws.internal. internal. 86400 IN A 108.220.213.121 internal. 86400 IN A 10.0.0.1 internal. 86400 IN MX 10 mail.internal. mail.internal. 86400 IN A 108.220.213.122 ws.internal. 86400 IN A 108.220.213.121 ws.internal. 86400 IN A 10.0.0.101 ws2.internal. 86400 IN A 10.0.0.102 www.internal. 86400 IN A 108.220.213.121 www.internal. 86400 IN A 10.0.0.101
You have internal and external IPs in your internal zone? And two answers for the same domain names.
i want to thank all the wizards that guided me toward a working dns.
i have struggled with this setup for weeks now; on to https & dnssec.
again, Thank You Very Much!!
On Sat, Nov 14, 2020 at 12:19 PM Tim via users < users@lists.fedoraproject.org> wrote:
On Sat, 2020-11-14 at 11:33 -0800, Jack Craig wrote:
zone: /var/named/internal
internal. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 internal. 86400 IN NS ws.internal. internal. 86400 IN A 108.220.213.121 internal. 86400 IN A 10.0.0.1 internal. 86400 IN MX 10 mail.internal. mail.internal. 86400 IN A 108.220.213.122 ws.internal. 86400 IN A 108.220.213.121 ws.internal. 86400 IN A 10.0.0.101 ws2.internal. 86400 IN A 10.0.0.102 www.internal. 86400 IN A 108.220.213.121 www.internal. 86400 IN A 10.0.0.101
You have internal and external IPs in your internal zone? And two answers for the same domain names.
--
uname -rsvp Linux 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Sat, 2020-11-14 at 11:33 -0800, Jack Craig wrote:
zone: /var/named/internal
internal. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 internal. 86400 IN NS ws.internal. internal. 86400 IN A 108.220.213.121 internal. 86400 IN A 10.0.0.1 internal. 86400 IN MX 10 mail.internal. mail.internal. 86400 IN A 108.220.213.122 ws.internal. 86400 IN A 108.220.213.121 ws.internal. 86400 IN A 10.0.0.101 ws2.internal. 86400 IN A 10.0.0.102 www.internal. 86400 IN A 108.220.213.121 www.internal. 86400 IN A 10.0.0.101
Also, what names do you want resolved for internal searches?
If you put a dot at the end of the name (mail.internal. etc), that's the whole domain name, it's not going to use it as a hostname suffixed with your domain name. Without a dot, they'll be prefix subdomains.
e.g. For an example.com zone file, an entry like this:
www A 192.168.1.2
will answer queries for: "www.example.com"
But, an entry like this:
www. A 192.168.1.2
would be an answer for a query about: "www"
At least, that's how BIND9 works on my computers. Though I have read that it can handle different kinds of record files, I haven't tried them out.
Here's an entire local network domain record on my system:
$ORIGIN . $TTL 86400 ; 1 day example.lan IN SOA ns.example.lan hostmaster.example.lan ( 359 ; serial 300 ; refresh (5 minutes) 900 ; retry (15 minutes) 3600 ; expire (1 hour) 1800 ; minimum (30 minutes) ) NS ns.example.lan. A 192.168.1.1 MX 1 mail.example.lan. $ORIGIN example.lan. mail A 192.168.1.1 ns A 192.168.1.1 web CNAME www www A 192.168.1.1
Taking that all in line by line.
* This is the top-level record for this domain (dot origin) * With a 1 day time-to-live for record data. * It's the start of authority record (master records) for an example.lan domain name. * Records held at ns.example.lan * Admin contact is hostmaster@example.lan * The serial number is 359 (be sure to increment it any time you change any DNS record data). * Check for updated records every 5 minutes (this is a LAN with dynamic IPs, so short is okay, here). * If the master server is unresponsive, wait for 15 minutes before trying again (keep using your previously cached data). I haven't optimised this setting. * Discard any unrefreshed cached data after 1 hour. * Other DNS servers should cache this data for at least 30 minutes, even if they've not been able to refresh it. Yes, I know it's different from the 1 day TTL, I'd been trying to see which figures were obeyed, but I don't remember my test results from all those years ago. * The domain's NS server is ns.example.lan (note the trailing dot, meaning this is the end of this domain name, it's not a suffix to add example.lan to the end of it). Theoretically, I could have just written ns by itself, with no dot at the end, and the domain name would be appended to it. * The example.lan domain is at 192.168.1.1 * Its priority 1 mail exchanger is mail.example.lan (again, note the trailing dot) * The following records are subdomains of example.lan (the probably redundant origin line). * The mail subdomain (mail.example.lan) is at 192.168.1.1 * The ns subdomain (ns.example.lan) is at 192.168.1.1 * A web subdomain (web.example.lan) is an alternative for the www subdomain * The www subdomain (www.example.lan) is at 192.168.1.1
i am still working to take all this in, Thank You for this time/wisdom...
On Sat, Nov 14, 2020 at 9:12 PM Tim via users users@lists.fedoraproject.org wrote:
On Sat, 2020-11-14 at 11:33 -0800, Jack Craig wrote:
zone: /var/named/internal
internal. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 internal. 86400 IN NS ws.internal. internal. 86400 IN A 108.220.213.121 internal. 86400 IN A 10.0.0.1 internal. 86400 IN MX 10 mail.internal. mail.internal. 86400 IN A 108.220.213.122 ws.internal. 86400 IN A 108.220.213.121 ws.internal. 86400 IN A 10.0.0.101 ws2.internal. 86400 IN A 10.0.0.102 www.internal. 86400 IN A 108.220.213.121 www.internal. 86400 IN A 10.0.0.101
Also, what names do you want resolved for internal searches?
If you put a dot at the end of the name (mail.internal. etc), that's the whole domain name, it's not going to use it as a hostname suffixed with your domain name. Without a dot, they'll be prefix subdomains.
e.g. For an example.com zone file, an entry like this:
www A 192.168.1.2
will answer queries for: "www.example.com"
But, an entry like this:
www. A 192.168.1.2
would be an answer for a query about: "www"
At least, that's how BIND9 works on my computers. Though I have read that it can handle different kinds of record files, I haven't tried them out.
Here's an entire local network domain record on my system:
$ORIGIN . $TTL 86400 ; 1 day example.lan IN SOA ns.example.lan hostmaster.example.lan ( 359 ; serial 300 ; refresh (5 minutes) 900 ; retry (15 minutes) 3600 ; expire (1 hour) 1800 ; minimum (30 minutes) ) NS ns.example.lan. A 192.168.1.1 MX 1 mail.example.lan. $ORIGIN example.lan. mail A 192.168.1.1 ns A 192.168.1.1 web CNAME www www A 192.168.1.1
Taking that all in line by line.
- This is the top-level record for this domain (dot origin)
- With a 1 day time-to-live for record data.
- It's the start of authority record (master records) for an example.lan domain name.
- Records held at ns.example.lan
- Admin contact is hostmaster@example.lan
- The serial number is 359 (be sure to increment it any time you change any DNS record data).
- Check for updated records every 5 minutes (this is a LAN with dynamic IPs, so short is okay, here).
- If the master server is unresponsive, wait for 15 minutes before trying again (keep using your previously cached data). I haven't optimised this setting.
- Discard any unrefreshed cached data after 1 hour.
- Other DNS servers should cache this data for at least 30 minutes, even if they've not been able to refresh it. Yes, I know it's different from the 1 day TTL, I'd been trying to see which figures were obeyed, but I don't remember my test results from all those years ago.
- The domain's NS server is ns.example.lan (note the trailing dot, meaning this is the end of this domain name, it's not a suffix to add example.lan to the end of it). Theoretically, I could have just written ns by itself, with no dot at the end, and the domain name would be appended to it.
- The example.lan domain is at 192.168.1.1
- Its priority 1 mail exchanger is mail.example.lan (again, note the trailing dot)
- The following records are subdomains of example.lan (the probably redundant origin line).
- The mail subdomain (mail.example.lan) is at 192.168.1.1
- The ns subdomain (ns.example.lan) is at 192.168.1.1
- A web subdomain (web.example.lan) is an alternative for the www subdomain
- The www subdomain (www.example.lan) is at 192.168.1.1
--
uname -rsvp Linux 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Sat, Nov 14, 2020 at 9:12 PM Tim via users users@lists.fedoraproject.org wrote:
On Sat, 2020-11-14 at 11:33 -0800, Jack Craig wrote:
zone: /var/named/internal
internal. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400 internal. 86400 IN NS ws.internal. internal. 86400 IN A 108.220.213.121 internal. 86400 IN A 10.0.0.1 internal. 86400 IN MX 10 mail.internal. mail.internal. 86400 IN A 108.220.213.122 ws.internal. 86400 IN A 108.220.213.121 ws.internal. 86400 IN A 10.0.0.101 ws2.internal. 86400 IN A 10.0.0.102 www.internal. 86400 IN A 108.220.213.121 www.internal. 86400 IN A 10.0.0.101
Also, what names do you want resolved for internal searches?
i have about half dpzenn 10.0.0. ip's for internal.
your below has resulted na god external.view, but my internal.db keeps giving out of zone errors. do you have input for the internal view as you did for external view? what am i missing?
tia, ...
*external view...*
Authoritative data for linuxlighthouse.com zone ; $ORIGIN . $TTL 86400 linuxlighthouse.com IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 86400 ; minimum ) NS ws.linuxlighthouse.com. A 108.220.213.121
$ORIGIN linuxlighthouse.com.
ws A 108.220.213.121 www A 108.220.213.121
*internal view*
~ ; Authoritative data for internal-lan-view zone ; $ORIGIN linuxlighthouse.com. $TTL 86400 @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2020101601 ; serial 1D ; refresh 1H ; retry 1W ; expire 86400 ; minimum )
IN NS ws.linuxlighthouse.com. ws IN A 10.0.0.101 www IN A 10.0.0.101 ws2 IN A 10.0.0.102 ;printer IN A 10.0.0.108
If you put a dot at the end of the name (mail.internal. etc), that's the whole domain name, it's not going to use it as a hostname suffixed with your domain name. Without a dot, they'll be prefix subdomains.
e.g. For an example.com zone file, an entry like this:
www A 192.168.1.2
will answer queries for: "www.example.com"
But, an entry like this:
www. A 192.168.1.2
would be an answer for a query about: "www"
At least, that's how BIND9 works on my computers. Though I have read that it can handle different kinds of record files, I haven't tried them out.
Here's an entire local network domain record on my system:
$ORIGIN . $TTL 86400 ; 1 day example.lan IN SOA ns.example.lan hostmaster.example.lan ( 359 ; serial 300 ; refresh (5 minutes) 900 ; retry (15 minutes) 3600 ; expire (1 hour) 1800 ; minimum (30 minutes) ) NS ns.example.lan. A 192.168.1.1 MX 1 mail.example.lan. $ORIGIN example.lan. mail A 192.168.1.1 ns A 192.168.1.1 web CNAME www www A 192.168.1.1
Taking that all in line by line.
- This is the top-level record for this domain (dot origin)
- With a 1 day time-to-live for record data.
- It's the start of authority record (master records) for an example.lan domain name.
- Records held at ns.example.lan
- Admin contact is hostmaster@example.lan
- The serial number is 359 (be sure to increment it any time you change any DNS record data).
- Check for updated records every 5 minutes (this is a LAN with dynamic IPs, so short is okay, here).
- If the master server is unresponsive, wait for 15 minutes before trying again (keep using your previously cached data). I haven't optimised this setting.
- Discard any unrefreshed cached data after 1 hour.
- Other DNS servers should cache this data for at least 30 minutes, even if they've not been able to refresh it. Yes, I know it's different from the 1 day TTL, I'd been trying to see which figures were obeyed, but I don't remember my test results from all those years ago.
- The domain's NS server is ns.example.lan (note the trailing dot, meaning this is the end of this domain name, it's not a suffix to add example.lan to the end of it). Theoretically, I could have just written ns by itself, with no dot at the end, and the domain name would be appended to it.
- The example.lan domain is at 192.168.1.1
- Its priority 1 mail exchanger is mail.example.lan (again, note the trailing dot)
- The following records are subdomains of example.lan (the probably redundant origin line).
- The mail subdomain (mail.example.lan) is at 192.168.1.1
- The ns subdomain (ns.example.lan) is at 192.168.1.1
- A web subdomain (web.example.lan) is an alternative for the www subdomain
- The www subdomain (www.example.lan) is at 192.168.1.1
--
uname -rsvp Linux 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Thu, 2020-11-19 at 11:15 -0800, Jack Craig wrote:
my internal.db keeps giving out of zone errors. do you have input for the internal view as you did for external view? what am i missing?
Asking the obvious questions:
Are you restarting the named service after you've made changes to configuration and zone record files?
You should be increasing the serial numbers any time you change anything in their zone files. Although you could expect things to read current zone files every time you directly query your server, not changing the serial number does indicate that there's no need to purge previously cached results.
When you're doing tests of internal and external views, are you making the request from internal IPs and external IPs where appropriate? You need to be careful when making queries from a machine which has internal and external addresses on its ports.
On Thu, 2020-11-19 at 11:15 -0800, Jack Craig wrote:
your below has resulted na god external.view, but my internal.db keeps giving out of zone errors. do you have input for the internal view as you did for external view? what am i missing?
I've done the following tests on my name server:
I've inserted some acls into the named.conf file, the middle two are the hostnames and IPs of some PCs on the LAN, the last is the original "everyone on my LAN" declaration:
acl "itself" { 127.0.0.1; };
acl "rocky" { 192.168.1.1; };
acl "fluffy" { 192.168.1.12; };
acl lan { 192.168/16; 127.0.0.1; };
And inserted some views into the named.conf file before all the other zone files:
view itself { match-clients { itself; }; zone "viewtest" { type master; file "viewtest.itself.zone"; }; };
view rocky { match-clients { rocky; }; zone "viewtest" { type master; file "viewtest.rocky.zone"; }; };
view fluffy { match-clients { fluffy; }; zone "viewtest" { type master; file "viewtest.fluffy.zone"; }; };
view lan { match-clients { any; }; zone "viewtest" { type master; file "viewtest.lan.zone"; };
// the rest of my original zone files are here
};
With the last entry being a fall-back with my pre-existing zone records.
And created those zone files thus:
viewtest.itself.zone file:
$ORIGIN . $TTL 86400 ; 1 day viewtest IN SOA viewtest. hostmaster.viewtest ( 42 ; serial 300 ; refresh (5 minutes) 900 ; retry (15 minutes) 3600 ; expire (1 hour) 1800 ; minimum (30 minutes) ) NS ns.viewtest. A 192.168.1.1 MX 1 mail.viewtest. $ORIGIN viewtest. ns A 192.168.1.1 www A 127.0.0.1
viewtest.rocky.zone file:
$ORIGIN . $TTL 86400 ; 1 day viewtest IN SOA viewtest. hostmaster.viewtest ( 42 ; serial 300 ; refresh (5 minutes) 900 ; retry (15 minutes) 3600 ; expire (1 hour) 1800 ; minimum (30 minutes) ) NS ns.viewtest. A 192.168.1.1 MX 1 mail.viewtest. $ORIGIN viewtest. ns A 192.168.1.1 www A 192.168.1.1
the viewtest.fluffy.zone file:
$ORIGIN . $TTL 86400 ; 1 day viewtest IN SOA viewtest. hostmaster.viewtest ( 42 ; serial 300 ; refresh (5 minutes) 900 ; retry (15 minutes) 3600 ; expire (1 hour) 1800 ; minimum (30 minutes) ) NS ns.viewtest. A 192.168.1.1 MX 1 mail.viewtest. $ORIGIN viewtest. ns A 192.168.1.1 www A 192.168.1.12
the viewtest.lan.zone file:
$ORIGIN . $TTL 86400 ; 1 day viewtest IN SOA viewtest. hostmaster.viewtest ( 42 ; serial 300 ; refresh (5 minutes) 900 ; retry (15 minutes) 3600 ; expire (1 hour) 1800 ; minimum (30 minutes) ) NS ns.viewtest. A 192.168.1.1 MX 1 mail.viewtest. $ORIGIN viewtest. ns A 192.168.1.1 www A 192.168.1.112
In those zone files, I've set the www record to different IPs for each record, but left everything else the same.
When I do a "dig www.viewtest" command on the rocky PC (so called for being a wobbly case), I get the expected result of 127.0.0.1. The nameserver is running on that machine, and the command line comes from localhost rather than its network address.
When I do a "dig www.viewtest @192.168.1.1" command on the rocky PC, I get the expected result of 192.168.1.1. This time I've told dig to query a specific address, and it's bypassing localhost.
When I do a "dig www.viewtest" command on the fluffy PC (so called for the box being full of fluff when I acquired it - yes I like obvious names), I get the expected result of 192.168.1.12.
When I do a "dig www.viewtest" command on another PC that doesn't have a specific ACL, I get the expected fallback 192.168.1.112 address.
So, ACL and VIEW declarations work as expected here (specific matches get their special answers, everyone else gets the fallback). I'll admit that the server is running CentOS 7, and the client is Fedora 32, but the installation of BIND is bind-9.11.4-26.P2.el7_9.2.x86_64, and I'd expect Fedora's to work the same.
Things to watch out for:
Overlaps of identities: In my case, I did the test on the nameserver PC (rocky) and two separate ones. The server PC has two IPs that could be used in its communications (127.0.0.1 and 192.168.1.1), the localhost address was what it used as that's how the machines work by default (localtraffic on the localhost).
Typing errors: The names used in ACLs must exactly match the names inside the MATCH-CLIENTS used inside the VIEWs. I've also used the same name for the VIEW, and inside the zone filename, just for my own convenience of not making mistakes. Check you've written match-clients and not match-client. Check you've got braces and semi-colons in the right places. Check you've written the correct filenames inside the zone declarations. Check you've typed IP addresses correctly.
When testing your external IP, how are you testing it? Are you actually doing a query from an outside machine? Are you using the IP you think you are?
-
Greg Woods -
Jack Craig -
Petr Menšík -
Tim