DANE plus wildcard record

[Viktor Dukhovni]

On Sat, Jun 15, 2019 at 12:11:29PM -0500, Rob McGee wrote:

> One of my subscribers recently signed his or her zone, and sadly, has a
> wildcard A in that zone.

Wildcard A records are not in themselves a problem for DANE, lots
of domains have them with no issues.  What can be a problem is
having a nameserver that omits the wildcard name from the NSEC/NSEC3
chain, and therefore returns "bogus" denial of existence when asked
for the TLSA records. Consider a zone containing only the zone apex
(with SOA, DNSKEY, NS, MX records and associated RRSIGs) and a
signed wildcard A record (with RRSIG):

	; Zone apex NS/SOA/DNSKEY/... elided
	example.com. IN MX 0 smtp.example.com.
	example.com. IN A 192.0.2.1

	; Wildcard A record only other node in the zone
	*.example.com. IN A 192.0.2.1

Its NSEC chain *should* be:

	example.com. IN NSEC *.example.com. A NS SOA MX RRSIG NSEC DNSKEY
	*.example.com. IN NSEC example.com. A RRSIG NSEC

The address of the MX host "smtp.example.com" is wildcard-synthesised,
and the correct response for the TLSA query would be:

	$ dig +norecur +dnssec -t tlsa _25.tcp.smtp.example.com. @ns1.example.com.

	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
	;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
	; _25._tcp.smtp.example.com IN TLSA ?

	;; OPT PSEUDOSECTION:
	; ...
	;; QUESTION SECTION:
	;_25._tcp.smtp.example.com. IN TLSA

	example.com. IN SOA ...
	example.com. IN RRSIG SOA ...
	example.com. IN NSEC example.com. A NS SOA MX RRSIG NSEC DNSKEY
	example.com. IN RRSIG NSEC ...

The NOERROR rather than NXDOMAIN is due to the wildcard, but since
it only has A records, and no TLSA records, the answer count is
zero.  The authority records provide the authenticated denial of
existence proof.  The signed NSEC record establishes the existence
of the wildcard, and non-existence of "smtp.example.com" as an
explicit name in the zone.

Now, consider what happens if the nameserver software or zone data
is broken and omits the wildcard from NSEC chain, which now contains
only the zone apex (This is a circular reference in otherwise empty
zones):

	$ dig +norecur +dnssec -t tlsa _25.tcp.smtp.example.com. @ns1.example.com.

	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
	;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
	; _25._tcp.smtp.example.com IN TLSA ?

	;; OPT PSEUDOSECTION:
	; ...
	;; QUESTION SECTION:
	;_25._tcp.smtp.example.com. IN TLSA

	example.com. IN SOA ...
	example.com. IN RRSIG SOA ...
	example.com. IN NSEC example.com. A RRSIG NSEC
	example.com. IN RRSIG NSEC ...

We now have a contradiction. The header says "NOERROR", implying
the name exists or is wildcard-synthesised, but the NSEC chain
proves that only the zone apex exists, so a consistent answer would
be NXDOMAIN.  In this situation (and others similar in spirit if
not every detail), the validating resolver returns "SERVFAIL".

This problem is somewhat more frequent with PowerDNS servers backed
by a database, when the SQL database with the zone data is incorrectly
populated, or the software is substantially outdated.

> The checker reports "DNS lookup error for TLSA records: SERVFAIL",
> which is what I get on the named recursive resolver that Postfix is
> using, querying "_25._tcp.smtp.example.com./IN/TLSA".
> 
> So Postfix is refusing to deliver, believing that there should be a
> TLSA.  But AFAIK this user never published TLSA.

Yes, but that fact has to have a valid denial of existence proof,
or else absence of TLSA records could be trivially spoofed, introducing
MiTM attacks that DNSSEC is designed to prevent.

> The SOA MNAME host has disabled version.bind./CH/TXT lookups so I am
> not sure what software is in use, but having A for an invalid hostname
> (underscores not allowed in hostnames) would be a problem for BIND
> named, which by default would not allow that.

The "_" is allowed in TLSA records, this is not relevant here.

> But I don't know how that feature interacts with wildcard records.

Wildcard A records work as one would expect.  Indeed you should be
able to resolve "_25._tcp.smtp.example.com IN A ?" and get the
wildcard address.

> Testing on a dnsmasq from home I don't get SERVFAIL, just NOERROR.

That's because dnsmasq is not doing DNSSEC validation.

On Sat, Jun 15, 2019 at 01:48:27PM -0500, Rob McGee wrote:

> The immediate problem has been solved with a bandaid,
> smtp_tls_policy_maps, with an entry:
> 
> example.com    may

Or, alternatively, in e.g. unbound:

	server:
		domain-insecure: "example.com."

> I still think this is an interesting problem, perhaps a BIND problem.

No, the issue is broken DNS for example.com.

On Sat, Jun 15, 2019 at 02:41:15PM -0500, Rob McGee wrote:

> Logs (from named) of the SERVFAIL:
> 
> 15-Jun-2019 18:49:00.567 lame-servers: info: broken trust chain 
> resolving '_25._tcp.smtp.example.com/TLSA/IN': 176.56.237.121#53

Finally, a data leak! :-)  That IP address, 176.56.237.121, is
dynu.com.  They have multiple domains that have broken DoE (Denial
of Existence), e.g.

    jerryscomputing.com SOA ns1.dynu.com administrator at dynu.com

When I ask the domain's nameservers for TLSA records, they all just
return empty NOERROR replies (EDNS OPT record only, no SOA, no
RRSIG, ...):

    @ns1.dynu.com.[207.38.70.2]
    @ns2.dynu.com.[104.247.193.125]
    @ns3.dynu.com.[45.79.219.7]
    @ns4.dynu.com.[45.119.209.45]
    @ns5.dynu.com.[74.121.191.194]
    @ns6.dynu.com.[168.235.71.124]
    ; <<>> DiG 9.14.2 <<>> +noidnout +nosearch +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t tlsa _25._tcp.jerryscomputing.com @...
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31304
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    ;_25._tcp.jerryscomputing.com. IN TLSA

While asking for an A record for the same name returns:

    @ns1.dynu.com.[207.38.70.2]
    @ns2.dynu.com.[104.247.193.125]
    @ns3.dynu.com.[45.79.219.7]
    @ns4.dynu.com.[45.119.209.45]
    @ns5.dynu.com.[74.121.191.194]
    @ns6.dynu.com.[168.235.71.124]
    ; <<>> DiG 9.14.2 <<>> +noidnout +nosearch +dnssec +noall +cmd +comment +qu +ans +auth +nocl +nottl +nosplit +norecur -t a _25._tcp.jerryscomputing.com @...
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63350
    ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ;_25._tcp.jerryscomputing.com. IN A
    _25._tcp.jerryscomputing.com. RRSIG A 13 4 90 20190617213727 20190613213727 5126 jerryscomputing.com.
    _25._tcp.jerryscomputing.com. A 3.13.189.185

which appears to be signed "on the fly" (ECDSA P-256, algorithm 13,
is fast enough to make that practical) rather than wildcard-synthesised,
because the RRSIG label count is 4 and no NSEC records were sent
to justify the use of a wildcard.  So this server lies about wildcards
and returns synethetic records on the fly, avoiding NSEC as much
as possible, but does not know how to handle non-existent RR types.

This is a case of all-too-clever broken software, that fails to
correctly implement DNSSEC denial of existence.  Your subscriber
needs to find a more competent DNS provider.

-- 
	Viktor.