Pick the transport based on the destination host, not domain?

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

Pick the transport based on the destination host, not domain?

Darren Pilgrim
I've run into a problem with a hosting service's IPv6 connectivity.
Their IPv6 broken such that they get odd transient failures.  Normally
not a problem, but their anti-spam appliance or whatever they're using
in front of their mail servers hard-bounces on those failures instead of
following the established-since-forever practice of soft-bouncing on
such issues.

Originally I had only one domain using this hoster, so for that one
domain I simply added a transport map that points the domain at the an
extra smtp transport that has -o inet_protocols=ipv4.

But now I have a second such doamin, and I'd like to head-off a
maintenance problem.  All such domains use the same set of MXes, so it's
an obvious pattern to switch transports if the next hop is one of the
offending MXes.

Can Postfix even do this?  A read through the relevant docs indicates
those transport lookups are based solely on recipient domain.

If it can't, is there something out there that can do this using the
socketmap interface?  If not, I'll write one.
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

A. Schulze

Darren Pilgrim:

> But now I have a second such doamin, and I'd like to head-off a  
> maintenance problem.  All such domains use the same set of MXes, so  
> it's an obvious pattern to switch transports if the next hop is one  
> of the offending MXes.

if ipv4 is still working you could
- modify your local dns resolver to strip the AAAA part in it's answer  
for the hosts in question
- modify your local firewall to *reject* outbound connections to the  
IPv6 address in question
both are not perfect any may have unwanted side effects.

Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Darren Pilgrim
On 11/22/2014 1:12 PM, A. Schulze wrote:

> Darren Pilgrim:
>
>> But now I have a second such doamin, and I'd like to head-off a
>> maintenance problem.  All such domains use the same set of MXes, so
>> it's an obvious pattern to switch transports if the next hop is one
>> of the offending MXes.
>
> if ipv4 is still working you could
> - modify your local dns resolver to strip the AAAA part in it's answer
> for the hosts in question

I thought about that, but the domains in question use DNSSEC and I
generally try not to break other people's protective measures. :)

> - modify your local firewall to *reject* outbound connections to the
> IPv6 address in question
> both are not perfect any may have unwanted side effects.

Considered this as well, but I'm trying to get away from maintaining a
static list of non-static things.  Maintaining a host pattern still has
that problem, but it at least gets me some automation if they renumber
or rename their MXes, which I've seen them do.
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Wietse Venema
Darren Pilgrim:

> > if ipv4 is still working you could
> > - modify your local dns resolver to strip the AAAA part in it's answer
> > for the hosts in question
>
> I thought about that, but the domains in question use DNSSEC and I
> generally try not to break other people's protective measures. :)
>
> > - modify your local firewall to *reject* outbound connections to the
> > IPv6 address in question
> > both are not perfect any may have unwanted side effects.
>
> Considered this as well, but I'm trying to get away from maintaining a
> static list of non-static things.  Maintaining a host pattern still has
> that problem, but it at least gets me some automation if they renumber
> or rename their MXes, which I've seen them do.

It could be kludged together with a transport map based on tcp_table
or socketmap, plus some clever scripting to generate the right
transport map responses.

Otherwise this requires new Postfix code. Giving this a few minutes
of thought I came up with two designs.

My simplest design is a new configurable DNS reply filter that can
be used to ignore Google AAAA records (but it can also be used to
ignore other results).

/etc/postfix/main.cf:
    smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter

/etc/postfix/smtp_dns_reply_filter:
    # aspmx.l.google.com. 300 IN AAAA 2607:f8b0:400d:c03::1b
    /^\S+\.google\.com\s+\S+\s+\S+\s+aaaa/ ignore

This would go into the Postfix DNS library, where it can be used
to filter queries by all Postfix programs, and provide a new kind
of rope that people can shoot themselves into the feet with.

Downside of this is that it can filter only on things that Postfix
asks for. For example, it cannot be used to filter on Google's NS
records because the Postfix SMTP client does not ask for those.

