polri.go.id DNS issues (was: Not resolving some top level domain)

[Viktor Dukhovni]

On Mon, Feb 27, 2017 at 12:54:11PM +0100, Carsten Strotmann wrote:

> However the domain "polri.go.id" has several errors, see
> 
> <https://zonemaster.net/test/774bd160515887e1>
> and
> <http://dnsviz.net/d/polri.go.id/dnssec/>

It so happens that just yesterday I reported problems with IPv4 DNS
to the owners of polri.go.id:

    $ dig +noall +ans +nocl +nottl -t mx polri.go.id
    polri.go.id.		MX	0 mailprotection1.polri.go.id.
    polri.go.id.		MX	10 mailprotection2.polri.go.id.
    polri.go.id.		MX	20 mailprotection3.polri.go.id.

has DNSSEC-related problems as shown at:

    http://dnsviz.net/d/_25._tcp.mailprotection1.polri.go.id/dnssec/

The same can be verified with command-line DNS lookup utilities such
as "dig":

    $ dig +noall +ans +nocl +nottl -t ns polri.go.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.

Queries to these nameservers for TLSA records fail:

    @ns1.polri.go.id.[120.29.230.230]
    ; <<>> DiG 9.11.0-P3 <<>> +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t tlsa _25._tcp.mailprotection1.polri.go.id @120.29.230.230
    ;; connection timed out; no servers could be reached

    ...

and yet queries for the same name with the record type changed to
"A" correctly return an answer showing that no such name exists:

    @ns1.polri.go.id.[120.29.230.230]
    ; <<>> DiG 9.11.0-P3 <<>> +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit -4 +norecur -t a _25._tcp.mailprotection1.polri.go.id @120.29.230.230
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10894
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;_25._tcp.mailprotection1.polri.go.id. IN A
    polri.go.id.            SOA     ns1.polri.go.id. lifin.polri.go.id. 3592 10800 600 2419200 900
    mailprotection1.polri.go.id. NSEC mailprotection2.polri.go.id. A RRSIG NSEC

    ...

This looks like a misconfigured Arbor Networks firewall, that blocks
various DNS lookups over IPv4 (but not IPv6).  This is bad, since
many resolvers don't yet have IPv6 connectivity.  In addition to
potential impact on email delivery see also:

    https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-06

for why filtering of RRtypes is generally wrong.  Please address
this problem to ensure that email to uspta.org arrives reliably in
a timely manner.

-- 
	Viktor.