[Dnsmasq-discuss] TCP DNSSEC request over IPv6 abandoned in v2.79

[Chris Staite]

Hi,

I've recently upgraded my router to an alpha firmware that uses DNSmasq v2.79. I'm having issues with it performing DNSSEC validation that I didn't have with the old version of DNSmasq (which I'm not entirely sure which version it was).

I've managed to pin down the exact conditions that cause the error. When I perform DNSSEC validation over IPv6 for a long domain it causes DNSmasq to return SRVFAIL. Specifically, I get the log message "validation 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct is ABANDONED".

The full trail of the log is:

Sep 25 20:40:42 dnsmasq[24782]: query[A] 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct from 192.168.1.107
Sep 25 20:40:42 dnsmasq[24782]: forwarded 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct to 2606:4700:4700::1111
Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DS] direct to 2606:4700:4700::1111
Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DNSKEY] . to 2606:4700:4700::1111
Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 20326, algo 8
Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 2134, algo 8
Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 41656, algo 8
Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 19036, algo 8
Sep 25 20:40:42 dnsmasq[24782]: reply direct is DS keytag 20629, algo 8, digest 1
Sep 25 20:40:42 dnsmasq[24782]: reply direct is DS keytag 20629, algo 8, digest 2
Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DS] plex.direct to 2606:4700:4700::1111
Sep 25 20:40:42 dnsmasq[24782]: validation 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct is ABANDONED

If the request is performed over UDP it is successful, but the length forces it to fall back to TCP which has this issue. The only difference between the queries that I can see from the packet captures is that the Transaction ID is 0 for all of the follow-up queries over TCP. Looking through the source it seems the processing for TCP is completely separate to UDP, so there may be a logic error between them?

I'm happy to provide any more packet captures or information as required. I currently don't have a cross-compiling environment set up to build changes for the router binary, but if that would be helpful I could probably make one.

Thanks, Chris.

[Simon Kelley]

Post by Chris Staite
Hi,
I've recently upgraded my router to an alpha firmware that uses DNSmasq v2.79. I'm having issues with it performing DNSSEC validation that I didn't have with the old version of DNSmasq (which I'm not entirely sure which version it was).
I've managed to pin down the exact conditions that cause the error. When I perform DNSSEC validation over IPv6 for a long domain it causes DNSmasq to return SRVFAIL. Specifically, I get the log message "validation 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct is ABANDONED".
Sep 25 20:40:42 dnsmasq[24782]: query[A] 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct from 192.168.1.107
Sep 25 20:40:42 dnsmasq[24782]: forwarded 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct to 2606:4700:4700::1111
Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DS] direct to 2606:4700:4700::1111
Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DNSKEY] . to 2606:4700:4700::1111
Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 20326, algo 8
Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 2134, algo 8
Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 41656, algo 8
Sep 25 20:40:42 dnsmasq[24782]: reply . is DNSKEY keytag 19036, algo 8
Sep 25 20:40:42 dnsmasq[24782]: reply direct is DS keytag 20629, algo 8, digest 1
Sep 25 20:40:42 dnsmasq[24782]: reply direct is DS keytag 20629, algo 8, digest 2
Sep 25 20:40:42 dnsmasq[24782]: dnssec-query[DS] plex.direct to 2606:4700:4700::1111
Sep 25 20:40:42 dnsmasq[24782]: validation 192-168-0-123.0d0f0601f95b420c82cb9dcac0f0a2d5.plex.direct is ABANDONED
If the request is performed over UDP it is successful, but the length forces it to fall back to TCP which has this issue. The only difference between the queries that I can see from the packet captures is that the Transaction ID is 0 for all of the follow-up queries over TCP. Looking through the source it seems the processing for TCP is completely separate to UDP, so there may be a logic error between them?
I'm happy to provide any more packet captures or information as required. I currently don't have a cross-compiling environment set up to build changes for the router binary, but if that would be helpful I could probably make one.

You say "When I perform DNSSEC validation over IPv6" which implies, but
doesn't state, that the same test works when talking to usptream DNS
servers over IPv4? Is that the case? Certainly, a quick test here works
over IPv4. I'm wondering if I need to resurrect my severely bit-rotted
IPv6 tunnel setup?


Cheers,

Simon.

[Josh Soref]

Post by Simon Kelley
You say "When I perform DNSSEC validation over IPv6" which implies, but
doesn't state, that the same test works when talking to usptream DNS
servers over IPv4? Is that the case? Certainly, a quick test here works
over IPv4. I'm wondering if I need to resurrect my severely bit-rotted
IPv6 tunnel setup?

Fwiw, I found https://tunnelbroker.net/ to be very easy to set up...
(Everything else related to dns is harder...)

[Simon Kelley]

Post by Josh Soref

Post by Simon Kelley
You say "When I perform DNSSEC validation over IPv6" which implies, but
doesn't state, that the same test works when talking to usptream DNS
servers over IPv4? Is that the case? Certainly, a quick test here works
over IPv4. I'm wondering if I need to resurrect my severely bit-rotted
IPv6 tunnel setup?

Fwiw, I found https://tunnelbroker.net/ to be very easy to set up...
(Everything else related to dns is harder...)

I used to use sixxs, but that's gone now.

My ISP (EE) seems to be rolling out IPv6, so it might be best to try and
get the stuff at this end set up for that. Being mobile makes it all
more difficult.



Cheers,

Simon.