[Freeipa-devel] DNS improvements: Should we add some sanity checking?

[Simo Sorce]

On Mon, 2013-09-16 at 09:45 +0200, Petr Spacek wrote:
> On 16.9.2013 09:06, Martin Kosek wrote:
> > On 09/13/2013 06:17 PM, Simo Sorce wrote:
> >> On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote:
> >>> Hello list,
> >>>
> >>> Jan Pazdziora <jpazdziora at redhat.com> proposed that 'ipa dns*' commands should
> >>> do some sanity checking/waiting after the record is added to LDAP.
> >>>
> >>> I think that it could be valuable and I would like to get opinions from
> >>> freeipa-devel list.
> >>>
> >>>
> >>> === The problem ===
> >>> ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't
> >>> mean that the data are *immediately* resolvable via DNS protocol. Note that
> >>> data from LDAP are *asynchronously* read and processed by Named and the time
> >>> when records are available is not predictable.
> >>>
> >>> A mismatch between LDAP can be caused by some connection problem between DNS
> >>> and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS<->LDAP
> >>> synchronization code. (This is becomming more and more important if we
> >>> consider the whole DNSSEC effort and related re-factoring.)
> >>>
> >>> My experience is that users are very confused if the ipa dnsrecord-add command
> >>> says 'record added' but it is still not available via DNS. It is really hard
> >>> to debug when you see the problem first 10 times :-)
> >>>
> >>>
> >>> === The proposal ===
> >>> 1. Let FreeIPA framework to change DNS data in LDAP as we do now.
> >>> 2. After each change, do DNS queries for changed record and wait until the new
> >>> data are available.
> >>>
> >>> IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth)
> >>> and it would save a lot of headaches to users and support.
> >>>
> >>> This will naturally catch the case where named crashes after the change etc.
> >>>
> >>>
> >>> === Expected outcome ===
> >>> There will not be any failure like this:
> >>>
> >>> $ ipa-adtrust-install
> >>>
> >>> $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN
> >>> --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP
> >>> --forward-policy=only --ip-address=$AD_IP
> >>> 	  Zone name: dom123.example.com
> >>> 	  [...]
> >>>
> >>> $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password
> >>> 	Password for admin at DOM123.EXAMPLE.COM:
> >>> 	ipa: ERROR: Cannot find specified domain or server name
> >>>
> >>
> >> Would it make sense to change the code to use dynDNS update to add
> >> records ?
> >>
> >> Wouldn't that force named to be in sync ?
> >>
> >> Simo.
> >
> > Switching from LDAP modify operation to dynDNS update seems as a too big change
> > to me. If nothing else, it would not fly with our LDAP ACI/permission system
> > and ability to delegate DNS read/write rights to somebody else.
> 
> I can see pros and cons for both ways:
> 
> LDAP:
> + we have the code :-)
> + ACI magic
> - works only with bind-dyndb-ldap
> - can get out of sync (bugs, timeouts etc.)
> 
> Standard DNS updates:
> + can work with any DNS server
> + with AD integration, we could use existing AD DNS infrastructure: i.e. 
> manage DNS records for FreeIPA servers and host without deploying a new DNS 
> server and related 'politics'
> + bind-dyndb-ldap is not necessary (ouh, my work is useless now :-))
> - we don't have the code in FreeIPA framework
> - ACI magic is not available (in reality, it depends on the DNS server)
> - reading of current state could be more complex for user interface (On the 
> other hand, current user interface doesn't show real state of thing because 
> LDAP != DNS.)
> 

I forgot one thing that breaks, we cannot create new zones via dyndns,
so we'd still have a mixed set. But I was thinking about your pros too,
esp being able to use an AD DNS if necessary (evil but doable).

I do not want to insist, because I also agree with Martin, but we should
think about it.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York