Bug 961318 - dyndns update for only one address of multi-homed machine
dyndns update for only one address of multi-homed machine
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-09 08:09 EDT by Stef Walter
Modified: 2013-08-08 10:06 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-08 10:06:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stef Walter 2013-05-09 08:09:15 EDT
Description of problem:

Followed this test case to have sssd do dynamic DNS updates. However only one A record was added. My machine is multi-homed, and has several relevant addresses.

https://fedoraproject.org/wiki/QA:Testcase_sssd_ad_dns_update


Version-Release number of selected component (if applicable):

sssd-1.10.0-4.fc19

How reproducible:

Every time

Steps to Reproduce:
1. Have a multihomed machine.
2. https://fedoraproject.org/wiki/QA:Testcase_sssd_ad_dns_update

Actual results:

Only one address, in my case for virbr0 was added.

Expected results:

All relevant (non localhost, non zeroconf) addresses are dynamically updated to DNS.
Comment 1 Jakub Hrozek 2013-05-09 10:33:10 EDT
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?
Comment 2 Stephen Gallagher 2013-05-09 11:09:31 EDT
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.
Comment 3 Stef Walter 2013-05-13 11:29:40 EDT
(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?
Comment 4 Jakub Hrozek 2013-05-13 12:06:47 EDT
(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)
Comment 5 Stephen Gallagher 2013-05-13 12:10:44 EDT
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.
Comment 6 Stephen Gallagher 2013-05-13 12:12:03 EDT
(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.
Comment 7 Jakub Hrozek 2013-05-13 12:16:18 EDT
(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).
Comment 8 Jakub Hrozek 2013-05-13 12:18:11 EDT
(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.
Comment 9 Stef Walter 2013-05-13 14:34:01 EDT
(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.
Comment 10 Jakub Hrozek 2013-05-13 14:57:45 EDT
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.
Comment 11 Jakub Hrozek 2013-05-13 15:52:31 EDT
(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
Comment 12 Jakub Hrozek 2013-05-16 11:37:53 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1924
Comment 13 Fedora Update System 2013-06-12 08:01:38 EDT
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
Comment 14 Fedora Update System 2013-06-12 15:11:03 EDT
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).
Comment 15 Fedora Update System 2013-06-13 14:04:25 EDT
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).
Comment 16 Jakub Hrozek 2013-08-08 10:06:34 EDT
This is fixed for some time.

Note You need to log in before you can comment on or make changes to this bug.