Post ASd4fhtD1PN5hTHLbE by winfried@fosstodon.org
(DIR) More posts by winfried@fosstodon.org
(DIR) Post #ASbHGuEYtmQtplqolc by bortzmeyer@mastodon.gougere.fr
2023-02-12T10:19:01Z
0 likes, 0 repeats
The Drink #DNS authoritative server signs now its responses with #DNSSEC https://botsin.space/@DNSresolver/109851250824047761#SeenAtFOSDEM
(DIR) Post #ASbI5R2VCdMO3dIvRI by winfried@fosstodon.org
2023-02-12T10:28:24Z
1 likes, 0 repeats
@bortzmeyer But it has bug regarding NSECNSEC proving non-existence of ip.dyn.bortzmeyer.fr/A: The following queries resulted in an answer response, even though the bitmap in the NSEC RR indicates that the queried records don't exist: ip.dyn.bortzmeyer.fr/Ahttps://dnsviz.net/d/ip.dyn.bortzmeyer.fr/dnssec/
(DIR) Post #ASbIFDOQnIyYd8Dzkm by bortzmeyer@mastodon.gougere.fr
2023-02-12T10:30:06Z
0 likes, 0 repeats
@winfried I am not sure it is a bug. (Do the query with dig or through your normal resolver, you will have no problem.) I guess it comes from DNSviz doing two requests (A and AAAA) at a short interval and, since the NSEC has a TTL of 10 secondes, using one NSEC for another response.
(DIR) Post #ASbIyRONan1R4xlXxw by winfried@fosstodon.org
2023-02-12T10:38:25Z
0 likes, 0 repeats
@bortzmeyer tried with a DNS App. Got Servfail after I queried SRV and then A and then after TTL has expired
(DIR) Post #ASbKEau85uEXASsobo by bortzmeyer@mastodon.gougere.fr
2023-02-12T10:52:31Z
0 likes, 0 repeats
@winfried It may be a routing problem (the zone has just one authoritative server, and it is a low-end VM) or another network glitch since most RIPE Atlas probes have no problem with this zone:https://framagit.org/-/snippets/6880
(DIR) Post #ASbKkdLQYa7E0Evesq by winfried@fosstodon.org
2023-02-12T10:53:00Z
0 likes, 0 repeats
@bortzmeyer also unreliable on Q1, Q8, Q9 after querying nonexistent type
(DIR) Post #ASbKkdzU9e9s0TfeK0 by bortzmeyer@mastodon.gougere.fr
2023-02-12T10:58:17Z
0 likes, 0 repeats
@winfried Unfortunately, I cannot reproduce the bug. https://framagit.org/-/snippets/6883Could you send me a complete copy-and-paste of the session?
(DIR) Post #ASbLAthMNOzMFhiA5o by winfried@fosstodon.org
2023-02-12T11:03:06Z
0 likes, 0 repeats
@bortzmeyer yes I can send it tomorrow
(DIR) Post #ASbOFxC56ieeP6BRya by winfried@fosstodon.org
2023-02-12T11:37:37Z
0 likes, 0 repeats
@bortzmeyer on the Q Resolvers you must send the wrong type query a lot of times to hit most of their instances, then wait 10s then do the A query multiple times. With TXT I was not able to reproduce it
(DIR) Post #ASbc74e7QhDGGhxSDI by bortzmeyer@mastodon.gougere.fr
2023-02-12T14:12:49Z
0 likes, 0 repeats
@winfried In the mean time: https://framagit.org/bortzmeyer/drink/-/issues/47
(DIR) Post #ASd4fhtD1PN5hTHLbE by winfried@fosstodon.org
2023-02-13T07:07:35Z
0 likes, 0 repeats
@bortzmeyer Reproduction of the missing A RR with Q1 and Q8 and trace of the SERVFAIL case with PowerDNS Recursor: https://p.6core.net/p/2t07x0mmqq2CARGiJXk6Fd3B
(DIR) Post #ASdc5db6tlZuPCmm6i by bortzmeyer@mastodon.gougere.fr
2023-02-13T13:21:56Z
0 likes, 0 repeats
@winfried The "No A" are perfectly normal, since the QuadN resolver probably queried over IPv6 (and then Drink returned a AAAA).The PowerDNS trace shows a problem but it is not obvious at first glance. Added to the bug report https://framagit.org/bortzmeyer/drink/-/issues/47 thanks.
(DIR) Post #ASdczrt2xTFIwJzK2i by winfried@fosstodon.org
2023-02-13T13:32:07Z
0 likes, 0 repeats
@bortzmeyer that's strange that I get an AAAA RR (in the ADDITIONAL SECTION) when querying A if transport uses IPv6. Transport protocol must be independent from data in the DNS.
(DIR) Post #ASddug6zPV6qvTbBke by bortzmeyer@mastodon.gougere.fr
2023-02-13T13:42:19Z
0 likes, 0 repeats
@winfried I disagree.
(DIR) Post #ASde3gF6IF9RwDgXrc by bortzmeyer@mastodon.gougere.fr
2023-02-13T13:42:54Z
0 likes, 0 repeats
@winfried I disagree. The whole point of Drink is to make answers that depend on the request.
(DIR) Post #ASdeUYrfpduksIXsHo by winfried@fosstodon.org
2023-02-13T13:48:52Z
0 likes, 0 repeats
@bortzmeyer okay, got it :)
(DIR) Post #ASdepIVTqUHSDs3JEe by bortzmeyer@mastodon.gougere.fr
2023-02-13T13:52:40Z
0 likes, 0 repeats
@winfried But it's true that returning AAAA (in the Additional section) when the client asked for A (or the opposite) is unexpected and raises some issues (not just with DNSSEC).
(DIR) Post #ASdhvKHITNGvJez65w by rgacogne@mamot.fr
2023-02-13T14:27:18Z
0 likes, 0 repeats
@bortzmeyer @winfried I see that the NS and SOA types are set in the NSEC record for ip.dyn.bortzmeyer.fr present in the answer for ip.dyn.bortzmeyer.fr|A, whichs seems to indicate that ip.dyn.bortzmeyer.fr is the apex of the current zone, while the signer of the corresponding RRSIG, and the SOA record delivered in the same answer both state that the apex is at dyn.bortzmeyer.fr. PowerDNS Recursor will reject non-apex NSEC(3)s that have both the NS and SOA bits set.
(DIR) Post #ASdiF78X2eK4LnJvHc by bortzmeyer@mastodon.gougere.fr
2023-02-13T14:30:58Z
0 likes, 0 repeats
@rgacogne @winfried Why this extra rule? It does not seem to be in the RFCs.
(DIR) Post #ASdirieW0Umjhxgkro by rgacogne@mamot.fr
2023-02-13T14:37:54Z
0 likes, 0 repeats
@bortzmeyer @winfried If I remember correctly, we added it as a hardening check when making sure we were following rfc5155 section 8.9: https://www.rfc-editor.org/rfc/rfc5155.html#section-8.9
(DIR) Post #ASjnWVudqNU6plhOeu by bortzmeyer@mastodon.gougere.fr
2023-02-16T12:58:22Z
0 likes, 0 repeats
@rgacogne @winfried I just modified Drink for this case https://framagit.org/bortzmeyer/drink/-/commit/37b4ca6eae9ce3e2c83363cd7a806ab49ce18523#72f44c84dd066f302273343a6519ba224dc540de_109_111 and it's now deployed (dyn.bortzmeyer.fr and dyn.sources.org). It should now be OK with PowerDNS Recursor.
(DIR) Post #ASlwMO01hJdZIdNoQq by rgacogne@mamot.fr
2023-02-17T13:46:43Z
0 likes, 0 repeats
@bortzmeyer @winfried Wonderful, thank you! For completeness, having the NS bit set when not at the apex is fine, it happens for ancestor delegations, but the SOA is indeed an issue for our validator.