Re: DNS error, from a newbee to the real experts..
>From what you posted, it appears when you query the recursive server NS1 (192.168.14.10), it returns no error, it gives back NXDOMAIN with the AD flag. That would indicate DNSSEC worked. That does not match the log messages you posted, that would indicate there's a DNSSEC validation error, and you should have received SERVFAIL. On Mon, Jul 20, 2020 at 11:47 PM Weeltin wrote: > Hi Josh, > > Thanks for your answer, it made me go trough all the config again, just to > make sure that it wasnt pointing to the authoritative server anywhere but > in the configuration of the recursive server > > I saw that "“recursion requested but not available" when i send the query > against the authoritative. Kind a expected that, since it aint allowed to > do recursion. > > as requested i made the dig on the the authoritative server i get the > correct answer, so i expect it has loaded the zonefiles correctly. > > ns2:/home/weeltin# dig @127.0.0.01 example.home > > ; <<>> DiG 9.14.12 <<>> @127.0.0.01 example.home > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45487 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: b9129ece5d9fbc3e6f01a2215f15a461388d4af048be37fa (good) > ;; QUESTION SECTION: > ;example.home. IN A > > ;; AUTHORITY SECTION: > example.home. 604800 IN SOA ns2.example.home. hostmaster.example.home. 2 > 604800 86400 2419200 604800 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Mon Jul 20 14:04:17 UTC 2020 > ;; MSG SIZE rcvd: 120 > > > just to be sure, i rand the dig command again on my client > > [weeltin@c1 ~]$ dig c1.example.home > > ; <<>> DiG 9.11.11-RedHat-9.11.11-1.fc31 <<>> c1.example.home > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1787 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 862cc48a975a32a324cd14e65f15ba5e3f2c972d1f753586 (good) > ;; QUESTION SECTION: > ;c1.example.home. IN A > > ;; AUTHORITY SECTION: > . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020072000 > 1800 900 604800 86400 > > ;; Query time: 1043 msec > ;; SERVER: 192.168.14.10#53(192.168.14.10) > ;; WHEN: Mon Jul 20 11:38:06 EDT 2020 > ;; MSG SIZE rcvd: 147 > > > Log output from NS1 (recursive) > > Jul 20 15:38:05 ns1 daemon.info named[4022]: validating > example.home/SOA: got insecure response; parent indicates it should be > secure > Jul 20 15:38:05 ns1 daemon.info named[4022]: no valid RRSIG resolving > 'c1.example.home/DS/IN': 192.168.14.20#53 > Jul 20 15:38:06 ns1 daemon.info named[4022]: insecurity proof failed > resolving 'c1.example.home/A/IN': 192.168.14.20#53 > > > and there is no log entries on the authoritative server > > /Weeltin > > On Sun, Jul 19, 2020 at 6:05 AM Josh Kuo wrote: > >> When querying your internal domain, I see the query actually ends with >> “recursion requested but not available”, it looks like you are querying >> directly against your auth server, so I would check the setting to ensure >> the zone file is actually loaded correctly. >> >> What Mark answered is assuming you are querying the recursive which then >> returned SERVFAIL due to DNSSEC validation, but I do not see that in the >> information you provided. >> >> Can you run dig on the auth server itself, dig @ 127.0.0.1 for >> example.home, and see what it returns? >> >> >> ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS error, from a newbee to the real experts..
Hi Josh, Thanks for your answer, it made me go trough all the config again, just to make sure that it wasnt pointing to the authoritative server anywhere but in the configuration of the recursive server I saw that "“recursion requested but not available" when i send the query against the authoritative. Kind a expected that, since it aint allowed to do recursion. as requested i made the dig on the the authoritative server i get the correct answer, so i expect it has loaded the zonefiles correctly. ns2:/home/weeltin# dig @127.0.0.01 example.home ; <<>> DiG 9.14.12 <<>> @127.0.0.01 example.home ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45487 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: b9129ece5d9fbc3e6f01a2215f15a461388d4af048be37fa (good) ;; QUESTION SECTION: ;example.home. IN A ;; AUTHORITY SECTION: example.home. 604800 IN SOA ns2.example.home. hostmaster.example.home. 2 604800 86400 2419200 604800 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jul 20 14:04:17 UTC 2020 ;; MSG SIZE rcvd: 120 just to be sure, i rand the dig command again on my client [weeltin@c1 ~]$ dig c1.example.home ; <<>> DiG 9.11.11-RedHat-9.11.11-1.fc31 <<>> c1.example.home ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1787 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 862cc48a975a32a324cd14e65f15ba5e3f2c972d1f753586 (good) ;; QUESTION SECTION: ;c1.example.home. IN A ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020072000 1800 900 604800 86400 ;; Query time: 1043 msec ;; SERVER: 192.168.14.10#53(192.168.14.10) ;; WHEN: Mon Jul 20 11:38:06 EDT 2020 ;; MSG SIZE rcvd: 147 Log output from NS1 (recursive) Jul 20 15:38:05 ns1 daemon.info named[4022]: validating example.home/SOA: got insecure response; parent indicates it should be secure Jul 20 15:38:05 ns1 daemon.info named[4022]: no valid RRSIG resolving 'c1.example.home/DS/IN': 192.168.14.20#53 Jul 20 15:38:06 ns1 daemon.info named[4022]: insecurity proof failed resolving 'c1.example.home/A/IN': 192.168.14.20#53 and there is no log entries on the authoritative server /Weeltin On Sun, Jul 19, 2020 at 6:05 AM Josh Kuo wrote: > When querying your internal domain, I see the query actually ends with > “recursion requested but not available”, it looks like you are querying > directly against your auth server, so I would check the setting to ensure > the zone file is actually loaded correctly. > > What Mark answered is assuming you are querying the recursive which then > returned SERVFAIL due to DNSSEC validation, but I do not see that in the > information you provided. > > Can you run dig on the auth server itself, dig @ 127.0.0.1 for > example.home, and see what it returns? > > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS error, from a newbee to the real experts..
Your problem comes from the fact that BIND 9.14 has DNSSEC validation enabled
by default (unless disabled at configure time or in named.conf) and the answers
from the grafted on namespace (.home) fail DNSSEC validation as there is not a
insecure delegation for .home to break the DNSSEC chain of trust. You can use
validate-except to teach there recursive server to not validate parts of the
namespace but it is NOT RECOMMENDED as it doesn’t help validating clients.
e.g.
validate-except { home; };
I would stop trying to use .home as it has not been delegated for home use.
Use home.arpa instead which has been reserved for home use and has a insecure
delegation to break the DNSSEC chain of trust pointing at servers which only
return NXDOMAIN for names under home.arpa. This is the same delegation model
used for the RFC 1918 reverse zone. Note that DS is absent from the list of
types at the delegation point in the NSEC record. There was an attempt made to
delegate .home this way but it floundered on ICANN/IETF politics.
e.g.
home.arpa. 172800 IN NS blackhole-1.iana.org.
home.arpa. 172800 IN NS blackhole-2.iana.org.
home.arpa. 86400 IN NSECin-addr.arpa. NS RRSIG NSEC
home.arpa. 86400 IN RRSIG NSEC 8 2 86400 2020073112
2020071811 57156 arpa.
lSqLNz1E/6WkAUDAJDnvo9X248B+PAWM34s0S0PJFjPi4YLoE//6zSR6
Dgm0T+2qV2KrgvYbOzHV9Z/lRopFxSEJSSwoHgrUmfofXmIbQiKgQHBi
g9dvL8yeJm0cRe6QMuM1q/D/3+AnPv5OQNBhC6+UEA+enO3JtDbvjr/H
XfPPvfDfozacZkHPe+AYpJbmT7qfHv8Gw/BeeNtDex9jMoDbJ2l0BLT1
UTPKE9+Abrh3RawcKBF3BbLNWU6AhIkOLZRADGMjcZg1M/IHUk/rOWXV
EMZihg1+5I4GSmaRDN0jTX9g5jr822EZfaZLmCKlcGYMMHVOkMUA7k0r +v/Zrg==
If you are using forward zones (not recommended) set “forward only;” as you
don’t want to fallback to querying servers on the global Internet when grafting
on namespace. If you do use a forward zone then the servers being forwarded to
need to either a) serve the *entire* namespace under the forward zone, or b) be
configured as recursive servers.
zone home.arpa {
type forward;
forward only;
forwarders {192.168.14.20;};
};
I would recommend using secondary zone rather than forward zones for grafting
on namespaces, just ensure that the all slave servers are receiving NOTIFY
messages (use also-notify) so that they receive changes fast. Fast propagation
of changes is needed in a home environment. Secondary zone also provide a
break in the DNSSEC chain of trust as far as the recursive server is concerned.
They however do not break the DNSSEC chain of trust for any DNSSEC validating
clients of the recursive server.
zone home.arpa {
type secondary;
primaries {192.168.14.20;};
file “home.arpa.db”;
...
};
zone home.arpa {
type primary;
file “home.arpa.db”;
also-notify { address list; };
...
};
Also forget any garbage that recursive servers should not also serve zones.
People have take the advice that listed authoritative servers shouldn’t be
recursive (which is good advise when serving zones to the public) and inverted
it to come up with bad advice.
Mark
> On 18 Jul 2020, at 05:18, Weeltin wrote:
>
> Hello all,
>
> I’m trying to implement a DNS structure, containing a recursive and
> authoritative server, but in doing so, I have run into a small problem. I can
> make DNS queries from a client toward the net, but when I try to do the same
> toward my internal domain, I get no result. I have spent days trying to
> figure out what is going on, but to no avail, I there for hope that someone
> on this list can point me in the right direction or right out tell what is
> wrong.
>
> /Weeltin.
>
> -DIG troubleshoots
>
> [weeltin@c1 ~]$ cat /etc/resolv.conf
> # Generated by NetworkManager
> nameserver 192.168.14.10
>
> [weeltin@c1 ~]$ dig google.com
> ; <<>> DiG 9.11.11-RedHat-9.11.11-1.fc31 <<>> google.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48932
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: c1bc4a11c40bd755905c8c705f11f5ffe699cc0116ed8ba5 (good)
> ;; QUESTION SECTION:
> ;google.com. IN A
>
> ;; ANSWER SECTION:
> google.com. 300 IN A 216.58.211.142
>
> ;; Query time: 179 msec
> ;; SERVER: 192.168.14.10#53(192.168.14.10)
> ;; WHEN: Fri Jul 17 15:03:27 EDT 2020
> ;; MSG SIZE rcvd: 83
>
>
> [weeltin@c1 ~]$ dig c1.example.home
> ; <<>> DiG 9.11.11-RedHat-9.11.11-1.fc31 <<>> c1.example.home
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62602
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: cf8876e3b35138f47040188e5f11f64a91445aa4f8310f5a (good)
> ;; QUEST
