[Freeipa-devel] ipa-replica-prepare requests reverse zone on RHEL

[Petr Vobornik]

On 08/20/2015 03:19 PM, Simo Sorce wrote:
> On Thu, 2015-08-20 at 15:11 +0200, Petr Vobornik wrote:
>> On 08/20/2015 02:46 PM, Martin Basti wrote:
>>>
>>>
>>> On 08/20/2015 02:40 PM, Oleg Fayans wrote:
>>>> Done. https://fedorahosted.org/freeipa/ticket/5240
>>>>
>>>> The initial question however is still unsolved: why does
>>>> ipa-replica-prepare behaves differently on fedora and rhel? I thought,
>>>> rhel host had more than one reverse zone, but it's not the case.
>
> Not sure why the difference but you can pass --no-host-dns to
> ipa-replica-install, it should skip the reverse zone check.
> We may want to add a ticket to make the reverse check just a warning,
> installation should not fail, but the default is to stop in unattended
> mode unfortunately.
>
>>> Can you try fedora on the same machine?
>>
>> Are you sure that both systems has the same configuration. E.g. one
>> could have only IPv4 but the other also IPv6?
>>
>>>>
>>>>
>>>> On 08/20/2015 01:43 PM, Martin Basti wrote:
>>>>> It could be, please file a bug.
>>>>>
>>>>> On 08/20/2015 12:51 PM, Oleg Fayans wrote:
>>>>>> Hi Martin,
>>>>>>
>>>>>> I guess, I know where is the problem. During replica-install the
>>>>>> replica tries to resolve it's own ip to a hostname to check whether
>>>>>> the dns is configured correctly. And fails, since we specified
>>>>>> --no-reverse during the replica preparation on master.
>>>>>> This looks like a bug to me.
>>
>> Why is that a bug? Where should ipa-replica-prepare put a SRV record if
>> no reverse zone is created?
>
> SRV records are not stored in the reverse zone, we should work just fine
> w/o a reverse zone.

Sorry, I meant PTR

>
>> I.e. if I do not want to add them by ipa-replica-prepare e.g. because
>> they are not managed in IPA then they have to be added to DNS
>> server(whatever server it is) by other means.
>
> We *should* be able to work fine w/o reverse zones or with reverse zones
> that point to bogus names.
> I think this is something we SHOULD test because it is a normal network
> condition in some organizations (because they can't control reverse).
> If something fails if reverse is wrong/missing we need to fix it,
> because relying on reverse resolution is broken (vs security) anyway and
> we should not.
>
> Simo.
>

-- 
Petr Vobornik