[Pdns-users] TLSA problemns

[steffannoord at gmail.com]

Yes it is my own.
I use mysql replication 
If i test the dns servers it works.

I also see the difference in the TTL, but the settings are in my dns for several months.

The reasen why i test 8.8.8.8 is that SIDN uses them to test for tlsa/dane
And my domains are failing for there test.

Met vriendelijke groet,
Steffan Noord 

-----Oorspronkelijk bericht-----
Van: Brian Candler <b.candler at pobox.com> 
Verzonden: vrijdag 13 december 2019 14:44
Aan: steffannoord at gmail.com; 'Pdns-users Users' <pdns-users at mailman.powerdns.com>
Onderwerp: Re: [Pdns-users] TLSA problemns

On 13/12/2019 13:23, steffannoord at gmail.com wrote:
> I have a strange problem.
> When i do a:
> dig _25._tcp.mail01.tkservers.com tlsa @8.8.8.8
>
> om getting sometimes a NOERROR and sometimes a NXDOMAIN
>
> When i change the 8.8.8.8 to my dns servers that it works fine.
> When i use 1.1.1.1  it works fine
>
> Any idees why Google gives a NXDOMAIN randomly?

8.8.8.8 will be a big anycast pool of caches, and you may hit a different one with each query.  Other providers might have "sticky" load balancing.  Notice how the TTL bounces up and down here:

$ dig @8.8.8.8 powerdns.com | grep '^powerdns\.com'
powerdns.com.        3599    IN    A    188.166.104.92 $ dig @8.8.8.8 powerdns.com | grep '^powerdns\.com'
powerdns.com.        3599    IN    A    188.166.104.92 $ dig @8.8.8.8 powerdns.com | grep '^powerdns\.com'
powerdns.com.        1227    IN    A    188.166.104.92 $ dig @8.8.8.8 powerdns.com | grep '^powerdns\.com'
powerdns.com.        3026    IN    A    188.166.104.92 $ dig @8.8.8.8 powerdns.com | grep '^powerdns\.com'
powerdns.com.        3595    IN    A    188.166.104.92

Is tkservers.com your own domain?

You would need to dig into the details, but there are a whole bunch of possible reasons, most likely due to misconfiguration of tkservers.com authoritative DNS.  Examples:

- synchronization problem between master and slaves
- NS records in the delegation are different to the NS records in the zone

Or it could just be a temporary anomaly due to TTL expiring after a change, and will eventually become consistent.