Thanks. Here's the output of the various dig commands and the tcpdump where relevant. pf is unchanged and there is no difference whether disabled with pfctl -d or not. The tcpdump is interesting since apparently the query reached NSD and it replies - but Unbound does not see/accept it (?). Could it be that it refuses replies on the port it used to send the query?
The first dig command is run on another host in the lan (chief), the others are run on the dns server itself (dns03). Note that the successful replies refer to another dns server, but at the moment it does not exist. No machines are configured to use that, it's only in the zone files for now. ### Run on chief (192.168.x.95) ### [johan@chief ~]$ dig @192.168.x.91 ericsson.com ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> @192.168.x.91 ericsson.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32640 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ericsson.com. IN A ;; ANSWER SECTION: ericsson.com. 28800 IN A 193.180.16.203 ;; Query time: 51 msec ;; SERVER: 192.168.x.91#53(192.168.x.91) ;; WHEN: tis okt 11 13:40:10 CEST 2016 ;; MSG SIZE rcvd: 57 ### Run on dns03 (192.168.x.91) ### $ dig aftonbladet.se ; <<>> DiG 9.4.2-P2 <<>> aftonbladet.se ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5621 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;aftonbladet.se. IN A ;; ANSWER SECTION: aftonbladet.se. 300 IN A 52.50.97.124 aftonbladet.se. 300 IN A 52.30.21.46 aftonbladet.se. 300 IN A 52.50.100.254 ;; Query time: 66 msec ;; SERVER: 192.168.x.91#53(192.168.x.91) ;; WHEN: Tue Oct 11 13:42:40 2016 ;; MSG SIZE rcvd: 80 $ dig chief.my.domain ; <<>> DiG 9.4.2-P2 <<>> chief.my.domain ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3456 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;chief.my.domain. IN A ;; Query time: 442 msec ;; SERVER: 192.168.x.91#53(192.168.x.91) ;; WHEN: Tue Oct 11 13:43:45 2016 ;; MSG SIZE rcvd: 38 While running the above query the following tcpdump was captured: # tcpdump -i lo0 net 127 and port 53 tcpdump: listening on lo0, link-type LOOP 13:59:57.145012 localhost.39240 > localhost.domain: 10949% [1au] A? chief.my.domain. (49) 13:59:57.145478 localhost.domain > localhost.39240: 10949*- 1/2/3 A 192.168.x.95 (137) $ dig @localhost chief.my.domain ; <<>> DiG 9.4.2-P2 <<>> @localhost chief.my.domain ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36657 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;chief.my.domain. IN A ;; ANSWER SECTION: chief.my.domain. 86400 IN A 192.168.x.95 ;; AUTHORITY SECTION: my.domain. 86400 IN NS dns03.my.domain. my.domain. 86400 IN NS dns04.my.domain. ;; ADDITIONAL SECTION: dns03.my.domain. 86400 IN A 192.168.x.91 dns04.my.domain. 86400 IN A 192.168.x.92 ;; Query time: 6 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Oct 11 13:44:10 2016 ;; MSG SIZE rcvd: 126 And here's the tcpdump of that query: # tcpdump -i lo0 net 127 and port 53 tcpdump: listening on lo0, link-type LOOP 14:01:28.099979 localhost.30023 > localhost.domain: 51528+ A? chief.my.domain. (38) 14:01:28.100456 localhost.domain > localhost.30023: 51528*- 1/2/2 A 192.168.x.95 (126) $ dig @localhost chief ; <<>> DiG 9.4.2-P2 <<>> @localhost chief ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64595 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;chief. IN A ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Oct 11 13:47:55 2016 ;; MSG SIZE rcvd: 23 2016-10-11 8:29 GMT+02:00 Raimo Niskanen <raimo+open...@erix.ericsson.se>: > Please give more details on which dig commands you used on which machine(s) > and paste their exact results. Otherwise hard to tell since your setup > seems about right. Does pf get in your way? > > And -l Port to dig selects a non-default port. > > Anything interesting in your system logs on the DNS server? > > Try to tcpdump on 127.0.0.1 port 53 and see if you have traffic there > between unbound and nsd. > > Good luck! > > / Raimo Niskanen > > > > On Mon, Oct 10, 2016 at 11:42:16PM +0200, Johan Mellberg wrote: >> Hi all, >> >> I am setting up a fresh OpenBSD 6.0 server in a KVM VM to serve my >> home network with DNS. I have a custom zone (only for LAN use) set up >> and previously used BIND successfully (but that VM crashed and its >> disk was hosed...) both as authoritative and caching/resolving. >> >> So now I am trying to learn to set up NSD to be authoritative for my >> small zone and Unbound to serve the LAN with all other queries. But >> there is a problem: >> >> 1. Unbound successfully responds to queries and provides lookup to the >> LAN machines for "the internet". >> 2. NSD successfully responds to queries for the custom zone. >> 3. But I cannot get Unbound to get a reply from NSD... >> >> I have tried multiple combinations of ports and interface bindings and >> I suspect that I am missing something simple here. Currently I have >> set NSD to listen on 127.0.0.1 and Unbound listens on 192.168.x.91 - >> so there should not be a conflict. In fact it works fine if I use dig >> @localhost <LANhostname> and dig @192.168.x.91 <internethostname> >> respectively, but the second version only provides an answer-less >> response if asked for a LAN hostname. >> >> Unbound is set to ask localhost for the stub zones, forward and reverse. >> >> And, yes, I could of course use Unbound to serve my local zone and >> drop NSD - but that would be giving up... It's supposed to work from >> all I read! :-) >> >> I have also tried having NSD listen on 127.0.0.1@5353, and telling >> unbound to use that as the stub-address, while then having Unbound >> listen on 127.0.0.1 as well as 192.168.x.91 to be able to set >> 127.0.0.1 as the nameserver in /etc/resolv.conf. Same result except I >> can't test NSD with dig as it can't use an alternative port. >> >> A possibly related question: I can't seem to be able to use >> shortnames. The domain part should be picked up from the host name as >> given in /etc/myname, but that does not seem to work as I expect, I >> always have to provide the FQDN. Again something I have missed >> perhaps? >> >> Anyway, I am staring blindly at the config files now and really need >> help figuring it out. I have removed all that is commented, otherwise >> it's the default except for changes of course. >> >> Thanks for any clue bats coming my way... >> /Johan >> >> * resolv.conf >> lookup file bind >> nameserver 192.168.x.91 >> >> # cat /etc/myname >> dns03.my.domain >> >> # cat /etc/hosts >> 127.0.0.1 localhost >> ::1 localhost >> 192.168.x.91 dns03.my.domain dns03 >> >> # cat /var/unbound/etc/unbound.conf >> # $OpenBSD: unbound.conf,v 1.7 2016/03/30 01:41:25 sthen Exp $ >> >> server: >> interface: 192.168.x.91 >> interface: ::1 >> do-not-query-localhost: no >> >> access-control: 192.168.x.64/24 allow >> access-control: 127.0.0.0/8 allow >> access-control: 0.0.0.0/0 refuse >> access-control: ::0/0 refuse >> access-control: ::1 allow >> >> hide-identity: yes >> hide-version: yes >> >> # Uncomment to enable DNSSEC validation. >> # >> auto-trust-anchor-file: "/var/unbound/db/root.key" >> >> root-hints: /var/unbound/etc/root.hints >> >> remote-control: >> control-enable: yes >> control-use-cert: no >> control-interface: /var/run/unbound.sock >> >> stub-zone: >> name: "my.domain" >> stub-addr: 127.0.0.1 >> stub-zone: >> name: "x.168.192.in-addr.arpa" >> stub-addr: 127.0.0.1 >> >> # cat /var/nsd/etc/nsd.conf >> # $OpenBSD: nsd.conf,v 1.11 2015/04/12 11:49:39 sthen Exp $ >> >> server: >> hide-version: yes >> verbosity: 1 >> database: "" # disable database >> >> ## bind to a specific address/port >> ip-address: 127.0.0.1 >> >> remote-control: >> control-enable: yes >> >> zone: >> name: "my.domain" >> zonefile: "master/my.domain" >> zone: >> name: "x.168.192.in-addr.arpa" >> zonefile: "master/192.168.x.rev" > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB
