Re: [Pdns-users] SNAT and notify messages

[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] Inability to query SOA after upgrade of bind9 primary server. Truncation issue?

[Andy Smith via Pdns-users]

On Fri, Nov 18, 2022 at 01:31:25AM +, Andy Smith via Pdns-users wrote:
> one particular zone is unable to be transferred to any of the several
> PowerDNS secondary servers which have not been changed in any way.
> 
> PDNS logs:
> 
> Nov 18 00:25:26 daiquiri pdns_server[32452]: While checking domain
> freshness: Query to '2001:ba8:1f1:f085::53' for SOA of
> 'f.4.1.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa' did not return a SOA

Well, hours of head scratching then I send this email and suddenly
find something that is probably very relevant:

 "auth: slave zone soa check does not use tcp if udp answer was
 truncated #10447"
 https://github.com/PowerDNS/pdns/issues/10447

I'm guessing that bind9's behaviour has changed to be more correct and
there probably won't be any configuration change on that side that I
could/should use to make this work again.

So I expect my best option is to hasten my upgrade to PDNS 4.7.x and
make use of "secondary-check-signature-freshness=no".

Unless there are other solutions I am unaware of?

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

[Pdns-users] Inability to query SOA after upgrade of bind9 primary server. Truncation issue?

[Andy Smith via Pdns-users]

Hi,

I recently upgraded a Debian 9 / bind9 system to Debian 11, so that
would be bind9 package version 1:9.10.3.dfsg.P4-12.3+deb9u12 to
1:9.16.27-1~deb11u1. Ever since doing so, one particular zone is unable
to be transferred to any of the several PowerDNS secondary servers which
have not been changed in any way.

PDNS logs:

Nov 18 00:25:26 daiquiri pdns_server[32452]: While checking domain
freshness: Query to '2001:ba8:1f1:f085::53' for SOA of
'f.4.1.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa' did not return a SOA

The baffling thing is that a "dig" for the SOA from that server works:

$ dig +short -t soa f.4.1.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa 
@2001:ba8:1f1:f085::53
ns0.ribenakid.me.uk. bind.ribenakid.me.uk. 1668670704 28800 14400 360 86400

I can also do an axfr from that host with "dig" and I can also force
PDNS to do an axfr which it successfully does.

This only happens with the zone
"f.4.1.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa".

I did a tcpdump and captured the response to PowerDNS's SOA query, which
was indeed empty. I note that it had the truncated bit set, and yes,
f.4.1.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa is DNSSEC signed and doing "dig
+dnssec -t SOA …" confirms that it's of size 2293. However, there is no
retry over TCP from PowerDNS.

Clearly bind9 behaviour has changed, since that zone has been DNSSEC
signed for a long time and PDNS was fine with it; what's changed is the
bind9 version. But, I don't know if bind9 is wrong here or not! I've
asked about this in the bind9 community as well in case there are some
settings I should change there.

Now, the PDNS servers in use are out of support (it's on my TODO list…)
so before asking about this I did stand up a new 4.7 instance. That also
behaves the same ("did not return an SOA").

I ran this through the ISC EDNS compliance tester and it all came back
okay:
https://ednscomp.isc.org/ednscomp/a8c22e7194

I've attached a text dump from Wireshark of the relevant 4 packets. It
shows:

1) 85.119.80.222 (another IP on the same host as 2001:ba8:1f1:f085::53)
   sending out a notify for "f.4.1.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa"
   to 172.104.29.216 (one of the PDNS secondary servers).

2) 172.104.29.216 response back to notify.

3) 172.104.29.216 query to 85.119.80.222 for SOA.

4) 85.119.80.222 empty response to 172.104.29.216.

Packet #4 shows the truncated bit.

Any insight into where the problem lies and how best to fix it would be
appreciated!

Thanks,
Andy
No. Time   SourceDestination   Protocol 
Length Info
  1 0.00   85.119.80.222 172.104.29.216DNS  160 
   Zone change notification 0xe40c SOA f.4.1.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa 
SOA ns0.ribenakid.me.uk

