Bug 961318

From man sssd-ad:

dyndns_iface (string)
      Optional. Applicable only when dyndns_update is true. Choose the
      interface whose IP address should be used for dynamic DNS updates.

      Default: Use the IP address of the IPA LDAP connection

Apart from the typo above (shouldn't say IPA but AD), is this option what you're looking for?

I'd say we may also want an RFE to make dyndns_iface into a multivalued attribute. In a multihomed system, you may want to submit results from more than one interface.

(In reply to comment #2)
> I'd say we may also want an RFE to make dyndns_iface into a multivalued
> attribute. In a multihomed system, you may want to submit results from more
> than one interface.

Yes, that would make sense.

How does sssd determine which interface to use by default?

(In reply to comment #3)
> (In reply to comment #2)
> > I'd say we may also want an RFE to make dyndns_iface into a multivalued
> > attribute. In a multihomed system, you may want to submit results from more
> > than one interface.
> 
> Yes, that would make sense.
> 
> How does sssd determine which interface to use by default?

The way I read Stephen's suggestion (which I agree with and will open a RFE), the intent was to include ALL addresses from ALL configured interfaces. In pseudocode:

addrlist = new_list()

if dyndns_iface:
 for iface in dyndns_iface:
    iface_addrlist = get_addresses_from_one_iface(iface)
    extend_list(addrlist, iface_addrlist)
 endfor
else:
  # This is the default. Addrlist contains exactly one address now.
  addrlist = get_address_from_LDAP_connection()
fi

update_dns_with_addresses(addrlist)

SSSD uses the interface from which it is currently connected to LDAP as the
default. This is because we assumed that this function would be most often used
on individual systems like laptops where they would not likely have multiple
interfaces.

That said, I am rethinking my RFE suggestion above. It occurs to me that it's
probably *not* in our best interest to support multihoming. The reason for this
is that multi-home generally exists because the system is connected to two
different networks, and therefore needs different connection information on
each.

However, the problem here is that if we put both 24.5.1.12 (public) and
192.168.1.12 (private network) into DNS for the server.example.com entry,
clients won't necessarily behave correctly. The problem is that multiple IP
addresses served for the same hostname in DNS are assumed to be load-balanced
alternative servers, not various IP addresses for the same server. By putting
IP addresses for all interfaces into the DNS A[AAA] record, we're essentially
telling all clients that any of these addresses will work for them to reach the
server, which may not actually be true. For example, do a 'dig www.google.com'
several times at look at the output. They give back the same set of IP
addresses in a random order (to load-balance). If we occasionally gave back an
internal-only IP, it would result in seemingly-random failures of client
applications.

I think we probably want to stick with just a single authoritative IP address
to represent the A[AAA] record for the hostname as recognized by IPA and allow
manual configuration of other records for other hosts *as different hostnames*
directly in the IPA DNS server.

The only advantage I can see of having SSSD handle multiple interfaces would
potentially be so that it could update reverse lookup (PTR) entries, but as
we've established in other forums, allowing clients to update PTR entries is a
severe security risk and should probably not be allowed.

(In reply to comment #4)
> The way I read Stephen's suggestion (which I agree with and will open a
> RFE), the intent was to include ALL addresses from ALL configured
> interfaces. In pseudocode:

See my above comment. I'm backpedaling on that. Also, no: the intent was to include all addresses from a SINGLE configured interface, but even that might be the wrong approach, given the thoughts I had above. Needs investigation.

(In reply to comment #6)
> See my above comment. I'm backpedaling on that. Also, no: the intent was to
> include all addresses from a SINGLE configured interface.

We already include all addresses from a single interface when dyndns_iface is set (and have done so for ages since the dyndns feature was written).

(In reply to comment #5)
> The only advantage I can see of having SSSD handle multiple interfaces would
> potentially be so that it could update reverse lookup (PTR) entries, but as
> we've established in other forums, allowing clients to update PTR entries is
> a
> severe security risk and should probably not be allowed.

The AD dyndns updates do update their PTR records as AD doesn't autogenerate the PTR records when forward records are updated automatically (unlike IPA).

Updating PTR records is allowed by default by AD on the server side and you can actually even modify other machine's records easily. There is no check short of having the Kerberos ticket.

(In reply to comment #5)
> SSSD uses the interface from which it is currently connected to LDAP as the
> default. This is because we assumed that this function would be most often
> used
> on individual systems like laptops where they would not likely have multiple
> interfaces.

This is good default behavior. I agree this makes sense as a default. Is this documented? If so, I think we can close this WONTFIX.

It is, but I admit that if I never read the code before, I'm not sure I would have understood right away from reading the man page which states:

-------------------
dyndns_iface (string)
           Optional. Applicable only when dyndns_update is true. Choose the
           interface whose IP address should be used for dynamic DNS updates.

           Default: Use the IP address of the IPA LDAP connection
-------------------

So maybe we could amend the man page to specifically say which address is used by default along with the description of dyndns_update (which enables/disables the update) or even add a short paragraph describing how the updates work.

I think the first option would be enough.

So I'd turn this bug into an RFE to amend the SSSD documentation to make it clear how the updates work.

(In reply to comment #10)
> So I'd turn this bug into an RFE to amend the SSSD documentation to make it
> clear how the updates work.

https://fedorahosted.org/sssd/ticket/1924

Upstream ticket:
https://fedorahosted.org/sssd/ticket/1924

sssd-1.10.0-8.fc19.beta2 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/sssd-1.10.0-8.fc19.beta2

Package sssd-1.10.0-8.fc19.beta2:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.10.0-8.fc19.beta2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10683/sssd-1.10.0-8.fc19.beta2
then log in and leave karma (feedback).

Package sssd-1.10.0-10.fc19.beta2:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.10.0-10.fc19.beta2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10683/sssd-1.10.0-10.fc19.beta2
then log in and leave karma (feedback).

This is fixed for some time.