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.