Re: [Pdns-users] pdns-recursor zone-forward block and allow lists

2024-04-30 Thread Brian Candler via Pdns-users

On 30/04/2024 08:23, Jan Gardian via Pdns-users wrote:

tcpdump:
"
17:31:22.071802 IP 192.168.0.101.41941 > pdns-recursor.domain: 65094+ 
[1au] A? liveaqest.live. (55)
17:31:22.072588 IP pdns-recursor.55092 > dns.google.domain: 5457+% 
[1au] A? liveaqest.live. (43)
17:31:22.090703 IP dns.google.domain > pdns-recursor.55092: 5457 2/0/1 
A 188.114.97.3, A 188.114.96.3 (75)
17:31:22.091020 IP pdns-recursor.52908 > dns0.eu.domain: 55841 [1au] 
DS? live. (33)
17:31:22.095823 IP dns0.eu.domain > pdns-recursor.52908: 55841$ 0/14/1 
(530)
17:31:22.096001 IP pdns-recursor.25826 > dns0.eu.domain: 28404 [1au] 
DS? live. (33)
17:31:22.099646 IP pdns-recursor.34244 > 10.35.21.1.domain: 26987+ 
PTR? 101.0.164.192.in-addr.arpa. (42)
17:31:22.100761 IP dns0.eu.domain > pdns-recursor.25826: 28404$ 0/14/1 
(530)
17:31:22.101142 IP pdns-recursor.domain > 192.168.0.101.41941: 65094 
ServFail 0/0/1 (43)

"


The fourth and fifth packets shows a query and response for a DS record, 
i.e. it's trying to do DNSSEC validation, starting at "live." and 
working downwards. I therefore suspect that's the problem.


I'm not sure *exactly* why DNSSEC is failing to verify though: it seems 
"live" is signed but "liveaqest.live" is not, and that ought to be 
fine.  And I don't know why the 6th/8th packets are repeating the same 
DS query.


As a quick workaround (or at least to prove whether this is the issue), 
you could add a Negative Trust Anchor for liveaqest.live. See:


https://doc.powerdns.com/recursor/yamlsettings.html#recursor-forward-zones

https://doc.powerdns.com/recursor/dnssec.html#negative-trust-anchors

Or turn off DNSSEC processing completely. Or crank up logging to see 
if/why DNSSEC validation is failing.


I guess when you're forwarding queries to an upstream recursive server, 
it would be nice to have a way to say "trust the AD flag queries in 
responses from that server, and skip local DNSSEC validation" - but I 
don't see a way to configure that.


Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] How to config pdns to send notification to addres not in "IN NS" record.

2024-03-12 Thread Brian Candler via Pdns-users

On 12/03/2024 13:11, Bino Oetomo wrote:
The zone record editing is done via CPanel webUI. There is "zone 
editor" in that UI and thats the one I use itu.

Via that UI, I just change single IN A record of one record.


Then it becomes a question of how CPanel integrates with pdns, and since 
I believe CPanel is commercial software, perhaps it would be best if you 
take it up with your vendor.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] How to config pdns to send notification to addres not in "IN NS" record.

2024-03-12 Thread Brian Candler via Pdns-users

On 12/03/2024 11:40, Bino Oetomo wrote:
I run --> tcpdump -vv --interface eth1 port 53 at powerdns box , got 
no traffic indicating notification sent.
But when I restart the bind9 service at the slave, tcpdump shows some 
traffic to and from slave.


So still IMHO my pdns box did not send any notification to slaves.


OK, so next you said you "did some record editing ", how exactly did you 
do that? Editing the zone files and restarting or reloading pdns? Via 
the API? Something else?


There's information about the bind backend, including its behavior 
w.r.t. notifies, here:


https://doc.powerdns.com/authoritative/backends/bind.html

In particular, note that restarting powerdns will *not* send out notifies.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] How to config pdns to send notification to addres not in "IN NS" record.

2024-03-12 Thread Brian Candler via Pdns-users

On 12/03/2024 10:41, Bino Oetomo via Pdns-users wrote:

dear all

I have a cpanel box with powerdns as it's DNS server. it's IP address 
is 192.168.1.101



...


zone "domain0.bino" {
type secondary;
file "/var/named/domain0.bino.db";
primaries {103.30.144.60;};
};


103.30.144.60 != 192.168.1.101

If the powerDNS and bind boxes are behind NAT without VPN tunnels 
between them, then this is going to cause you problems (e.g. 
192.168.1.101 may not be able to send to 192.168.8.79)


You can use tcpdump at both ends to see if notifications are being sent 
from the primary, and if they are, whether they are being received by 
the secondary.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] [EXT] Re: remote backend

2023-11-30 Thread Brian Candler via Pdns-users
That code is incomplete and not runnable. What is "[0:netip]" for 
example? More importantly, what is "c" when you do c.Write(data) ?


However, there is also an unstated question here, which is "how are the 
requests and responses delimited when PowerDNS using the unixsock remote 
backend?"  You're just assuming that a Read() and a Write() are 
sufficient to delimit messages, and that seems pretty unlikely to me.


Now, looking in the Ruby code in modules/remotebackend/unittest_pipe.rb, 
it appears that the format is newline-delimited, i.e. this is JSON-Lines 
.


This appears to be confirmed in modules/remotebackend/pipeconnector.cc

int PipeConnector::send_message(const Json& input)
{
  auto line = input.dump();
  launch();

*  line.append(1, '\n');*

...

    if (!stringfgets(d_fp.get(), receive)) {
  throw PDNSException("Child closed pipe");
    }

// stringfgets is in pdns/misc.cc, and it reads up to a newline:

  do {
    if(!fgets(buffer, sizeof(buffer), fp))
  return !line.empty();

    line.append(buffer);
*  } while(!strchr(buffer, '\n'));*
  return true;

So the main issue seems to be: you need to write a newline after your 
JSON response.  (And make sure your response *isn't* pretty-printed, and 
any embedded newlines in strings are represented by "\n", so that each 
JSON object is exactly one line)


Then instead of Read(1024), you need to either read up to a newline 
(e.g. using bufio.Scanner or bufio.Reader) - or you need to use a 
streaming JSON decoder which will use the end of each JSON object as the 
delimiter, and ignores the newlines in between them.  (Go's 
encoding/json can quite happily do that)


HTH,

Brian.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Short Name Resolution

2023-11-30 Thread Brian Candler via Pdns-users

On 29/11/2023 21:32, t...@garayfam.com wrote:


So, create my local domain (something.lan) and put all my entries in 
that then configure the clients to use something.lan as the default 
search domain?


Yes, that's the way. However it would be better to use a subdomain of a 
real domain that you actually own. Using a fake / undelegated domain 
means that you need a forwarding rule in your PDNS recursor to forward 
it to your PDNS auth.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Short Name Resolution

2023-11-29 Thread Brian Candler via Pdns-users

On 29/11/2023 20:27, Tim Garay via Pdns-users wrote:


How can I setup PDNS to resolve short names?

I would like to be able to resolve something like “testserver” to 
192.168.1.1.  No domain.


Generally this is the job of the stub resolver on the client, to expand 
"testserver" to "testserver.some.domain", by configuring it to retry 
queries which fail by adding "some.domain" to them.


Most clients will honour a DHCP parameter for the search domain. For 
example, a Linux client may put the setting "search some.domain" in 
/etc/resolv.conf
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] remote backend

2023-11-29 Thread Brian Candler via Pdns-users

On 29/11/2023 14:04, Alexis Fidalgo wrote:
So, by now, i dont know what is making for a query to be answered and 
another not (timeout) and in a retry is answered ok. (this is why i 
thought on speed and considered the unix socket but now i know it’s 
not that)


Put logging in your remote backend and show what queries it receives and 
how long it takes to respond to each one. Use these logs to check that 
the queries generated by PowerDNS are what you expect (it may make 
multiple requests for a single received DNS query).


You can also take PowerDNS entirely out of the problem by making a set 
of suitable test HTTP calls directly to your backend, for the same set 
queries that PowerDNS would generate. If you can prove that your backend 
is taking too long to answer them (on the first attempt at least), then 
you know where to investigate.


For example, it might be that MongoDB is doing a lot of slow disk seeks 
(is it spinning rust or SSD?) but once it has the answer, everything it 
needs is cached in RAM so it's much quicker on the second attempt. Or 
maybe it's not indexed properly. You really need to drill down further 
to prove or disprove that idea.


If you find that MongoDB is the bottleneck and can't be tuned, then 
there are other options. For example, if this database doesn't change 
very often, then you could write it out to a CDB file:


https://cr.yp.to/cdb.html
https://en.wikipedia.org/wiki/Cdb_(software)

This is optimised for very fast lookup with minimum seeking, and can be 
indexed in a single pass - but it can't be modified, so you'd have to 
regenerate the whole file periodically.  Also it has a 4GB size limit 
which is probably an issue here (limiting you to avg 14 bytes per 
key/value pair) so you may need to split into multiple files.


A suitably-indexed Postgres table with 300 million entries is big but 
not impossible, and PowerDNS could query it directly.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] remote backend

2023-11-29 Thread Brian Candler via Pdns-users

On 29/11/2023 10:19, Alexis Fidalgo wrote:


by the responder, what im not understanding is, why in 2 different languages 
(golang and python) i get the same behavior.


Well, you haven't shown the code from either.



It would be extremely inefficient for PowerDNS to open a new connection for every message 
and close it immediately afterwards. That would be like HTTP without keepalive.  And it 
would make no sense to send an "initialize" message to setup a connection, only 
to drop the connection immediately afterwards.

I agree on this, makes no sense at all to close the socket after each message, 
what i found even worse is (again, at least in golang and python), from server 
side on the UDS. Im seeing

. bind the socket to the fd
. open the socket
. Accept from the socket (locks)


Note that accept() returns you a *new* fd (socket) representing this 
connection.




. Reads from the socket


...where "the socket" here means the new one returned from accept()



. Answer to the socket (*)
. Locks for ever if i dont close it


Maybe you have a problem with buffering then. Perhaps you need to flush 
the buffer after sending the response? If you don't show code, I can 
only speculate.  But I guess we're moving away from the topic of 
PowerDNS, and onto the topic of socket programming.



Im with you on this, right after Accept + Read, if im processing/answering in a 
different thread, it should go immediately to accept again and lock there 
waiting for a new message and so on, that’s the correct way to act, but im not 
getting that.


No, accept() is not for receiving another message, it's for receiving 
another connection on the same Unix domain socket, which will require 
another thread to answer. Whether this happens is a question of whether 
PowerDNS will open multiple connections to the same Unix domain socket; 
this doesn't seem to be documented but it certainly could. So you need a 
main (thread/goroutine/green thread) calling accept() on the socket, 
which starts a new (thread/goroutine/green thread) to process each 
connection, and each connection can process multiple messages in sequence.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] remote backend

2023-11-29 Thread Brian Candler via Pdns-users

On 29/11/2023 00:07, Alexis Fidalgo via Pdns-users wrote:
I think i found why this is not working, as you can see below, socket 
is connected and first message is sent (the initialize message), which 
is answered and the response is read ({“result”: true}).


Problem is (and i’ve testing with golang and python) after the answer 
the “initialize” message, the socket is closed,


By whom - by PowerDNS, or by your remote backend application code? I 
think it's the latter, and if so, the problem is at your side, not PowerDNS.


It would be extremely inefficient for PowerDNS to open a new connection 
for every message and close it immediately afterwards. That would be 
like HTTP without keepalive.  And it would make no sense to send an 
"initialize" message to setup a connection, only to drop the connection 
immediately afterwards.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] remote backend

2023-11-28 Thread Brian Candler via Pdns-users

On 28/11/2023 18:10, Walter Parker via Pdns-users wrote:
Unclear as to what you mean by “remote backend connected using Unix 
sockets”


See: https://doc.powerdns.com/authoritative/backends/remote.html

"Remote backend" in this case means "out-of-process", not necessarily on 
a different server.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Share DNS-Records between two zones/views (internal & external)

2023-11-15 Thread Brian Candler via Pdns-users

On 15/11/2023 17:11, Sebastian Neumann via Pdns-users wrote:
3. Install a Response Policy Zone (RPZ) in the recursor to *override* 
the results provided by the auth for queries from internal clients

Thanks a lot for that hint, I will look into that.
I guess you are talking about this bit here? 
https://doc.powerdns.com/recursor/lua-config/index.html
So I would need to write some lua-code that gets executed before the 
response is being returned, and in case the response is a NXDOMAIN, I 
make a new lookup towards the external-pdns-auth server and return 
whatever that one returns?


No, you just need to load the RPZ.

https://doc.powerdns.com/recursor/lua-config/rpz.html

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Share DNS-Records between two zones/views (internal & external)

2023-11-15 Thread Brian Candler via Pdns-users

On 15/11/2023 14:53, sebastian-n-95--- via Pdns-users wrote:

Hey,

I am considering migrating my current BIND-Based setup to PowerDNS.

For multiple zones, I currently have split-view in bind, so that I can 
define DNS-Records available only for internal clients.


To achieve this, I have the following zonefiles:

mydomain.com.ext.zone <- This zonefile is used for the external view
mydomain.com.int.zone  <- This zonesfile is used for the internal view
But I also have:
mydomain.com.include    <- This file is included in both zonefiles, so 
records defined there are available in both zones.

I was wondering, how I could replicate a setup like this in PowerDNS.


BIND combines the roles of authoritative server and recursor; PowerDNS 
has separate programs (pdns and pdns-recursor)


Split views are IMO a bad idea anyway, but if you wanted to do it you 
would need to do something like this:


1. Run pdns-recursor for your internal clients to use
2. Run an instance of pdns-auth with your internal zones
3. Set up forwarding rules on pdns-recursor for your internal zones, 
pointing at your internal pdns-auth
4. Run a separate instance of pdns-auth with your external zones (i.e. 
the ones which your NS records point at)


Note that even with this setup, your clients will need to point to one 
IP address (the pdns-recursor server), and your NS records will need to 
point to a different IP address (the pdns-auth server with the 
externally visible zones).  So you will need to renumber one or the other.


If you really, really, really want to have a single IP address that 
performs both functions, then you will indeed need to put dnsdist on 
that address. But I would strongly advise against it; it's too many 
moving parts. Either just renumber your recursor IP (maybe you can give 
the new address to all your clients using DHCP), or renumber your 
external auth nameserver (which just means changing the A record for 
your nameserver, and possibly glue records).


PowerDNS is designed for use in large-scale ISP operations, where it is 
best practice to separate recursor and authoritative services and run 
them on different IP addresses.



But for DNS-Records that I want to have for internal AND external 
clients, I would need to create them in both PowerDNS-instances.
To me, the risk seems too high, that by accident, DNS-Records are only 
created/updated on one PowerDNS-Instance, but not on the other.


That is one of the (several) risks associated with split DNS, yes.

Regards,

Brian.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] LUA for "filter-aaaa-on-v4"

2023-10-30 Thread Brian Candler via Pdns-users

On 30/10/2023 09:10, Djerk Geurts via Pdns-users wrote:


Your right that once dual stack is enabled on parts of the network and 
in clients, then we'll need to be mindful of this. But, I would expect 
most dual stack clients to default to querying DNS using IPv6. In fact 
as we control the client IP addressing, we can ensure to convert DNS 
server settings to IPv6 when enabling dual stack.


DHCP(v4) can only give out IPv4 DNS server addresses. Therefore, your 
dual-stack clients will end up learning about both v4 and v6 DNS 
servers, and you cannot control which they use. You can *hope* that they 
will prefer the IPv6 ones, but you can't enforce it.


I can't really see what problem you're trying to solve.  Do you have 
evidence that certain client OSes are making DNS requests for  
addresses even when they don't have an IPv6 address? If so, have you 
measured the amount of extra network traffic or DNS recursor load these 
are generating, and is this significant in the overall picture?


Furthermore, even for IPv4-only single stack clients, it seems to me you 
are going to create more problems than you solve by trying to mess with 
this: it's a case of an unnecessary "optimisation". If you drop the 
requests you will force the clients to retry, which could add several 
seconds of latency before they give up. But if you respond to them, you 
might as well give the valid response to the query they asked for.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Logging to /var/log/messages

2023-09-14 Thread Brian Candler via Pdns-users

On 14/09/2023 15:32, Ian Goldstein (BLOOMBERG/ 120 PARK) wrote:

The log entry that appears in my pdns.log is:
Sep 14 09:07:52 xx-232 pdns[1380]: AXFR of domain 'foo.bar.com' to 
1.2.3.4 finished


The entry that appears in /var/log/messages:
Sep 14 09:26:30 xx-209 pdns_server: AXFR of domain 'foo.bar.com' 
initiated by 1.2.3.4


also, the output from journalctl shows 2 entries
Sep 14 10:22:41 xx-209 pdns_server[98865]: AXFR of domain 
'foo.bar.com' to 1.2.3.4finished
Sep 14 10:22:41 xx-209 pdns[98865]: AXFR of domain 'foo.bar.com' 
to 1.2.3.4 finished


xx-232 and xx-209 appear to be two different hostnames, and you 
might want to check why one is running "pdns", one is running 
"pdns_server", and some logs show the PID and some don't. Basically 
those logs are too obfuscated to be meaningful. 



journalctl is going to show the logs which are coming directly from 
powerdns on stdout/stderr.


Apart from that, I think you'd be better off asking your question on an 
rsyslog mailing list, since powerdns has no control over how rsyslog 
processes or writes logs.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Logging to /var/log/messages

2023-09-14 Thread Brian Candler via Pdns-users
On 13/09/2023 22:48, Ian Goldstein (BLOOMBERG/ 120 PARK) via Pdns-users 
wrote:
While I am successfully logging to /var/log/pdns.log, I am also 
logging to /var/log/messages which I do not want.


That question is entirely about rsyslog and not powerdns, but in short 
you'll need something like this:


local1.* {
    # Logging for powerdns
    # facility-specific targets
    action(type="omfile" file="/var/log/pdns.log")
*    stop*
}

You can see some more examples at 
https://www.rsyslog.com/doc/v8-stable/configuration/converting_to_new_format.html#converting-action-chains


/("A common construct is to send messages to a remote host based on some 
message content and then not further process it")/
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Recursor forwarder DoT configuration

2023-09-08 Thread Brian Candler via Pdns-users

On 08/09/2023 15:50, Christoph via Pdns-users wrote:
- does it validate the server certificate? how do I configure the name 
when performing certificate verification? 


Not answering your questions about PDNS recursor specifically, but I'll 
just point out that 1.1.1.1:853 and 1.0.0.1:853 both have valid signed 
certificates with IP SANs, so certificate validation can be performed 
with IP address only.


$ openssl s_client -connect 1.1.1.1:853
...
    Verify return code: 0 (ok)

Decoding the certificate with openssl x509 -noout -text:

    X509v3 Subject Alternative Name:
    DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, 
DNS:one.one.one.one, IP Address:1.0.0.1, IP Address:1.1.1.1, IP 
Address:162.159.36.1, IP Address:162.159.46.1, IP 
Address:2606:4700:4700:0:0:0:0:1001, IP 
Address:2606:4700:4700:0:0:0:0:, IP 
Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400

...

For the same reason, using https://1.1.1.1/ in your browser also works.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC error

2023-08-18 Thread Brian Candler via Pdns-users

On 18/08/2023 10:12, Huber, Peter via Pdns-users wrote:
Thank you, I understand, that our server is not authoritative for .de. 
bur it seems our zone is no longer signed, but it was signed in the past.


There's a DS record in the parent zone:

$ dig @a.nic.de. uni-wh.de. ds
uni-wh.de.        86400    IN    DS    6632 14 2 
16556A7A06EC51AF8317D1CEF7EBF9F78D6214B648D83D14007C7820 A2561AF0


Therefore, if the zone isn't signed, then your names wouldn't resolve 
(by a DNSSEC-validating resolver).  But it all looks fine to me:


$ dig @8.8.8.8 uni-wh.de. +dnssec +trace

; <<>> DiG 9.10.6 <<>> @8.8.8.8 uni-wh.de. +dnssec +trace
; (1 server found)
;; global options: +cmd
.            38984    IN    NS    a.root-servers.net.
.            38984    IN    NS    b.root-servers.net.
.            38984    IN    NS    c.root-servers.net.
.            38984    IN    NS    d.root-servers.net.
.            38984    IN    NS    e.root-servers.net.
.            38984    IN    NS    f.root-servers.net.
.            38984    IN    NS    g.root-servers.net.
.            38984    IN    NS    h.root-servers.net.
.            38984    IN    NS    i.root-servers.net.
.            38984    IN    NS    j.root-servers.net.
.            38984    IN    NS    k.root-servers.net.
.            38984    IN    NS    l.root-servers.net.
.            38984    IN    NS    m.root-servers.net.
.            38984    IN    RRSIG    NS 8 0 518400 2023083017 
2023081716 11019 . 
Oui2ZZOta0+GnD7/uTK7N4X7WljjlYNw65RFma/tLxhpfnaxCRntCdl0 
ZH1p91FYWxOM0KimWnlUUivG3Xv4cbS4Bezj+4+tC1r1v3tPOGXKyvmV 
wmprioRC0JV8gIIw5Y6kxXk7BABmYYctCqONfRNluxW1YIkqFaRz7lm/ 
VFsMxXG42Q/C2OB+o8a0zQHEAoRN7RnC29H2a6cpwM0NmFkLnKY3k1UH 
hODGz0FUlEekGb99oaEhEj6GC+Khr0sHgdNCkMGaqSjtG+0m0LA4bDP+ 
66jebfxUFcIXyDKRny24qw5Xpnu/Zoq9GeYU6IC+kF5OlcOZ9/WGG/KE Q30F3g==

;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 55 ms

de.            172800    IN    NS    a.nic.de.
de.            172800    IN    NS    f.nic.de.
de.            172800    IN    NS    l.de.net.
de.            172800    IN    NS    n.de.net.
de.            172800    IN    NS    s.de.net.
de.            172800    IN    NS    z.nic.de.
de.            86400    IN    DS    26755 8 2 
F341357809A5954311CCB82ADE114C6C1D724A75C0395137AA397803 5425E78D
de.            86400    IN    RRSIG    DS 8 1 86400 2023083105 
2023081804 11019 . 
Pb4neoqNz+vSDNnOh9VFn/eCi9AOy7ZzL3QmZRO2k+xsBRCQZyezRRXp 
+G8fowBatDtq8BSKrdHYNZmkENYUiVJ/bOIAZBdTzRYhg7B4nBrj/dqs 
SdnL+dS/1LKFjI43ttXaoY1Ut3UPPTg+o0lV1c2Mdo50bcP6l6XBa9Dd 
PHTr1Ww8QgDGgkEC0JrtoLemuQOKYDCNFQu3UY0Dg8dmS8Y7L2DjBry8 
vOOd9UashIihFM5ZbLc2yRVNbq5bSc+mB1U/9+sM8h7SClSJMm0aAeB6 
mWpflyCLLKEWYNu0aoLH6nfvSxTjfQoS2exhhUzioY+WaiK/IrI0b7PF rSBo1w==

;; Received 749 bytes from 193.0.14.129#53(k.root-servers.net) in 6 ms

uni-wh.de.        86400    IN    NS    dns-3.dfn.de.
uni-wh.de.        86400    IN    NS    dmz6.uni-wh.de.
uni-wh.de.        86400    IN    DS    6632 14 2 
16556A7A06EC51AF8317D1CEF7EBF9F78D6214B648D83D14007C7820 A2561AF0
uni-wh.de.        86400    IN    RRSIG    DS 8 2 86400 20230831065512 
20230817052512 23418 de. 
ZkkyTC5y59RsxU4WYmFF4VYm9WwZA6MjGUeKoNT2vJO+wEu+Cu2baqSg 
Ty1Qu7jmW1Jq09lWJaVHLczVXQ8OaYygAxAeWZnceUoKJdy9+CrVQz/Q 
9MxfmyoVgQ5Y+nllukSTCzhqf0hwg5Tys2NgytxpbrIBFxj5ve4dfyst 5vY=

;; Received 309 bytes from 194.246.96.1#53(z.nic.de) in 19 ms

uni-wh.de.        3600    IN    A    193.175.243.73
uni-wh.de.        3600    IN    RRSIG    A 14 2 3600 2023083100 
2023081000 6632 uni-wh.de. 
jeJVLcdTgZTEAfbv1wIKrYFracW6//zzHwINZP4jM0hpdz+iYrmld7ss 
uX2sU2ZfXlWClNY6GBd0GKD4yozlk8ZZHb6nnQu+k3TF+4Ti/vGO+XvY 2vcAgcMKstfeY/We

;; Received 191 bytes from 193.175.243.110#53(dmz6.uni-wh.de) in 27 ms

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC error

2023-08-18 Thread Brian Candler via Pdns-users

On 18/08/2023 08:53, Huber, Peter via Pdns-users wrote:


i have strange thing using the pdns resolver. My domain uni-wh.de was 
ok for a long time, now there seems to be a DNSSEC problem and I don’t 
know where this comes from, nor how to fix this.


What I am testing:

delv @193.175.243.110 uni-wh.de

You say the problem is with a "pdns resolver", but 193.175.243.110 is an 
authoritative server, not a recursor.


From the error output you gave, it looks like you're using a tool which 
wants to talk to a recursor:


;; chase DS servers resolving 'uni-wh.de/DS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving './NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/DS/IN': 193.175.243.110#53

Your authoritative server is (correctly) refusing to answer queries for 
domains it is not authoritative for, like ".de" and the root.


There are various online DNSSEC checkers. I checked a couple with 
uni-wh.de and they seem to think it's fine (and I can resolve it fine), 
so I don't think there's any problem.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] listen on net iface

2023-07-28 Thread Brian Candler via Pdns-users

On 28/07/2023 10:07, Klaus Darilion via Pdns-users wrote:

PS: This sound like you want to run PDNS in an active-standby HA-setup with a 
"hot" standby


If it were me, I'd have a pair of dnsdist instances (with the floating 
IP moving between those), which in turn point to the real servers behind.


This has a number of advantages:

- active-active operation (load-sharing)
- can scale to more than 2 back-end servers
- actively sends test DNS queries to each backend every second, and 
takes unresponsive ones out of the pool

- provides lots of metrics 
- binding to an interface name instead of IP is apparently supported 
:


/On recent Linux versions specifying the interface via 
the//|interface|//parameter should work as well./


The issues Klaus raised around master/slave operation still require care 
of course. If you're using native mode with SQL-level replication, 
things may be simpler.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Cannot update server-id

2023-05-26 Thread Brian Candler via Pdns-users

On 26/05/2023 12:01, Kevin P. Fleming via Pdns-users wrote:
I'm pretty sure those are unrelated IDs, and the 'localhost' in the 
API URLs cannot be changed.


Confirmed at https://doc.powerdns.com/authoritative/http-api/server.html

In the PowerDNS Authoritative Server, the|server_id|is 
always|localhost|. However, the API is written in a way that a proxy 
could be in front of many servers, each with their own|server_id|.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] SSL Proxy with PowerDNS

2023-05-05 Thread Brian Candler via Pdns-users

On 04/05/2023 18:21, Tom Barrett via Pdns-users wrote:
I'm looking for a solution for running an SSL proxy with PowerDNS. 
This is a service that will auto-generate SSL certs (such as 
letsencrypt) for each zone.


I think you might be confusing several concepts here, most of which are 
nothing to do with PowerDNS.


Firstly, a TLS certificate is not issued for an entire zone, only 
individual hostnames in that zone (e.g. "example.com" or 
"www.example.com"). As a special case, you can get a wildcard 
certificate for "*.example.com" (but it only matches one subdomain deep)


Secondly, a "proxy" generally means something that passes through user 
traffic. What sort of "proxy" are you looking for?  There are HTTP 
reverse proxies (Apache, Nginx, Traefik...): these decrypt the traffic 
at the proxy, and only work with HTTP, but mean all your keys and certs 
are centralised on the proxy. There are also layer 4 TCP proxies which 
can forward the entire TCP session by sniffing the TLS SNI header (I use 
sniproxy, but I think haproxy can do this too) - in this case the 
traffic remains encrypted end-to-end, but each endpoint host needs its 
own key and cert.


Thirdly, the issuance of certificates is mostly unrelated to your choice 
of proxy.  You might find some proxies have specific helpers available 
for issuing certificates (e.g. I think there's an Apache module which 
can request letsencrypt certs, and kubernetes has cert-manager). But 
often you would deploy a separate tool to do this: either standalone 
tools like certbot, dehydrated, acme.sh; or a centralised tool for 
certificate issuance like certgrinder.  The tool creates the private key 
and certificate, and these are then read in by your webserver or proxy.


Fourthly, the issuance of certificates does not need to involve DNS. The 
only place where DNS might come into play is if you are using the DNS01 
challenge to prove your ownership of a domain (as opposed to the more 
common HTTP01 challenge).  You'll need to use the DNS01 challenge in two 
cases: (1) your hosts do not accept incoming HTTP connections on port 80 
from the Internet; or (2) you want to issue a wildcard certificate.


The DNS01 challenge requires dynamic additional and removal of TXT 
records from the zone.  This is the only point where PowerDNS might get 
involved: your certificate issuance tool will need to be able to 
add/remove those records, e.g. using RFC2136 dynamic DNS updates, or 
using the PDNS API.  If you prefer not to expose your important zones to 
dynamic updates, you can set up a separate zone for the TXT records, and 
statically point CNAMEs at it.  If you delegate that zone to a separate 
DNS server running acme-dns  then 
you can leave dynamic updates in PowerDNS completely disabled.


However this is all quite complicated to get your head around at first, 
so for any server which is reachable from the public Internet and 
doesn't need a wildcard cert, the HTTP01 challenge is likely to be much 
easier to set up.


A proxy which accepts inbound connections from the public Internet will 
be able to get Letsencrypt certs using HTTP01 just fine. Setting this up 
is nothing to do with PowerDNS at all, and therefore I think it would be 
more appropriate to continue your query at the Letsencrypt Community 
forum 


I hope this gives you a few pointers anyway.

Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Strange behaviour with ALIAS/CNAME records

2023-04-17 Thread Brian Candler via Pdns-users

On 17/04/2023 14:56, Andrea Biancalani wrote:

Using the PowerDNS-admin GUI from github

https://github.com/PowerDNS-Admin/PowerDNS-Admin


In that case, I'd suggest your best starting point is to raise your 
problem as an issue with that project, since that's what you're actually 
interacting with.


I don't use PowerDNS-Admin, and I cannot see from the project's minimal 
documentation 
 
even how you configure it to connect to PowerDNS (although I can see it 
has a SQL database for its own state).


If it uses the PDNS HTTP API 
, 
and you can reproduce the problem using direct API calls independently 
of PowerDNS-Admin (e.g. using curl), at that point it may be appropriate 
to raise it as a PDNS issue.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Strange behaviour with ALIAS/CNAME records

2023-04-17 Thread Brian Candler via Pdns-users

On 17/04/2023 14:05, Andrea Biancalani wrote:
after I've applied with success above example.com zone (as you notice 
in attached image)


You appear to be using some sort of (unspecified) front-end web 
application.  It could be editing zone files directly, or it could be 
making direct SQL updates, or it could be using the PDNS API. Depends on 
what it is and how it is configured.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Strange behaviour with ALIAS/CNAME records

2023-04-17 Thread Brian Candler via Pdns-users
I suggest you specify the version of pdns authoritative you're running, 
otherwise this isn't reproducible by anyone.  Also what backend you're 
using and how you're adding/removing records, although I'm guessing it's 
probably the bind backend.



On 17/04/2023 12:50, Andrea Biancalani via Pdns-users wrote:


4) edit the zone example.com and modify contents like this


@    IN ALIAS 60 mytest.example.com.
www IN CNANE 60 @.




5) commit changes, it will popup an error

*RRset www.example.com. IN CNAME: Conflicts with pre-existing RRSET*



(assuming you meant "CNAME" not "CNANE")

The implication is that there is some other record for "www.example.com"

What does the following command show at that point?

dig @x.x.x.x www.example.com. any

(where x.x.x.x is your pdns-auth server's address)




6) delete now the www record and commit changes
7) create now the same record, as before


@    IN ALIAS 60 mytest.example.com.
www IN CNANE 60 @.




8) commit changes, and /voilà /... *SUCCESS: Applied changes successfully.
*


Is it possible that you deleted other records for "www.example.com" at 
the same time?


Again, what does "dig @x.x.x.x www.example.com. any" show at this point, 
and is it different to case 5?



___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] (no subject)

2023-03-14 Thread Brian Candler via Pdns-users

On 14/03/2023 06:45, Raghvendra Choudhary via Pdns-users wrote:
I want to put the DNS of google in the *forwarder* in the 
recursor.conf but i am unable to resolve the DNS form the *forwarder. 
*Please help me to get this configuration in the right way.


The setting you need is forward-zones-recurse 
, 
and the zone to forward for "everything" is a dot by itself.


If this doesn't work, please show what configuration you tried, and what 
error message you get when using it.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] reverse zone ipv4 and ipv6

2023-02-01 Thread Brian Candler via Pdns-users

On 01/02/2023 20:05, Vinícius Dalcin wrote:

where am i going wrong?


(Aside: it's hard to read screenshots rather than text, and I can't copy 
paste from them)


I can't explain why it's not working, but I do see a few odd things.

1. Where does /etc/resolv.conf point on your host?

I note that "nslookup" and "dig" will send to the local *resolver* by 
default.  This shouldn't work for testing an authoritative server, 
unless you have actually configured delegation for your IPv6 block 
(which you haven't). I don't understand how you got it to work for v4 
though.


In any case, better to send your requests explicitly to the right place:

dig @x.x.x.x -x 2804:2b6c::2

where x.x.x.x is the IP address where powerdns authoritative is 
running.  (Note that your /etc/resolv.conf should *not* point to this 
address; it should point to a recursor)


2. What are all those NULL records? I think you need to delete them.

3. I can't copy-paste it, but the record with ID 154 is completely 
broken: it's ip6.arpa under ip6.arpa.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] reverse zone ipv4 and ipv6

2023-02-01 Thread Brian Candler via Pdns-users

On 01/02/2023 18:13, Vinícius Dalcin via Pdns-users wrote:

good I made some adjustments and as for the ipv4 this functional.

When to ipv6 I get REFUSED query response.


Can you show what configuration you made, the exact query you made, and 
the exact response you got back?


Please make sure you don't obfuscate any domain names or IP addresses.  
See 
https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Creating a www CNAME in powerDNS Admin (mysql backend) automatically pointing to @

2023-01-23 Thread Brian Candler via Pdns-users

On 23/01/2023 12:10, Andrea Biancalani wrote:


my default template for new hosting is similar to this


@ SOA ...
@ NS ...
@ MX ...
@ A 192.0.2.1
@  2001:db8::1
www A 192.0.2.1
www  2001:db8::1


but if I try to use this template


@ SOA ...
@ NS ...
@ MX ...
@ ALIAS www. /*(added final dot)*/
www A 192.0.2.1
www  2001:db8::1


I can resolve the www.foo.bar record, but when trying to resolve 
foo.bar I get a "Server failed" answer ( dns-server is not able to 
find foo.bar)


That is as expected. If you add the final dot to www, then you are 
forcing it to resolve the top-level name, literally just "www" (not 
"www.foo.bar"), which of course does not exist.


If this were a BIND zonefile, then "www" without the dot would have the 
current domain appended implicitly.  I haven't tried this with PDNS.


Also, alias records only work if you've configured pdns-auth with a 
resolver to be able to look them up.





Trying to use a template like this instead, gave as result a "RRset 
foo.bar. IN CNAME: Conflicts with pre-existing RRset"



@ SOA ...
@ NS ...
@ MX ...
@ CNAME www. /*(added final dot)*/
www A 192.0.2.1
www  2001:db8::1


That is forbidden by the RFCs. A CNAME cannot exist at the same position 
in the DNS tree as any other records: in your case above, you have SOA, 
NS and MX records with the same label, which conflict with it.




that doesn't happens if I use the zone record as target of the CNAME


@ SOA ...
@ NS ...
@ MX ...
@ CNAME foo.bar. /*(added final dot)*/
www A 192.0.2.1
www  2001:db8::1


That should give the same error - it doesn't make any difference what 
the target of the CNAME is - except if the domain in question is 
foo.bar, then you have a CNAME from foo.bar pointing to foo.bar, which 
is meaningless anyway. It may have been silently discarded.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Creating a www CNAME in powerDNS Admin (mysql backend) automatically pointing to @

2023-01-23 Thread Brian Candler via Pdns-users

On 23/01/2023 08:39, Andrea Biancalani via Pdns-users wrote:


Hello there,

do you know if it is possible with pdns Admin GUI (using mysql backend)


Questions about a particular third-party project which integrates with 
PDNS would be better raised with that third-party project.


There are dozens of admin web interfaces:

https://github.com/PowerDNS/pdns/wiki/WebFrontends

If you are talking about the one called "PowerDNS-Admin" then it has its 
own discussion forum here:


https://github.com/PowerDNS-Admin/PowerDNS-Admin/discussions



@ IN A 1.2.3.4
www IN CNAME *foo.bar*.


so how can I create a functional template to auto add the www record 
in my template based on domain name? Or... can I solve this using an 
ALIAS type or something different?


Suppose you had a template like this:

@ SOA ...
@ NS ...
@ MX ...
@ A 192.0.2.1
@  2001:db8::1
www A 192.0.2.1
www  2001:db8::1

An alias record can be used to simplify it to:

@ SOA ...
@ NS ...
@ MX ...
@ ALIAS www
www A 192.0.2.1
www  2001:db8::1

Or even:

@ SOA ...
@ NS ...
@ MX ...
@ ALIAS webhost.mycompany.com.
www ALIAS webhost.mycompany.com.    ; see [note] below

Behind the scenes, the auth server does a recursive lookup for the ALIAS 
target and returns the A/ records as if authoritative.  It can be 
used to avoid duplicating IP addresses across many zone files.


[note]: that particular one could also be a CNAME; the one above 
couldn't.  But CNAMEs are visible in DNS lookups, whilst ALIAS records 
are invisible.


See also: https://doc.powerdns.com/authoritative/guides/alias.html

HTH,

Brian.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Glue records in PowerDNS and MySQL backend

2023-01-11 Thread Brian Candler via Pdns-users

On 11/01/2023 15:13, Carsten Schmitz via Pdns-users wrote:


Hello,

My case is a bit complicated:

I run a PowerDNS  server with a zone "firstdomain.org" which is using 
a name server name ns1.seconddomain.org .



Please read:

https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/

If you give the actual domain names, we can help you with those domains.

But setting that aside, it sounds like you're asking for something which 
is not supported by any DNS server: replying with out-of-zone 
information in the 'additional' section.


Historically, caches used to accept and store this information, but it 
was used as a source of cache poisoning attacks - so caches were changed 
to ignore it.  As a result, even if you *could* include those hints, 
they would be thrown away.


Caches have to follow the full recursive process to resolve the IP 
address of your domain's nameservers, and that's normal.  As long as 
those A records don't have low TTLs, then caching will mean they rarely 
need to be looked up.  (I'd suggest at least 8 hours, preferably 24, for 
A records for nameservers).


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] stupid recursor question [SOLVED]

2022-12-07 Thread Brian Candler via Pdns-users

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

2022-12-06 Thread Brian Candler via Pdns-users

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

2022-12-06 Thread Brian Candler via Pdns-users

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


Re: [Pdns-users] CNAME Resoluion

2022-12-05 Thread Brian Candler via Pdns-users

