@DNS: So long as the server host names are identical to their respective XMPP domain names (chat.example.com) you should not need SRV records, but, as BigD advises, you should have an A record in place. If the host and domain names that a given server is handling are different (server1.example.com is managing the example.com XMPP domain), then you'll need the appropriate SRV records, like:
SRV _xmpp-server._tcp.example.com 5269 server1.example.com.
Also, some non-Openfire servers (like MS Lync) will check for the SRV record, and depending upon how they're configured, may refuse the connection.
@Ports: XMPP S2S should only need 5269 (or whatever port you configure on the server for S2S). Even where the only port allowed both ways is 5269, the servers should be able to establish the necessary connection. If other ports are open, the servers will try using them in their responses. I have not found a configuration parameter in Openfire that allows you to lock the app down to only communicating on a single port (e.g. the way you can with ISC Bind).
@S2S: Definitely check to make sure both servers either have a publicly signed cert, or that any self-signed certs have been imported into the other server's truststore. Note the option to allow self-signed certs can be enabled, but this may not be an option on non-Openfire servers (you guessed it, like Lync). For those you'll need to import any self-signed certs into the partner server. My team has had problems with S2S between Openfire versions up to and including 3.9.3 and MS Lync due to an issue with how Openfire handles dialback. I am in the process of testing whether this is fixed in the latest Openfire 3.10.0 Alpha nightly builds. My initial results on trial connections between two Openfire servers using the nightly build are that it is now in fact fixed. I'm currently waiting for some network changes that will allow me to test between Openfire nightly and Lync 2013 (thanks to enterprise change control).