posttls-finger / DANE failure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Mal
Reply | Threaded
Open this post in threaded view
|

posttls-finger / DANE failure

Mal

Hello

This MTA is a dual stack postfix machine, which also has a dual stack
resolver running.

When testing DANE to a remove IPv4 only MTA, i see an attempt to lookup
a non-existent AAAA record by posttls-finger.  The remote site has only
IPv4 records in the zone, except for the zone NS records, which come
from dual stack revolvers (which are auth).

>
me@mta:/#posttls-finger -v -c -l dane -P/etc/ssl/certs domain1.com.au
posttls-finger: name_mask: dns
posttls-finger: name_mask: routine
posttls-finger: name_mask: certmatch
posttls-finger: name_mask: routine
posttls-finger: name_mask: certmatch
posttls-finger: name_mask: ipv6
posttls-finger: name_mask: ipv4
posttls-finger: inet_addr_local: configured 2 IPv4 addresses
posttls-finger: inet_addr_local: configured 3 IPv6 addresses
posttls-finger: parse_destination: domain1.com.au smtp
posttls-finger: dns_query: domain1.com.au (MX): OK
posttls-finger: dns_get_answer: type MX for domain1.com.au
posttls-finger: dns_get_answer: type RRSIG for domain1.com.au
posttls-finger: addr_one: host mta.domain1.com.au
posttls-finger: lookup mta.domain1.com.au type A flags 8388608
posttls-finger: dns_query: mta.domain1.com.au (A): OK
posttls-finger: dns_get_answer: type A for mta.domain1.com.au
posttls-finger: dns_get_answer: type RRSIG for mta.domain1.com.au
posttls-finger: lookup mta.domain1.com.au type AAAA flags 8388608
posttls-finger: dns_query: mta.domain1.com.au (AAAA): Host found but no
data record of requested type
posttls-finger: no TLSA records found, resorting to "secure"


The (slave) resolver on this box contains the AD records for the remote
domain.  I don't seem to have DANE issues with any other remote DANE
enabled domains.


As a test, when I issue the same query on the actual remote MTA, he
receives the TLSA record successfully and is able to Verify the TLS.

>
me@mta2:/#posttls-finger -v -c -l dane -P/etc/ssl/certs domain1.com.au
posttls-finger: inet_addr_local: configured 2 IPv4 addresses
posttls-finger: parse_destination: domain1.com.au smtp
posttls-finger: dns_query: domain1.com.au (MX): OK
posttls-finger: dns_get_answer: type MX for domain1.com.au
posttls-finger: dns_get_answer: type RRSIG for domain1.com.au
posttls-finger: addr_one: host mta.domain1.com.au
posttls-finger: lookup mta.domain1.com.au type A flags 8388608
posttls-finger: dns_query: mta.domain1.com.au (A): OK
posttls-finger: dns_get_answer: type A for mta.domain1.com.au
posttls-finger: dns_get_answer: type RRSIG for mta.domain1.com.au
posttls-finger: dns_query: _25._tcp.mta.domain1.com.au (TLSA): OK
posttls-finger: dns_get_answer: type TLSA for _25._tcp.mta.domain1.com.au
posttls-finger: dns_get_answer: type RRSIG for _25._tcp.mta.domain1.com.au
posttls-finger: using DANE RR: _25._tcp.mta.domain1.com.au IN TLSA 3 1 1
EC:xxx (blah)


Any thoughts as to why posttls-finger / postfix are seeking a
non-existent AAAA record ?


Mal
Reply | Threaded
Open this post in threaded view
|

Re: posttls-finger / DANE failure

Viktor Dukhovni
On Tue, Oct 17, 2017 at 01:56:39PM +1030, Mal wrote:

> This MTA is a dual stack postfix machine, which also has a dual stack
> resolver running.

Not clear how this is relevant...

> When testing DANE to a remove IPv4 only MTA, I see an attempt to lookup
> a non-existent AAAA record by posttls-finger.