On 05/12/2022 17:58, Tony Annese via Pdns-users wrote:
[Error] Record 'enterpriseenrollment.icdf3.org IN CNAME 
enterpriseenrollment.manage.microsoft.com' in zone 'icfd3.org' is 
out-of-zone.


Read the error carefully.

Hint: icdf3.org != icfd3.org

:-)
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] CNAME Resoluion

2022-12-04 Thread Brian Candler via Pdns-users

On 05/12/2022 05:03, Tony Annese via Pdns-users wrote:

Here is the unobfuscated data.


Thank you, because that now makes it possible to help you:

$ dig +norec @ns.whidbey.net. sip.icfd3.org. any
...

;; ANSWER SECTION:
sip.icfd3.org.        3600    IN    TXT    "v=spf1 mx 
include:ess.barracudanetworks.com include:spf.protection.outlook.com ~all"
sip.icfd3.org.        3600    IN    MX    0 
d227914a.ess.barracudanetworks.com.
sip.icfd3.org.        3600    IN    MX    10 
d227914b.ess.barracudanetworks.com.


You cannot have other resource records alongside a CNAME.  That's a 
requirement of the DNS, not of Powerdns specifically.


You should put A/ records there.  Or if you want to avoid the 
duplication of information, you can look into ALIAS records which do 
this for you.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Remove zombie/dead zones on superslave server

2022-11-30 Thread Brian Candler via Pdns-users

On 30/11/2022 10:35, Andrea Biancalani via Pdns-users wrote:
is there a way to be noticed on master's GUI (or slave) of 
zombie/dead zones in superslave server?


Which GUI?



Don't you know about PowerDNS-Admin GUI?

https://github.com/PowerDNS-Admin/PowerDNS-Admin


"Which GUI" is a fair question, because there are many. See:

https://github.com/PowerDNS/pdns/wiki/WebFrontends
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] What are the differences between PowerDNS Authoritative Server and Recursor?

2022-11-26 Thread Brian Candler via Pdns-users

On 25/11/2022 22:10, Michael Hallager (personal) via Pdns-users wrote:
This mailing list, like all the other industry ones, is a place for 
people with some background experience to come and ask a specific and 
clearly stated question.


The context and terms of this list are clearly stated here - where you 
joined:

https://www.powerdns.com/mailing-lists.html


You may find this document useful as well:

http://www.catb.org/~esr/faqs/smart-questions.html#intro


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Configure Powerdns and check if the domain which is not present in Powerdns is tranferring the traffic to 8.8.8.8 .

2022-11-18 Thread Brian Candler via Pdns-users

On 18/11/2022 09:42, Raghvendra Choudhary via Pdns-users wrote:
share me some sample entries  which is insert to the databases.  so it 
wll easy for me I want to copy all the domain entries which is present 
in the my hosts file. 


I'd suggest that you start by reading the PowerDNS documentation, where 
you will find:


https://doc.powerdns.com/authoritative/migration.html#id1

https://doc.powerdns.com/authoritative/backends/generic-sql.html#basic-functionality

https://doc.powerdns.com/authoritative/backends/generic-mysql.html#default-schema


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] SNAT and notify messages

2022-11-17 Thread Brian Candler via Pdns-users

On 17/11/2022 22:48, Michael Hallager via Pdns-users wrote:
I recommend you fix your underlying issues now by getting all your 
servers onto the same net block or net blocks which can route between 
each other without NAT. 


Also I'd suggest fixing the other underlying issue, which is that a 
single IP address is used for answering both recursive DNS and 
authoritative DNS.  If you put the recursor and [ext] authoritative on 
different IPs, then dnsdist can vanish and a lot of complexity disappears.


Since the [ext] authoritative servers would have their own dedicated 
public IPs, then there would be no issue with notifies and zone 
transfers between them.


The [int] authoritative servers can all be bound to private IPs, and can 
be VPN'd together.  The only clients which send requests to them are 
their local recursors.


Unfortunately this does involve config changes, but you have two options:

1. Change the IP address of the recursors: you must change all the 
client machines to point to these new IPs
2. Change the IP address of the ext authoritative servers: you must 
change either the NS records in your public zones, or the A records 
associated with your NS records (and glue records where you have them)


If you choose option 1, and you bind your recursive servers to private 
IPs, then you don't need any extra public IP addresses.


However for performance reasons, it's better if you can give your 
recursors public IP addresses as well.  This is so that the outbound 
queries they send don't have to go via NAT, which could generate a lot 
of NAT states in the NAT router they are sitting behind.  But of course, 
the int recursor *can* share the same public IP address as the ext 
authoritative.


So you could build it like this, if you don't need to serve recursor 
clients on the public Internet, and you can put two 10.x.x.x private IPs 
on each server:


* pdns_server [external] binds to public IP port 53
* pdns_recursor binds to internal IP 1 port 53 . It uses the public IP 
for outbound queries, and forwards requests for local domains 
pdns_server [internal]
* pdns_server [internal] binds to internal IP 2 port 53 (and/or to a 127 
address; the second internal IP is for these servers to do zone transfers)


Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] pdns-recursor ecs support config designs

2022-11-08 Thread Brian Candler via Pdns-users

On 08/11/2022 09:20, Robby Pedrica via Pdns-users wrote:

The CDN services work correctly when a branch uses the ISP-assigned 
DNS for that specific branch/link. But as mentioned, it's difficult to 
manage these DNS entries when you have many branches across the world 
(180 sites with 2 different ISP links at each site). It would be much 
easier if we had a central recursor that could use ecs to determine 
geo-located services for each branch.


The central recursor would be able to see the source IP addresses of all 
the clients, correct?  Would it see the public (post NAT) or internal 
address (e.g. site-to-site VPN)?


The recursor itself doesn't "use ecs" as such, but it could *pass* the 
client's IP address via ecs to the authoritative servers.  However, 
whether the authoritative servers use that information or not is not 
within your control.  They may ignore it, and look at the source IP 
address of the request only (i.e. the IP address of your recursor).  In 
which case, you're stuck.


In any case, getting clients to use a local DNS cache would be much 
better for resilience and performance than routing all queries via a 
central recursor.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] About "null MX"

2022-10-31 Thread Brian Candler via Pdns-users

On 31/10/2022 11:37, De Gubellini via Pdns-users wrote:
Do you know from which version of the authoritative server "Null MX" 
was supported?

This should be the RFC
https://www.rfc-editor.org/rfc/rfc7505

I am asking this because I have an old version of powerdns that I 
can't upgrade in a short time.


It's just a standard resource record. Can you try it and see if it works?

blah.example.com.   IN  MX  0  .


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] IPv6 PTR with gmysql backend

2022-10-20 Thread Brian Candler via Pdns-users

On 20/10/2022 14:17, qutic development via Pdns-users wrote:

Thank you Brian for taking note! That was my bad in the email cause I changed 
the real ipv6-address into a sample one.


https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] IPv6 PTR with gmysql backend

2022-10-20 Thread Brian Candler via Pdns-users

On 20/10/2022 12:55, qutic development via Pdns-users wrote:

In the domains-table there is a record with name 
"0.0.0.0.0.8.b.d.1.0.0.2.ip6.arpa."


That's wrong. It should be 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

- that is, the original address is really 2001:0db8::/48 (when you write 
out all 4 hex digits, and don't omit the leading zero)



___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Protobuf - Telegraf

2022-10-01 Thread Brian Candler via Pdns-users

On 01/10/2022 07:28, Otto Moerbeek via Pdns-users wrote:

The protobuf streams add a framing header of two bytes of length per protobuf 
message.
The receiving side has to take that into account.


Perhaps this issue (still open) is relevant:

https://github.com/influxdata/telegraf/issues/6025


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Is there any option to change the custom RRSIG signature validity in DNSSEC?

2022-08-31 Thread Brian Candler via Pdns-users

On 31/08/2022 20:28, Mohammad Ishtiaq Ashiq Khan via Pdns-users wrote:
Right now, it is set to 3 weeks and after looking at the code, it 
seems like this is fixed at PowerDNS. Please correct me if I am wrong. 


No, you're correct. See:

https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html#signatures

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] (pdns 4.3.0 version) support for RFC2317

2022-08-17 Thread Brian Candler via Pdns-users

On 17/08/2022 00:27, Xandro Gavino via Pdns-users wrote:
I just would like to confirm if the PowerDNS Authoritative Server 
(pdns 4.3.0 version) support the RFC2317. 


pdns 4.3.0 doesn't support anything, because it's end-of-life and 
unsupported:


https://doc.powerdns.com/authoritative/appendices/EOL.html

(unless you have a commercial support agreement, in which case you 
wouldn't be asking here).


However, RFC2317 is classless in-addr delegation, which is only a 
convention for how you build reverse zones containing CNAME records 
pointing to PTR records in another zone.  In other words, it's not a 
feature of the server at all: it's a way of choosing what data to 
populate it with.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] How to hide pdns authoritative server banner

2022-07-11 Thread Brian Candler via Pdns-users

On 11/07/2022 16:22, Wafa BEN KHOUD via Pdns-users wrote:

Can you please explain how to hide pdns authoritative server banner?


Do you mean the version.bind CHAOS TXT record?  If I google "powerdns 
version.bind chaos txt" then I get this as the first hit:


https://doc.powerdns.com/authoritative/settings.html#version-string

If that's not it, please describe which banner you're referring to.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] LUA script for primary server

2022-06-06 Thread Brian Candler via Pdns-users

On 06/06/2022 11:34, Djerk Geurts wrote:

Maybe if I add some examples:

1.2.3.4.5.6.e164.arpa. NAPTR “some text with sip call routing info: AAA”
*.4.5.6.e164.arpa. NAPTR “some different sip call routing info: BBB”

A query for 9.9.9.4.5.6.e164.arpa. will result in BBB
A query for 1.2.3.4.5.6.e164.arpa. yields AAA
A query for 3.3.3.4.5.6.e164.arpa. yields NXDOMAIN

The above is all according to RFC and expected PowerDNS behaviour.


Yep. Depending on your use case and how many domains you have, it might 
be possible to implement


*.e164.arpa. LUA NAPTR "// some LUA code here"

The query name, including the part matched by the wildcard, should be 
available in a query variable 
.


Or there is the Lua2 backend 
 (in the 
Ubuntu packages it's in a separate package "pdns-backend-lua2"), or 
other backends 
 like pipe 
and remote.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] LUA script for primary server

2022-06-06 Thread Brian Candler via Pdns-users

On 06/06/2022 10:52, Djerk Geurts via Pdns-users wrote:
Jun 06 11:28:29 host.example.com  
pdns_server[3559402]: Fatal error: Trying to set unknown setting 
'lua-dns-script’


"lua-dns-script" is not a valid setting for pdns authoritative server. See:

https://doc.powerdns.com/authoritative/settings.html

https://doc.powerdns.com/authoritative/lua-records/index.html

It's not clear what you're trying to do when catching NXDOMAIN 
responses, but having a wildcard LUA record might achieve it.


Otherwise, as you suggested yourself, dnsdist is very powerful. (You 
definitely don't want to use a recursor as your authoritative server though)
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Pdns Authoritative

2022-05-30 Thread Brian Candler via Pdns-users

On 30/05/2022 16:45, Wafa BEN KHOUD via Pdns-users wrote:
s it possible to configure pdns slave with fixed content records? And 
how to do it?


As example:
master records for zone "test.com " are NS 
"ns.test.com " and MX "mx.test.com 
" and slave records are NS "ns.test.com 
" and MX "mx55.test.com "


What are you actually trying to achieve here; or, what problem are you 
trying to solve by this?


The whole point of master and slave is that the slave is an identical 
copy of the master.  If you want these two servers to serve different 
answers, then you need to build two different master servers, with their 
own zone data.


Are you trying to do split DNS (serve different answers to internal 
clients versus external users)?  Or something else? There may be a 
better solution to the problem.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] SOA request MariaDB backend

2022-05-10 Thread Brian Candler via Pdns-users

On 10/05/2022 09:17, Jan-Piet Mens via Pdns-users wrote:

dig @127.0.0.1 zone-name.bo soa +norec


zone-name.bo is NXDOMAIN. 


The longer version of that answer is here:

https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Questions about PowerDNS - CNAME@APEX, Capacity, management, etc...

2022-05-06 Thread Brian Candler via Pdns-users

On 06/05/2022 18:02, Jan-Piet Mens via Pdns-users wrote:

CNAME @ APEX questions:


There is no such thing. "No CNAME and other data" is the rule.


Fired off too quickly. RFC 1912 2.4 clarifies this [1] 


And don't forget that there is the ALIAS pseudo resource record for this 
purpose.


https://doc.powerdns.com/authoritative/guides/alias.html

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNAME randomly failing on Linux clients

2022-04-06 Thread Brian Candler via Pdns-users

On 06/04/2022 10:44, Adam Cecile wrote:
If at all possible, I'd suggest you simply run auth and recursor 
bound to separate IP addresses - whether that be on the same host, or 
in VMs or containers.  Then you point your clients at your recursor 
IP(s), your NS records at your auth server hostname(s), and dnsdist 
isn't required.
Well that'd make things more complicated because the server running 
authoritative do need to use recursor facilities too :D


That's not an issue.

If the server needs to *use* recursor facilities, then you point its 
resolv.conf to whatever IP address your recursor is bound to - whether 
this is on the same host, or a different host makes no difference.


Normally you'd dedicate a server to auth (or VM or container), and point 
to a separate recursor - well, two recursors for redundancy.  But if you 
run both auth and recursor on the same server/VM, but bound to different 
IPs, that will work too.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNAME randomly failing on Linux clients

