Please, provide a debug log from the ssh (with -vvv). It might uncover more of what is going on there.

With -vvv we get this:

debug1: Server host key: ssh-rsa SHA256:xxx
debug3: verify_host_key_dns
debug1: found 1 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
The authenticity of host 'machine.example.com (2a01:xxx:xx:fffx:xxxx:xxxx:xxxx:xxxx)' can't be established.
RSA key fingerprint is SHA256:xxx.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no/[fingerprint])? 

The key line is "found 1 insecure fingerprints in DNS".

The command "dig AAAA +dnssec machine.example.com" on the same machine returns a valid secure record.

AFAIK you need edns0 in addition to DNSSEC. If you are using any remote resolved, you are getting just a bit whether its chain was verified, but no reasonable way how to trust this answer. If you want to use SSHFP from DNS, you should really run local resolver. We had very similar discussion here some years back:

https://bugzilla.redhat.com/show_bug.cgi?id=1630180

One option would be to implement all the validation inside of SSH, but it does not look like neither good idea nor something that is going to happen any time soon.

There is a bit more about it:

https://weberblog.net/sshfp-authenticate-ssh-fingerprints-via-dnssec/

You need the answer from DNS to have the AD flag to be able to accept the fingerprints from DNS automatically.

I already run a local resolver (unbound) to solve this problem (otherwise the response would be meaningless):

