#3210 [RFE] Separate master and forward DNS zones
Closed: Fixed None Opened 11 years ago by pspacek.

Now we are mixing zone types 'master' and 'forward' in the single thing (in IPA UI and in objectClass 'idnsZone').

Zone types recognized in BIND:
http://www.zytrax.com/books/dns/ch7/zone.html#type

Current situation leads to confusion for users because:

  • Behaviour is not well defined (in BIND it is possible to set forwarders for 'master' zones with different effect than for 'forward' zones)
  • BIND documentation is not applicable
  • Users are forced to create imaginary SOA record (which is never seen by client) even for 'forward' zones
  • It is possible to create subordinate records in 'forward' zone but these records are ignored

Proposal:

  • Use existing objectClass 'idnsZone' for master zones (no change).
  • Create a new objectClass 'idnsForwardZone'
    • mandatory single-value attribute idnsName (for RDN, same as in 'idnsZone')
    • mandatory multi-value attribute idnsForwarders (same as in 'idnsZone')
    • optional single-value attribute idnsForwardPolicy (same as in 'idnsZone')

Changing 3.2 priority

Moving my tickets back to free-to-take pool.

This is a blocker for #4149 (for reasons internal to BIND 9 and bind-dyndb-ldap).

Support on bind-dyndb-ldap side [#99)]]([https://fedorahosted.org/bind-dyndb-ldap/ticket/99|(ticket) is ready from version 3.0.

We just need UI which seems to be relatively easy:

  • Add "zone type" with selection "master" and "forward".
  • The "zone type" will change set of allowed attributes.
  • Other zone types (like "slave") can be added as necessary in the future so this is more flexible than current state.

Let us do the change in 4.0 then.

Upgrade procedure patches posted for review

DNS Forward Zones:

master:

  • 49068ad Separate master and forward DNS zones
  • 266015c Prevent commands to modify different type of a zone
  • 727f5f3 Create BASE zone class
  • 11c250a Tests DNS: forward zones

not closing, upgrade patches should follow

Since the semantics of the command ipa dnszone-add --forward changed, but the syntax stayed the same, we should issue a UserWarning any time user issues a command which would have different semantics in the older version of IPA.

This will help prevent confusion from users that were used to the old syntax / found old documentation.

We should also make sure that documentation of the both commands reflect the changes done (ipa help dnszone-add should contain relevant info).

Adding to list of tickets required for 4.0 release.

Upgrade part:

master:

  • c1f3fd6 Added upgrade step executed before schmema is upgraded
  • aa2ef07 Upgrade special master zones to forward zones

Reopening as Tomas had a valid request in comment:16 which should be addressed before release.

We should also replace this part of the DNS help with the correct use of dnsforwardzone-add/mod...:

 Forward all requests for the zone external.com to another nameserver using
 a "first" policy (it will send the queries to the selected forwarder and if
 not answered it will use global resolvers):
   ipa dnszone-add external.com
   ipa dnszone-mod external.com --forwarder=10.20.0.1 \\
                                --forward-policy=first

It seems that upgrade procedure is failing on current master, Martin Basti is investigating it.

master:

  • 33cf958 Add warning about semantic change for zones
  • d18eea4 Use documentation addresses in dns help
  • d22d971 Help for forward zones
  • 1c5fa1c Split dns docstring

master:

  • f8b6595 Restore privileges after forward zones update

Metadata Update from @pspacek:
- Issue assigned to mbasti
- Issue set to the milestone: FreeIPA 4.0 GA

7 years ago

Login to comment on this ticket.

Metadata