2022-04-06 Thread Brian Candler via Pdns-users

On 06/04/2022 10:25, Adam Cecile via Pdns-users wrote:
I need some recursion / logging facilities so I added on top of them 
(same machine) pdns-recursor or dnsdist. I first went for recursor but 
ended up thinking dnsdist was more flexible (especially on filtering 
updates / axfr, you're right).
If at all possible, I'd suggest you simply run auth and recursor bound 
to separate IP addresses - whether that be on the same host, or in VMs 
or containers.  Then you point your clients at your recursor IP(s), your 
NS records at your auth server hostname(s), and dnsdist isn't required.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNAME randomly failing on Linux clients

2022-04-06 Thread Brian Candler via Pdns-users
If I understand that right: you have dnsdist and auth running on the 
local server, and recursor is on a remote server?


If your requirements are simple, for basic DNS querying you may not need 
dnsdist at all.  Just run the recursor on port 53, and use forward-zones 
/ forward-zones-recurse as you do today. Looking at your config though, 
maybe it's to do with AXFR/IXFR requirements though.



Any idea ? I can definitely make TCPDumps at some point but I'm not 
sure to able to understand them ;-)
If the above statement is true, you'll need two simultaneously, in 
separate windows:


tcpdump -i lo -nn -s0 -v port 53 or port 5353

tcpdump -i eth0 -nn -s0 -v port 53

It should decode the packets for you, so it should be clear. (Except 
port 5353. New version of tcpdump have "-T domain" to force decoding as 
DNS, but you'll need a very recent version; Ubuntu 20.04 is not new enough)


The tcpdumps will show:

- queries from dig to dnsdist (53) and dnsdist to auth (5353)
- queries from dnsdist to recursor

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNAME randomly failing on Linux clients

2022-04-06 Thread Brian Candler via Pdns-users

On 06/04/2022 09:36, Adam Cecile via Pdns-users wrote:
Any idea what's going on here, I'm completely lost. I guess my DNAME 
usage is somehow incorrect but I don't understand why it's working 
intermittently (and always with pure DNS call using dig...)


Just a thought, but does your system use systemd-resolved? (Clue: 
/etc/resolv.conf points to nameserver 127.0.0.53).  For example, it may 
treat ".local" differently, given that domain is reserved for multicast 
DNS (as dig output informs you); or there may be some DNSSEC issue.  
"systemd-resolve --status" may give you some clue.


Apart from that, I suggest you look at the raw queries and responses on 
the wire, and see how this differs between using direct dig and 
gethostbyname:


tcpdump -i eth0 -nn -s0 -v port 53

(replace "eth0" with whatever your external interace is)

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] zone forwarding in 4.0.6

2022-04-05 Thread Brian Candler via Pdns-users

On 04/04/2022 23:57, Brian Lehnhardt via Pdns-users wrote:


It seems like this should just work, but perhaps I am missing 
something. I'm using an older version of pdns as you can see from my 
config, and I can't seem to find any documentation on this older 
version. Any idea what I'm doing wrong here?



Indeed you are using a very old, unsupported version:

https://doc.powerdns.com/authoritative/appendices/EOL.html
https://doc.powerdns.com/recursor/appendices/EOL.html

When you do migrate to supported versions, note that authoritative and 
recursor have now been fully split: the authoritative server since 4.1.0 
cannot do any recursion at all (*).  There are some migration options in 
this article:


https://doc.powerdns.com/authoritative/guides/recursion.html

If you really, really need a single IP address to respond to both 
authoritative and recursive queries, then it's possible to put dnsdist 
in front of them both.  However I would suggest that you split them 
properly:


- bind pdns-recursor to one IP address
- bind pdns-auth to another IP address (or put it in its own VM or 
container)


You then configure your end clients to point to the recursor, and your 
NS records point to the authoritative server.


You can still forward queries from pdns-recursor to pdns-auth, e.g. for 
private zones.  Depending on whether the parent domain has DNSSEC 
enabled, you may need to set a Negative Trust Anchor for the subdomain.


So to do what you're want with modern powerdns, you need to swap the 
roles around: clients must send their queries to the recursor, not the 
authoritative server.  Hence you could bind the recursor to port 53, and 
auth to 5353 - as long as no external queries arrive at the auth server 
(i.e. it's completely private, no NS records point at it).


Regards,

Brian.

(*) pdns-auth can still make use of a resolver 
 but this 
is only for when it needs to resolve things for itself, like ALIAS records.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Recursor and forward-zones-file

2022-03-17 Thread Brian Candler via Pdns-users

On 17/03/2022 15:50, Pepe Charli wrote:
But the idea is to have in the future a file forward-zones-file of the 
type

test1.com =192.168.1.1
test2.com =192.168.1.2
.=192.168.68.63, 192.168.68.64


I think dnsdist is better for that application - it's what it's designed 
for. For example, it actively tests the backends with a query every 
second, so failover is faster.


# sample configuration

setACL({'192.168.0.0/16','10.0.0.0/8'})

newServer({address='192.168.68.63', pool='default'})
newServer({address='192.168.68.64', pool='default'})
newServer({address='192.168.1.1', pool='test1'})
newServer({address='192.168.1.2', pool='test2'})

addAction({'test1.com.'}, PoolAction('test1'))
addAction({'test1.com.'}, PoolAction('test2'))
addAction(AllRule(), PoolAction('default'))
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] ddns: no A records created, only PTR

2022-03-17 Thread Brian Candler via Pdns-users

On 17/03/2022 15:37, Patrick Bervoets via Pdns-users wrote:


ddns-domainname "psc-elsene.be";
ddns-rev-domainname "in-addr.arpa.";
zone psc-elsene.be { primary 127.0.0.53; key dhcpdupdate; }
zone 103.103.10.in-addr.arpa. { primary 127.0.0.53; key dhcpdupdate; }

...
  set ddns-client-fqdn = "vpc2102.PSC-ELSENE.BE";
  set ddns-rev-name = "12.103.103.10.in-addr.arpa.";

In the above places you have trailing dots on "arpa" but not on "be". 
That might not be the issue, but it is worth checking.


domainmetadata
|id |domain_id|kind    |content    |
|---|-||---|
|5  |10   |TSIG-ALLOW-DNSUPDATE|dhcpdupdate    |
|7  |15   |TSIG-ALLOW-DNSUPDATE|dhcpdupdate    |
|9  |10   |ALLOW-DNSUPDATE-FROM|127.0.0.0/8    |
|10 |15   |ALLOW-DNSUPDATE-FROM|127.0.0.1  |
|13 |10   |ALLOW-DNSUPDATE-FROM|10.103.103.0/24|

These aren't consistent, but since zone 15 is working, zone 10 should be 
OK. In any case, you can use tcpdump to check what is the source address 
of the DDNS update packets (and should also decode their contents)


tcpdump -ilo -s0 -nnv port 53

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Recursor and forward-zones-file

2022-03-17 Thread Brian Candler via Pdns-users

On 17/03/2022 15:26, Pepe Charli wrote:
     In the traces only the domain has been changed to test.com 


     192.168.68.63 and 192.168.68.64 are autoritatives for this domain.
     Both resolver and authoritative are only used internally with 
private IPs


Are 192.168.68.63/64 authoritative-only servers (like pdns auth), or 
mixed recursor+authoritative (like bind)?


If they are authoritative-only, this implies the recursor can never 
resolve a public DNS name. In that case, the recursor seems to serve 
little purpose: you could point the clients directly at the 
authoritatives, or use dnsdist to forward the queries.


If they are mixed, and you want to be able to resolve names in the 
public DNS, then you will need "+." in your forward-zones-file in the 
pdns recursor.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Recursor and forward-zones-file

2022-03-17 Thread Brian Candler via Pdns-users

Hmm, see also:

https://github.com/PowerDNS/pdns/issues/10638
https://github.com/PowerDNS/pdns/pull/10643

But this was backported to the 4.4 branch, and should be present in 
recursor 4.4.7:


https://github.com/PowerDNS/pdns/pull/10654


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Recursor and forward-zones-file

2022-03-17 Thread Brian Candler via Pdns-users

On 17/03/2022 12:04, Pepe Charli via Pdns-users wrote:

The recursor is configured to forward all zones to other DNS servers

forward-zones-file=/path/to/file
and the file itself contains
.=192.168.68.63, 192.168.68.64


If you're forwarding the whole world then you need a plus sign for the 
request to be sent with the "recursion desired" bit:


+.=192.168.68.63, 192.168.68.64

See: https://docs.powerdns.com/recursor/settings.html#forward-zones-file

You haven't said anything about the configuration of the servers 
192.168.68.63 and .64.  If they are authoritative servers for test.com, 
then this doesn't explain the problem with a query for orac2-scan.test.com.


However, I suspect you don't actually own the "test.com" domain, so you 
should also see 
https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Immediate update visibility

2022-03-09 Thread Brian Candler via Pdns-users
Thanks to Otto for explaining about the recursor notify feature in 4.6.0 
- this is very cool and I wasn't aware of it.


I think the OP is observing two different problems, and that would solve 
one of them.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Immediate update visibility

2022-03-08 Thread Brian Candler via Pdns-users

On 09/03/2022 07:08, Daniel Miller via Pdns-users wrote:
Anyway, after all that - when I make a change to a domain record using 
pdnsutil or an external tool using the API - the changes are 
immediately applied to the zone but are not immediately visible 
through the recursor. To make that happen I need to either flush the 
cache or just restart the recursor.


This is an issue when creating/updating ACME challenge records - I 
haven't been able to totally automate the process. I need to introduce 
lengthy delays, try manually applying the changes, restart the 
servers, whatever.


That doesn't really make sense as an explanation of whatever problem you 
see.


1. LetsEncrypt will be talking to your authoritative server, not your 
recursor.


2. Even if it were talking to the recursor, it would be querying 
_acme-challenge.somedomain TXT. Unless that query had been made 
recently, it won't be in the recursor's cache.


If you're hitting a caching problem here, it's not to do with the 
recursor, but either the packet cache or the query cache in 
pdns-authoritative. See: 
https://doc.powerdns.com/authoritative/performance.html#packet-cache


If LetsEncrypt had queried _acme-challenge.somedomain TXT a few seconds 
before you had changed the zone, and then again afterwards, it could see 
the old data. However, that shouldn't be happening: you should be 
inserting the TXT record *before* LetsEncrypt does the query. Therefore, 
although you can disable those caches, you shouldn't really need to do so.


The most likely problem I can think of is that your authoritative zones 
are replicated, and there's some delay in updates to the primary getting 
replicated to the secondaries.  Remember that LetsEncrypt could query 
*any* of your auth nameservers with equal probability.


One solution is to ensure that notifies are working properly, and then 
insert a short (say 5 second) delay in your ACME process to ensure it 
has had time to complete.


Another solution is to get LetsEncrypt to talk to a single instance, by 
putting a single NS record wherever you need:


_acme-challenge.www.example.com.  NS  ns-primary.example.com.

If you wish, this approach also lets you have a completely separate 
authoritative server, dedicated to handling ACME challenges. That in 
turn can be something that accepts dynamic updates, without having to 
allow dynamic updates on your main infrastructure.


If you need to debug this further, I suggest you capture the data 
between LetsEncrypt and your authoritative servers, with query logging 
or at worst using tcpdump, to work out what's going on.





is there a way to make changes in the auth server immediately visible 
in the recursor?


You mean, clients using your local recursor are querying local zones and 
seeing stale data? That's a completely different matter: that's just 
standard recursor caching, and it's how the DNS is designed.


You can avoid that by setting a low TTL on the records in your zone, and 
for negative caching using the "minimum" parameter in the SOA record.  
In the extreme, you'd set those to zero, and then the recursor would 
directly forward all queries to the authoritative server - but something 
like 60 seconds is more system friendly.  You might as well get *some* 
benefit from the recursor cache.


Or else, whenever you bump the auth zone, you can flush the 
corresponding recursor zone - but that's a step you'd have to do yourself.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Low ttl with combination of forward zones makes queries fail

2022-02-08 Thread Brian Candler via Pdns-users

On 08/02/2022 12:24, Thomas Mieslinger via Pdns-users wrote:

But remember, pdns_recursor does not do background checking whether a
Nameserver is alive. Background checking is only done by dnsdist afaik. 


That's a good point.  dnsdist continuously sends one query per second to 
each backend to check it's alive.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Low ttl with combination of forward zones makes queries fail

2022-02-08 Thread Brian Candler via Pdns-users

On 08/02/2022 12:08, Prochazka via Pdns-users wrote:


Pdns recursor config:

...
forward-zones=
forward-zones+=some.domain.tld=AUTH1_ipv6
forward-zones+=some.domain.tld=AUTH1_ipv4
forward-zones+=some.domain.tld=AUTH2_ipv6
forward-zones+=some.domain.tld=AUTH2_ipv4
forward-zones+=some.domain.tld=AUTH3_ipv6
forward-zones+=some.domain.tld=AUTH3_ipv4
forward-zones+=some.domain.tld=AUTH4_ipv6
forward-zones+=some.domain.tld=AUTH4_ipv4
...


Have you tried listing the destinations on the same line, separated by 
semicolons ?


forward-zones+=some.domain.tld=AUTH1_ipv6;AUTH1_ipv4;AUTH2_ipv6;...etc

