Maintained by: NLnet Labs

[polri.go.id DNS issues, glueless delegation, confusing NSEC???]

W.C.A. Wijngaards
Thu Mar 2 12:46:19 CET 2017


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

On 28/02/17 18:51, Viktor Dukhovni via Unbound-users wrote:
> [ 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/
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20170302/66357a6d/attachment.sig>