My not-so-simple design involves a new DNS-based lookup table and
a configurable SMTP client policy table.

/etc/postfix/main.cf:
    smtp_policy_maps = pipemap:{dns:mx, pcre:/etc/postfix/dnsmx.pcre}

/etc/postfix/dnsmx.pcre:
    /\.google\.com$/ inet_protocols=ipv4

Query the DNS for MX records for the next-hop domain (usually the
recipient domain). Feed the results one line at a time into the
PCRE table.  Disable IPv6 if at least one MX host is a Google host.
This PCRE map should probably not support $number expansions.

This feature makes its own DNS lookups, so it can make queries
that the Postfix SMTP client would not make, such as NS records.

For now, I think that the DNS reply filter is sufficient. It is
a lot simpler.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Darren Pilgrim
On 11/22/2014 5:10 PM, Wietse Venema wrote:

> Darren Pilgrim:
>>> if ipv4 is still working you could
>>> - modify your local dns resolver to strip the AAAA part in it's answer
>>> for the hosts in question
>>
>> I thought about that, but the domains in question use DNSSEC and I
>> generally try not to break other people's protective measures. :)
>>
>>> - modify your local firewall to *reject* outbound connections to the
>>> IPv6 address in question
>>> both are not perfect any may have unwanted side effects.
>>
>> Considered this as well, but I'm trying to get away from maintaining a
>> static list of non-static things.  Maintaining a host pattern still has
>> that problem, but it at least gets me some automation if they renumber
>> or rename their MXes, which I've seen them do.
>
> It could be kludged together with a transport map based on tcp_table
> or socketmap, plus some clever scripting to generate the right
> transport map responses.
>
> Otherwise this requires new Postfix code. Giving this a few minutes
> of thought I came up with two designs.
>
> My simplest design is a new configurable DNS reply filter that can
> be used to ignore Google AAAA records (but it can also be used to
> ignore other results).
>
> /etc/postfix/main.cf:
>      smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter
>
> /etc/postfix/smtp_dns_reply_filter:
>      # aspmx.l.google.com. 300 IN AAAA 2607:f8b0:400d:c03::1b
>      /^\S+\.google\.com\s+\S+\s+\S+\s+aaaa/ ignore
>
> This would go into the Postfix DNS library, where it can be used
> to filter queries by all Postfix programs, and provide a new kind
> of rope that people can shoot themselves into the feet with.
 >
 > Downside of this is that it can filter only on things that Postfix
 > asks for. For example, it cannot be used to filter on Google's NS
 > records because the Postfix SMTP client does not ask for those.

I think this would fit the need.  Pushing this down to the application
avoids the DNSSEC invalidation issue with filtering DNS responses.

Let's say the first next hop is an IPv4-only host, but later MXes have
IPv6.  Will filtering out A records result in Postfix logging a "host
not found" error and safely moving to the next MX?  If so, should the
dns reply filter also log discarded RRs?

Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Viktor Dukhovni
In reply to this post by Wietse Venema
On Sat, Nov 22, 2014 at 08:10:38PM -0500, Wietse Venema wrote:

> Otherwise this requires new Postfix code. Giving this a few minutes
> of thought I came up with two designs.
>
> My simplest design is a new configurable DNS reply filter that can
> be used to ignore Google AAAA records (but it can also be used to
> ignore other results).
>
> /etc/postfix/main.cf:
>     smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter
>
> [...]
>
> My not-so-simple design involves a new DNS-based lookup table and
> a configurable SMTP client policy table.
>
> /etc/postfix/main.cf:
>     smtp_policy_maps = pipemap:{dns:mx, pcre:/etc/postfix/dnsmx.pcre}
>
> /etc/postfix/dnsmx.pcre:
>     /\.google\.com$/ inet_protocols=ipv4
I have a third design (and implementation).

  /etc/postfix/main.cf:
    inet_protocols = any
    smtp_inet_protocol_host_maps = texthash:${config_directory}/inet_protocols

  /etc/postfix/inet_protocols:
    .google.com ipv4

