DNS error, from a newbee to the real experts..
Weeltin
weeltinl at gmail.com
Mon Jul 20 15:20:52 UTC 2020
Hello Mark,
Thanks for your answer, it gave me a lot to think about.
I have been reading about the "validate-except" command, but can't get
myself to use a command that is not recommended.
I did a lot of research, before I went for the .home domain. I didn't want
to end up with a domain that potentially could conflict with a domain on
the internet.
That ment that I had to read a lot of reports, most of them from ICANN, of
them from back in Feb 2018(*), reported that .home (.corp and .mail) would
not be sold and available on the internet.
i didn't know about the insecure delegation to break the DNSSEC, so it
might be worth it to switch to .home.arpa, even though I had hoped to keep
the domain name to 1 tier.
I have been learning that the DNS structure needs to have a recursive and
an authoritative server, to be more exact 2 of each for failover purposes,
if you want a reliable and secure DNS structure. my plan was/is to
configure failover servers when i got this structure to work..
so when i am a little bit confused and when reading that "forward zones"
is not recommended. any links to publications about this?
also, could i get you to explain the last statement in your reply. As I
want to implement a DNS structure that follows best practices and hopefully
is secure, I want to learn about the reasons for this.
(*)
https://www.icann.org/resources/board-material/resolutions-2018-02-04-en#2.c
/Weeltin
On Sun, Jul 19, 2020 at 3:10 AM Mark Andrews <marka at isc.org> wrote:
> 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 NSEC in-addr.arpa. NS RRSIG NSEC
> home.arpa. 86400 IN RRSIG NSEC 8 2 86400
> 20200731120000 20200718110000 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 <weeltinl at gmail.com> 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 at c1 ~]$ cat /etc/resolv.conf
> > # Generated by NetworkManager
> > nameserver 192.168.14.10
> >
> > [weeltin at 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 at 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)
> > ;; QUESTION SECTION:
> > ;c1.example.home. IN A
> >
> > ;; AUTHORITY SECTION:
> > . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com.
> 2020071701 1800 900 604800 86400
> >
> > ;; Query time: 263 msec
> > ;; SERVER: 192.168.14.10#53(192.168.14.10)
> > ;; WHEN: Fri Jul 17 15:04:42 EDT 2020
> > ;; MSG SIZE rcvd: 147
> >
> >
> >
> > [weeltin at c1 ~]$ dig @192.168.14.20 c1.example.home
> >
> > ; <<>> DiG 9.11.11-RedHat-9.11.11-1.fc31 <<>> @192.168.14.20
> c1.example.home
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20704
> > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 747289c94876cf349034aec35f11f794a29c6747bb6a694f (good)
> > ;; QUESTION SECTION:
> > ;c1.example.home. IN A
> >
> > ;; ANSWER SECTION:
> > c1.example.home. 604800 IN A 192.168.14.1
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 192.168.14.20#53(192.168.14.20)
> > ;; WHEN: Fri Jul 17 15:10:12 EDT 2020
> > ;; MSG SIZE rcvd: 88
> >
> >
> >
> >
> >
> > ----- informations and configurations ----
> >
> > OS: Alpine 3.12
> >
> > Bind: bind 9.14.12
> >
> >
> > Ns1: 192.168.14.10 (recursive)
> >
> > Ns2: 192.168.14.20 (authoritative)
> >
> > C1: 192.168.14.1 (client)
> >
> >
> > --- recursive config (NS1)
> >
> > // recursive named.conf
> > //
> >
> > acl trusted {
> >
> > 192.168.14.0/24;
> >
> > localhost;
> >
> > };
> >
> >
> > acl rfc1918 {
> >
> > 10.0.0.0/8;
> >
> > 172.16.0.0/12;
> >
> > !192.168.14.0/24;
> >
> > 192.168.0.0/16;
> >
> > };
> >
> >
> > acl rfc5735 {
> >
> > 0.0.0.0/8;
> >
> > 169.254.0.0/16;
> >
> > 192.0.0.0/24;
> >
> > 192.0.2.0/24;
> >
> > 192.88.99.0/24;
> >
> > 198.18.0.0/15;
> >
> > 198.51.100.0/24;
> >
> > 203.0.113.0/24;
> >
> > 224.0.0.0/4;
> >
> > };
> >
> >
> > options {
> >
> > directory "/var/bind";
> >
> > listen-on {
> > 127.0.0.1;
> >
> > 192.168.14.10;
> >
> > };
> >
> > listen-on-v6 {
> >
> > none;
> >
> > };
> >
> > allow-query {
> >
> > trusted;
> >
> > };
> >
> > //query-source address * port 53;
> >
> > allow-query-cache {
> >
> > trusted;
> >
> > };
> >
> > blackhole {
> >
> > rfc1918;
> >
> > rfc5735;
> >
> > };
> >
> > allow-transfer {
> >
> > none;
> >
> > };
> >
> > pid-file "/var/run/named/named.pid";
> >
> >
> > // Changing this is NOT RECOMMENDED; see the notes above and in
> >
> > // named.conf.recursive.
> >
> > allow-recursion {
> >
> > trusted;
> >
> > };
> >
> > recursion yes;
> >
> > };
> >
> > zone "." IN {
> >
> > type hint;
> >
> > file "root.cache";
> >
> > };
> >
> >
> > zone "localhost" IN {
> >
> > type master;
> >
> > file "pri/localhost.zone";
> >
> > allow-update { none; };
> >
> > notify no;
> >
> > };
> >
> >
> > zone "127.in-addr.arpa" IN {
> >
> > type master;
> >
> > file "pri/127.zone";
> >
> > allow-update { none; };
> >
> > notify no;
> >
> > };
> >
> >
> > zone "example.home" {
> >
> > type forward;
> >
> > forwarders { 192.168.14.20; };
> >
> > };
> >
> >
> >
> > --- authoritative config (NS2)
> > // authoritative named.conf
> > //
> > acl trusted {
> > 192.168.14.0/24;
> > localhost;
> > };
> >
> > acl rfc1918 {
> > 10.0.0.0/8;
> > 172.16.0.0/12;
> > !192.168.14.0/24;
> > 192.168.0.0/16;
> > };
> >
> > acl rfc5735 {
> > 0.0.0.0/8;
> > 169.254.0.0/16;
> > 192.0.0.0/24;
> > 192.0.2.0/24;
> > 192.88.99.0/24;
> > 198.18.0.0/15;
> > 198.51.100.0/24;
> > 203.0.113.0/24;
> > 224.0.0.0/4;
> > };
> >
> > options {
> > directory "/var/bind";
> >
> > // Configure the IPs to listen on here.
> > listen-on {
> > 127.0.0.1;
> > 192.168.14.20;
> > };
> > listen-on-v6 {
> > none;
> > };
> >
> > allow-query {
> > trusted;
> > };
> >
> > //query-source address * port 53;
> >
> > allow-query-cache {
> > trusted;
> > };
> >
> > blackhole {
> > rfc5735;
> > rfc1918;
> > };
> >
> > allow-transfer {
> > none;
> > };
> >
> > // Cryptographic authentication of DNS information
> > // ENABLE LATER
> > //dnssec-enable yes;
> > //dnssec-validation yes;
> >
> > pid-file "/var/run/named/named.pid";
> >
> > // Changing this is NOT RECOMMENDED for a authoritative
> nameserver
> > allow-recursion { none; };
> > recursion no;
> > };
> >
> > zone "example.home" {
> > type master;
> > file "/etc/bind/db.example.home.zone";
> > };
> >
> > zone "14.168.192.in-addr.arpa" {
> > type master;
> > file "/etc/bind/db.14.168.192.zone";
> > };
> >
> >
> >
> > ; ZONE file for example.home.
> > ;
> > $TTL 604800
> > @ IN SOA ns2.example.home. hostmaster.example.home. (
> > 2 ; Serial
> > 604800 ; Refresh 1week
> > 86400 ; Retry
> > 2419200 ; Expire 28days
> > 604800 ; Negative Cache TTL
> > )
> > ;; name servers (NS)
> > ;; only authoritative servers
> > @ IN NS ns2.example.home.
> > ns2 IN A 192.168.14.20
> > ;; hosts (A)
> > ns1 IN A 192.168.14.10
> > c1 IN A 192.168.14.1
> >
> > ;; alias (CNAME)
> > client IN CNAME c1
> >
> >
> >
> > ; ZONE file for 14.168.192.in-addr.arpa.
> > ;
> > $TTL 604800
> > @ IN SOA ns2.example.home. hostmaster.example.home. (
> > 1 ; Serial
> > 604800 ; Refresh 1week
> > 86400 ; Retry
> > 2419200 ; Expire 28days
> > 604800 ; Negative Cache TTL
> > )
> > ;; name servers (NS)
> > ;; only authoritative servers
> > @ IN NS ns2.example.home.
> > 20 IN PTR ns2.example.home.
> > ;; pointer records (PTR)
> > 1 IN PTR c1.example.home.
> > 10 IN PTR ns1.example.home.
> >
> > _______________________________________________
> > 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 at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200720/2e80685c/attachment-0001.htm>
More information about the bind-users
mailing list