SSHFP records

[Simon Matthews]

When enrolling a client, I get the message:

Could not update DNS SSHFP records.

Everything seems to be working. Is this an issue I need to worry about? 

The reason it can't update these records is that the master DNS for the network is on
a different server and it needs a TSIG in order to accept an update.

[Sam Morris]

Only a problem if you want to use SSHFP records to verify the host keys presented by the
SSH server running on the client.

When SSHing to the client from another machine that has been enrolled, the host key will
usually be verified by sss_ssh_knownhostsproxy which does not use SSHFP records.

You might use these records in conjunction with DNSSEC to allow non-enrolled clients to
have a secure way to fetch a host's public keys for verification, but that setup is
not the default & requires extra work.

More generally, it sounds like sssd's is not going to be able to update the A records
for your clients either.

-- 
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

[Simon Matthews]

My primary nameserver is on another machine. It is already configured with an RNDC key to
allow updates from DHCP. 

How would I tell IPA to use this RNDC key to update the primary? 

I assume that these updates come from the IPA server, not the client when enrolling a
client. 

Currently, the SSH keys are in the user's home directory, which will be accessible on
any machine that a user would log into, but it might be useful to have an alternative to
this.

[Rob Crittenden]

Simon Matthews via FreeIPA-users wrote:
>  My primary nameserver is on another machine. It is already configured
> with an RNDC key to allow updates from DHCP. 
>  
>  How would I tell IPA to use this RNDC key to update the primary? 
>  
>  I assume that these updates come from the IPA server, not the client when enrolling a
> client. 
>  
>  Currently, the SSH keys are in the user's home directory, which will be accessible on
> any machine that a user would log into, but it might be useful to have an alternative to
> this.  
The updates come from the client directly, they own the keys after all.
The IPA client only supports GSS-TSIG and unauthenticated updates. If
the GSS-TSIG fails during ipa-client-install then it will fall back and
try an unauthenticated nsupdate with 4.9.6+. Prior to that only GSS-TSIG
was supported.

This of course requires the DNS admin to configure their zones to allow
unauthenticated dynamic DNS updates which isn't a terrific idea.

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

rob