[polri.go.id DNS issues, glueless delegation, confusing NSEC???]
W.C.A. Wijngaards
wouter at nlnetlabs.nl
Thu Mar 2 12:35:41 UTC 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: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20170302/4f42d36d/attachment.bin>
More information about the Unbound-users
mailing list