On Mon, Sep 21, 2015 at 02:23:15PM +0200, Giovane C. M. Moura wrote:
> > I'd be curious to know what you're seeing for the dominant "_<port>"
> >> number in the observed TLSA queries, and whether any particular
> >> resolvers are responsible for the bulk of the "_25" queries.
>
> Now I see you meant something else, the port number listed in the
> qname: E.g: the "25" part in _25._tcp.mail.example2.nl.
Yes, and I am specifically interested in whether for those qnames,
a particuler set of client resolvers account for the bulk of the
queries seen by the .nl nameservers. The theory is that such
queries might more likely originate from testing tools than real
DANE MTAs, because the latter would first resolve the A/AAAA records
of the SMTP server, and only then check for TLSA, in which case
the query should typically go the authoritative server rather than
.nl.
> select regexp_extract(qname, "^(_[0-9]*)\.",0) as label, count(1) as
> total from dns.queries where qtype=52 and year='2015' group by label
> order by total desc;
>
> Port,TotalQueries
> 25,93592
> 443,36536
> ...
Thanks, most of the queries being SMTP makes sense. The question
is then whether drilling down into just the port 25 queries, you
see any interesting distribution of client IPs (if available in
your dataset).
Ways in which TLSA lookups from "real" MTAs might hit "cold"
caches and make it to .nl are:
* MTA's local resolver is configured with multiple forwarders,
and the A/AAAA queries were forwarded to a different forwarder
than the TLSA query.
* Postfix or Exim MTA misconfigured to directly use multiple remote
iterative resolvers (remote hosts in /etc/resolv.conf).
* Queries to multiple remote iterators from some MTA other than
Postfix or Exim that does validation in the application rather
than relying on AD-bit from resolver.
* Some MTA other than Postfix or Exim that either does not determine
the security status of the address records before TLSA lookups, or
does both "in parallel".
I am not aware of any MTAs other than Postfix and Exim that implement
client-side DANE, but perhaps they exist.
--
Viktor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
