Created attachment 746 [details] NXDOMAIN screenshot After this commit : https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=1b6b8d97aac8a8056a4ef5c9d571a1947551e17f I started to get NXDOMAIN replies by unbound when querying local hosts (both with FQ and NFQ queries). The attachment shows the output of nslookup directly in the ipfire console, but the same happens on each PC in the network. I nailed down the issue to the use of the "typetransparent" directive in /etc/init.d/unbound. In my case using "static" (which is suitable in my setup) or "transparent" works well. Best regards, Giovanni
Hey Giovanni, is proxy.casa.int something that you are using as a "host" on the web UI or do you have any DNS forwarding configured? What is the output of "unbound-control list_local_data"?
Created attachment 747 [details] attachment-5338-0.html Hi Michael, it is a host record inserted through the web UI, no forwarding for the zone is defined. This is the output with a grep to avoid disclosure of more data than necessary: [root@ipfire ~]# unbound-control list_local_data |grep proxy proxy.casa.int. 60 IN A 10.5.11.125 Let me know if you really need the whole output. I chose the record "proxy" as an example, but the same applies to each host record. Best regards, Giovanni ________________________________ Da: IPFire Bugzilla <bugzilla@ipfire.org> Inviato: lunedì 27 aprile 2020 11:19 A: giovanni.aneloni@live.com <giovanni.aneloni@live.com> Oggetto: [Bug 12391] NXDOMAIN replies by unbound when querying local hosts after Core Update 143 Michael Tremer<mailto:michael.tremer@ipfire.org> changed bug 12391<https://bugzilla.ipfire.org/show_bug.cgi?id=12391> What Removed Added Assignee nobody@ipfire.org michael.tremer@ipfire.org Status NEW ASSIGNED CC michael.tremer@ipfire.org Comment # 1<https://bugzilla.ipfire.org/show_bug.cgi?id=12391#c1> on bug 12391<https://bugzilla.ipfire.org/show_bug.cgi?id=12391> from Michael Tremer<mailto:michael.tremer@ipfire.org> Hey Giovanni, is proxy.casa.int something that you are using as a "host" on the web UI or do you have any DNS forwarding configured? What is the output of "unbound-control list_local_data"? ________________________________ You are receiving this mail because: * You are on the CC list for the bug. * You reported the bug.
According to the documentation typetransparent is correct and should work: > typetransparent > If there is a match from local data, the query is answered. If the query is for a different name, or for the same name but for a different type, the query is resolved normally. So, similar to transparent but types that are not listed in local data are resolved normally, so if an A record is in the local data that does not cause a nodata reply for AAAA queries. https://linux.die.net/man/5/unbound.conf Static would not resolve any other hostnames in the same domain. The whole output would be helpful to see if there are any other entries matching first. Can you try disabling all other entries and only keeping this one?
Created attachment 748 [details] attachment-7704-0.html Hi Michael, I believe the behavior is as expected, we need no more investigation: Nslookup queries by default BOTH ipv4 (A) and ipv6 (AAAA) records: for instance: [root@ipfire ~]# nslookup www.google.it Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: www.google.it Address: 216.58.206.35 Name: www.google.it Address: 2a00:1450:4002:801::2003 So with "typetransparent", when querying local hostnames, the A record matches, but the AAAA query is forwarded to the default resolver which has no clues about the local zone and returns NXDOMAIN. As we can see manually specifying the type of query. [root@ipfire ~]# nslookup > set q=A > proxy Server: 127.0.0.1 Address: 127.0.0.1#53 Name: proxy.casa.int Address: 10.5.11.125 > set q=AAAA > proxy Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find proxy: NXDOMAIN > exit For my personal taste I'd like more "static" because I do not want to forward queries concerning my local zone to my provider, and that would not beneficial anyway since it cannot answer, but maybe that would not fit everyone needs. If you are (and welcome to be) of a different opinion maybe "transparent" could be a balanced choice since it forwards the query only in the case there is no match in local. With "transparent" if would be possible to override specific hosts of public domains, without troubles resolving the whole domain. If I understand correctly this ability is what you are seeing as appealing, and I can agree. Typetransparent, on the contrary, delivers a mixed answer in which the A query succeeds and the AAAA query fails. Some software detect this as a failure in name resolution, and I don't see advantages in doing so. [root@ipfire ~]# nslookup proxy Server: 127.0.0.1 Address: 127.0.0.1#53 Name: proxy.casa.int Address: 10.5.11.125 -> A record, postive answer ** server can't find proxy.casa.int: NXDOMAIN -> AAAA record, failure As a bottom line "transparent" seems a solid default choice, with no downsides. Let me know if I can support with more information. Thanks a lot for your time and effort on the project. Best regards, Giovanni ________________________________ Da: IPFire Bugzilla <bugzilla@ipfire.org> Inviato: lunedì 27 aprile 2020 14:27 A: giovanni.aneloni@live.com <giovanni.aneloni@live.com> Oggetto: [Bug 12391] NXDOMAIN replies by unbound when querying local hosts after Core Update 143 Comment # 3<https://bugzilla.ipfire.org/show_bug.cgi?id=12391#c3> on bug 12391<https://bugzilla.ipfire.org/show_bug.cgi?id=12391> from Michael Tremer<mailto:michael.tremer@ipfire.org> According to the documentation typetransparent is correct and should work: > typetransparent > If there is a match from local data, the query is answered. If the query is for a different name, or for the same name but for a different type, the query is resolved normally. So, similar to transparent but types that are not listed in local data are resolved normally, so if an A record is in the local data that does not cause a nodata reply for AAAA queries. https://linux.die.net/man/5/unbound.conf Static would not resolve any other hostnames in the same domain. The whole output would be helpful to see if there are any other entries matching first. Can you try disabling all other entries and only keeping this one? ________________________________ You are receiving this mail because: * You reported the bug. * You are on the CC list for the bug.
Created attachment 749 [details] attachment-17695-0.html To further help with the diagnosis i just installed a pristine ipfire on a VM, and did nothing else beside configuring NICs and definining a host named "one" in the web interface. This is the output (this time I used the command host to exclude it was something tied to nslookup). [root@ipfire ~]# host google.com google.com has address 216.58.208.174 google.com has IPv6 address 2a00:1450:4002:800::200e google.com mail is handled by 20 alt1.aspmx.l.google.com. google.com mail is handled by 40 alt3.aspmx.l.google.com. google.com mail is handled by 50 alt4.aspmx.l.google.com. google.com mail is handled by 30 alt2.aspmx.l.google.com. google.com mail is handled by 10 aspmx.l.google.com. [root@ipfire ~]# host one one.localdomain has address 10.5.11.1 Host one.localdomain not found: 3(NXDOMAIN) Host one.localdomain not found: 3(NXDOMAIN) [root@ipfire ~]# unbound-control list_local_data 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN NS localhost. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN PTR localhost. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN NS localhost. 8.b.d.0.1.0.0.2.ip6.arpa. 10800 IN NS localhost. 8.b.d.0.1.0.0.2.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 d.f.ip6.arpa. 10800 IN NS localhost. d.f.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 8.e.f.ip6.arpa. 10800 IN NS localhost. 8.e.f.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 9.e.f.ip6.arpa. 10800 IN NS localhost. 9.e.f.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 a.e.f.ip6.arpa. 10800 IN NS localhost. a.e.f.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 b.e.f.ip6.arpa. 10800 IN NS localhost. b.e.f.ip6.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 0.in-addr.arpa. 10800 IN NS localhost. 0.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 10.in-addr.arpa. 10800 IN NS localhost. 10.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 1.11.5.10.in-addr.arpa. 60 IN PTR one.localdomain. 7.11.5.10.in-addr.arpa. 60 IN PTR ipfire.localdomain. 64.100.in-addr.arpa. 10800 IN NS localhost. 64.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 65.100.in-addr.arpa. 10800 IN NS localhost. 65.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 66.100.in-addr.arpa. 10800 IN NS localhost. 66.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 67.100.in-addr.arpa. 10800 IN NS localhost. 67.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 68.100.in-addr.arpa. 10800 IN NS localhost. 68.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 69.100.in-addr.arpa. 10800 IN NS localhost. 69.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 70.100.in-addr.arpa. 10800 IN NS localhost. 70.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 71.100.in-addr.arpa. 10800 IN NS localhost. 71.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 72.100.in-addr.arpa. 10800 IN NS localhost. 72.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 73.100.in-addr.arpa. 10800 IN NS localhost. 73.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 74.100.in-addr.arpa. 10800 IN NS localhost. 74.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 75.100.in-addr.arpa. 10800 IN NS localhost. 75.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 76.100.in-addr.arpa. 10800 IN NS localhost. 76.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 77.100.in-addr.arpa. 10800 IN NS localhost. 77.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 78.100.in-addr.arpa. 10800 IN NS localhost. 78.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 79.100.in-addr.arpa. 10800 IN NS localhost. 79.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 80.100.in-addr.arpa. 10800 IN NS localhost. 80.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 81.100.in-addr.arpa. 10800 IN NS localhost. 81.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 82.100.in-addr.arpa. 10800 IN NS localhost. 82.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 83.100.in-addr.arpa. 10800 IN NS localhost. 83.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 84.100.in-addr.arpa. 10800 IN NS localhost. 84.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 85.100.in-addr.arpa. 10800 IN NS localhost. 85.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 86.100.in-addr.arpa. 10800 IN NS localhost. 86.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 87.100.in-addr.arpa. 10800 IN NS localhost. 87.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 88.100.in-addr.arpa. 10800 IN NS localhost. 88.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 89.100.in-addr.arpa. 10800 IN NS localhost. 89.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 90.100.in-addr.arpa. 10800 IN NS localhost. 90.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 91.100.in-addr.arpa. 10800 IN NS localhost. 91.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 92.100.in-addr.arpa. 10800 IN NS localhost. 92.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 93.100.in-addr.arpa. 10800 IN NS localhost. 93.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 94.100.in-addr.arpa. 10800 IN NS localhost. 94.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 95.100.in-addr.arpa. 10800 IN NS localhost. 95.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 96.100.in-addr.arpa. 10800 IN NS localhost. 96.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 97.100.in-addr.arpa. 10800 IN NS localhost. 97.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 98.100.in-addr.arpa. 10800 IN NS localhost. 98.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 99.100.in-addr.arpa. 10800 IN NS localhost. 99.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 100.100.in-addr.arpa. 10800 IN NS localhost. 100.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 101.100.in-addr.arpa. 10800 IN NS localhost. 101.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 102.100.in-addr.arpa. 10800 IN NS localhost. 102.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 103.100.in-addr.arpa. 10800 IN NS localhost. 103.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 104.100.in-addr.arpa. 10800 IN NS localhost. 104.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 105.100.in-addr.arpa. 10800 IN NS localhost. 105.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 106.100.in-addr.arpa. 10800 IN NS localhost. 106.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 107.100.in-addr.arpa. 10800 IN NS localhost. 107.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 108.100.in-addr.arpa. 10800 IN NS localhost. 108.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 109.100.in-addr.arpa. 10800 IN NS localhost. 109.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 110.100.in-addr.arpa. 10800 IN NS localhost. 110.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 111.100.in-addr.arpa. 10800 IN NS localhost. 111.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 112.100.in-addr.arpa. 10800 IN NS localhost. 112.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 113.100.in-addr.arpa. 10800 IN NS localhost. 113.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 114.100.in-addr.arpa. 10800 IN NS localhost. 114.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 115.100.in-addr.arpa. 10800 IN NS localhost. 115.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 116.100.in-addr.arpa. 10800 IN NS localhost. 116.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 117.100.in-addr.arpa. 10800 IN NS localhost. 117.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 118.100.in-addr.arpa. 10800 IN NS localhost. 118.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 119.100.in-addr.arpa. 10800 IN NS localhost. 119.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 120.100.in-addr.arpa. 10800 IN NS localhost. 120.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 121.100.in-addr.arpa. 10800 IN NS localhost. 121.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 122.100.in-addr.arpa. 10800 IN NS localhost. 122.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 123.100.in-addr.arpa. 10800 IN NS localhost. 123.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 124.100.in-addr.arpa. 10800 IN NS localhost. 124.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 125.100.in-addr.arpa. 10800 IN NS localhost. 125.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 126.100.in-addr.arpa. 10800 IN NS localhost. 126.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 127.100.in-addr.arpa. 10800 IN NS localhost. 127.100.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 127.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 127.in-addr.arpa. 10800 IN NS localhost. 1.0.0.127.in-addr.arpa. 10800 IN PTR localhost. 254.169.in-addr.arpa. 10800 IN NS localhost. 254.169.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 16.172.in-addr.arpa. 10800 IN NS localhost. 16.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 17.172.in-addr.arpa. 10800 IN NS localhost. 17.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 18.172.in-addr.arpa. 10800 IN NS localhost. 18.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 19.172.in-addr.arpa. 10800 IN NS localhost. 19.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 20.172.in-addr.arpa. 10800 IN NS localhost. 20.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 21.172.in-addr.arpa. 10800 IN NS localhost. 21.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 22.172.in-addr.arpa. 10800 IN NS localhost. 22.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 23.172.in-addr.arpa. 10800 IN NS localhost. 23.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 24.172.in-addr.arpa. 10800 IN NS localhost. 24.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 25.172.in-addr.arpa. 10800 IN NS localhost. 25.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 26.172.in-addr.arpa. 10800 IN NS localhost. 26.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 27.172.in-addr.arpa. 10800 IN NS localhost. 27.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 28.172.in-addr.arpa. 10800 IN NS localhost. 28.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 29.172.in-addr.arpa. 10800 IN NS localhost. 29.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 30.172.in-addr.arpa. 10800 IN NS localhost. 30.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 31.172.in-addr.arpa. 10800 IN NS localhost. 31.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 2.0.192.in-addr.arpa. 10800 IN NS localhost. 2.0.192.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 168.192.in-addr.arpa. 10800 IN NS localhost. 168.192.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 100.51.198.in-addr.arpa. 10800 IN NS localhost. 100.51.198.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 113.0.203.in-addr.arpa. 10800 IN NS localhost. 113.0.203.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 255.255.255.255.in-addr.arpa. 10800 IN NS localhost. 255.255.255.255.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 test. 10800 IN NS localhost. test. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 onion. 10800 IN NS localhost. onion. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 invalid. 10800 IN NS localhost. invalid. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 localhost. 10800 IN AAAA ::1 localhost. 10800 IN A 127.0.0.1 localhost. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 localhost. 10800 IN NS localhost. ipfire.localdomain. 60 IN A 10.5.11.7 one.localdomain. 60 IN A 10.5.11.1 [root@ipfire ~]# Hope this helps, Giovanni
(In reply to Giovanni Aneloni from comment #4) > So with "typetransparent", when querying local hostnames, the A record > matches, but the AAAA query is forwarded to the default resolver which has > no clues about the local zone and returns NXDOMAIN. Okay. That is not what I expected. > As a bottom line "transparent" seems a solid default choice, with no > downsides. I agree. Would you be happy to submit a patch to the mailing list? > https://wiki.ipfire.org/devel/submit-patches P.S. Also, if you quote an email, maybe drop the original email, because Bugzilla does not seem to handle it well.
I've read the wiki and submitted the patch to development@lists.ipfire.org, don't hesitate to point out any mistake if I have missed something. Fixes: https://bugzilla.ipfire.org/show_bug.cgi?id=12391 Change local zone to "trasnparent" instead of "typetransparent" to avoid NXDOMAIN when querying local hosts Signed-off-by: Giovanni Aneloni <giovanni.aneloni@live.com> --- diff --git a/src/initscripts/system/unbound b/src/initscripts/system/unbound index acbf6f5b5..825ac74ec 100644 --- a/src/initscripts/system/unbound +++ b/src/initscripts/system/unbound @@ -81,7 +81,7 @@ write_hosts_conf() { # Skip empty domainnames [ "${domainname}" = "" ] && continue - echo "local-zone: ${domainname} typetransparent" + echo "local-zone: ${domainname} transparent" done < /var/ipfire/main/hosts | sort -u # Add all hosts
Thank you for the patch. That looks excellent. However, since people on the list have raised concerns, let's see if the proposed solution will work for everyone.
> However, since people on the list have raised concerns, let's see if the > proposed solution will work for everyone. +1 from my point of view for this. :-)
Hello, I observed the identical issue on my system due to nslookup queries on my IPFire system (3rdfire) like Giovanni: [root@3rdfire ~]# nslookup 3rdfire Server: 127.0.0.1 Address: 127.0.0.1#53 Name: 3rdfire.home.arpa Address: 192.168.1.1 ** server can't find 3rdfire.home.arpa: NXDOMAIN [root@3rdfire ~]# unbound-control list_local_data | grep 3rdfire 3rdfire.home.arpa. 60 IN A 192.168.1.1 1.1.168.192.in-addr.arpa. 60 IN PTR 3rdfire.home.arpa. 1.2.168.192.in-addr.arpa. 60 IN PTR 3rdfire.home.arpa. 1.3.168.192.in-addr.arpa. 60 IN PTR 3rdfire.home.arpa. The same could be observed for clients, at green for example: [root@3rdfire ~]# nslookup k48 Server: 127.0.0.1 Address: 127.0.0.1#53 Name: k48.home.arpa Address: 192.168.1.5 ** server can't find k48.home.arpa: NXDOMAIN [root@3rdfire ~]# unbound-control list_local_data | grep k48 k48.home.arpa. 60 IN A 192.168.1.5 5.1.168.192.in-addr.arpa. 60 IN PTR k48.home.arpa. Not nice but no sigificant issue so far. Contrary to this switching to a client machine shows some instability: k48:~# nslookup 3rdfire Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: 3rdfire.home.arpa Address: 192.168.1.1 ** server can't find 3rdfire.home.arpa: NXDOMAIN k48:~# nslookup 3rdfire Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find 3rdfire: SERVFAIL After a while nslookup queries respond with SERVFAIL. Restarting the network restores the NXDOMAIN response: k48:~# systemctl restart systemd-networkd k48:~# nslookup 3rdfire Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: 3rdfire.home.arpa Address: 192.168.1.1 ** server can't find 3rdfire.home.arpa: NXDOMAIN But the SERVFAIL will come back after while: k48:~# nslookup 3rdfire Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find 3rdfire: SERVFAIL As you can see my (debian testing) client machine bases on systemd-resolved using the 127.0.0.53 stub-resolver. It seems that systemd-resolved is (time delayed) sensitive to NXDOMAIN DNS responses. A dig directly to 3rdfire unbound resolver shows no issue: k48:~# dig @192.168.1.1 3rdfire.home.arpa ; <<>> DiG 9.16.8-Debian <<>> @192.168.1.1 3rdfire.home.arpa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36231 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;3rdfire.home.arpa. IN A ;; ANSWER SECTION: 3rdfire.home.arpa. 60 IN A 192.168.1.1 ;; Query time: 0 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Mi Dez 30 16:40:46 CET 2020 ;; MSG SIZE rcvd: 62 As shown the replacement in /etc/init.d/unbound at line 84: echo "local-zone: \"${domainname}\" transparent" avoids the NXDOMAIN response on IPFire (3rdfire): [root@3rdfire ~]# nslookup 3rdfire Server: 127.0.0.1 Address: 127.0.0.1#53 Name: 3rdfire.home.arpa Address: 192.168.1.1 Also the same situation on the systemd-resolved based client (k48): k48:~# nslookup 3rdfire Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: 3rdfire.home.arpa Address: 192.168.1.1 No NXDOMAIN and later on SERVFAIL issue. To conclude the observations I would recommend accept the patch. The option transparent instead of typetransparent seems to be a more stable solution. Regards, Martin Krieger (makrie)
Hello, after several attempts I found a solution for this issue that does not require a change from typetransparent to transparent for the local zone in the server section of unbound.conf. The background of this is that several dns tools does a simultaneous query for A & AAAA type (IPv4 & IPv6) records: [root@3rdfire ~]# nslookup 3rdfire Server: 127.0.0.1 Address: 127.0.0.1#53 Name: 3rdfire.home.arpa Address: 192.168.1.1 ** server can't find 3rdfire.home.arpa: NXDOMAIN So we simply get two answers, a successfull for IPv4 and NXDOMAIN for IPv6! This is due to the fact that IPFire bases on IPv4. The IPv6 query will be forwarded as you can see if we use the debug option of nslookup: root@3rdfire ~]# nslookup -debug 3rdfire Server: 127.0.0.1 Address: 127.0.0.1#53 ------------ QUESTIONS: 3rdfire.home.arpa, type = A, class = IN ANSWERS: -> 3rdfire.home.arpa internet address = 192.168.1.1 ttl = 60 AUTHORITY RECORDS: ADDITIONAL RECORDS: ------------ Name: 3rdfire.home.arpa Address: 192.168.1.1 ------------ QUESTIONS: 3rdfire.home.arpa, type = AAAA, class = IN ANSWERS: AUTHORITY RECORDS: -> home.arpa origin = prisoner.iana.org mail addr = hostmaster.root-servers.org serial = 1 refresh = 604800 retry = 60 expire = 604800 minimum = 604800 ttl = 1234 ADDITIONAL RECORDS: ------------ ** server can't find 3rdfire.home.arpa: NXDOMAIN On the first sight no problem, but the AAAA record will be stored in the unbound cache for a temporary ttl time period served by the origin of the IPv6 query answer! This is not a problem for IPFire but for any subsequent stub-resolver in the local zone because the IPv4 & IPv6 answers will propagate and stay for some time on the local zone defined by the two different authoritative dns servers. So, what should we do? Simply, we have to ensure that unsuccessfull queries, like NXDOMAIN will not enter the cache of unbound at IPFire. To achieve this we need to create local configuration file /etc/unbound/local.d/local.conf with following content: server: # Time to live maximum for RRsets and messages in the cache. cache-max-ttl: 60 # Time to live maximum for negative responses. This applies to nxdomain and nodata answers. cache-max-negative-ttl: 0 The server option cache-max-negative-ttl does the trick. It defaults to 3600 seconds! The additional cache-max-ttl is reduced from 86400 seconds to 60 seconds for sanity to correspond to the values defined in the hosts.conf file. I'm pretty shure that several mysterious dns issues reported & discussed in the support forum arose from cached IPv6 NXDOMAIN records. I hope that helps to improve IPv4 dns stabilty in IPFire. Regards, Martin Krieger (makrie)
Hello, this issue is caused if unbound in IPFire is misconfigured by the user. Any domainname of actual hosts defined on the hostname webinterface should not coincide with any domainname of the system: red (in /etc/resolv.conf), green, blue & orange. If so the described NXDOMAIN answers of non A-Type queries will happen. Influence by domainame of VPN connections (IPSec or Openvpn) where not checked by me. But I assume this will cause the same issue. Maybe I'm one of these user lacking even most basic IT/networking/security skills because of my decision to use the same domain suffix in the whole system including orange which was defined under hostname for resolving purposes. Strict name separation of domains solved the issue. Regards, Martin Krieger (makrie)
(In reply to Martin Krieger from comment #12) > Strict name separation of domains solved the issue. Yes, it would always be best to have things clean and tidy. However, the world is not perfect and people are running plenty of grown setups. Sometimes those were set up by people who did not know too much about what they were doing, or they simply did not know how large their networks would become at some point. In hindsight - I am sure - people would do many things different. However, it is not an option to not cache any negative responses. IPFire uses a DNS cache to keep things fast and that would do the opposite. So the patch as proposed is what we want. I merged it and it will be released with Core Update 154.
> So the patch as proposed is what we want. I merged it and it will be released with Core Update 154. Closing this as being FIXED, since Core Update 154 was released in March. Please reopen, if necessary. https://blog.ipfire.org/post/ipfire-2-25-core-update-154-released