[dns-operations] Quad9 denial of existence for _25._tcp.mx1.p01.antagonist.nl IN TLSA

[Viktor Dukhovni]

On Tue, Nov 26, 2019 at 02:41:26PM +0100, Martijn Reening wrote:

> We haven't changed anything on our side in the past days, but I see the
> expected response from Quad9 now:
> 
> $ dig +dnssec +noall +comment +ans +auth -t tlsa _25._tcp.mx1.p01.antagonist.nl @9.9.9.10
> _25._tcp.mx1.p01.antagonist.nl.    300 IN    TLSA    2 1 1 E12D92CF8D801D0FDB21BEDEE1CEC09C15AC2A61E27FA27D6B151312 D2206520
> 
> I checked our nameservers for the proper ENT responses and there do not seem
> to be any abnormalities.  Do you still see this error, or perhaps know
> something else to check?

Yes, I still the DoE response from 9.9.9.10, and also (not always) from
its peer 149.112.112.10:

    $ dig +dnssec +noall +comment +ans +auth -t tlsa _25._tcp.mx1.p01.antagonist.nl @149.112.112.10
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1327
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 512
    ;; AUTHORITY SECTION:
    antagonist.nl.          180     IN      SOA     ns1.antagonist.nl. hostmaster.antagonist.nl. 2018052300 180 3600 1209600 86400
    cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 43200 IN NSEC3 1 0 1 AB D04COHDERT50P43FHSP1N5F7LDVTORH7 A AAAA RRSIG
    i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 43200 IN NSEC3 1 0 1 AB IDTV8EDH9FRO5UU2OC4N3PUM51SRLDGH A RRSIG
    g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 43200 IN NSEC3 1 0 1 AB GFL0IAO83UJDAA6IHCTHFGL6T4KNILQO A RRSIG
    antagonist.nl.          180     IN      RRSIG   SOA 13 2 180 20191205000000 20191114000000 47684 antagonist.nl. TjahhD+sFLbHkIAUcUFFo+vC4icQKK2Zh+74BN+eFQ9JhkZaQ6AMYNbT wGfDZuNntzd2C3FS4SiIptAr6fOkvA==
    cueh7hkbnbrqk65590909p4r0pq6cd45.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. 5KPt3wExlfKg4tZJ1fdR1xhnj8x8DsmgYR2+pCHkcc041thw3E6jQCfY CESVytcQcp6Zb/uJ3zxNXExJkEzZoQ==
    i33uq5toep0fslekf0mqpnv6pb6s002e.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. Wrzps6dY9zhq14kBiFp0KwDqdkMtceOMV2cMKPkznhxFcsmpsTazZX1Z MAw/565cRwpWRoU5LuGNzGHg3ZstUQ==
    g7u4gpdfmf579evnnqmc3v816rafktip.antagonist.nl. 86400 IN RRSIG NSEC3 13 3 86400 20191205000000 20191114000000 47684 antagonist.nl. DBJvz7HbYSFS/PHtTXD2qMwsKuWXoqNj8MPNMIk84Jv4kY1w52EevWIS nIgDknp9DbzYcczQzOOu1cyEYulYPg==

The TTLs are remarkably unchanging at:

    * 180s SOA and RRSIG TTL == origin TTL
    * 12H NSEC3 TTL == 0.5 origin TTL
    * 24H RRSIG NSEC3 TTL == origin TTL

So either I'm getting uncached data, or something more interesting is
happening.  It feels like some nodes at Quad9 are caching NSEC3 responses for
the full RRSIG validity, and then generating responses with TTLs based on
capped by the origin TTL and/or a local limit.

Using the signature inception/expiration interval as a cache interval, rather
the provided TTL (if that's what this is) is not expected or I believe valid.

-- 
    Viktor.