[polri.go.id DNS issues, glueless delegation, confusing NSEC???]
Viktor Dukhovni
ietf-dane at dukhovni.org
Tue Feb 28 17:51:25 UTC 2017
[ Perhaps dnsviz should detect and report "glueless" delegations
of NS names if that's the issue. See below. ]
On Tue, Feb 28, 2017 at 10:33:18AM +0700, battossai wrote:
> 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
==
ns1.polri.go.id. NS ns1.polri.go.id.
ns1.polri.go.id. NS ns2.polri.go.id.
ns1.polri.go.id. NS ns3.polri.go.id.
ns1.polri.go.id. NS ns4.polri.go.id.
==
ns2.polri.go.id. NS ns1.polri.go.id.
ns2.polri.go.id. NS ns2.polri.go.id.
ns2.polri.go.id. NS ns3.polri.go.id.
ns2.polri.go.id. NS ns4.polri.go.id.
==
ns3.polri.go.id. NS ns1.polri.go.id.
ns3.polri.go.id. NS ns2.polri.go.id.
ns3.polri.go.id. NS ns3.polri.go.id.
ns3.polri.go.id. NS ns4.polri.go.id.
==
ns4.polri.go.id. NS ns1.polri.go.id.
ns4.polri.go.id. NS ns2.polri.go.id.
ns4.polri.go.id. NS ns3.polri.go.id.
ns4.polri.go.id. NS ns4.polri.go.id.
Further, probing for secure delegations (DS records) we see:
$ dig +norecur +noall +comment +ans +auth +add +nocl +nottl +dnssec +nosplit -t ds ns1.polri.go.id @120.29.230.230 |
pcregrep -v '\.\s+RRSIG'
;; Truncated, retrying in TCP mode.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29846
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; AUTHORITY SECTION:
polri.go.id. SOA ns1.polri.go.id. lifin.polri.go.id. 3720 10800 600 2419200 900
ns1.polri.go.id. NSEC ns2.polri.go.id. NS RRSIG NSEC
that the NSEC records that deny the "DS" records also deny the
existence of "A" or "AAAA" records. Since the response is from an
authoritative server, perhaps unbound concludes that the zone has
no such records (which could be a bug, but this is doubly speculative).
This is an interesting case of course, because the "DS" record is
logically from the parent zone of that same server, while the A
records would be from the insecure delegated zone:
$ dig +norecur +noall +comment +ans +auth +add +nocl +nottl +dnssec +nosplit -t a ns1.polri.go.id @120.29.230.230
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29776
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; ANSWER SECTION:
ns1.polri.go.id. A 120.29.230.230
So in addition to filtering TLSA records, the zone administrators
have rather inadvisedly chosen to split off each nameserver into
a separate child zone, served by the same set of authoritative
servers.
If the problem is not the glueless delegation, I am not sure whether
the server or unbound is then out of spec in generating/processing
the resulting DS query NSEC records, or there is some other issue
(lack of glue in the server's NS response), but the simplest solution
is for the domain owners to NOT delegate the nameservers into
individual sub-zones. And of course there should not be firewalls
blocking queries for TLSA or any other RR types.
http://dnsviz.net/d/_25._tcp.mailprotection1.polri.go.id/dnssec/
--
Viktor.
More information about the Unbound-users
mailing list