Personally I would use forward-zones-file to make this cleaner. Also, I 
wouldn't forward to both ipv4 and ipv6 on the same server; if the server 
is down, it's going to be unreachable via both.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PowerDNS Recursor Performance and Tuning

2022-01-19 Thread Brian Candler via Pdns-users

On 19/01/2022 09:54, Hamed Haghshenas via Pdns-users wrote:
How can I secure my dns Recursor? I try read document about dnssec in 
powerdns wiki but can’t understand what should I do ?


https://doc.powerdns.com/recursor/dnssec.html

In short:

dnssec=validate
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] How to make Authoritative work?

2022-01-18 Thread Brian Candler via Pdns-users

On 18/01/2022 15:03, jrd-p...@jrd.org wrote:

Let's get back to my original question:  How do I get pdns, with no
recursor in the picture, to believe that it's authoritative for a zone?


(Presumably by "pdns" you mean "pdns authoritative server")



When I it hit with a query, I get

root@f3-kong-dyndns /etc/powerdns # dig -p 5300 jrd.org soa @localhost

; <<>> DiG 9.16.22 <<>> -p 5300 jrd.org soa @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37408
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available


That looks right to me. flags: aa = authoritative answer set on the 
reply.  What do you expect to be different?


If you want to avoid the "recursion requested but not available" 
warning, use dig +norec


dig +norec -p 5300 jrd.org. soa @localhost

Note that if the server wasn't authoritative for the requested zone, it 
would reply to the query with REFUSED.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] How to make Authoritative work?

2022-01-18 Thread Brian Candler via Pdns-users

On 18/01/2022 14:38, jrd-p...@jrd.org wrote:

. . . but when I query direct to the pdns, it also doesn't say it's
authoritative.  See previous mail.


Sorry, I missed that mail.  Did you send a dig directly to port 5300?  I 
didn't catch that.



I probably need to go back and re-read the DNS specs.  It's been years
since I was deep into this, but I don't remember that a recursor
always returns non-authoritative, even when wherever it got the answer
was authoritative.  Did that behaviour change somewhere along in
there?


I don't think it's changed, although bind may have performed in an odd 
way (e.g. returning AA for the first answer from cache, non-AA for 
subsequent)


Even from the very oldest spec, RFC1035:

AA  Authoritative Answer - this bit is valid in responses,
and specifies that*the responding name server is an authority for the domain name in 
question section*.


A recursor is not an authority for the name.


Assuming I'm simply mis-remembering how that's supposed to work,
what's the recipe for setting up a local (set of) server(s) which:
   .  Returns authoritative for some zones, for which it has local data
   .  Recurses to other servers for other zones


You Really Don't Want To Do That™.

If you think you must (and continue to use powerdns), then you can look 
at putting dnsdist in front of pdns-auth and pdns-recursor.  But really, 
really you don't.  Just give your cache(s) their own IP addresses, and 
your authoritative server(s) their own IP addresses.  This is how DNS is 
supposed to work.


The only reason I can think of for not doing that is that you need to 
share a single public IP address between recursor and authoritative; but 
then you might as well just put your recursor behind NAT.  Either way, 
it doesn't scale, and pdns is designed for ISP-scale deployments.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] How to make Authoritative work?

2022-01-18 Thread Brian Candler via Pdns-users

On 18/01/2022 13:55, jrd-p...@jrd.org wrote:

Oops.  Yes.  Port 53 has a pdns-recursor listening on it, which is
feeding requests to pdns.  Want the recursor config too?


No need.  You asked why the response didn't have the AA flag set, and 
the answer is because the response came from a recursor - it's as simple 
as that.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] How to make Authoritative work?

2022-01-18 Thread Brian Candler via Pdns-users

On 18/01/2022 12:19, jrd via Pdns-users wrote:

root@f3-kong-dyndns /etc/powerdns # dig jrd.org soa @localhost

; <<>> DiG 9.16.22 <<>> jrd.org soa @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58908
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; Query time: 90 msec
*;; SERVER: 127.0.0.1#53(127.0.0.1)*


RD = recursion desired, RA = recursion available.  Are you *sure* it's 
powerdns authoritative that you're talking to on localhost port 53?!


Ah, digging through your config:

> # local-port=53
> local-port=5300

Clearly, it isn't.  Your dig query is going to something else 
(unspecified) which is listening on port 53.  That'll be why you're not 
getting AA.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PowerDNS Recursor Performance and Tuning

2022-01-16 Thread Brian Candler via Pdns-users

On 16/01/2022 09:41, Hamed Haghshenas via Pdns-users wrote:

quiet=no

I need the logs and should export domains to my analyzer platform .


There are more scalable ways of doing this.  The "standards-compliant" 
way is dnstap:


https://dnstap.info/
https://docs.powerdns.com/recursor/lua-config/protobuf.html#logging-in-dnstap-format-using-framestreams

You'll need to install a separate dnstap collector to receive the messages.

Note that powerDNS has a dependency on the "fstrm" library:

https://mailman.powerdns.com/pipermail/pdns-users/2020-June/026725.html

If you have an older version of fstrm then you can only log to a local 
unix domain socket (which may be fine, it just means running your dnstap 
collector on the same host).  A newer version is required if you want to 
log to a remote host over TCP.


I don't know about versions in RHEL/CentOS, but Ubuntu 18.04 has 
libfstrm0 version 0.3.0, and that only does unix domain sockets.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PowerDNS with LDAP backend / TFTP-Server for PXE boot

2022-01-13 Thread Brian Candler via Pdns-users

On 13/01/2022 19:00, Stefan Harbich via Pdns-users wrote:

I have set up a PowerDNS server with an LDAP backend. I would like to
install a TFTP server and wanted to ask if I can set up the following
in the PowerDNS LDAP backend?
...
When configuring your DHCP server you will need to add the ‘next-
server’ directive to your DHCP configuration file, this directive
should have the IP address of your TFTP server i.e. (next-server
192.168.0.1;). The second directive that needs to be added to your DHCP
configuration file is ‘filename’ and it should have the value of
‘pxelinux.0’ i.e. (filename “pxelinux.0”;) this will enable PXE
booting.
...

The TFTP server should be an atftpd server service and not administer
any DHCP addresses.


Sorry, can you explain in what way your desired TFTP server is related 
to your PowerDNS (auth) server? I can't think of any way in which they 
are connected.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Recursor - force IPv6

2021-11-16 Thread Brian Candler via Pdns-users

On 16/11/2021 08:57, Otto Moerbeek wrote:

I set "query-local-address=0.0.0.0,::" to allow the recursor to use both.

I think since 4.5 we do the right thing and*only*  use v6 if you set 
query-local-address=::
But that has the consequence that a lot of (v4 only) nameservers become 
unreachable.


Ah yes: sorry I misunderstood the OPs requirement "force usage of 
IPv6".  They wanted something less strong: prioritise IPv6 (if both 
available).


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Recursor - force IPv6

2021-11-16 Thread Brian Candler via Pdns-users

On 16/11/2021 08:29, Otto Moerbeek via Pdns-users wrote:

Is there possible to get similar to unbound command to force usage of IPv6 in 
PDNS Recursor?

prefer-ip6: 
 If enabled, prefer IPv6 transport for sending DNS queries to internet 
nameservers. Default is no.


Thanks,

No, we do not have an equivalent option.

pdsn_recursor will use both protocols and figure out what works best
per domain and nameserver.  Periodically it wil keep trying
alternatives to see if the situation changed.


What happens if you set

query-local-address=::

or

query-local-address=yo:ur:ip:v6::addr:ess ?

I note that the default is "query-local-address=0.0.0.0" and this only 
sends outbound queries on IPv4.


I set "query-local-address=0.0.0.0,::" to allow the recursor to use both.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Best practice for serving a few public domains + auth/recursion for VMs & VPN clients

2021-10-04 Thread Brian Candler via Pdns-users

On 04/10/2021 13:44, Patrick Laimbock via Pdns-users wrote:
New to the list & PowerDNS. Pleased to meet you. I have about 50 
domains, 10 VMs and 10 VPN clients I would like to setup DNS for. I 
went through DuckDuckGo and a bunch of ML archives but did not find 
any hints of a best practice architecture for this small setup. I did 
find:


https://doc.powerdns.com/authoritative/guides/recursion.html#scenario-2-authoritative-server-as-recursor-for-clients-and-serving-public-domains 



Is this deduction of scenario 2 "New situation" pic on the right correct?

Internet -> dnsdist -> auth (for serving the public zones)
VMs/VPN clients -> dnsdist -> auth (for public/private zones)
VMs/VPN clients -> dnsdist -> recursor -> Internet (for the rest) 


No. There's no need for dnsdist unless you have a specially complex or 
unusual installations.  It's only shown that way in the document you 
quote for people who are *forced* to put both authoritative and 
recursive nameservice on the same IP address, for legacy reasons or 
because of bad planning.


All you want is:

* Internet -> auth  (for serving the public zones) [note 1]

* VMs/VPN clients -> recursor [note 2, 3]


[note 1]: public zones need to be served by at least *two* auth servers 
located in at least two different networks (autonomous systems), and 
preferably different continents.  See RFC 2182.


[note 2]: you probably want two recursors for redundancy too.

[note 3]: as long as your public zones are properly public and 
delegated, there is no need to point your recursor at your auth servers: 
the recursor will follow the published NS records just like everyone else.


However if you have *private* domains, that are only visible to your own 
recursor users, that's when you look at using forward-zones - and you 
might have to use negative trust anchors (NTA) if these private domains 
are subdomains of a DNSSEC-signed zone.  It's much simpler just to keep 
the DNS public.


Your authoritative nameservers need public IPs; your recursors can be 
behind NAT.


HTH,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] error which prevented lookup Out of range exception

2021-09-30 Thread Brian Candler via Pdns-users

On 30/09/2021 17:39, Oliver Dzombic via Pdns-users wrote:

In 4.3 Versions this SOA record worked:

ns3.isp4p.net hostmas...@isp4p.net 2006040100

Now with a new server

ns3.cloud-interactive.de i...@cloud-interactive.de 2021093000

or

ns3.cloud-interactive.de 2021093000

or

ns3.cloud-interactive.de

nor other combinations do not work.




Those don't look like complete SOA records.  Can you try this?

ns3.cloud-interactive.de.info.cloud-interactive.de. 2021093000 14400 
3600 2419200 60


As well as the extra fields, the contact E-mail address in the RNAME 
field needs the '@' changed to '.'


See: https://en.wikipedia.org/wiki/SOA_record

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Prevent external lookup of (private) subdomains

2021-09-23 Thread Brian Candler via Pdns-users

On 23/09/2021 14:31, inform...@trinaxab.se wrote:

I don't necessarily need to use PowerDNS for the ACME DNS server, so I might 
employ bind with the former plugin instead, since it's only going to be a 
minimal DNS configuration.


Exactly.  You can stand up a separate nameserver purely for responding 
to ACME challenges, and delegate to it using


intra.example.com.  NS  acme-ns.example.com.

You don't even need to run multiple nameservers, because the normal 
RFC2182 redundancy requirements don't come into play here. That makes 
answering DNS01 challenges much faster, as you don't need to wait for 
updates to replicate to secondary nameservers.


If you want to issue certs for hosts which are not under 
intra.example.com, you can still do so: just add static NS records like


_acme-challenge.www.example.com. NS acme-ns.example.com.

for each name that you want to issue a cert for.  Best practice is to 
create separate zones for these on your acme-ns nameserver, with 
different TSIG keys, so that each host is only able to issue certs for 
its own hostname(s).


I like this approach because you can keep your robust, static public DNS 
as-is, and not have to introduce any dynamic DNS updates into it.


Regards,

Brian.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Prevent external lookup of (private) subdomains

2021-09-22 Thread Brian Candler via Pdns-users

On 22/09/2021 10:54, inform...@trinaxab.se wrote:

July 9, 2021 5:12 PM, "Brian Candler"  wrote:


On 09/07/2021 15:29,inform...@trinaxab.se  wrote:


Specifically, the intention is to use a single wildcard certificate 
*.intra.example.com rather than
one for each subdomain. I don't know if that changes anything.

No difference. You just need to be able to insert TXT records in the zone

_acme-challenge.intra.example.com

to get a wildcard cert for *.intra.example.com. (Note that wildcard certs only 
match one level:
e.g. "accounts.intra.example.com" will match but not 
"mail.accounts.intra.example.com")

How do I set this up? I haven't really worked with DNS on this level before. I 
find things relating to DNS updates, AXFR, TSIG and master/slave 
configurations, but I'm not sure which of those are relevant.


In short:

