On 13/05/2019 10:40, Kevin Darbyshire-Bryant wrote:
> Hi All,
>
> Part of the reason for submitting
> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q2/013026.html
> "[PATCH] dnssec: add hostname info to insecure DS warning” was to easily find
> out what domain was prompting the warning.
>
> Some of my mystery ‘Insecure DS reply’ turns out to be this:
>
> Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply
> received for 168.192.in-addr.arpa, check domain configuration and upstream
> DNS server DNSSEC support
> Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply
> received for 168.192.in-addr.arpa, check domain configuration and upstream
> DNS server DNSSEC support
> Mon May 13 09:57:27 2019 daemon.warn dnsmasq[20911]: Insecure DS reply
> received for 168.192.in-addr.arpa, check domain configuration and upstream
> DNS server DNSSEC support
> Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply
> received for 168.192.in-addr.arpa, check domain configuration and upstream
> DNS server DNSSEC support
> Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply
> received for 168.192.in-addr.arpa, check domain configuration and upstream
> DNS server DNSSEC support
> Mon May 13 09:58:57 2019 daemon.warn dnsmasq[20911]: Insecure DS reply
> received for 168.192.in-addr.arpa, check domain configuration and upstream
> DNS server DNSSEC support
>
> Is this a genuine configuration error on my/upstream’s part or is it false
> positive log spam?
>
> (I think) The relevant bits from dnsmasq config:
>
> dnssec
> dnssec-check-unsigned
>
> Upstream servers are Google’s 8.8.8.8 & friends.
>
> Trust anchors:
>
> trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
> trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
>
>
Continuing through the mail backlog from the missing months
I think the answer is that Google & friends block queries to the RFC
1918 ranges, and return locally generated (and not DNSSEC signed)
replies. Cloudflare even tells you.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51064
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;168.192.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
168.192.in-addr.arpa. 10800 IN SOA nobody.invalid. nobody.invalid.
1
3600 1200 604800 10800
;; ADDITIONAL SECTION:
explanation.invalid.10800 IN TXT "Blocking is mandated by
standards,
see references on
https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml";
Since these are not signed, validators try and check that's ok, by
proving that there is no DS record for 168.192.in-addr.arpa
If you go to the authoritative servers then that proof is indeed
available, but the DS queries get blocked by Google and cloudflare too,
so dnsmasq can't get at it. Hence it fails and gets upset.
The best you can do is tell dnsmasq never to forward such queries with
--server=/168.192.in-addr.arpa/
You should be able to do the same more nicely with
--rev-server=192.168.0.0/16
but that's broken for the "no server address" case. I just pushed a fix
for that.
Cheers,
Simon.
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
