Maintained by: NLnet Labs

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

W.C.A. Wijngaards
Thu Mar 2 13:35:41 CET 2017


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

On 02/03/17 12:46, W.C.A. Wijngaards via Unbound-users wrote:
> 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/4f42d36d/attachment.sig>