Re: [Pdns-users] stupid recursor question [SOLVED]
Heh, totally missed the error. duh. Thanks for pointing it out. I’ll check out the hairpinning on the nat. didn’t even think of that. Sent from my iPhone > On Dec 7, 2022, at 3:18 PM, Brian Candler wrote: > > On 07/12/2022 18:47, Curtis Maurand via Pdns-users wrote: >> dig doesn't return an error > ... >> root@sirius:~# dig sirius.xyonet.com >> >> ; <<>> DiG 9.16.33-Debian <<>> sirius.xyonet.com >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10323 > > To be clear: SERVFAIL *is* an explicit error response from the recursor. It > means it couldn't contact any of the nameservers for the domain you're > querying. > > And I suspect this would also fail: > > root@sirius:~# dig +norec @208.105.217.26 sirius.xyonet.com. > > Hence the problem is that the nameserver can't be reached on its *public* IP > from the *private* network. But as you've found, sending the query to the > private IP fixes this. I'm glad you've managed to make it work! > ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question [SOLVED]
On 07/12/2022 18:47, Curtis Maurand via Pdns-users wrote: dig doesn't return an error ... root@sirius:~# dig sirius.xyonet.com ; <<>> DiG 9.16.33-Debian <<>> sirius.xyonet.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10323 To be clear: SERVFAIL *is* an explicit error response from the recursor. It means it couldn't contact any of the nameservers for the domain you're querying. And I suspect this would also fail: root@sirius:~# dig +norec @208.105.217.26 sirius.xyonet.com. Hence the problem is that the nameserver can't be reached on its *public* IP from the *private* network. But as you've found, sending the query to the private IP fixes this. I'm glad you've managed to make it work! ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question [SOLVED]
On Wed, Dec 7, 2022, at 13:47, Curtis Maurand via Pdns-users wrote: > > I just added to the recursor.conf forward-zones=xyonet.com=192.168.100.30 and > that worked. I would now call this solved. > The most likely cause is that your router/firewall is not configured properly for 'hairpin NAT' and thus the recursor inside the NAT is not able to reach the auth server on its *public* address, only on its *private* address. Using forward-zone is a good solution for this, and for many other problems too.___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question [SOLVED]
Op 7 dec. 2022 om 19:47 heeft Curtis Maurand via Pdns-users het volgende geschreven: Hello, Sorry for the delay. I was dealing with multiple problems at once. The largest and most pressing was whether the server would continue to run with a couple of broken inodes. Now that that is out of the way. In answer to Brian's questions. Both servers are on the same nat'ed subnet. one at 192.168.100.0/24. The primary name server does have an outside address. ns1.xyonet.com is 208.105.217.26. port 53 is forwarded to 192.168.100.30. dig doesn't return an erroIt does., I just doesn't return an address, but it is actually making the query to the resolver that is adjacent at 192.168.100.20 root@sirius:~# dig sirius.xyonet.com ; <<>> DiG 9.16.33-Debian <<>> sirius.xyonet.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10323 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;sirius.xyonet.com. IN A ;; Query time: 0 msec ;; SERVER: 192.168.100.20#53(192.168.100.20) ;; WHEN: Wed Dec 07 13:32:48 EST 2022 ;; MSG SIZE rcvd: 46 again, it's only for the locally host domain at 192.168.100.30 I just added to the recursor.conf forward-zones=xyonet.com=192.168.100.30 and that worked. I would now call this solved. On 12/6/22 21:45, Leeflangetje via Pdns-users wrote: You did not report back the results of the other 2 troubleshoot actions that Brian suggested (dig and tcpdump) These could hold clues to the cause of your problem. On Tue, 2022-12-06 at 14:33 -0500, Curtis Maurand via Pdns-users wrote: OK, just did the upgrade and adjusted the tables accordingly. I don't like the fact that the update clobbered the /etc/init.d/pdns file. We don't all run distributions with systemd. Systemd is big and buggy, not to mention the controtions one has to go through to get things to work properly. My system is way more manageable without it. More stable, too. I knew I needed to do upgrade, debian hasn't upgraded the version in their repos. I added the powerdns repo to the sources.list.d/pdns. I digress. I'm now running 4.7.2. It took a few minutes to get the supermaster/superslave set up and working. Things are working from outside and pretty fast, too. It's internally where things aren't working. the internal recursor is not resolving anything that is hosted. wierd. --Curtis On 12/6/22 12:52, Brian Candler wrote: On 06/12/2022 17:41, Curtis Maurand via Pdns-users wrote: You can use either xyonet.com or cybernexus.net And the pdns-auth server which you are referring to is ns1.xyonet.com or ns2.xyonet.com? Or is it neither of these, and is a hidden primary? FYI, ns2.xyonet.com is not responding at the moment. Also, ns1 is running PowerDNS Authoritative Server 4.4.1, which is end-of-life, so you ought to look at upgrading it. See https://repo.powerdns.com/ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users -- Curtis https://curtis.maurand.com ___Pdns-users mailing listPdns-users@mailman.powerdns.comhttps://mailman.powerdns.com/mailman/listinfo/pdns-users___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question [SOLVED]
Hello, Sorry for the delay. I was dealing with multiple problems at once. The largest and most pressing was whether the server would continue to run with a couple of broken inodes. Now that that is out of the way. In answer to Brian's questions. Both servers are on the same nat'ed subnet. one at 192.168.100.0/24. The primary name server does have an outside address. ns1.xyonet.com is 208.105.217.26. port 53 is forwarded to 192.168.100.30. dig doesn't return an error, I just doesn't return an address, but it is actually making the query to the resolver that is adjacent at 192.168.100.20 root@sirius:~# dig sirius.xyonet.com ; <<>> DiG 9.16.33-Debian <<>> sirius.xyonet.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10323 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;sirius.xyonet.com. IN A ;; Query time: 0 msec ;; SERVER: 192.168.100.20#53(192.168.100.20) ;; WHEN: Wed Dec 07 13:32:48 EST 2022 ;; MSG SIZE rcvd: 46 again, it's only for the locally host domain at 192.168.100.30 I just added to the recursor.conf forward-zones=xyonet.com=192.168.100.30 and that worked. I would now call this solved. On 12/6/22 21:45, Leeflangetje via Pdns-users wrote: You did not report back the results of the other 2 troubleshoot actions that Brian suggested (dig and tcpdump) These could hold clues to the cause of your problem. On Tue, 2022-12-06 at 14:33 -0500, Curtis Maurand via Pdns-users wrote: OK, just did the upgrade and adjusted the tables accordingly. I don't like the fact that the update clobbered the /etc/init.d/pdns file. We don't all run distributions with systemd. Systemd is big and buggy, not to mention the controtions one has to go through to get things to work properly. My system is way more manageable without it. More stable, too. I knew I needed to do upgrade, debian hasn't upgraded the version in their repos. I added the powerdns repo to the sources.list.d/pdns. I digress. I'm now running 4.7.2. It took a few minutes to get the supermaster/superslave set up and working. Things are working from outside and pretty fast, too. It's internally where things aren't working. the internal recursor is not resolving anything that is hosted. wierd. --Curtis On 12/6/22 12:52, Brian Candler wrote: On 06/12/2022 17:41, Curtis Maurand via Pdns-users wrote: You can use either xyonet.com or cybernexus.net And the pdns-auth server which you are referring to is ns1.xyonet.com or ns2.xyonet.com? Or is it neither of these, and is a hidden primary? FYI, ns2.xyonet.com is not responding at the moment. Also, ns1 is running PowerDNS Authoritative Server 4.4.1, which is end-of-life, so you ought to look at upgrading it. See https://repo.powerdns.com/ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users -- Curtis https://curtis.maurand.com ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question
You did not report back the results of the other 2 troubleshoot actions that Brian suggested (dig and tcpdump) These could hold clues to the cause of your problem. On Tue, 2022-12-06 at 14:33 -0500, Curtis Maurand via Pdns-users wrote: > OK, just did the upgrade and adjusted the tables accordingly. I > don't like the fact that the update clobbered the /etc/init.d/pdns > file. We don't all run distributions with systemd. Systemd is big > and buggy, not to mention the controtions one has to go through to > get things to work properly. My system is way more manageable without > it. More stable, too. I knew I needed to do upgrade, debian hasn't > upgraded the version in their repos. I added the powerdns repo to > the sources.list.d/pdns. I digress. I'm now running 4.7.2. It took > a few minutes to get the supermaster/superslave set up and working. > > Things are working from outside and pretty fast, too. It's internally > where things aren't working. the internal recursor is not resolving > anything that is hosted. wierd. > > --Curtis > > > > On 12/6/22 12:52, Brian Candler wrote: > > > > > On 06/12/2022 17:41, Curtis Maurand via Pdns-users wrote: > > > > > > > > You can use either xyonet.com or cybernexus.net > > And the pdns-auth server which you are referring to is > > ns1.xyonet.com or ns2.xyonet.com? Or is it neither of these, and > > is a hidden primary? > > FYI, ns2.xyonet.com is not responding at the moment. Also, ns1 is > > running PowerDNS Authoritative Server 4.4.1, which is end-of-life, > > so you ought to look at upgrading it. See > > https://repo.powerdns.com/ > > > > ___ > Pdns-users mailing list > Pdns-users@mailman.powerdns.com > https://mailman.powerdns.com/mailman/listinfo/pdns-users ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question
OK, just did the upgrade and adjusted the tables accordingly. I don't like the fact that the update clobbered the /etc/init.d/pdns file. We don't all run distributions with systemd. Systemd is big and buggy, not to mention the controtions one has to go through to get things to work properly. My system is way more manageable without it. More stable, too. I knew I needed to do upgrade, debian hasn't upgraded the version in their repos. I added the powerdns repo to the sources.list.d/pdns. I digress. I'm now running 4.7.2. It took a few minutes to get the supermaster/superslave set up and working. Things are working from outside and pretty fast, too. It's internally where things aren't working. the internal recursor is not resolving anything that is hosted. wierd. --Curtis On 12/6/22 12:52, Brian Candler wrote: On 06/12/2022 17:41, Curtis Maurand via Pdns-users wrote: You can use either xyonet.com or cybernexus.net And the pdns-auth server which you are referring to is ns1.xyonet.com or ns2.xyonet.com? Or is it neither of these, and is a hidden primary? FYI, ns2.xyonet.com is not responding at the moment. Also, ns1 is running PowerDNS Authoritative Server 4.4.1, which is end-of-life, so you ought to look at upgrading it. See https://repo.powerdns.com/ -- Curtis https://curtis.maurand.com ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question
On 06/12/2022 17:41, Curtis Maurand via Pdns-users wrote: You can use either xyonet.com or cybernexus.net And the pdns-auth server which you are referring to is ns1.xyonet.com or ns2.xyonet.com? Or is it neither of these, and is a hidden primary? FYI, ns2.xyonet.com is not responding at the moment. Also, ns1 is running PowerDNS Authoritative Server 4.4.1, which is end-of-life, so you ought to look at upgrading it. See https://repo.powerdns.com/ ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question
You can use either xyonet.com or cybernexus.net On 12/6/22 12:26, Brian Candler wrote: On 06/12/2022 17:06, Curtis Maurand via Pdns-users wrote: On the authoritative server I host a domain that I'll call domain.tld as the example. It really helps if you give the real domain, since many problems can be diagnosed easily by querying the auth nameserver. See https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ Is this a real domain, i.e. does your authoritative server have a public IP address and NS records pointing at it? I am guessing that it is, since you say it's dnssec signed. Is your auth server behind any sort of NAT? All seems to be well, until I query the local recursor which returns nothing. It answers, but doesn't return a response. Define "nothing": NOERROR with no records, NXDOMAIN, SERVFAIL, something else? Can your recursor reach the authoritative server on its public IP address? That is, from the shell of the recursor, can you query the auth server like this: dig +norec @x.x.x.x domain.tld. a I've tried forward-zones = domain.tld=192.168.100.30; and that doesn't seem to work. You can run tcpdump to see whether the recursor is sending queries to 192.168.100.30, and if so, what response it gets. tcpdump -i eth0 -nn -s0 -v port 53 and host 192.168.100.30 -- Curtis https://curtis.maurand.com ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
Re: [Pdns-users] stupid recursor question
On 06/12/2022 17:06, Curtis Maurand via Pdns-users wrote: On the authoritative server I host a domain that I'll call domain.tld as the example. It really helps if you give the real domain, since many problems can be diagnosed easily by querying the auth nameserver. See https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ Is this a real domain, i.e. does your authoritative server have a public IP address and NS records pointing at it? I am guessing that it is, since you say it's dnssec signed. Is your auth server behind any sort of NAT? All seems to be well, until I query the local recursor which returns nothing. It answers, but doesn't return a response. Define "nothing": NOERROR with no records, NXDOMAIN, SERVFAIL, something else? Can your recursor reach the authoritative server on its public IP address? That is, from the shell of the recursor, can you query the auth server like this: dig +norec @x.x.x.x domain.tld. a I've tried forward-zones = domain.tld=192.168.100.30; and that doesn't seem to work. You can run tcpdump to see whether the recursor is sending queries to 192.168.100.30, and if so, what response it gets. tcpdump -i eth0 -nn -s0 -v port 53 and host 192.168.100.30 ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
[Pdns-users] stupid recursor question
Hello, I've been a pdns user since, well, forever. I abandoned bind long ago. I currently have a set up where I run an authoritative server on a virtual machine and I run pdns-recursor on a separate virtual machine. On the authoritative server I host a domain that I'll call domain.tld as the example. It works fine. It returns all of the correct answers and the zone is signed and those answers come back correctly. queries to outside recursors such as 8.8.8.8 or 1.1.1.1 or 4.2.2.2, return appropriate responses. All seems to be well, until I query the local recursor which returns nothing. It answers, but doesn't return a response. The local networks are set up in the recursor.conf (allow-from=127.0.0.0/8, 192.168.100.0/24, 192.168.192.0/24, 192.168.100.0/24) querying a foreign domain such as ibm.com or microsoft.com works fine. It just seems to be my local recursor is finding nothing that I actually host. I've tried forward-zones = domain.tld=192.168.100.30; and that doesn't seem to work. Does anyone have any ideas? Thank in advance, Curtis -- Curtis https://curtis.maurand.com ___ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