The only way to find out they don't exist is to ask.

> The remote site has only
> IPv4 records in the zone, except for the zone NS records, which come
> from dual stack revolvers (which are auth).

Still not clear how this is relevant.

> me@mta:/#posttls-finger -v -c -l dane -P/etc/ssl/certs domain1.com.au
> [ ... unnecessary verbose output elided ... ]
> posttls-finger: no TLSA records found, resorting to "secure"

No TLSA records were found, perhaps because the "A" records were
reported insecure, or because the TLSA records don't exist.

> The (slave) resolver on this box contains the AD records for the remote
> domain.  I don't seem to have DANE issues with any other remote DANE
> enabled domains.

There's no such thing as "AD records".  And the help you can get
will be rather limited if you must obfuscate the actual target
domain.  Post the (unobfuscated) output of:

    $ domain=domain1.com.au # actual domain here
    $ dig +noall +comment +ans +auth +nocl +nottl -t mx "$domain."
    $ for mx in $(dig +short -t mx $domain | sort -n | awk '{print $2}')
      do
        dig +noall +comment +ans +auth +nocl +nottl -t a "$mx"
        dig +noall +comment +ans +auth +nocl +nottl -t aaaa "$mx"
        dig +noall +comment +ans +auth +nocl +nottl -t tlsa "_25._tcp.$mx"
      done

> As a test, when I issue the same query on the actual remote MTA, he
> receives the TLSA record successfully and is able to Verify the TLS.

Probably the resolver there behaves differently.  Post the
(unobfuscated) output of the above commands when executed there.


> Any thoughts as to why posttls-finger / postfix are seeking a
> non-existent AAAA record ?

Wrong question.

--
        Viktor.
Mal
Reply | Threaded
Open this post in threaded view
|

Re: posttls-finger / DANE failure

Mal


On 17/10/2017 5:11 PM, Viktor Dukhovni wrote:

> The only way to find out they don't exist is to ask.

Very good.

> No TLSA records were found, perhaps because the "A" records were
> reported insecure, or because the TLSA records don't exist.

TLSA record is present.  The sys4 Dane SMTP validator gives me three
green boxes.  It lists the usable TLSA record.

> There's no such thing as "AD records".

Was just a shortcut for 'Authoritative domain record'.  The zone exists
on that resolver and is queried directly.  Will avoid lose english in
future.

> Post the (unobfuscated) output

malz@Woody:~$ domain="signsinc.com.au"
malz@Woody:~$ dig +noall +comment +ans +auth +nocl +nottl -t mx "$domain."
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55931
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
signsinc.com.au.        MX      20 access.signsinc.com.au.

;; AUTHORITY SECTION:
signsinc.com.au.        NS      twiggy.jetlan.com.
signsinc.com.au.        NS      woody.jetlan.com.
signsinc.com.au.        NS      mrt.jetlan.com.

malz@Woody:~$ for mx in $(dig +short -t mx $domain | sort -n | awk
'{print $2}')
> do
>   dig +noall +comment +ans +auth +nocl +nottl -t a "$mx"
>   dig +noall +comment +ans +auth +nocl +nottl -t aaaa "$mx"
>   dig +noall +comment +ans +auth +nocl +nottl -t tlsa "_25._tcp.$mx"
> done
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37823
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
access.signsinc.com.au. A       150.101.252.86

;; AUTHORITY SECTION:
signsinc.com.au.        NS      woody.jetlan.com.
signsinc.com.au.        NS      twiggy.jetlan.com.
signsinc.com.au.        NS      mrt.jetlan.com.

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42772
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; AUTHORITY SECTION:
signsinc.com.au.        SOA     twiggy.jetlan.com.
postmaster.signsinc.com.au. 2017101602 12000 120 1209600 3600

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10350
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
_25._tcp.access.signsinc.com.au. TLSA 3 1 1
EC3FED1F09D91F899A4FA41D35A2A052CD79CBDCA1F8C7A4D72FED10 61CDB9B6