- if you've decided to use PowerDNS as the authoritative server for 
intra.example.com, you need to choose a backend which allows dynamic 
updates (i.e. not the BIND backend; one of the SQL ones will be fine)
- you need to enable dynamic updates (e.g. using TSIG or via the API 
depending on how you're going to perform the updates)

- you need to configure your ACME client to perform the updates.

For example, "dehydrated <https://dehydrated.io/>" is a shell script for 
obtaining certificates, and here's a script which can do TSIG updates 
<https://github.com/dehydrated-io/dehydrated/wiki/example-dns-01-nsupdate-script>. 
Here are others which can do direct mysql updates 
<https://github.com/antoiner77/dehyrated-pdns> or API updates 
<https://github.com/silkeh/pdns_api.sh>.


I've not tested any of these with PowerDNS (I use bind for LetsEncrypt 
as it doesn't need a database), so I'm afraid you need to put these bits 
together yourself.


Make sure you point at the LetsEncrypt "staging environment" while 
you're testing this, otherwise you'll hit rate limits that will prevent 
you making further API calls to LetsEncrypt for several hours.  Once all 
the challenge/response stuff is working, then switch to the production 
environment to get real certs.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PowerDNS issues

2021-09-10 Thread Brian Candler via Pdns-users

On 10/09/2021 10:07, Andrey Sedletsky via Pdns-users wrote:

One last question.
Our company would like to have commercial support for your product. 
Is this possible and, if so, what needs to be done for this ?

Below is the link to the attachments:
https://cloud.mail.ru/public/3y53/RzaP6z2a6


Beware: I checked that link with curl, and it contains a bunch of 
Javascript and a massive embedded base64 binary payload which pretends 
to be an image/gif:


background-image:url("data:image/gif;base64,R0lGODlhLQAtAOZ/AGm27CmW5Dm

I suppose it *might* be a pdns log wrapped in some cloud fluff, but I 
don't want to find out - and it couldn't look more suspicious if it tried.


If this is a genuine query, I suggest the OP posts a link to a text log 
file instead.  Otherwise, steer cleer.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Server Hostname not visible

2021-09-02 Thread Brian Candler via Pdns-users

On 02/09/2021 07:12, SOLIT | Michael via Pdns-users wrote:


I’m trying to add the server hostname to PowerDNS. This does not seem 
to work.


When I do an nslookup to the specific PowerDNS server I get back that 
the server hostname is Unknown.



Sorry, but this question has nothing to do with PowerDNS at all.

Firstly, nslookup is part of the bind suite of tools, and the behaviour 
is local to nslookup.  Secondly, you are using Windows, which has 
Microsoft's obsolete and forked version of bind/nslookup.


Try using the Linux version of nslookup and you'll see the difference:

# nslookup solit.nl ns1.globe.hosting
Server:        ns1.globe.hosting
Address:    5.44.79.65#53

Name:    solit.nl
Address: 5.44.79.60


The above example was run on Ubuntu 18.04.5 LTS, which has the nslookup 
from bind 9.11.3


# which nslookup
/usr/bin/nslookup
# dpkg-query -S /usr/bin/nslookup
dnsutils: /usr/bin/nslookup
# dpkg-query -l dnsutils
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture   
Description

+++-==-==-==-=
ii  dnsutils   1:9.11.3+dfsg-1ubuntu1 
amd64  Clients provided with BIND


HTH,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] API listening address/port

2021-08-20 Thread Brian Candler via Pdns-users

On 20/08/2021 21:31, MRob via Pdns-users wrote:

Hi, the API docs shows that it listens at 127.0.0.1:8081

I only see 3 api config vars-- is there any settings for API listening 
port or interfaces? 


You need to set configuration setting "webserver-address":

https://doc.powerdns.com/authoritative/http-api/index.html

https://doc.powerdns.com/authoritative/http-api/index.html#enabling-the-api


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Logging outgoing queries and responses

2021-08-04 Thread Brian Candler via Pdns-users

On 04/08/2021 10:49, Hamed Haghshenas via Pdns-users wrote:


and add to it :

protobufServer(server[[[ ,logQueries=true], logResponses=true] 
,exportTypes={'A', '', 'CNAME', 'MX', 'NS'}]);


I don't think those square brackets are meant to be there literally; 
rather they're saying that logQuestions, logResponses and exportTypes 
are optional.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PowerDNS admin Configuration

2021-07-20 Thread Brian Candler via Pdns-users

On 20/07/2021 13:05, Bill Pye via Pdns-users wrote:
I don't know why you think PowerDNS-Admin is not maintained any more 
or had it's last code change two years ago. It is under continued 
development but I'm guessing you're not talking about this product: 
https://github.com/ngoduykhanh/PowerDNS-Admin 



Perhaps the o/p is also talking about another product?


Possibly it was misconstrued as the old but widely-known PowerAdmin 
, which is a PHP application.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Why does pdns-recursor fail to resolve: data.public.lu

2021-07-12 Thread Brian Candler via Pdns-users

What version of pdns-recursor?
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Prevent external lookup of (private) subdomains

2021-07-09 Thread Brian Candler via Pdns-users

On 09/07/2021 15:29, inform...@trinaxab.se wrote:
Specifically, the intention is to use a single wildcard certificate 
*.intra.example.com rather than one for each subdomain. I don't know 
if that changes anything.


No difference.  You just need to be able to insert TXT records in the zone

_acme-challenge.intra.example.com

to get a wildcard cert for *.intra.example.com.  (Note that wildcard 
certs only match one level: e.g. "accounts.intra.example.com" will match 
but not "mail.accounts.intra.example.com")


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Prevent external lookup of (private) subdomains

2021-07-09 Thread Brian Candler via Pdns-users

On 09/07/2021 14:43, informant--- via Pdns-users wrote:
I intend to set up a PowerDNS authoritative server and recursor, where 
a few subdomains will be forwarded to the auth server for internal use 
only. (local IP addresses) We do not wish to allow lookups for these 
domains by any external host. So far, so good.


Now, additionally, I would like to employ Let’s Encrypt certificates 
for these private services by using DNS wildcard challenge. This, of 
course, requires that the DNS server be public. My question, then, is 
can I set up PowerDNS in such a way that the DNS server allows the 
necessary lookups required to complete the DNS challenge, but prevents 
lookups for any subdomains by any external host?


You have a domain like "int.example.com" where you don't want any names 
to be visible to the outside world, but you want to be able to obtain 
certificates for them.  Correct?


The way I deal with this is to have a separate nameserver, say 
ns-acme.example.com, and delegate int.example.com to that server (in the 
public DNS):


int.example.com.  NS  ns-acme.example.com.

The zone file on ns-acme is empty, so if anyone tries to resolve 
XXX.int.example.com they'll get NXDOMAIN.  However, you also set up TSIG 
zones on this server so that servers can response to DNS01 challenges.


You can either just have a single TSIG record which allows all updates 
to the domain; or (more securely) you can create separate zones on the 
nameserver, e.g.


_acme-challenge.foo.int.example.com
_acme-challenge.bar.int.example.com

so that the servers foo.int.example.com and bar.int.example.com have 
separate TSIG keys, and can only issue certs for themselves.


Any lightweight authoritative DNS server that supports TSIG updates is 
fine - e.g. powerdns with SQLite backend, BIND with filebackend.


Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PowerDNS suddenly refuses to resolve

2021-06-24 Thread Brian Candler via Pdns-users

On 24/06/2021 12:03, Laurie Brown via Pdns-users wrote:

One of my pdns name servers has suddenly stopped resolving, giving a
status to dig of status: REFUSED. I have no idea why as it was working
perfectly well for several days (it's a new installation).


Quite possibly because it's not running powerdns at all, it's running 
bind 9 - or at least claims to be.


$ dig +short @ns6.convergent-ict.com version.bind txt chaos
"9.16.1-Ubuntu"
$ dig +short @ns7.convergent-ict.com version.bind txt chaos
"PowerDNS Authoritative Server 4.2.1"

Maybe what has happened is that someone has installed/started bind on 
that server, it bound to port 53, and this in turn is stopping powerdns 
from starting.


BTW, this makes it very clear why the "out in the open" support policy 
is so important! :-)


Also, do note that powerdns 4.2 is due to go end-of-life soon:

https://doc.powerdns.com/authoritative/appendices/EOL.html

Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Zone transfert rejected in Powerdns Letsencrypt challenge

2021-06-23 Thread Brian Candler via Pdns-users

On 23/06/2021 08:54, Cheikh Dieng wrote:

Very Thanks,

It's clear for me. For dnsdist i  need HA pour my Powerdns.


And how are you achieving HA of your dnsdist?

The normal, recommended approach for authoritative DNS resilience is to 
have multiple nameservers, listed as separate NS records. dnsdist is 
best deployed in special situations, such as the need to preprocess 
requests and send them to different destinations.


There's not a problem deploying dnsdist as such: it's just adding 
unnecessary complexity, and is an additional layer to manage and debug.



>>The delegation is done at the parent level, yes. However the 
delegated domain still needs to contain NS records and a SOA record 
for its own zone:


Yes, this is some details

...
cloud.lfpw.dsna.fr       3600    IN    
 NS ns.cloud.lfpw.dsna.fr .



(1) That NS record disagrees with the delegation NS records. They need 
to match.


(2) As far as I can see, you don't have any A record for 
"ns.cloud.lfpw.dsna.fr" in your "cloud.lfpw.dsna.fr" zone, which means 
your NS record won't resolve.


But there are worse problems.

Firstly, lfpw.dsns.fr and cloud.lfpw.dsna.fr are both delegated to 
"vitre.cena.fr." but that nameserver does not answer to either of those 
domains.  Either contact that nameserver operator and get them to fix it 
- or change your delegation so you don't use that nameserver.


Secondly, cloud.lfpw.dsna.fr is delegated to vip-in.cloud.lfpw.dsna.fr, 
which has a glue record address of 195.83.98.243.  (Glue records are 
used when the nameserver's name is inside the domain being delegated: 
that is, the nameserver vip-in.cloud.lfpw.dsna.fr is within 
cloud.lfpw.dsna.fr)


However that nameserver does not respond:

$ dig +norec @195.83.98.243 cloud.lfpw.dsna.fr. soa

; <<>> DiG 9.10.6 <<>> +norec @195.83.98.243 cloud.lfpw.dsna.fr. soa
; (1 server found)
;; global options: +cmd

;; connection timed out; no servers could be reached


If you delegate a domain to two nameservers, and both of those 
nameservers are not responding, then your domain is completely broken.  
You must fix at least one of those problems for it to start working; and 
preferably fix both of those problems to have some resilience.


I think I will drop out of this thread now.  I've tried to explain the 
problem three times, and it seems my explanations are not clear enough, 
so I will let someone else try.  Also, this isn't really a powerDNS 
question, but more one of understanding DNS in general.


Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Zone transfert rejected in Powerdns Letsencrypt challenge

2021-06-23 Thread Brian Candler via Pdns-users

On 22/06/2021 23:30, Cheikh Dieng wrote:

Hi, excuse for delay..

For context:
My powerdns listen in port 2053
My dnsdist listen in port 1053
We are an translating port through 53 (from external request) to 1053 
. That's why from external we use port 53 and in internal we can use 
port 1053 or 2053


In that case I would have thought your powerdns authoritative needs 
"local-port = 2053", not "local-port = 53"


Do you have a particular reason for using dnsdist?  It does add 
complexity that is often not required.






* Detail: DNS problem: query timed out looking up TXT for
_acme-challenge.cloud.lfpw.dsna.fr
*

As I explained before, your entire domain "cloud.lfpw.dsna.fr" is 
broken.  ACME challenges and DNS updates are not the problem; the 
problem is that *nobody* can resolve *any* address within that domain.


$ dig @8.8.8.8 cloud.lfpw.dsna.fr. soa

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: *SERVFAIL*, id: 7572


That's the problem you need to fix first.  To repeat:

$ dig +trace @8.8.8.8 cloud.lfpw.dsna.fr
...
lfpw.dsna.fr.        86400    IN    NS    vitre.cena.fr.
lfpw.dsna.fr.        86400    IN    NS    hilar.cena.fr.

dig +norec @vitre.cena.fr. cloud.lfpw.dsna.fr. txt   >> answer is SERVFAIL

dig +norec @hilar.cena.fr. cloud.lfpw.dsna.fr. txt   >> gives delegation 
(NS) to vitre.cena.fr. and vip-in.cloud.lfpw.dsna.fr.


>> we already know that vitre.cena.fr gives SERVFAIL

>> we cannot resolve the name vip-in.cloud.lfpw.dnsa.fr, and therefore 
we cannot send a DNS query to it


>> therefore, 2 out of 2 nameservers for cloud.lfpw.dnsa.fr are not 
reachable


>> therefore, the entire domain cloud.lfpw.dnsa.fr is broken




For first conclusion I understand from your return that:

  *   the Letsencrypt protocol DNS01 challenge does not use zone transfers
  * cloud.lfpw.dsna.fr  is a subdomain and
doesn't have to configure delagation (it make sense).  This
delegation configuration should be done at parent level
(lfpw.dsna.fr )

The delegation is done at the parent level, yes.  However the delegated 
domain still needs to contain NS records and a SOA record for its own zone.


Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Authoritative and CNAME pointing to external Domain responds with NXDOMAIN

2021-06-22 Thread Brian Candler via Pdns-users

On 22/06/2021 16:16, Thomas via Pdns-users wrote:
Thanks for the clarification, but this scares me. How can I have 
configured the server in a way it thinks it is authoritative for the 
entire Internet?
It should be authoritative for zur-sonne.it and the other 2500 domains 
we have, sihosting.cloud is not part of the domains we host


Check your configs and database, see if you have a zone "" or "."

As misconfigurations go, this isn't a very scary one.  You should never 
be receiving queries at this nameserver for domains that you're not 
authoritative for - that is, unless someone has wrongly pointed NS 
records at this server.


However it might trip you up if you point one of your *own* domains at 
this server, but haven't yet added the zone, and some proportion of 
queries which hit this server get an authoritative NXDOMAIN response, 
which the user will see as "this site cannot be reached" or similar.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Authoritative and CNAME pointing to external Domain responds with NXDOMAIN

2021-06-22 Thread Brian Candler via Pdns-users

On 22/06/2021 15:54, Thomas wrote:
Doing a "dig www.zur-sonne.it +nostats +nocomments +nocmd @localhost" 
I (think) get correct result:



; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> www.zur-sonne.it 
+nostats +nocomments +nocmd @localhost

;; global options: +cmd
;www.zur-sonne.it.  IN  A
www.zur-sonne.it.   10800 IN  CNAME cms-v2.sihosting.cloud.

And nslookup can not resolve cms-v2.sihosting.cloud as I pointed it to 
localhost to query from. Correct?


I believe you're right.  nslookup thinks it's talking to a recursive 
nameserver, and wants to chase the CNAME record. However I would not 
have expected an NXDOMAIN response here; your nameserver ought to have 
returned REFUSED.  It seems like you've made your nameserver 
authoritative for the entire DNS (or at least, for sihosting.cloud)


For that dig command line, when talking to an authoritative nameserver, 
I'd also recommend you add the "+norec" flag, which makes it explicit 
that you don't want to recurse.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PDNS Authoritative and CNAME pointing to external Domain responds with NXDOMAIN

2021-06-22 Thread Brian Candler via Pdns-users

On 22/06/2021 14:55, Thomas via Pdns-users wrote:
I have upgraded pdns authoritative server from version 4.3 to version 
4.4.1 on CentOS 7, MySQL is the backend.
If I query a CNAME record on both servers I get the following error 
(do not remember if it worked before the upgrade):


[root@pdns1 log]# nslookup www.example.it localhost
Server: localhost
Address:    ::1#53

www.example.it    canonical name = cms-v2.externaldomain.cloud.
** server can't find cms-v2.externaldomain.cloud: NXDOMAIN 


Firstly, please don't hide domains: see

https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/

Secondly, which of those domains is your server authoritative for?

PowerDNS will not attempt to follow CNAME records.  General recursion 
was removed in Authoritative Server 4.1.  (It will send queries for 
ALIAS records, but only if you've configured it with a recursor to use).



___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Zone transfert rejected in Powerdns Letsencrypt challenge

2021-06-22 Thread Brian Candler via Pdns-users

On 22/06/2021 12:33, Jan-Piet Mens via Pdns-users wrote:

For Letsencrypt protocol to generate certificate I have to enable zone
transfer in my powerdns.


I think you mean "DNS Updates" for Let's Encrypt dns-01, but I don't
believe these are possible in PowerDNS with the LDAP backend. 


Possibly, although the OP was specifically testing AXFR.

Regarding the separate issue of DNS updates, the way I deal with this is:

1. I run a separate nameserver for Letsencrypt use only (say 
"acme-ns.example.net")


2. For every domain I want a cert for (say "foo.example.com"), I 
statically add an NS record in my main DNS, pointing at that server:


_acme-challenge.foo.example.com.  NS    acme-ns.example.net.

3. I create empty zone "_acme-challenge.foo.example.com" on 
"acme-ns.example.net", with a random TSIG secret for DNS updates.


4. I give that secret to the server that wants to obtain a certificate.

It doesn't actually matter what nameserver you use for 
acme-ns.example.net, because the data stored within it is completely 
transitory.  Even something with a RAM backend would be fine.  I happen 
to use bind9 because it was easy to set up; I didn't want to use a 
database, and the powerdns bind backend doesn't support DNS updates 
.


With this approach, there's no risk that the target server could ever 
modify any record in the production DNS, accidentally or maliciously.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Zone transfert rejected in Powerdns Letsencrypt challenge

2021-06-21 Thread Brian Candler via Pdns-users

On 21/06/2021 08:53, Cheikh Dieng via Pdns-users wrote:

Hi,

My powerdns reject request for zone transfert .

My powerdns domain is "cloud.lfpw.dsna.fr 
" it is a sub domain of "lfpw.dsna.fr 
" (this parent domain  is not a powerdns solution).
For Letsencrypt protocol to generate certificate I have to enable zone 
transfer in my powerdns.


That doesn't make much sense: the Letsencrypt protocol DNS01 challenge 
does not use zone transfers.


It might make sense if cloud.lfpw.dsna.fr were delegated to a separate 
set of publicly-reachable nameservers, and your powerdns is a hidden 
primary that those servers perform zone transfers from.  That looks like 
it's possible:


$ dig +trace @8.8.8.8 _acme-challenge.cloud.lfpw.dsna.fr.
...
*lfpw.dsna.fr.        86400    IN    NS    vitre.cena.fr.**
**lfpw.dsna.fr.        86400    IN    NS    hilar.cena.fr.**
*;; Received 108 bytes from 2001:4b98:::fa#53(ns-249-a.gandi.net) in 
18 ms

...
*cloud.lfpw.dsna.fr.    172800    IN    NS    vitre.cena.fr.**
**cloud.lfpw.dsna.fr.    172800    IN    NS vip-in.cloud.lfpw.dsna.fr.**
*;; Received 125 bytes from 195.83.98.1#53(hilar.cena.fr) in 39 ms

However the cloud.lfpw.dsna.fr domain looks to be totally broken.  One 
nameserver gives servfail:


$ dig @vitre.cena.fr. cloud.lfpw.dsna.fr. ns

; <<>> DiG 9.10.3-P4-Debian <<>> @vitre.cena.fr. cloud.lfpw.dsna.fr. ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: *SERVFAIL*, id: 33460
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cloud.lfpw.dsna.fr.        IN    NS

;; Query time: 36 msec
;; SERVER: 2001:660:6607:100::1#53(2001:660:6607:100::1)
;; WHEN: Mon Jun 21 09:20:26 BST 2021
;; MSG SIZE  rcvd: 47

The other nameserver, "vip-in.cloud.lfpw.dsna.fr" does not resolve at all:

$ dig @vip-in.cloud.lfpw.dsna.fr. cloud.lfpw.dsna.fr. ns

; <<>> DiG 9.10.3-P4-Debian <<>> @vip-in.cloud.lfpw.dsna.fr. 
cloud.lfpw.dsna.fr. ns

; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

The address from the glue record doesn't work either:

$ dig @195.83.98.243 cloud.lfpw.dsna.fr. ns

; <<>> DiG 9.10.3-P4-Debian <<>> @195.83.98.243 cloud.lfpw.dsna.fr. ns
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached


Only one of the two nameservers for lfpw.dsna.fr *is* working - this is 
where I got the glue record from.


$ dig @hilar.cena.fr. cloud.lfpw.dsna.fr. ns

; <<>> DiG 9.10.3-P4-Debian <<>> @hilar.cena.fr. cloud.lfpw.dsna.fr. ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10103
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cloud.lfpw.dsna.fr.        IN    NS

;; AUTHORITY SECTION:
*cloud.lfpw.dsna.fr.    172800    IN    NS vip-in.cloud.lfpw.dsna.fr.**
**cloud.lfpw.dsna.fr.    172800    IN    NS vitre.cena.fr.**
*
;; ADDITIONAL SECTION:
*vip-in.cloud.lfpw.dsna.fr. 172800 IN    A    195.83.98.243*

;; Query time: 39 msec
;; SERVER: 195.83.98.1#53(195.83.98.1)
;; WHEN: Mon Jun 21 09:23:11 BST 2021
;; MSG SIZE  rcvd: 109


In summary: lfpw.dsna.fr is half-broken, and cloud.lfpw.dsna.fr is 
completely broken.  Getting Letsencrypt certificates is the least of 
your worries right now.





Is my pdns.conf file correct ?

local-address = 0.0.0.0, ::
launch = ldap
guardian = yes
ldap-host = ldap: //200.17.xx.xx: 1389 /
ldap-basedn = dc = cloud, dc = lfpw, dc = dsna, dc = fr
ldap-binddn = cn = admin, dc = dsna, dc = fr
ldap-secret = x
ldap-method = simple
disable-axfr = no
allow-axfr-ips = 127.0.0.0 / 8,195.xx.xx.xx / 32,51.91.xx.xx / 32
local-port = 53
cache-ttl = 0

loglevel = 9
logging-facility = 0
api = yes
api-key = x
master = yes
include-dir = / etc / powerdns / pdns.d


My powerdns listen in port 2053.



That doesn't make sense either.  You have "local-port=53", but you say 
it listens on port 2053 ??


What does powerdns log when you try to make a zone transfer?  Can you 
use tcpdump to prove the query is arriving?





The AXFR request failed, see bellow:

[pduser@hyp03 ~]$ dig axfr @0 cloud.lfpw.dsna.fr
 -p 2053

; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> axfr @0
cloud.lfpw.dsna.fr  -p 2053
; (1 server found)
;; global options: +cmd
; Transfer failed.

It looks like you haven't copy-pasted correctly.  "dig @0" is certainly 
going to fail:


;; Connection to 0.0.0.0#2053(0.0.0.0) for cloud.lfpw.dsna.fr failed: 
connection refused.


So I can only guess what host you're 

Re: [Pdns-users] Sub-domains and zones

2021-06-18 Thread Brian Candler via Pdns-users

On 18/06/2021 05:16, Daniel Miller via Pdns-users wrote:
Given a published zone of ".myzone.com" - I want to have a list of 
hosts like:


a.sub.myzone.com
b.sub.myzone.com
c.sub.myzone.com

Nothing special. I can implement this by explicitly declaring each 
host in my parent zone - and this works. But I want to manage the 
subdomain separately. So besides creating a zone ".sub.myzone.com" and 
adding the host records - what other "glue" is required?


Do I need to explicitly publish ".sub.myzone.com" with my registrar?

No.


Do I place NS records for ".sub.myzone.com" in the parent zone?
Yes.  This is the delegation.  The nameservers for sub.myzone.com aren't 
necessarily the same as those for myzone.com.


Do I place NS records for ".sub.myzone.com" in the sub-zone?


Yes.  This is the authoritative source of the NS records.  (I always 
thought this was a weird aspect of DNS design, as having two sources of 
info makes it likely that they will be inconsistent, but that's how it 
is.  Just make sure they match.)




Do I need to explicitly declare a forward-zone for ".sub.myzone.com" 
in addition to the parent zone?


No.

In any case, there's no such thing as a forward-zone in an authoritative 
DNS server; that would be something in a recursor. But the recursor can 
just follow the NS records.  You shouldn't even have a forward-zone 
entry for myzone.com.


The only exception would be if this is if myzone.com is a private 
domain, which is not delegated in the public DNS.  In that case, you 
will need a forwarding entry for sub.myzone.com - but only if you're 
forwarding to a different set of servers than myzone.com.


HTH,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Geo DNS - Apex Alias (not resolving)

2021-06-14 Thread Brian Candler via Pdns-users

$ dig +short @dns0.hotchilli.uk. geo.hotchilli.co.uk. a
46.17.220.152
$ dig +short @dns0.hotchilli.uk. hotchilli.co.uk. a
10.0.2.18

I see that's the response you configured for "unknown.geo.hotchilli.co.uk"

I'd be inclined to use tcpdump to look at queries from dist to auth, 
auth to recursor, and recursor to auth - and check the flow of packets 
when you send an external query for "hotchilli.co.uk". My guess is that 
the source subnet of the original query isn't propagating all the way 
through, and maybe you can identify at which step it's lost.


I do wonder if there's a better way; perhaps dnsdist itself could map 
hotchilli.co.uk to geo.hotchilli.co.uk? But I don't use dnsdist myself.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Upgrading Auth Server directly from 4.1.14 to 4.4.1

2021-05-19 Thread Brian Candler via Pdns-users

On 19/05/2021 19:40, Nikolaos Milas via Pdns-users wrote:
Can we upgrade directly to 4.4.1 provided we do pertinent config 
changes as described in the upgrade guide, or it is suggested to 
upgrade in steps, e.g. to the last point release of each major version 
(4.1.14 --> 4.2.3 --> 4.3.2 --> 4.4.1)? 


There is no state stored in pdns-auth itself, other than the state in 
the backend.  So as long as you change your backend to be compatible 
with 4.4.1, I see no reason why you can't jump straight to 4.4.1.


Of course you should first do this in a test environment, cloned or 
copied from your live environment, to discover anything that you might 
have missed.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Private IP Addresses in DNS Records

2021-05-14 Thread Brian Candler via Pdns-users

On 14/05/2021 16:13, Nikolaos Milas wrote:
Hmm, probably you mean IPv6 Link-local addresses (rather than GUAs); 
GUAs are reachable indeed.
GUAs aren't necessarily reachable: you can have internal ranges that are 
not routed, or blocked by ACLs.  Or he might have meant ULAs.


Either way, I agree with him. I am perfectly happy publishing private 
and unreachable addresses in the public DNS, for the very reason that 
they are not reachable!  Hence it doesn't matter whether anyone can 
resolve them or not.


If company policy doesn't let you work that way, and you still want to 
use PowerDNS, then setting up a separate private DNS authoritative 
service is the simplest way to do it.  PowerDNS doesn't have "views" 
like bind: it's designed for ISP-scale robustness and performance.  To 
do clever tricks like answering differently depending on the source IP 
address, then you can use dnsdist in front, or you can use LUA scripting.


As for controlling AXFRs: that's normally done by TSIG authentication 
and/or by source IP address restrictions, but as I don't use LDAP as the 
backend, I'm afraid I can't tell you whether it's supported with that.


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


  1   2   3   4   >