The attached patch is missing only the internal developer documentation
for the new inet_proto_lookup() function.  It applies to Postfix
2.12 snapshots.  [ It conflicts with the IDNA for TLS patch I sent
off-list to Wietse in that a new header file #include is added to
src/smtp/smtp_addr.c in the same place by both patches. ]

--
        Viktor.

0001-smtp_inet_protocol_host_maps.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Peter Ajamian
In reply to this post by Wietse Venema
On 11/23/2014 02:10 PM, Wietse Venema wrote:
> It could be kludged together with a transport map based on tcp_table
> or socketmap, plus some clever scripting to generate the right
> transport map responses.

I think a more elegant solution that should work would be to create a
policy daemon that would be coded to look up MX records for the
recipient domain and return a result based on a table match (could stub
postmap -q for the table lookups).  This could be made as a simple
add-on to postfix that doesn't require any patching or new code to
implement so it would work on older versions of postfix as well as new.


Peter
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Viktor Dukhovni
In reply to this post by Viktor Dukhovni
On Sun, Nov 23, 2014 at 05:43:44AM +0000, Viktor Dukhovni wrote:

> It applies to Postfix
> 2.12 snapshots.  [ It conflicts with the IDNA for TLS patch I sent
> off-list to Wietse in that a new header file #include is added to
> src/smtp/smtp_addr.c in the same place by both patches. ]

Oops that conflict was imaginary, I added midna.h to tls_client.c
not smtp_addr.c.  So I edited the patch in error.  Corrected
patch attached.  This applies to 2.12-20141119 with or without
the off-list IDNA enhancements for TLS.

--
        Viktor.

0001-smtp_inet_protocol_host_maps.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Wietse Venema
Viktor Dukhovni:

> On Sun, Nov 23, 2014 at 05:43:44AM +0000, Viktor Dukhovni wrote:
>
> > It applies to Postfix
> > 2.12 snapshots.  [ It conflicts with the IDNA for TLS patch I sent
> > off-list to Wietse in that a new header file #include is added to
> > src/smtp/smtp_addr.c in the same place by both patches. ]
>
> Oops that conflict was imaginary, I added midna.h to tls_client.c
> not smtp_addr.c.  So I edited the patch in error.  Corrected
> patch attached.  This applies to 2.12-20141119 with or without
> the off-list IDNA enhancements for TLS.

I have a preference for the design that addresses the problem at a
lower level in the stack, so that the solution is not limited to
the SMTP client and not limited to inet protocol selection.

That code can then also be used to address other forms of trouble
that manifest themselves via DNS (for example the next time someone
changes the meaning of some corner case, like nullmx).

I have a draft implementation that is being tested.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Darren Pilgrim
In reply to this post by Peter Ajamian
On 11/23/2014 1:46 AM, Peter wrote:

> On 11/23/2014 02:10 PM, Wietse Venema wrote:
>> It could be kludged together with a transport map based on tcp_table
>> or socketmap, plus some clever scripting to generate the right
>> transport map responses.
>
> I think a more elegant solution that should work would be to create a
> policy daemon that would be coded to look up MX records for the
> recipient domain and return a result based on a table match (could stub
> postmap -q for the table lookups).  This could be made as a simple
> add-on to postfix that doesn't require any patching or new code to
> implement so it would work on older versions of postfix as well as new.

You can't use policy services with the smtp client, only the smtp server.

Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Peter Ajamian
On 11/24/2014 02:25 PM, Darren Pilgrim wrote:
> You can't use policy services with the smtp client, only the smtp server.

Weitse's proposal to use tcp tables is probably a better approach
anyways, but you can use a policy daemon and route from smtpd.  The
point is you're routing *from* smtpd to a specific smtp transport.