;; AUTHORITY SECTION:
signsinc.com.au.        NS      twiggy.jetlan.com.
signsinc.com.au.        NS      mrt.jetlan.com.
signsinc.com.au.        NS      woody.jetlan.com.



Reply | Threaded
Open this post in threaded view
|

Re: posttls-finger / DANE failure

Viktor Dukhovni

> On Oct 17, 2017, at 3:58 AM, Mal <[hidden email]> wrote:
>
>> There's no such thing as "AD records".
>
> Was just a shortcut for 'Authoritative domain record'.

I've never seen that phrase before.

> The zone exists on that resolver and is queried directly.
> Will avoid lo[o]se english in future.

So it seems that the machine in question has the authoritative
server for the zone as its recursive server.  Such mixing of
authoritative and recursive workloads is discouraged these days,
and critically, it breaks DANE in Postfix for any authoritative
zones, because authoritative servers are not validating resolvers,
and don't set the AD bit in authoritative replies.  As seen below:

>> Post the (unobfuscated) output
>
> malz@Woody:~$ domain="signsinc.com.au"
> malz@Woody:~$ dig +noall +comment +ans +auth +nocl +nottl -t mx "$domain."
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55931
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8

No "ad" bit in the "flags:" field.

> signsinc.com.au.        MX      20 access.signsinc.com.au.

So the MX record is not seen as "secure" by Postfix.

> malz@Woody:~$ for mx in $(dig +short -t mx $domain | sort -n | awk
> '{print $2}')
>> do
>>  dig +noall +comment +ans +auth +nocl +nottl -t a "$mx"
>>  dig +noall +comment +ans +auth +nocl +nottl -t aaaa "$mx"
>>  dig +noall +comment +ans +auth +nocl +nottl -t tlsa "_25._tcp.$mx"
>> done
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37823
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7

No "ad" bit here either.

> access.signsinc.com.au. A       150.101.252.86

The A record is not seen as "secure" by Postfix.

On my server the authoritative BIND nameserver listens on the
external public IP address, while the validating unbound resolver
listens on 127.0.0.1 and the internal network interface.  The
"/etc/resolv.conf" file lists 127.0.0.1, so DNS queries from
applications go to unbound, not BIND.  The "unbound" server
is configured to do DNSSEC validation, and queries BIND setting
the "ad" bit as/when appropriate.

The BIND server refuses recursion, while the unbound server
serves no authoritative zones.

--
        Viktor.
Mal
Reply | Threaded
Open this post in threaded view
|

Re: posttls-finger / DANE failure

Mal


On 17/10/2017 7:14 PM, Viktor Dukhovni wrote:

> So it seems that the machine in question has the authoritative
> server for the zone as its recursive server.  Such mixing of
> authoritative and recursive workloads is discouraged these days,
> and critically, it breaks DANE in Postfix for any authoritative
> zones, because authoritative servers are not validating resolvers,
> and don't set the AD bit in authoritative replies.

Bingo.  That information certainly explains the behavior observed.

Does this therefore require DNSSEC-validation to be set to "no" (for the
authoritative NS):
   dnssec-enable yes;
   dnssec-validation no;
   dnssec-lookaside auto;


> The A record is not seen as "secure" by Postfix.

Got it.

> On my server the authoritative BIND nameserver listens on the
> external public IP address, while the validating unbound resolver
> listens on 127.0.0.1 and the internal network interface.  The
> "/etc/resolv.conf" file lists 127.0.0.1, so DNS queries from
> applications go to unbound, not BIND.  The "unbound" server
> is configured to do DNSSEC validation, and queries BIND setting
> the "ad" bit as/when appropriate.
>
> The BIND server refuses recursion, while the unbound server
> serves no authoritative zones.


Mal


Reply | Threaded
Open this post in threaded view
|

Re: posttls-finger / DANE failure

