On Mon, Apr 13, 2020 at 02:35:22PM -0400, Rich Felker wrote:
> > The problem can be partly resolved by setting the "AD" bit in the
> > outgoing DNS query header sent by the musl-libc stub resolver. Then
> > the local iterative resolver will return the AD bit in its response.
> >
> > However, lack of support for retrying truncated responses over TCP
> > or support for disabling RES_DEFNAMES and RES_DNSRCH remain as issues.
>
> musl's stub resolver intentionally speaks only rfc1035 udp,
Lack of TCP support and ignoring the TC bit means that large responses
get truncated, possibly breaking FCrDNS and triggering false positivies
via reject_unknown_client_hostname.
It is also not uncommon for applications that use SRV records to
encounter large RRsets (e.g. Windows Domain controller lists for
large Active-Directory domains in MIT Kerberos or Heimdal).
> and the intent has always been that DNSSEC validation and policy be
> the responsibility of the nameserver running on localhost, not the
> stub resolver or the calling application.
But some applications need to see the AD bit returned by the local
resolver in order to distiguish between validated and non-validated
results. Recursive Nameservers (BIND, Unbound, ...) will only set
(when appropriate) the AD bit in replies if it is set in the incoming
query. The AD bit is part of the standard DNS header:
The basic DNS header flags word is a mixture of flag bits and numbers,
<https://tools.ietf.org/html/rfc2535#section-6.1>:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
and a one-line change in the musl-libc stub resolver can set the AD bit
when the target resolver is local (127.0.0.0/8 or ::1/128).
> The resolver is intentionally stateless.
By stateless you mean no shared global environment, which means no
_res.options. That does not preclude TCP support, EDNS(0) support,
etc., though historically, efficient support of EDNS(0) meant
remembering which upstream nameservers don't support EDNS(0).
Now that pretty all the iterative resolvers you're likely to
encounter as upstream forwarders do support EDNS, you could
just require such a resolver and use EDNS(0) unconditionally,
and use a buffer size larger than 512 for UDP, and support
TCP retries for truncated responses.
> RES_DEFNAMES and RES_DNSRCH are irrelevant as search is never
> performed by the res_* interfaces, and domain/search keywords are used
> only by the high-level ones (getaddrinfo/getnameinfo and the old
> legacy gethostby*).
That's fine then.
> What is relevant, as far as I can tell, is that Postfix wants a way to
> perform an EDNS0 query that lets it distinguish between a valid signed
> result and a valid unsigned result.
No, Postfix just wants the AD bit, but sadly the traditional resolver
API does not have RES_USE_ADBIT, it only has RES_USE_DNSSEC which sets
the DO bit in the EDNS(0) extended header. If (see above) you just
set the AD bit for all requests to local resolvers, Postfix will get
all the DNSSEC support it needs.
> This is currently not possible, but would be practical to add based on
> "options edns0" in resolv.conf.
EDNS(0) is not needed, except to avoid unnecessary TCP failover for
responses between 512 and ~1400 bytes (precise recommended EDNS(0) UDP
buffer size still under discussion in the DNS community, the recent
recommendation of 1232 bytes may be too conservative).
> I'm not sure if or how soon that will happen, but determining that is
> something I'd like to have come out of this discussion.
A one line change can set the AD bit, ideally only when the target
resolver is local (i.e. loopback, which would be an improvement for
Postfix, we normally can't tell whether the AD bit was returned by a
trusted local or untrusted remote resolver).
> From my perspective, what would work best with what's always been the
> intended DNSSEC usage model of musl would be if Postfix supported use
> of DANE with smtp_dns_support_level=enabled, i.e. outsourcing all
> DNSSEC functionality to the nameserver.
Sorry, we actually need to know which records were validated in
signed domains, and which are "insecure" responses from unsigned
domains. That's what the AD bit is for, and you're not setting
it in requests, and so it does not come back in the response.
--
Viktor.