Peter
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Darren Pilgrim
On 11/23/2014 8:42 PM, Peter wrote:
> On 11/24/2014 02:25 PM, Darren Pilgrim wrote:
>> You can't use policy services with the smtp client, only the smtp server.
>
> Weitse's proposal to use tcp tables is probably a better approach
> anyways, but you can use a policy daemon and route from smtpd.  The
> point is you're routing *from* smtpd to a specific smtp transport.

Nexthop transport isn't determined until after smtpd hands off the
message to cleanup.
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Wietse Venema
Darren Pilgrim:

> On 11/23/2014 8:42 PM, Peter wrote:
> > On 11/24/2014 02:25 PM, Darren Pilgrim wrote:
> >> You can't use policy services with the smtp client, only the smtp server.
> >
> > Weitse's proposal to use tcp tables is probably a better approach
> > anyways, but you can use a policy daemon and route from smtpd.  The
> > point is you're routing *from* smtpd to a specific smtp transport.
>
> Nexthop transport isn't determined until after smtpd hands off the
> message to cleanup.

Under very limited conditions, an SMTPD access table or policy
server can specify a filter action like this:

    FILTER ipv4-only-transport:

This will send mail over the ipv4-only-transport to the SMTP
destination host.

        Wietse

Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Darren Pilgrim
On 11/24/2014 8:03 AM, Wietse Venema wrote:

> Darren Pilgrim:
>> On 11/23/2014 8:42 PM, Peter wrote:
>>> On 11/24/2014 02:25 PM, Darren Pilgrim wrote:
>>>> You can't use policy services with the smtp client, only the smtp server.
>>>
>>> Weitse's proposal to use tcp tables is probably a better approach
>>> anyways, but you can use a policy daemon and route from smtpd.  The
>>> point is you're routing *from* smtpd to a specific smtp transport.
>>
>> Nexthop transport isn't determined until after smtpd hands off the
>> message to cleanup.
>
> Under very limited conditions, an SMTPD access table or policy
> server can specify a filter action like this:
>
>      FILTER ipv4-only-transport:
>
> This will send mail over the ipv4-only-transport to the SMTP
> destination host.

Yes, if you can ensure you never recieve any email with multiple
recipients.  You could receive by one instance, then relay to a second
instance via an transport that sets the recipient limit to 1.  That
second instance could then use the FILTER directive reliabily.  IMO
that's even more kludgy than using a socketmap daemon with transport
maps, though.
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Viktor Dukhovni
In reply to this post by Wietse Venema
On Sun, Nov 23, 2014 at 02:17:23PM -0500, Wietse Venema wrote:

> I have a preference for the design that addresses the problem at a
> lower level in the stack, so that the solution is not limited to
> the SMTP client and not limited to inet protocol selection.
>
> That code can then also be used to address other forms of trouble
> that manifest themselves via DNS (for example the next time someone
> changes the meaning of some corner case, like nullmx).
>
> I have a draft implementation that is being tested.

Feel free to compare notes.  The code changes in inet_proto.c are
for example policy neutral, this just supports on-the-fly protocol
settings for whatever code happens to want such data.  I forgot to
include one last change for that module, that avoids too large a
mask array should we ever support more than 2 protocols. (2^2^n
happens to equal 2*2^n for n=1,2).

