Bug 790105

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Created attachment 693835 [details]
output of multicast-broadcast scenarios

Jakub,

Multicast and Broadcast addresses are not being filtered out.

Multicast address:
=================
[root@rhel64master ~]# ipa dnsrecord-show testrelm.com rhel64client1
  Record name: rhel64client1
  A record: 224.0.0.1
  AAAA record: 2620:52:0:41c9:5054:ff:fe73:69b8
  SSHFP record: 1 1 57EA2E45D2179CA8CB657F87D193779CD748443E, 2 1 E63F99C498C201838B383EFD423D7A38B3370F04
[root@rhel64master ~]#

Broadcast address:
=================
[root@rhel64master ~]# ipa dnsrecord-show testrelm.com rhel64client1
  Record name: rhel64client1
  A record: 10.65.201.255
  AAAA record: 2620:52:0:41c9:5054:ff:fe73:69b8
  SSHFP record: 1 1 57EA2E45D2179CA8CB657F87D193779CD748443E, 2 1 E63F99C498C201838B383EFD423D7A38B3370F04
[root@rhel64master ~]#

Am i missing something here?

Please find the attachment for details.

The multicast check is wrong, please file a bug against the SSSD. I have a patch already.

I'm not sure about the broadcast check, I think the only permitted address for IPv4 broadcast is 255.255.255.255. When I set that one, SSSD correctly detected it as broadcast.

(In reply to comment #7)
> The multicast check is wrong, please file a bug against the SSSD. I have a
> patch already.
> 
> I'm not sure about the broadcast check, I think the only permitted address
> for IPv4 broadcast is 255.255.255.255. When I set that one, SSSD correctly
> detected it as broadcast.

255.255.255.255 is broadcast address for zero network 0.0.0.0 
Every subnet has a broadcast address. for example in above subnet 10.65.201.0/24 , the broadcast address is 10.65.201.255. 
So my understanding is that any address ending in 0.0.0.255 should be filtered out.
Correct me if i am wrong.

(In reply to comment #8)
> (In reply to comment #7)
> > The multicast check is wrong, please file a bug against the SSSD. I have a
> > patch already.
> > 
> > I'm not sure about the broadcast check, I think the only permitted address
> > for IPv4 broadcast is 255.255.255.255. When I set that one, SSSD correctly
> > detected it as broadcast.
> 
> 255.255.255.255 is broadcast address for zero network 0.0.0.0 
> Every subnet has a broadcast address. for example in above subnet
> 10.65.201.0/24 , the broadcast address is 10.65.201.255. 
> So my understanding is that any address ending in 0.0.0.255 should be
> filtered out.
> Correct me if i am wrong.

Yes, but these subnet addresses are not returned by getifaddrs(). The only broadcast address that you can reasonably configure is 255.255.255.255.

Verified for loopback and link-local addresses.

Multicast and subnet broadcast address are not being filtered out. so will file another bugzilla for these addresses.

sssd version:
=============
[root@rhel64client1 ~]# rpm -q sssd
sssd-1.9.2-82.el6.x86_64
[root@rhel64client1 ~]#

Steps used to verify:
====================
(1)Loopback address:
=================
On Client:
==========
(a)sssd.conf has lo interface for ipa_dyndns_iface parameter

[root@rhel64client1 ~]# cat /etc/sssd/sssd.conf|grep ipa_dyn
ipa_dyndns_update = True
ipa_dyndns_iface = lo 
[root@rhel64client1 ~]#

(b)sssd debug log shows that Loopback address are filtered.
(Tue Feb  5 20:09:17 2013) [sssd[be[testrelm.com]]] [ok_for_dns] (0x0200): Loopback IPv4 address 127.0.0.1
(Tue Feb  5 20:09:17 2013) [sssd[be[testrelm.com]]] [ok_for_dns] (0x0200): Loopback IPv6 address ::1
(Tue Feb  5 20:09:18 2013) [sssd[be[testrelm.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry

On Server:
==========
(a)No A record exist for rhel64client1
[root@rhel64master ~]# ipa dnsrecord-show testrelm.com rhel64client1
  Record name: rhel64client1
  SSHFP record: 1 1 57EA2E45D2179CA8CB657F87D193779CD748443E, 2 1 E63F99C498C201838B383EFD423D7A38B3370F04
[root@rhel64master ~]#

(2)Link local IPv6 address:
========================
(a)Interface having global and link local ip addresses

   eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:73:69:b8 brd ff:ff:ff:ff:ff:ff
    inet 224.0.0.1/0 brd 255.255.255.255 scope global eth2:1
    inet6 2620:52:0:41c9:5054:ff:fe73:69b8/64 scope global dynamic 
       valid_lft 2591865sec preferred_lft 604665sec
    inet6 fe80::5054:ff:fe73:69b8/64 scope link 
       valid_lft forever preferred_lft forever
[root@rhel64client1 ~]#

global ipv6 address : 2620:52:0:41c9:5054:ff:fe73:69b8/64
link local ipv6 address : fe80::5054:ff:fe73:69b8/64

(b)link local ipv6 address is filtered out for dynamic dns update

(Wed Feb  6 13:10:00 2013) [sssd[be[testrelm.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication.
(Wed Feb  6 13:10:00 2013) [sssd[be[testrelm.com]]] [ok_for_dns] (0x0200): Link local IPv6 address fe80::5054:ff:fe73:69b8
(Wed Feb  6 13:10:01 2013) [sssd[be[testrelm.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Wed Feb  6 13:10:01 2013) [sssd[be[testrelm.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Wed Feb  6 13:10:01 2013) [sssd[be[testrelm.com]]] [create_nsupdate_message] (0x0200): Creating update message for realm [TESTRELM.COM] and zone [testrelm.com].

(c)Global ipv6 adddress added on ipa-server as AAAA record and not the Link local IPv6 address fe80::5054:ff:fe73:69b8
[root@rhel64master ~]# ipa dnsrecord-show testrelm.com rhel64client1
  Record name: rhel64client1
  A record: 10.65.201.102
  AAAA record: 2620:52:0:41c9:5054:ff:fe73:69b8
  SSHFP record: 1 1 57EA2E45D2179CA8CB657F87D193779CD748443E, 2 1 E63F99C498C201838B383EFD423D7A38B3370F04
[root@rhel64master ~]#

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, and where to find the updated
files, follow the link below.

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

http://rhn.redhat.com/errata/RHSA-2013-0508.html