[Dnsmasq-discuss] DNSSEC query sent upstream despite local domain

Mon May 5 08:20:42 UTC 2025

On Mon, May 05, 2025 at 08:58:12AM +0200, Geert Stappers wrote:
> On Sun, May 04, 2025 at 07:29:14PM +0200, Dominik Derigs wrote:
> > 
> >  .... seeing an interesting report,
> > 
> > Relevant config lines are:
> > 
> > no-resolv
> > bogus-priv
> > server=8.8.8.8
> > server=8.8.4.4
> > rev-server=10.0.1.0/24,10.0.1.1
> > server=/fritz.box/10.0.1.1
> > dnssec
> > trust-anchor=.,<the default value)
> >
> >  .... log file:
> > Apr 21 19:00:01 dnsmasq[310194]: query[PTR] 1.1.0.10.in-addr.arpa from 127.0.0.1
> > Apr 21 19:00:01 dnsmasq[310194]: forwarded 1.1.0.10.in-addr.arpa to 10.0.1.1
> > Apr 21 19:00:01 dnsmasq[310194]: dnssec-query[DS] 10.in-addr.arpa to 8.8.4.4
> > Apr 21 19:00:01 dnsmasq[310194]: Insecure DS reply received for 10.in-addr.arpa, check domain configuration and upstream DNS server DNSSEC support
> > Apr 21 19:00:01 dnsmasq[310194]: reply 10.in-addr.arpa is BOGUS DS - not secure
> > Apr 21 19:00:01 dnsmasq[310194]: validation 1.1.0.10.in-addr.arpa is BOGUS
> > 
> > In the context of bogus-priv - is it actually expected that DNSSEC-related
> > queries are sent to non-local servers? My interpretation is that they
> > shouldn't be sent upstream here...
> 
> I do understand the concern.  I don't understand the (assumed?) relation
> between dnsmasq option bogus-priv and DNSSEC.

I still understand there is a concern, but not what the actual concern is.

My hope that is there will be further information.  Info about
what the expected behaviour of dnsmasq should be. And why.

What follows doesn't need be in a follow-up message.
Short version: There was effort made to understand the original posting.

> I would like to see a completer log file.

Because the provided log file looks incomplete.

> So I did a reproduce attempt.

It became several attempts. In my defense: No one said it would be easy.
And "first time right" was too optimistic.

> Config:
> rev-server=172.24.0.0/26,172.24.0.1
> server=/fritz.box/172.24.0.1

It is a translation of
> > rev-server=10.0.1.0/24,10.0.1.1
> > server=/fritz.box/10.0.1.1
to my network.

> Query:
> $ host 172.24.0.1
> 1.0.24.172.in-addr.arpa domain name pointer fritz.box.
> $
> 
> Logfile:
    ......
> mei 05 07:55:45 alpaca dnsmasq[23365]: started, version 2.92test1-1-ge8781a4 cachesize 150
    ......
> mei 05 07:56:03 alpaca dnsmasq[23365]: query[PTR] 1.0.24.172.in-addr.arpa from 172.24.0.9
> mei 05 07:56:03 alpaca dnsmasq[23365]: forwarded 1.0.24.172.in-addr.arpa to 172.24.0.1
> mei 05 07:56:03 alpaca dnsmasq[23365]: reply 172.24.0.1 is fritz.box

That reply is lacking in the original posting.

> Oh, that is without `dnssec` in the configurtion.  New attempt. Same query.
> 
> mei 05 08:26:00 alpaca dnsmasq[23449]: started, version 2.92test1-1-ge8781a4 cachesize 150
> 
> mei 05 08:28:36 alpaca dnsmasq[23449]: query[PTR] 1.0.24.172.in-addr.arpa from 172.24.0.9
> mei 05 08:28:36 alpaca dnsmasq[23449]: forwarded 1.0.24.172.in-addr.arpa to 172.24.0.1
> mei 05 08:28:36 alpaca dnsmasq[23449]: dnssec-query[DS] 172.in-addr.arpa to 127.0.0.1#35353

At 127.0.0.1:35353 listens bind9,  I have `server=127.0.0.1#35353`