Frame 1: 160 bytes on wire (1280 bits), 160 bytes captured (1280 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Nov 17, 2022 14:59:29.791115000 GMT
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1668697169.791115000 seconds
[Time delta from previous captured frame: 0.0 seconds]
[Time delta from previous displayed frame: 0.0 seconds]
[Time since reference or first frame: 0.0 seconds]
Frame Number: 1
Frame Length: 160 bytes (1280 bits)
Capture Length: 160 bytes (1280 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:dns]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Precisio_00:04:86 (00:16:5e:00:04:86), Dst: fe:ff:ff:ff:ff:ff 
(fe:ff:ff:ff:ff:ff)
Destination: fe:ff:ff:ff:ff:ff (fe:ff:ff:ff:ff:ff)
Address: fe:ff:ff:ff:ff:ff (fe:ff:ff:ff:ff:ff)
 ..1.     = LG bit: Locally administered address 
(this is NOT the factory default)
 ...0     = IG bit: Individual address (unicast)
Source: Precisio_00:04:86 (00:16:5e:00:04:86)
Address: Precisio_00:04:86 (00:16:5e:00:04:86)
 ..0.     = LG bit: Globally unique address 
(factory default)
 ...0     = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 85.119.80.222, Dst: 172.104.29.216
0100  = Version: 4
 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
 00.. = Differentiated Services Codepoint: Default (0)
 ..00 = Explicit Congestion Notification: Not ECN-Capable Transport 
(0)
Total Length: 146
Identification: 0x70e4 (28900)
Flags: 0x
0...    = Reserved bit: Not set
.0..    = Don't fragment: Not set
..0.    = More fragments: Not set
...0    = Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x98e1 [validation disabled]
[Header checksum status: Unverified]
Source: 85.119.80.222
Destination: 

Re: [Pdns-users] SNAT and notify messages

[Michael Hallager via Pdns-users]

Are you using double NAT? If so then its likely to double your issues.

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.


On 2022-11-18 11:37, ch via Pdns-users wrote:

Hi PDNS users, I need your advice:  (Note: there's a TL;DR: section at
the bottom)

We've set up three nameservers (ns1, ns2 and ns3) with two ip
addresses each: an internal 10.x.x.x and an external public ip.

Each server runs dnsdist, pdns_recursor, and two copies of
pdns_server, like this:

dnsdist -> pdns_recursor -> pdns_server [internal]
\
  pdns_server [external]

* Dnsdist is listening on 127.0.0.1, 10.x.x.x, and the external
public ip, all on port 53.
* pdns_recursor is listening on 127.0.0.2
* pdns_server (internal) is listening on 127.0.0.3
* pdns_server (external) is listening on 127.0.0.4
* systemd_resolved is listening on 127.0.0.53 to satisfy local dns
requests (Ubuntu 20.04 default configuration, with 127.0.0.2 as its
resolver)

Requests come in to dnsdist, and based on their source address they're
forwarded to 127.0.0.2 (internal) or 127.0.0.4 (external).
Pdns_recursor forwards requests to 127.0.0.3 (pdns_server internal)
for zones listed in the forward zones file and recursively answers the
rest.

So far, so good; requests come in, replies go out, and external
clients can't abuse our recursor or see our internal dns entries,
yayyy!

=

Here's where things start go off the rails:

Our internal network grew "organically", and for reasons lost in the
mists of time, we've got NAT gateways in our network, one of which is
between ns3 and the other two name servers.

* When a zone is updated on ns1, it sends a notify to ns3, but the
source ip is changed by the NAT gateway.
* The notify-acknowledgement is sent back through the NAT gateway
and ns1 gets it, since the gateway expected the response.
* Ns3 then sends an SOA request to the NAT gateway (as that's where
the notify came from), but it's lost because it's not related to the
previous conversation.
* Pdns_recursor seems to eat Notify and AXFR messages, so we've told
Dnsdist to direct those to 127.0.0.3

We've temporarily worked around the problem by adding an iptables rule
to ns3 that says 'redirect packets sent to "port 53 on the gateway" to
ns1', and it works.

==

Things are now going further off the rails here:

* Now we've added a bunch of independent sub-zones on small name
servers in different parts of our company, and they're going to be
using ns1, ns2 and ns3 as their secondary servers, whichever is
closest.
* Notifies are going to be flying all over, and packets from some of
them will be going through the same NAT gateway that ns1 uses to get
to ns3.
* Because of that, the iptables rule is going to mess things up, as
it assumes outgoing DNS requests to the NAT gateway should really go
to ns1's internal address.

Is there a way to get the SOA request from ns3 to go to the right
place using pdns or dnsdist?

==

Now we're so far off the rails, we're in the middle of a cornfield:

* The internal and external pdns servers have different zone files
(internal/external ip addresses, some hosts not listed in the external
zones).
* We're using the internal ips on ns1,2,3 for transferring internal
zones, and the external ips for external ones.
* We're attempting to use NetmaskGroupRule [1] with src=false to
have dnsdist direct requests internally/externally based on that.
* The independent sub-zone name servers will be notifying the
ns1,2,3 on both internal and external ips, and the NAT is going to
mess up the source ips, iptables can't handle this.

Can we use DoH/DoT to establish a TCP connection for the NOTIFY and
reuse it for the SOA and AXFR?  The NAT respects open TCP connections
much more than UDP conversations.

Should we manually add entries to the zone metadata to specify where
zones are really hosted?  I really wanted to use the auto-secondary
feature, but sometimes we can't have nice things.  :-/

Oh god, please don't tell me I have to set up a VPN between all the
name servers :-(

Anyhow, I'd love to hear someone write a happy ending to this story.

==

TL;DR: How do you get notifies + zone transfers to work when the
source ip addresses of NOTIFY packets are unreliable?

Thanks!

--
CH (ch-and-pdns-us...@ch.pkts.ca)

Links:
--
[1] https://dnsdist.org/rules-actions.html#NetmaskGroupRule
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


--
Net Trust Ltd
Internet Servers and Network Systems Administration
p: (06) 374 0880 | (09) 839 1000
m: 021 963 878
e: mich...@nettrust.nz
w: nettrust.nz
___
Pdns-users mailing list

[Pdns-users] SNAT and notify messages

[ch via Pdns-users]

Hi PDNS users, I need your advice:  (Note: there's a TL;DR: section at
the bottom) 

We've set up three nameservers (ns1, ns2 and ns3) with two ip addresses
each: an internal 10.x.x.x and an external public ip. 

Each server runs dnsdist, pdns_recursor, and two copies of pdns_server,
like this: 

dnsdist -> pdns_recursor -> pdns_server [internal]
\
  pdns_server [external] 

* Dnsdist is listening on 127.0.0.1, 10.x.x.x, and the external public
ip, all on port 53.
* pdns_recursor is listening on 127.0.0.2
* pdns_server (internal) is listening on 127.0.0.3
* pdns_server (external) is listening on 127.0.0.4
* systemd_resolved is listening on 127.0.0.53 to satisfy local dns
requests (Ubuntu 20.04 default configuration, with 127.0.0.2 as its
resolver)

Requests come in to dnsdist, and based on their source address they're
forwarded to 127.0.0.2 (internal) or 127.0.0.4 (external). 
Pdns_recursor forwards requests to 127.0.0.3 (pdns_server internal) for
zones listed in the forward zones file and recursively answers the rest.


So far, so good; requests come in, replies go out, and external clients
can't abuse our recursor or see our internal dns entries, yayyy! 

= 

Here's where things start go off the rails: 

Our internal network grew "organically", and for reasons lost in the
mists of time, we've got NAT gateways in our network, one of which is
between ns3 and the other two name servers. 

* When a zone is updated on ns1, it sends a notify to ns3, but the
source ip is changed by the NAT gateway. 
* The notify-acknowledgement is sent back through the NAT gateway and
ns1 gets it, since the gateway expected the response.
* Ns3 then sends an SOA request to the NAT gateway (as that's where
the notify came from), but it's lost because it's not related to the
previous conversation.
* Pdns_recursor seems to eat Notify and AXFR messages, so we've told
Dnsdist to direct those to 127.0.0.3

We've temporarily worked around the problem by adding an iptables rule
to ns3 that says 'redirect packets sent to "port 53 on the gateway" to
ns1', and it works. 

== 

Things are now going further off the rails here: 

* Now we've added a bunch of independent sub-zones on small name
servers in different parts of our company, and they're going to be using
ns1, ns2 and ns3 as their secondary servers, whichever is closest. 
* Notifies are going to be flying all over, and packets from some of
them will be going through the same NAT gateway that ns1 uses to get to
ns3.
* Because of that, the iptables rule is going to mess things up, as it
assumes outgoing DNS requests to the NAT gateway should really go to
ns1's internal address.

Is there a way to get the SOA request from ns3 to go to the right place
using pdns or dnsdist? 

== 

Now we're so far off the rails, we're in the middle of a cornfield: 

* The internal and external pdns servers have different zone files
(internal/external ip addresses, some hosts not listed in the external
zones).
* We're using the internal ips on ns1,2,3 for transferring internal
zones, and the external ips for external ones.
* We're attempting to use NetmaskGroupRule [1] with src=false to have
dnsdist direct requests internally/externally based on that.
* The independent sub-zone name servers will be notifying the ns1,2,3
on both internal and external ips, and the NAT is going to mess up the
source ips, iptables can't handle this.

Can we use DoH/DoT to establish a TCP connection for the NOTIFY and
reuse it for the SOA and AXFR?  The NAT respects open TCP connections
much more than UDP conversations. 

Should we manually add entries to the zone metadata to specify where
zones are really hosted?  I really wanted to use the auto-secondary
feature, but sometimes we can't have nice things.  :-/ 

Oh god, please don't tell me I have to set up a VPN between all the name
servers :-( 

Anyhow, I'd love to hear someone write a happy ending to this story. 

== 

TL;DR: How do you get notifies + zone transfers to work when the source
ip addresses of NOTIFY packets are unreliable?

Thanks! 

-- 
CH (ch-and-pdns-us...@ch.pkts.ca) 

Links:
--
[1] https://dnsdist.org/rules-actions.html#NetmaskGroupRule___
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 .

[Raghvendra Choudhary via Pdns-users]

Thank for the help.


*Raghvendra Choudhary*
DevOps Engineer | www.digivalet.com 

[image: Logo]

T:  +91.731.6667891

M: +91.96307.90947

E:  raghvendra.choudh...@digivalet.com 

[image: Banner]


On Thu, Nov 17, 2022 at 1:36 PM Michael Hallager 
wrote:

> Your signature states your role as "DevOps Engineer".
>
> Based on this, I can not fathom why you are asking what PowerDNS can be
> used for. I suggest reading the website at https://www.powerdns.com
>
> If you are not even aware of the basic use cases for PDNS Auth and PDNS
> Resolver, then its the wrong product for you.
>
> On 2022-11-17 21:01, Raghvendra Choudhary wrote:
> > Hi Michael,
> >
> > Can you let me know the uses of PowerDNS . Why Power DNS is used. can
> > we achieved whatever I said in the mail trail.
> >
> >  Raghvendra Choudhary
> >  DevOps Engineer | www.digivalet.com [3]
>
___
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 .

[Michael Hallager via Pdns-users]

Your signature states your role as "DevOps Engineer".

Based on this, I can not fathom why you are asking what PowerDNS can be 
used for. I suggest reading the website at https://www.powerdns.com


If you are not even aware of the basic use cases for PDNS Auth and PDNS 
Resolver, then its the wrong product for you.


On 2022-11-17 21:01, Raghvendra Choudhary wrote:

Hi Michael,

Can you let me know the uses of PowerDNS . Why Power DNS is used. can
we achieved whatever I said in the mail trail.

 Raghvendra Choudhary
 DevOps Engineer | www.digivalet.com [3]

___
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 .

[Raghvendra Choudhary via Pdns-users]

Hi Michael,

Can you let me know the uses of PowerDNS . Why Power DNS is used. can we
achieved whatever I said in the mail trail.

*Raghvendra Choudhary*
DevOps Engineer | www.digivalet.com 

[image: Logo]

T:  +91.731.6667891

M: +91.96307.90947

E:  raghvendra.choudh...@digivalet.com 

[image: Banner]


On Thu, Nov 17, 2022 at 1:27 PM Michael Hallager 
wrote:

> By default Linux will use hosts file first and then DNS servers listed
> in /etc/resolv.conf (If the specific application uses Glibc functions
> for name resolution) but dig is a DNS specific command.
>
> So maybe you want to use the ping command?
>
> At this time your question sounds more like a Linux user question rather
> then a PowerDNS one. If you are an end user host its unlikely you will
> need PowerDNS for anything.
>
> On 2022-11-17 20:46, Raghvendra Choudhary wrote:
> > My requirement is when I dig any DNS first it goes to the hosts file
> > in which all the host entry in linux the host file path is /etc/hosts.
> > First check the host entry if the DNS found in the Host it resolve. If
> > in case the DNS not found in the host Entry it redirect to the google
> > the DNS of the goofle is 8.8.8.8.So [3] this is my requirement. I hope
> > this is much clear.
> >
> >  Raghvendra Choudhary
> >  DevOps Engineer | www.digivalet.com [4]
>
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users