Hi Viktor,
Sorry, not fully understand your explaination.
It means NS polri.go.id is has error configuration for its DNSec ?
Why bind still can resolv it ?
What can i do to solve it with unbound ?
Thank you.
Regards,
Franky
[ Perhaps dnsviz should detect and report "glueless" delegations
of NS names if that's the issue. See below. ]
Sorry, not fully understand your explaination.
It means NS polri.go.id is has error configuration for its DNSec ?
Why bind still can resolv it ?
The domain has two IPv4 nameservers (ns3/ns4) that don't respond
at all. The remaining two (ns1/ns2) fail to respond for certain
query types like TLSA.
Observe that the domain's nameservers are purportedly (glue records):
$ dig +noall +ans +auth +add +nocl +nottl -t ns polri.go.id @d.dns.id.
polri.go.id. NS ns1.polri.go.id.
polri.go.id. NS ns2.polri.go.id.
polri.go.id. NS ns3.polri.go.id.
polri.go.id. NS ns4.polri.go.id.
ns1.polri.go.id. A 120.29.230.230
ns2.polri.go.id. A 120.29.231.231
ns3.polri.go.id. A 120.29.227.227
ns4.polri.go.id. A 120.29.227.228
Observe however that two of these are unreachable:
$ dig +noall +ans +auth +add +nocl +nottl -t ns polri.go.id @d.dns.id. |
grep -w A |
awk '{print $1,$3}' |
while read n a
do
echo "[$a]"; dig +noall +ans +auth +add +nocl +nottl -t ns polri.go.id @$a
done
[120.29.230.230]
polri.go.id. NS ns2.polri.go.id.
polri.go.id. NS ns1.polri.go.id.
polri.go.id. NS ns4.polri.go.id.
polri.go.id. NS ns3.polri.go.id.
[120.29.231.231]
polri.go.id. NS ns2.polri.go.id.
polri.go.id. NS ns1.polri.go.id.
polri.go.id. NS ns3.polri.go.id.
polri.go.id. NS ns4.polri.go.id.
[120.29.227.227]
;; connection timed out; no servers could be reached
[120.29.227.228]
;; connection timed out; no servers could be reached
Furthermore, we see that very unwisely, the nameservers are themselves
delegated as individual sub-domains of polri.id, with the same list
of auth servers. And yet there are no glue records returned for these
sub-delegations! That may be the source of the problem:
$ dig +noall +ans +auth +add +nocl +nottl -t ns polri.go.id @d.dns.id. |
grep -w A |
awk '{print $1,$3}' |
while read n a
do
echo "=="
dig +norecur +noall +ans +auth +add +nocl +nottl -t ns $n @120.29.230.230 |
sort
done
Hi Viktor,
I don't see bugs in unbound; but perhaps there is not enough information
about what is going on.
The lookup of this domain works for me.
Note that unbound will refuse to lookup on nameservers that are
themselves DNSSEC-bogus. The NS, A, or AAAA for the nameserver is bogus
and then unbound refuses to use that name. With the malformed server,
refusing TLSA, glueless delegations, perhaps those records are bogus (at
some time, for some queries, because the servers act weird).
Best regards, Wouter
Hi Viktor,
What is happening is that the domain has both a signed parent and
unsigned child-zones co-hosted. This confuses unbound's
dnssec-missing-response failover that starts to look for alternatives.
This takes a long time because of the timeouts because of the
non-responding servers. After a while it gets that no better
alternative exists, uses the unsigned response and this is correctly
insecure for DNSSEC. But these timeout could cause issues, I guess.
Best regards, Wouter
What is happening is that the domain has both a signed parent and
unsigned child-zones co-hosted.
Correct, and also missing glue records for the delegation from one
to other, and the child zones happen to be the nameservers for both.
This confuses unbound's
dnssec-missing-response failover that starts to look for alternatives.
This takes a long time because of the timeouts because of the
non-responding servers. After a while it gets that no better
alternative exists, uses the unsigned response and this is correctly
insecure for DNSSEC. But these timeout could cause issues, I guess.
What I see (from time to time) seems more than just transient
timeouts. Anyway the domain has multiple configuration issues
that its owners should resolve.
If this brings to light something worth improving in unbound that'd
be cool too, but so far so I've not identified any specific unbound
problem.
For what it's worth, DNSViz does detect missing glue where it can. But when child and parent zones are hosted on the same server, it is often not possible to tell if there is glue in the parent.
Casey