> mei 05 08:28:36 alpaca dnsmasq[23449]: reply 172.in-addr.arpa is DS for keytag 8719, algo 8, digest 2
> mei 05 08:28:36 alpaca dnsmasq[23449]: dnssec-query[DS] 24.172.in-addr.arpa to 127.0.0.1#35353
> mei 05 08:28:36 alpaca dnsmasq[23449]: dnssec-query[DNSKEY] 172.in-addr.arpa to 127.0.0.1#35353
> mei 05 08:28:36 alpaca dnsmasq[23449]: reply 172.in-addr.arpa is truncated
> mei 05 08:28:36 alpaca dnsmasq[23475]: dnssec-query[DNSKEY] 172.in-addr.arpa to 127.0.0.1#35353
> mei 05 08:28:36 alpaca dnsmasq[23475]: reply 172.in-addr.arpa is DNSKEY keytag 8719, algo 8
> mei 05 08:28:36 alpaca dnsmasq[23475]: reply 172.in-addr.arpa is DNSKEY keytag 17836, algo 8
> mei 05 08:28:36 alpaca dnsmasq[23475]: reply 172.in-addr.arpa is DNSKEY keytag 52701, algo 8
> mei 05 08:28:36 alpaca dnsmasq[23475]: reply 172.in-addr.arpa is DNSKEY keytag 38739, algo 8
> mei 05 08:28:36 alpaca dnsmasq[23449]: reply 24.172.in-addr.arpa is no DS
> mei 05 08:28:36 alpaca dnsmasq[23449]: validation result is INSECURE
> mei 05 08:28:36 alpaca dnsmasq[23449]: reply 172.24.0.1 is fritz.box

Again more log lines as in the original posting.

> Chips, a third attempt is needed. One with `bogus-priv` active.
> 
> mei 05 08:38:13 alpaca dnsmasq[23511]: started, version 2.92test1-1-ge8781a4 cachesize 150
>  
> mei 05 08:39:27 alpaca dnsmasq[23511]: query[PTR] 1.0.24.172.in-addr.arpa from 172.24.0.9
> mei 05 08:39:27 alpaca dnsmasq[23511]: forwarded 1.0.24.172.in-addr.arpa to 172.24.0.1
> mei 05 08:39:27 alpaca dnsmasq[23511]: dnssec-query[DS] 172.in-addr.arpa to 127.0.0.1#35353
> mei 05 08:39:27 alpaca dnsmasq[23511]: reply 172.in-addr.arpa is DS for keytag 8719, algo 8, digest 2
> mei 05 08:39:27 alpaca dnsmasq[23511]: dnssec-query[DS] 24.172.in-addr.arpa to 127.0.0.1#35353
> mei 05 08:39:27 alpaca dnsmasq[23511]: dnssec-query[DNSKEY] 172.in-addr.arpa to 127.0.0.1#35353
> mei 05 08:39:27 alpaca dnsmasq[23511]: reply 172.in-addr.arpa is truncated
> mei 05 08:39:27 alpaca dnsmasq[23542]: dnssec-query[DNSKEY] 172.in-addr.arpa to 127.0.0.1#35353
> mei 05 08:39:27 alpaca dnsmasq[23542]: reply 172.in-addr.arpa is DNSKEY keytag 17836, algo 8
> mei 05 08:39:27 alpaca dnsmasq[23542]: reply 172.in-addr.arpa is DNSKEY keytag 8719, algo 8
> mei 05 08:39:27 alpaca dnsmasq[23542]: reply 172.in-addr.arpa is DNSKEY keytag 52701, algo 8
> mei 05 08:39:27 alpaca dnsmasq[23542]: reply 172.in-addr.arpa is DNSKEY keytag 38739, algo 8
> mei 05 08:39:27 alpaca dnsmasq[23511]: reply 24.172.in-addr.arpa is no DS
> mei 05 08:39:27 alpaca dnsmasq[23511]: validation result is INSECURE
> mei 05 08:39:27 alpaca dnsmasq[23511]: reply 172.24.0.1 is fritz.box
> 
> 
> My current interpretation is that `bogus-priv` is ignored.

That will require further tests. Don't wait for me to do those tests,
the `bogus-priv` functionality handles bind for me.

> DNSMASQ(8)          System Manager's Manual         DNSMASQ(8)
>      ....
>        -b, --bogus-priv
>               Bogus   private  reverse  lookups.  All  reverse
>               lookups for private IP ranges  (ie  192.168.x.x,
>               etc)  which  are  not found in /etc/hosts or the
>               DHCP leases file are answered with "no such  do‐
>               main"  rather than being forwarded upstream. The
>               set of prefixes affected is the  list  given  in
>               RFC6303, for IPv4 and IPv6.

Groeten
Geert Stappers
-- 
Silence is hard to parse