| Summary: | NXDOMAIN replies by unbound when querying local hosts after Core Update 143 | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Giovanni Aneloni <giovanni.aneloni> |
| Component: | --- | Assignee: | Michael Tremer <michael.tremer> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | Major Usability | ||
| Priority: | - Unknown - | CC: | datamorgana, giovanni.aneloni, kairis, makrie, michael.tremer, peter.mueller, peter.mueller |
| Version: | 2 | ||
| Hardware: | all | ||
| OS: | All | ||
| Attachments: |
NXDOMAIN screenshot
attachment-5338-0.html attachment-7704-0.html attachment-17695-0.html |
||
|
Description
Giovanni Aneloni
2020-04-25 14:14:48 UTC
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 |