Inconsistency within TTL of records expanded during AXFR

[sdomi]

• This is not a support question, I have read about opensource and will send support questions to the IRC channel, GitHub Discussions or the mailing list.

• I have read and understood the 'out in the open' support policy

• Program: Authoritative

• Issue type: Bug report

Short description

When using ALIAS/ANAME with outgoing-axfr-expand-alias=yes, the primary server ends up using the upstream TTL, while all secondaries use record's TTL. This can be narrowed down to PowerDNS sending a different value during AXFR compared to a regular query:

$ dig @sakamoto.pl. AXFR sdomi.pl. | grep 'A\t185.236.240.103'
sdomi.pl.		3600	IN	A	185.236.240.103
$ dig @sakamoto.pl. A sdomi.pl. | grep 'A\t185.236.240.103'
sdomi.pl.		19530	IN	A	185.236.240.103

The ALIAS record is:

sdomi.pl. 3600 IN ALIAS sakamoto.pl.

The upstream A record is:

sakamoto.pl. 86400 IN A 185.236.240.103

With every subsequent query to the primary, the value is either decreased or some random offset is added; I haven't found any mention of this in the docs.

Environment

• Operating system: Alpine Linux edge
• Software version: 4.9.4
• Software source: repo

Steps to reproduce

pdns.conf

1. create any record with any TTL
2. create an ALIAS record pointing to it with a different TTL
3. observe

Expected behaviour

Generally, I'd expect the ALIAS' TTL to be mirrored for all records, just like it is done on secondaries. If not, a static value taken from the upstream would make this less weird to debug for others (and less prone to causing heart attacks, thinking that someone is MitMing your server)

[miodvallat]

This looks like an incorrectly initialized value somewhere. I've unfortunately been unable to reproduce the issue locally - I get the correct TTL values for every record.

Have you built the pdns_server binaries yourself? If so, which compiler version and compiler options have you been using?

[sdomi]

I'm using the binaries from Alpine's repositories, sorry that I didn't specify this clearly enough. Non-zero chance that this is a musl vs glibc thing, too.

I am coming from the same org as @sdomi.

I have been able to confirm the issue on non-musl systems, namely RHEL9 (pdns-4.8.4-1.el9.src.rpm from epel) and Debian Stable.

In my reproduction, the ALIAS record has a TTL of 300 set (first request below). The backing A record has its TTL set to 600 (second request below). The third request depicts the outgoing AXFR.

[merlin@ns1 pdns]$ dig @85.9.220.216 A m621.net | grep '188'
m621.net.               600     IN      A       188.136.38.251
[merlin@ns1 pdns]$ dig @85.9.220.216 A pwe1.ex.homecloud.lol | grep '188'
pwe1.ex.homecloud.lol.  600     IN      A       188.136.38.251
[merlin@ns1 pdns]$ dig @85.9.220.216 AXFR m621.net | grep '188'
m621.net.               300     IN      A       188.136.38.251

In the example, only the TTL on the ALIAS record is steadily decreasing, wrapping around to 600.