/dev/rob0
On Tue, Oct 17, 2017 at 08:28:02PM +1030, Mal wrote:

> On 17/10/2017 7:14 PM, Viktor Dukhovni wrote:
>
> > So it seems that the machine in question has the authoritative
> > server for the zone as its recursive server.  Such mixing of
> > authoritative and recursive workloads is discouraged these days,
> > and critically, it breaks DANE in Postfix for any authoritative
> > zones, because authoritative servers are not validating
> > resolvers, and don't set the AD bit in authoritative replies.
>
> Bingo.  That information certainly explains the behavior observed.
>
> Does this therefore require DNSSEC-validation to be set to "no"
> (for the authoritative NS):
>    dnssec-enable yes;
>    dnssec-validation no;
>    dnssec-lookaside auto;

Um, validation is exclusively done on NON-authoritative lookup
results.  I'm not sure what you are thinking.  In order:

1. dnssec-enable no; would prevent your BIND server from serving
required records from a signed zone.  It would prevent ANYONE from
being able to validate your signed zone.  This is surely not what
you're seeking?

2. dnssec-validation no; again, this has no effect when you're
serving authoritative data from a master or slave zone.

3. dnssec-lookaside has been removed!  Disable it now, on any
nameservers you control.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Mal
Reply | Threaded
Open this post in threaded view
|

Re: posttls-finger / DANE failure

Mal


On 18/10/2017 1:17 AM, /dev/rob0 wrote:

> Um, validation is exclusively done on NON-authoritative lookup
> results.  I'm not sure what you are thinking.  In order:

This was pointed out previously.

> 1. dnssec-enable no; would prevent your BIND server from serving
> required records from a signed zone.  It would prevent ANYONE from
> being able to validate your signed zone.  This is surely not what
> you're seeking?
Don't recall anyone suggesting this.

> 2. dnssec-validation no; again, this has no effect when you're
> serving authoritative data from a master or slave zone.

This was my question to Viktor, "dnssec-validation no", based upon his
previous post.  I shall remove it.

Mal
Reply | Threaded
Open this post in threaded view
|

Re: posttls-finger / DANE failure

Viktor Dukhovni
In reply to this post by Mal


> On Oct 17, 2017, at 5:58 AM, Mal <[hidden email]> wrote:
>
> Bingo.  That information certainly explains the behavior observed.
>
> Does this therefore require DNSSEC-validation to be set to "no" (for the
> authoritative NS):
>   dnssec-enable yes;

This must stay "yes" or else you DoS your domain.

>   dnssec-validation no;

This is ignored for authoritative zones, and useful for recursive
servers.  So long as your server continues to provide both authoritative
and recursive service (not a good idea), you should leave this in place.

The right thing to do is to deploy a separate validating recursive server,
use that in resolv.conf and then disable recursion in the authoritative
server, at which point this setting makes no difference.

>   dnssec-lookaside auto;

This is obsolete, the ISC DLV zone is now empty, so this should be set
to "no" in all recursive BIND servers.

--
        Viktor.

Mal
Reply | Threaded
Open this post in threaded view
|

Re: posttls-finger / DANE failure

Mal

On 18/10/2017 3:56 PM, Viktor Dukhovni wrote:

>>   dnssec-validation no;
>
> This is ignored for authoritative zones, and useful for recursive
> servers.  So long as your server continues to provide both authoritative
> and recursive service (not a good idea), you should leave this in place.
>
> The right thing to do is to deploy a separate validating recursive server,
> use that in resolv.conf and then disable recursion in the authoritative
> server, at which point this setting makes no difference.

Right thing done, set to 'no' and resolver work sent elsewhere.  Dane
record returning perfectly now, on posttls-finger, for that domain.


>>   dnssec-lookaside auto;
>
> This is obsolete, the ISC DLV zone is now empty, so this should be set
> to "no" in all recursive BIND servers.
>

I deleted this guy.

Thanks Viktor.

Mal