diff --git a/src/util/inet_proto.c b/src/util/inet_proto.c
index 31b1ac1..d572c47 100644
--- a/src/util/inet_proto.c
+++ b/src/util/inet_proto.c
@@ -131,7 +131,7 @@ static const NAME_MASK proto_table[] = {
  /*
   * Cache by mask value.
   */
-static INET_PROTO_INFO *info_by_mask[1<<INET_PROTO_MASK_LAST];
+static INET_PROTO_INFO *info_by_mask[INET_PROTO_MASK_LAST<<1];
 
 /* make_uchar_vector - create and initialize uchar vector */


I hope the low level mechanism in question will apply with some
specificity, e.g. for particular MX hosts among many for the same
nexthop domain.  Some domains mix Google and non-google MX hosts.
If some day their non-Google MX hosts only support IPv6, we might
inadverantly disable these entirely:

    kortingisleuk.nl. IN MX 10 kortingisleuk.nl.
    kortingisleuk.nl. IN A 85.17.142.4
    kortingisleuk.nl. IN MX 10 ASPMX.L.GOOGLE.COM.
    kortingisleuk.nl. IN MX 20 ALT1.ASPMX.L.GOOGLE.COM.
    kortingisleuk.nl. IN MX 20 ALT2.ASPMX.L.GOOGLE.COM.
    kortingisleuk.nl. IN MX 30 ASPMX2.GOOGLEMAIL.COM.
    kortingisleuk.nl. IN MX 30 ASPMX3.GOOGLEMAIL.COM.
    kortingisleuk.nl. IN MX 30 ASPMX4.GOOGLEMAIL.COM.
    kortingisleuk.nl. IN MX 30 ASPMX5.GOOGLEMAIL.COM.

Likewise, were someone to chose to only use IPv6 with Google some
day.

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

Re: Pick the transport based on the destination host, not domain?

Wietse Venema
Viktor Dukhovni:

> On Sun, Nov 23, 2014 at 02:17:23PM -0500, Wietse Venema wrote:
>
> > I have a preference for the design that addresses the problem at a
> > lower level in the stack, so that the solution is not limited to
> > the SMTP client and not limited to inet protocol selection.
> >
> > That code can then also be used to address other forms of trouble
> > that manifest themselves via DNS (for example the next time someone
> > changes the meaning of some corner case, like nullmx).
> >
> > I have a draft implementation that is being tested.
>
> I hope the low level mechanism in question will apply with some
> specificity, e.g. for particular MX hosts among many for the same
> nexthop domain.  Some domains mix Google and non-google MX hosts.

It can drop DNS records based on arbitrary criteria, but the initial
use case is to drop *.google.com AAAA records while passing on all
other AAAA records.

postscreen_dns_reply_filter (default: $default_dns_reply_filter)
        ...
smtp_dns_reply_filter (default: $default_dns_reply_filter)
        ...
smtpd_dns_reply_filter (default: $default_dns_reply_filter)
        ...
default_dns_reply_filter (default: empty)
        ...
       Example: ignore Google AAAA records in Postfix SMTP client DNS lookups,
       because Google sometimes hard-rejects mail from IPv6 clients with valid
       PTR etc. records.

       /etc/postfix/main.cf:
           smtp_dns_reply_filter = pcre:/etc/postfix/smtp_dns_reply_filter

       /etc/postfix/smtp_dns_reply_filter:
           # /domain ttl IN AAAA address/ action, all case-insensitive.
           # Note: the domain name ends in ".".
           /^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE

The implementation renders a DNS record as a string in the format
that we know from dig(1) and other tools, then matches that string
against a list of lookup tables. Currently, IGNORE is the only
implemented action. It removes the record from the DNS lookup result.

When all DNS lookup result reply records are deleted, it returns a
DNS_NOTFOUND status plus a diagnostic text with "All records
suppressed by policy filter".

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Viktor Dukhovni
On Mon, Nov 24, 2014 at 01:38:15PM -0500, Wietse Venema wrote:

>        /etc/postfix/smtp_dns_reply_filter:
>            # /domain ttl IN AAAA address/ action, all case-insensitive.
>            # Note: the domain name ends in ".".
>            /^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
>
> The implementation renders a DNS record as a string in the format
> that we know from dig(1) and other tools, then matches that string
> against a list of lookup tables. Currently, IGNORE is the only
> implemented action. It removes the record from the DNS lookup result.
>
> When all DNS lookup result reply records are deleted, it returns a
> DNS_NOTFOUND status plus a diagnostic text with "All records
> suppressed by policy filter".

There might be cases in which "DNS_NOTFOUND" should be replaced
with "DNS_FAIL" if as a result the RRset becomes empty.

For example, if a domain has MX records, but we drop them all, it
may not be appropriate to then use the A/AAAA records.  Rather, it
seems that such a domain is unreachable.  So the "IGNORE" could
be augmented by:

        IGNORE_FAIL_IF_EMPTY

or some such.

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

Re: Pick the transport based on the destination host, not domain?

Darren Pilgrim
On 11/25/2014 8:06 AM, Viktor Dukhovni wrote:

> On Mon, Nov 24, 2014 at 01:38:15PM -0500, Wietse Venema wrote:
>
>>         /etc/postfix/smtp_dns_reply_filter:
>>             # /domain ttl IN AAAA address/ action, all case-insensitive.
>>             # Note: the domain name ends in ".".
>>             /^\S+\.google.com\.\s+\S+\s+\S+\s+AAAA\s+/ IGNORE
>>
>> The implementation renders a DNS record as a string in the format
>> that we know from dig(1) and other tools, then matches that string
>> against a list of lookup tables. Currently, IGNORE is the only
>> implemented action. It removes the record from the DNS lookup result.
>>
>> When all DNS lookup result reply records are deleted, it returns a
>> DNS_NOTFOUND status plus a diagnostic text with "All records
>> suppressed by policy filter".
>
> There might be cases in which "DNS_NOTFOUND" should be replaced
> with "DNS_FAIL" if as a result the RRset becomes empty.
>
> For example, if a domain has MX records, but we drop them all, it
> may not be appropriate to then use the A/AAAA records.  Rather, it
> seems that such a domain is unreachable.  So the "IGNORE" could
> be augmented by:
>
> IGNORE_FAIL_IF_EMPTY

I can definitely see the utility of that.  I think in production I would
want "defer if empty" with logging stating that the set of A/AAAA
nexthops is empty after filtering.  That way I'm not bouncing email on
what could, ironically, be a transient DNS issue.

Reply | Threaded
Open this post in threaded view
|

Re: Pick the transport based on the destination host, not domain?

Viktor Dukhovni
On Tue, Nov 25, 2014 at 08:10:28AM -0800, Darren Pilgrim wrote:

> >For example, if a domain has MX records, but we drop them all, it
> >may not be appropriate to then use the A/AAAA records.  Rather, it
> >seems that such a domain is unreachable.  So the "IGNORE" could
> >be augmented by:
> >
> > IGNORE_FAIL_IF_EMPTY
>
> I can definitely see the utility of that.  I think in production I would
> want "defer if empty" with logging stating that the set of A/AAAA nexthops
> is empty after filtering.  That way I'm not bouncing email on what could,
> ironically, be a transient DNS issue.

Well, actual DNS answers are not supposed to be transient issues, those
are the result of timeouts and other lookup failures, however, if we
provide the hard-fail feature, creating a soft-fail variant is perhaps
not unreasonable as a matter of completeness.

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

Re: Pick the transport based on the destination host, not domain?

Darren Pilgrim
On 11/25/2014 8:48 AM, Viktor Dukhovni wrote:

> On Tue, Nov 25, 2014 at 08:10:28AM -0800, Darren Pilgrim wrote:
>>> For example, if a domain has MX records, but we drop them all, it
>>> may not be appropriate to then use the A/AAAA records.  Rather, it
>>> seems that such a domain is unreachable.  So the "IGNORE" could
>>> be augmented by:
>>>
>>> IGNORE_FAIL_IF_EMPTY
>>
>> I can definitely see the utility of that.  I think in production I would
>> want "defer if empty" with logging stating that the set of A/AAAA nexthops
>> is empty after filtering.  That way I'm not bouncing email on what could,
>> ironically, be a transient DNS issue.
>
> Well, actual DNS answers are not supposed to be transient issues, those
> are the result of timeouts and other lookup failures, however, if we
> provide the hard-fail feature, creating a soft-fail variant is perhaps
> not unreasonable as a matter of completeness.

The transient issue would be not getting a complete RRset to begin with.
  It's not the common fault case, but I've seen it happen.
12