[root@gatekeeper ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
search example.com
nameserver ::1

Adding "options edns0" manually and now it works:

[root@gatekeeper ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
search horizonmarine.co.za
nameserver ::1
options edns0

The question now becomes how does NetworkManager add the "options edns0", and is this documented clearly.

(In reply to Graham Leggett from comment #5)
> Adding "options edns0" manually and now it works:

good to hear that.

> The question now becomes how does NetworkManager add the "options edns0",
> and is this documented clearly.

That is probably more a question on the networking folks as I am not sure how networkmanager manages this file. Once we will have the answers, we should clearly document this somehow.

This was reported to the NetworkManager folks, but they haven't picked it up yet.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/233

The same bug existed in dnssec-triggerd, but this was fixed upstream:

https://github.com/NLnetLabs/dnssec-trigger/pull/2

Moved to NM as it is the only source which can influence content of the resolv.conf

> The question now becomes how does NetworkManager add the "options edns0", and is this documented clearly.

 $ nmcli connection modify "$PROFILE" +ipv4.dns-options ends0

and `man nm-settings`


(In reply to Graham Leggett from comment #7)
> This was reported to the NetworkManager folks, but they haven't picked it up
> yet.
> 
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/233

!233 should probably be done. However, it would only be done if NetworkManager runs its own local caching DNS server -- that is: "dns=dnsmasq" or "dns=systemd-resolved" in NetworkManager.conf.

You seem to run your own local caching DNS server, which NetworkManager wouldn't know about and it would thus not set edns0 automatically.

Could you show your NetworkManager relevant configuration?

  - NetworkManager --print-config
  - ls -la /etc/resolv.conf
  - nmcli -o connection show "$PROFILE" (for the relevant profiles. Possibly edit private data before posting).

I did a patch to automatically add 'options edns0 trust-ad' to
resolv.conf when NM uses dnsmasq or systemd-resolved, based on what
systemd does at [1].

This sounds right when using systemd-resolved because it does DNS
validation.

However I see that when starting dnsmasq, NetworkManager passes the
--proxy-dnssec option, which makes dnsmasq copy the AD bit from
upstream servers. In my limited understanding of DNSSEC, this is not
desirable in general as the upstream servers could be untrusted.

To anyone more familiar with DNSSEC, should NM add 'options trust-ad'
when using dnsmasq, or should it be opt-in by users? And with
systemd-resolved?


[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/644
[2] https://github.com/systemd/systemd/blob/v246/src/resolve/resolved-resolv-conf.c#L310

I'm not sure if systemd-resolved handles the AD bit correctly because it's such a non-traditional implementation of DNS.

You are right that setting trust-ad without a trusted network connection to a DNSSEC-validating (not just DNSSEC-aware) resolver is incorrect. If the DNS resolver on localhost does not do validation and is a non-recursive cache, enabling trust-ad depends on a trusted network connection to the actual recursive DNS resolver, and this resolver performing DNSSEC validation in a way that the local system considers trusted.

In the end, if DNSSEC validation is not happening on localhost, we really can't know if the AD bit that comes into the system from the outside is trustworthy or not. So setting it automatically without local validation would be wrong IMHO.

Not sure if this answers your question.

Florian, thanks for clarifications. For OpenSSH, it looks like we have one another option to build OpenSSH together with ldns to handle all this instead of glibc -- see the bug #1886343. As I am not a DNS expert, I am not sure what would be some other consequences of doing so, but according to the reporter, it looks like it solves their issues with recent Fedora (probably after it got recent glibc update with [1]).

What do you think? Is this something that should be handled completely inside of aplication (using ldns) or in the operating system (by glibc, sane values in resolv.conf set by NetworkManager and frineds)?

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=446997ff1433d33452b81dfa9e626b8dccf101a4

(In reply to Jakub Jelen from comment #14)
> Florian, thanks for clarifications. For OpenSSH, it looks like we have one
> another option to build OpenSSH together with ldns to handle all this
> instead of glibc -- see the bug #1886343. As I am not a DNS expert, I am not
> sure what would be some other consequences of doing so, but according to the
> reporter, it looks like it solves their issues with recent Fedora (probably
> after it got recent glibc update with [1]).

I don't think can't side-step the network trust issue with ldns because OpenSSH does this:

        /* Check for authenticated data */
        if (ldns_pkt_ad(pkt)) {
                rrset->rri_flags |= RRSET_VALIDATED;
        } else { /* AD is not set, try autonomous validation */
                ldns_rr_list * trusted_keys = ldns_rr_list_new();

                debug2("ldns: trying to validate RRset");
                /* Get eventual sigs */
                rrsigs = ldns_pkt_rr_list_by_type(pkt, LDNS_RR_TYPE_RRSIG,
                    LDNS_SECTION_ANSWER);

                rrset->rri_nsigs = ldns_rr_list_rr_count(rrsigs);
                debug2("ldns: got %u signature(s) (RRTYPE %u) from DNS",
                       rrset->rri_nsigs, LDNS_RR_TYPE_RRSIG);

                if ((err = ldns_verify_trusted(ldns_res, rrdata, rrsigs,
                     trusted_keys)) == LDNS_STATUS_OK) {
                        rrset->rri_flags |= RRSET_VALIDATED;
                        debug2("ldns: RRset is signed with a valid key");
                } else {
                        debug2("ldns: RRset validation failed: %s",
                            ldns_get_errorstr_by_id(err));
                }

                ldns_rr_list_deep_free(trusted_keys);
        }

If the network isn't trusted and you can a spurious AD bit, the trust model is still broken.

I don't know where ldns gets its keys. This needs configuration, in case the operator wants to override the public DNS (for split DNS, or to isolate from registry compromises).

(In reply to Beniamino Galvani from comment #12)
> I did a patch to automatically add 'options edns0 trust-ad' to
> resolv.conf when NM uses dnsmasq or systemd-resolved, based on what
> systemd does at [1].
> 
> This sounds right when using systemd-resolved because it does DNS
> validation.
Not so sure with systemd-resolved upstream developers attitude. It is not possible to validate, how well resolved does validation, because it does not pass dnssec records to local system.
It makes it risky to blind trust it.
 
> However I see that when starting dnsmasq, NetworkManager passes the
> --proxy-dnssec option, which makes dnsmasq copy the AD bit from
> upstream servers. In my limited understanding of DNSSEC, this is not
> desirable in general as the upstream servers could be untrusted.

I agree, it is not desirable to trust any flag resolver gives us. Dnsmasq is able to do validation, its support is enabled in RHEL8.
Include dnssec keyword and trust anchors in dnsmasq to enable its validation. I think validation should always be done on localhost in order to be trustworthy.

> 
> To anyone more familiar with DNSSEC, should NM add 'options trust-ad'
> when using dnsmasq, or should it be opt-in by users? And with
> systemd-resolved?
NM cannot know, whether dnsmasq validation is enabled. It should not therefore enable trust-ad in all cases. Btw, trust-ad is not documented on my F32 man resolv.conf.
resolved exports dnssec status, but it can downgrade any time. What is trust-ad used for anyway?

(In reply to Petr Menšík from comment #16)
> Btw, trust-ad is not documented on
> my F32 man resolv.conf.

Patch posted: https://lore.kernel.org/linux-man/87sgaj1yfe.fsf@oldenburg2.str.redhat.com/T

(In reply to Florian Weimer from comment #15)
> 
> I don't know where ldns gets its keys. This needs configuration, in case the
> operator wants to override the public DNS (for split DNS, or to isolate from
> registry compromises).

LDNS does not ship any trust anchors, even built-in. It can load trust anchors on client side, but ldns_resolver_push_dnssec_anchor or ldns_resolver_set_dnssec_anchors has to be used.
But it has build-in undeclared dependency on unbound libs trust anchor file /var/lib/unbound/root.key, which path is used by default. Maybe it worked well only because I have also unbound-libs installed.
It is used by drill -S, according to strace.

(In reply to Petr Menšík from comment #18)
> (In reply to Florian Weimer from comment #15)
> > 
> > I don't know where ldns gets its keys. This needs configuration, in case the
> > operator wants to override the public DNS (for split DNS, or to isolate from
> > registry compromises).
> 
> LDNS does not ship any trust anchors, even built-in. It can load trust
> anchors on client side, but ldns_resolver_push_dnssec_anchor or
> ldns_resolver_set_dnssec_anchors has to be used.
> But it has build-in undeclared dependency on unbound libs trust anchor file
> /var/lib/unbound/root.key, which path is used by default. Maybe it worked
> well only because I have also unbound-libs installed.

Are you sure your DNS server hasn't sent you replies with the AD bit set?  Then the DNSSEC validation path is never taken.

(In reply to Petr Menšík from comment #16)
> (In reply to Beniamino Galvani from comment #12)
> > I did a patch to automatically add 'options edns0 trust-ad' to
> > resolv.conf when NM uses dnsmasq or systemd-resolved, based on what
> > systemd does at [1].
> > 
> > This sounds right when using systemd-resolved because it does DNS
> > validation.
> Not so sure with systemd-resolved upstream developers attitude. It is not
> possible to validate, how well resolved does validation, because it does not
> pass dnssec records to local system.
> It makes it risky to blind trust it.

What do you mean? I thought that with DNSSEC=allow-downgrade (which seems to be
the default in Fedora and RHEL), systemd-resolved would do the local validation
if the DNS server supports DNSSEC. If not, it would return a not authenticated
answer.

Isn't "DNSSEC=allow-downgrade" equivalent to running dnsmasq with "--dnssec
--dnssec-check-unsigned=no" ?
  
> > However I see that when starting dnsmasq, NetworkManager passes the
> > --proxy-dnssec option, which makes dnsmasq copy the AD bit from
> > upstream servers. In my limited understanding of DNSSEC, this is not
> > desirable in general as the upstream servers could be untrusted.
> 
> I agree, it is not desirable to trust any flag resolver gives us. Dnsmasq is
> able to do validation, its support is enabled in RHEL8.
> Include dnssec keyword and trust anchors in dnsmasq to enable its
> validation. I think validation should always be done on localhost in order
> to be trustworthy.
> 
> > 
> > To anyone more familiar with DNSSEC, should NM add 'options trust-ad'
> > when using dnsmasq, or should it be opt-in by users? And with
> > systemd-resolved?
> NM cannot know, whether dnsmasq validation is enabled. 

The problem is that DNSSEC can be disabled at build time in dnsmasq, right?

(In reply to Beniamino Galvani from comment #20)
> What do you mean? I thought that with DNSSEC=allow-downgrade (which seems to
> be
> the default in Fedora and RHEL), systemd-resolved would do the local
> validation
> if the DNS server supports DNSSEC. If not, it would return a not
> authenticated
> answer.

Starting with Fedora 33, the default is DNSSEC=no (see https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC).

(In reply to Beniamino Galvani from comment #20)
> (In reply to Petr Menšík from comment #16)
> What do you mean? I thought that with DNSSEC=allow-downgrade (which seems to
> be
> the default in Fedora and RHEL), systemd-resolved would do the local
> validation
> if the DNS server supports DNSSEC. If not, it would return a not
> authenticated
> answer.

No, DNSSEC=no is new proposed default for F33. It is difficult to verify validation actually works, because it does not pass DNSSEC records to its clients.
So you are not able to verify, what were verified resolved with a AD flag by resolved.
> 
> Isn't "DNSSEC=allow-downgrade" equivalent to running dnsmasq with "--dnssec
> --dnssec-check-unsigned=no" ?

It is similar, but not equivalent. dnsmasq never blocks client DNSSEC requests. But it both allows unsigned queries to be accepted for signed parents.
--dnssec-check-unsigned were changed in dnsmasq 2.80 to default to yes. Unlike resolved, dnsmasq author it should not be the default.

> The problem is that DNSSEC can be disabled at build time in dnsmasq, right?

DNSSEC validation can be disabled at build time, yes. It is disabled in RHEL 7.
Also, it has to be enabled by configuration (in RHEL8), it is disabled without explicit dnssec keyword and trust anchor.

But unlike *resolved*, *dnsmasq* forwards always DNSSEC client queries to upstream resolver. Even without DNSSEC validation enabled, client validation would still work, if upstream server allows it.
Unless dnssec (validation) or dnssec-proxy option is used, replies would not have AD bit set. But client is able to check it itself. SSH can still validate SSHFP even without dnsmasq doing validation.

That is not possible on systemd-resolved and we are arguing about it with its upstream authors. But they claim it is not needed.

(In reply to Michael Catanzaro from comment #21)
> 
> Starting with Fedora 33, the default is DNSSEC=no (see
> https://fedoraproject.org/wiki/Changes/systemd-resolved#DNSSEC).

DNSSEC support in systemd-resolved is strange thing. It enables only AD flag in response, when DNSSEC support is enabled.
It might be sufficient for this case. It is unprovable that flag is correct IMHO.

(In reply to Florian Weimer from comment #15)
> (In reply to Jakub Jelen from comment #14)
> > Florian, thanks for clarifications. For OpenSSH, it looks like we have one
> > another option to build OpenSSH together with ldns to handle all this
> > instead of glibc -- see the bug #1886343. As I am not a DNS expert, I am not
> > sure what would be some other consequences of doing so, but according to the
> > reporter, it looks like it solves their issues with recent Fedora (probably
> > after it got recent glibc update with [1]).
> 
> I don't think can't side-step the network trust issue with ldns because
> OpenSSH does this:
> 
>         /* Check for authenticated data */
>         if (ldns_pkt_ad(pkt)) {
>                 rrset->rri_flags |= RRSET_VALIDATED;
>         } else { /* AD is not set, try autonomous validation */
>                 ldns_rr_list * trusted_keys = ldns_rr_list_new();
> 
>                 debug2("ldns: trying to validate RRset");
>                 /* Get eventual sigs */
>                 rrsigs = ldns_pkt_rr_list_by_type(pkt, LDNS_RR_TYPE_RRSIG,
>                     LDNS_SECTION_ANSWER);
> 
>                 rrset->rri_nsigs = ldns_rr_list_rr_count(rrsigs);
>                 debug2("ldns: got %u signature(s) (RRTYPE %u) from DNS",
>                        rrset->rri_nsigs, LDNS_RR_TYPE_RRSIG);
> 
>                 if ((err = ldns_verify_trusted(ldns_res, rrdata, rrsigs,
>                      trusted_keys)) == LDNS_STATUS_OK) {
>                         rrset->rri_flags |= RRSET_VALIDATED;
>                         debug2("ldns: RRset is signed with a valid key");
>                 } else {
>                         debug2("ldns: RRset validation failed: %s",
>                             ldns_get_errorstr_by_id(err));
>                 }
> 
>                 ldns_rr_list_deep_free(trusted_keys);
>         }
> 
> If the network isn't trusted and you can a spurious AD bit, the trust model
> is still broken.
> 
> I don't know where ldns gets its keys. This needs configuration, in case the
> operator wants to override the public DNS (for split DNS, or to isolate from
> registry compromises).

When checking openssh sources for bug #1886343, I tried strace on ssh with ldns built-in. It seems no trust anchors are ever pushed inside.
If that is correct, it might work the same way as resolv.conf with options edns0. Else branch would not ever work on client, because trust anchors are not used. Then any validation cannot succeed. Because there seems to be missing any way to configure anchors, it must be always failure.

I am afraid that means there is little need for ldns, until anchors can be provided.

(In reply to Thomas Haller from comment #10)

> (In reply to Graham Leggett from comment #7)
> > This was reported to the NetworkManager folks, but they haven't picked it up
> > yet.
> > 
> > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/233
> 
> !233 should probably be done. However, it would only be done if
> NetworkManager runs its own local caching DNS server -- that is:
> "dns=dnsmasq" or "dns=systemd-resolved" in NetworkManager.conf.
> 
> You seem to run your own local caching DNS server, which NetworkManager
> wouldn't know about and it would thus not set edns0 automatically.

The local caching DNS server is unbound in this case. NetworkManager is documented to be aware of unbound, but I couldn't make NetworkManager work sensibly to write the config to point the DNS at localhost. I suspect the implementation and docs are different.

> Could you show your NetworkManager relevant configuration?
> 
>   - NetworkManager --print-config

I currently have dns set to "none" so that nm doesn't break DNS. I'd like to set it to "unbound" and see it just work.

[root@gatekeeper ~]# NetworkManager --print-config
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (etc: none.conf)

[main]
# plugins=ifcfg-rh
# rc-manager=symlink
# auth-polkit=true
# dhcp=internal
dns=none

[logging]
# backend=journal
# audit=false

# no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"

>   - ls -la /etc/resolv.conf

In case you meant cat:

[root@gatekeeper ~]# ls -la /etc/resolv.conf
-rw-r--r--. 1 root root 189 Sep 20 23:29 /etc/resolv.conf
[root@gatekeeper ~]# cat /etc/resolv.conf
nameserver ::1
options edns0

>   - nmcli -o connection show "$PROFILE" (for the relevant profiles. Possibly
> edit private data before posting).

No idea what value of profile should be used.

[root@gatekeeper ~]# nmcli -o connection show 
NAME  UUID                                  TYPE      DEVICE 
ens3  381688f4-cd30-48bc-af6c-53d196f979b1  ethernet  ens3

From the discussion above, my understanding is that NM should always
add option "edns0" to resolv.conf when using systemd-resolved and
dnsmasq as local resolvers; it should *not* automatically add
"trust-ad" because that would require a trusted network
connection. Users can manually add "trust-ad" in the NM connection
profile if they wish.

Are there any objections to this?

(In reply to Beniamino Galvani from comment #26)
> From the discussion above, my understanding is that NM should always
> add option "edns0" to resolv.conf when using systemd-resolved and
> dnsmasq as local resolvers; it should *not* automatically add
> "trust-ad" because that would require a trusted network
> connection. Users can manually add "trust-ad" in the NM connection
> profile if they wish.
> 
> Are there any objections to this?

I think systemd-resolved can add trust-ad if it is configured to perform DNSSEC validation locally. It should not add trust-ad otherwise.

Are you going to suggest this to systemd developers? Thanks.

> I think systemd-resolved can add trust-ad if it is configured to perform DNSSEC validation locally. It should not add trust-ad otherwise.

> Are you going to suggest this to systemd developers? Thanks.

Here I'm talking of the case where NM is configured to use
systemd-resolved and to manage /etc/resolv.conf by itself. In such
case, NM writes "nameserver 127.0.0.53" (and possibly some options) to
the file and then updates systemd-resolved configuration via D-Bus.

Instead, if resolv.conf is managed by systemd-resolved (being a link
to /run/systemd/resolve/stub-resolv.conf - which seems to be the
default configuration on F33), NM doesn't touch resolv.conf. In this
case, the resolv.conf content seems to be hardcoded to have the
trust-ad option enabled. But there is nothing that NM can do about it.

So, for the situation when NM manages resolv.conf, the question is
whether NM can discover that DNSSEC validation is enabled in
systemd-resolved. It seems this information is available via D-Bus:

 # busctl introspect org.freedesktop.resolve1 /org/freedesktop/resolve1 | grep DNSSEC
 .DNSSEC                             property  s             "allow-downgrade"                        -
 .DNSSECSupported                    property  b             true                                     -

The documentation says:

 The DNSSECSupported boolean properties reports whether DNSSEC is
 enabled and the selected DNS servers support it. It combines
 information about system-wide and per-link DNS settings (see below),
 and only reports true if DNSSEC is enabled and supported on every
 interface for which DNS is configured and for the system-wide
 settings if there are any. Note that resolved assumes DNSSEC is
 supported by DNS servers until it verified that this is not the
 case. Thus, the reported value may initially be true, until the first
 transactions are executed.

Probably NM should set the "trust-ad" option based on the
"DNSSECSupported" D-Bus property, and keep monitoring the property for
changes.

Should be dnsmasq d-bus property configured as well? It can do dnssec validation as well, but its current d-bus interface cannot report it. Should setting trust-ad be part of DNS plugin interface?

I think it would require manual configuration. I think it could set trust-ad on implementations, which always ignore incoming AD flag on responses from upstream resolvers and set it for local clients only in case it actually verified DNSSEC itself. I think that might be the case of unbound.

Hi Graham Leggett,

Out developer said: 

Currently NM adds options 'edns0' and 'trust-ad' to resolv.conf when using systemd-resolved and dnsmasq, so the original issue is fixed.

Could you check whether your problem been fixed?

Hi Graham Leggett,

Currently NM adds options 'edns0' and 'trust-ad' to resolv.conf when using systemd-resolved and dnsmasq, so the original issue is fixed.

Could you check whether your problem been fixed?

I think --proxy-dnssec option to dnsmasq should be removed. dnsmasq were fixed and it always forwards DNSSEC enabled queries to upstream server. That means validating resolver would receive ad flag from dnsmasq when do flag were set in a query. If dnssec validation is enabled in dnsmasq, ad bit would be set by dnsmasq itself.

I doubt proxy-dnssec should be default, because it puts trust in remote resolver without any channel security. But I think that is should have different bug.

edns0 and trust-ad options were enough to fix it on Fedora. Because our test machines resolvers do not validate, I did not validate. But basics seems fixed IMO.

(In reply to Petr Menšík from comment #36)
> I think --proxy-dnssec option to dnsmasq should be removed. dnsmasq were
> fixed and it always forwards DNSSEC enabled queries to upstream server. That
> means validating resolver would receive ad flag from dnsmasq when do flag
> were set in a query. If dnssec validation is enabled in dnsmasq, ad bit
> would be set by dnsmasq itself.

If NM removes "--proxy-dnssec"  from dnsmasq options, does it need to pass anything else (maybe "--dnssec"?) to achieve what you said?

Since you are more familiar with this topic, would you mind filing a bugzilla for the removal of --proxy-dnssec?

Regarding the original bug, I think it's solved now and it's ready for verification.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:1985

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days

(In reply to Gris Ge from comment #34)
> Hi Graham Leggett,
> 
> Currently NM adds options 'edns0' and 'trust-ad' to resolv.conf when using
> systemd-resolved and dnsmasq, so the original issue is fixed.
> 
> Could you check whether your problem been fixed?

Finally got back to this.

Yes, it's fixed! Tested on RHEL9 with both bind and unbound running locally, and SSHFP records work properly.

Weirdly sshd cares about these flags, but postfix (specifically DANE support with TLSA) doesn't appear to need these flags. DNSSEC works at last.

Much appreciated.