[Freeipa-devel] Structured DNS record API proposal - summary

Rob Crittenden rcritten at redhat.com
Thu Sep 22 12:42:22 UTC 2011


Martin Kosek wrote:
> On Wed, 2011-09-21 at 11:22 +0200, Martin Kosek wrote:
>> On Tue, 2011-09-20 at 11:22 -0500, Endi Sukma Dewata wrote:
>>> On 9/20/2011 6:15 AM, Martin Kosek wrote:
>>>>>> ACK.  Proposal looks like it will work fairly easily with the UI.
>>>>>> We'll have to make some chagnes due to the Add doing something
>>>>>> different based on the type, but that is the case anyway.
>>>>>
>>>>> Yes, I was thinking how can we integrate this new API to WebUI. AFAIK
>>>>> you use dnsrecord-add $ZONE $REC --a-rec=... --mx-rec=... for adding a
>>>>> new DNS record and dnsrecord-mod $ZONE $REC --mx-rec=... when for
>>>>> example the mx record is being modified. All MX values (even the
>>>>> unmodified ones) are passed to dnsrecord-mod.
>>>>>
>>>>> 1) I was wondering how the new dnsrecord-<rrtype>-add commands can be
>>>>> used. I suppose WebUI will know a list of DNS record types with these
>>>>> new structured commands and offer the user new window to add a record
>>>>> for these types instead of typing them directly to the text box as it is
>>>>> now.
>>>
>>> When adding a DNS record the user will specify the name and the type,
>>> then the UI will show a set of fields based on the selected record type.
>>>
>>> So instead of a generic 'data' field like below (click Add):
>>>
>>> http://edewata.fedorapeople.org/freeipa/install/ui/index.html#dns=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=ayoung.boston.devel.redhat.com
>>>
>>> it will be similar to Permissions (click Add):
>>>
>>> http://edewata.fedorapeople.org/freeipa/install/ui/index.html#rolebased=permission&ipaserver=rolebased&navigation=ipaserver
>>>
>>> The UI will use the type to pick the correct dnsrecord-<rrtype>-add
>>> command and each parameter in that command will have a corresponding
>>> field to enter the value.
>>
>> Yes, I think this will work fine. Would it make sense to create
>> dnsrecord-<rr-type>-add commands also for non-structured DNS records? I
>> mean for example for A, AAAA, PTR, CNAME, ... record, which have just
>> one simple value or let plain old dnsrecord-add --a-rec=... handle it?
>>
>>>
>>>>> 2) But my main concern here is how the modification of current DNS
>>>>> records should work. Say, we have 2 MX records for example.com. How can
>>>>> we modify one of it in a new structured interface?
>>>>>
>>>>> We would have to implement dnsrecord-mx-show method so that you can fill
>>>>> all the text areas (preference, mailserver). Question is how to refer
>>>>> the value we want to show since DNS records are multivalued. We could
>>>>> pass --dnsrecord="..." with DNS record value, e.g. "0 mx.example.com."
>>>>> and then use the same value for dnsrecord-mx-mod. The whole command
>>>>> sequence would look this way:
>>>>>
>>>>> dnsrecord-find example.com      -- get all DNS records for example.com
>>>>> dnsrecord-show example.com @    -- show DNS records directly in the zone
>>>>> NS: "ns.example.com"
>>>>> MX: "0 mx1.example.com."
>>>>> MX: "1 mx2.example.com."<<   user wants to modify this one ->   new window
>>>
>>> I think for each record value the primary keys are the zone name, record
>>> name, and the value itself. To simplify operations, we should use the
>>> value as a single string. For CLI, users can copy&  paste the value more
>>> easily.
>>
>> Agreed. As Adam Tkac suggested, we can simplify this with interactive
>> prompt so that user doesn't have to copy&paste, but just choose a record
>> to -show/-mod.
>>
>>>
>>> For UI it depends whether (1) we're going to keep the current edit page
>>> where all records with the same name are considered a single entry, or
>>> whether (2) we're going to edit each record value in a separate page.
>>> See ticket #1478.
>>>
>>> If we stay with (1), the link to the edit page consists of zone name and
>>> record name only. But if we pick (2) the link consists of zone name,
>>> record name, value, and type (which can be obtained from -find output).
>>
>> This is more of a UXD decision, server API will remain intact. I just
>> see 2 issues here:
>>
>> 1) If you let user edit multiple structured DNS records, you would have
>> to call dnsrecord-<rr-type>-show multiple times so that you can populate
>> all the fields. This can slow down things.
>>
>> 2) Some DNS records may be pretty large. MX record data is small, but
>> for example CERT records have an entire certificate stored in it.
>> Wouldn't there be a problem if we place the large DNS record in URL?
>>
>>>
>>>>> dnsrecord-mx-show example.com --dnsrecord="1 mx1.example.com."
>>>>> PREFERENCE: 1	<<   user modifies this to 0
>>>>> MAILSERVER: mx2.example.com.
>>>
>>> For consistency, the record value should be specified as an argument
>>> instead of an option (like in automount). So it will be like this:
>>>
>>> dnsrecord-mx-show "example.com" "@" "1 mx1.example.com."
>>> PREFERENCE: 1
>>> MAILSERVER: mx2.example.com
>>
>> This can be done.
>>
>>>
>>> If we stay with (1) the UI will have to call the dnsrecord-<rrtype>-show
>>> for each value to get the value of each fields. The UI will need to
>>> implement a new widget (or section) that can handle multiple fields
>>> which will be duplicated for each value.
>>
>> Ah, yes - as I wrote above. This would also take more time to process.
>>
>>>
>>> The edit page for (2) is much simpler since it only needs to handle a
>>> single type at a time. The output of the -show command will be used to
>>> populate each field.
>>>
>>>>> dnsrecord-mx-mod example.com --dnsrecord="1 mx1.example.com." --preference=0
>>>
>>> When updating the value, option (1) is a bit more complicated because
>>> the UI will have to find the dirty record and then find the dirty field.
>>> Option (2) is simpler because it will only need to find the dirty field,
>>> but both will execute the following command:
>>>
>>> dnsrecord-mx-mod "example.com" "@" "1 mx1.example.com." --preference=0
>>>
>>> I think option (2) is more clear to users because we only have to
>>> introduce 2 concepts: zone and record (which is the individual value).
>>> With option (1) we will have to explain the underlying LDAP entry that
>>> will be deleted automatically when the last record value is deleted.
>>>
>>
>> When I look at it, option (2) looks better for our case.
>>
>> Martin
>
> I think this entire discussion became too academic. I would like to make
> it more down to earth :-) Adam proposed new complex attributes, IMHO it
> should be discussed separately from this API proposal. I gave it some
> thought and I just don't see the benefits that it would bring to DNS.
> Personally, I would like to continue with API that was proposed so far.
>
> Summary of the steps for new DNS types:
>
> 1) New API shall be implemented only for non-DNSSEC resource record (RR)
> types that are supported by bind-dyndb-ldap.
> DNSSEC RR types to be left unimplemented: DS, KEY, NSEC, RRSIG, SIG
> Unsupported RR types to be removed at all: APL, DHCID, DLV, DNSKEY, HIP,
> IPSECKEY, NSEC3, NSEC3PARAM, RP, TA, TKEY, TSIG
> In future, DNSSEC attributes should be generated automatically. But let
> us leave this discussion to the future.
>
>
> 2) -add commands shall be implemented for structured RR types:
>
>> ipa dnsrecord-afsdb-add --subtype=INT --hostname=STR
>> ipa dnsrecord-cert-add --type=ENUM --tag=INT --algorithm=ENUM --certificate=STR
>> ipa dnsrecord-kx-add --preference=INT --exchanger=STR
>> ipa dnsrecord-loc-add --lat-deg=INT --lat-min=INT --lat-sec=FLOAT --lat-dir=ENUM --lon-deg=INT --lon-min=INT --lon-sec=FLOAT --lon-dir=ENUM --alt=FLOAT --h-precision=FLOAT --v-precision=FLOAT
>> ipa dnsrecord-mx-add --priority=INT --mailserver=STR
>> ipa dnsrecord-naptr-add --order=INT --preference=INT --flag=ENUM --service=STR --regexp=STR --replacement=STR
>> ipa dnsrecord-srv-add --priority=INT --weight=INT --port=INT --target=STR
>> ipa dnsrecord-sshfp-add --algorithm=ENUM --type=ENUM --fingerprint=STR
>
> OPEN QUESTION: should we implement these new commands also for discrete
> DNS records types to be consistent? I mean for example A, AAAA, CNAME,
> PTR, ... They would look like
>
>> ipa dnsrecord-aaaa-add --ip-address=IPAddress
>
> BENEFITS of this approach (command per RR type):
> - use can get all help for RR type by simply typing "ipa help
> dnsrecord-mx-add"
> - we would be able to implement helper methods consistently on one
> place, for example:
> dnsrecord-aaaa-add --from-mac=00:1D:BA:06:37:64
>
>
> 3) -show commands shall be implemented for structured RR types:
> These commands will let UI populate the (text) fields, ENUMs, etc. They
> would look this way
>
>> ipa dnsrecord-mx-show ZONE NAME VALUE
>
> For example:
>> dnsrecord-mx-show "example.com" "@" "1 mx1.example.com."
>
> OPEN QUESTION: should we implement also -find methods
> (dnsrecord-mx-find) so that UI can for example populate text fields for
> all (MX) records for one DNS name?
>
>
> 4) -mod commands shall be implemented for structured RR types:
> API would be almost the same as with -add commands. User (WebUI) would
> just have to identify which record should be modified:
> a) by copy&passing the raw DNS value directly to the command:
>
>> dnsrecord-mx-mod example.com @ "1 mx1.example.com." --preference=0
>
> b) (CLI only) by using an interactive wizard that would let user choose
> the modified record like this way:
>
>> dnsrecord-mx-mod example.com @ --preference=0
> Which record would you like to change?
> [1] 1 mx1.example.com.
> [2] 10 mx2.example.com.
> DNS record:<user enters the number>
>
> I have already implemented an interactive wizard like this for
> dnsrecord-del and it works fine.
>
> Martin

This is sensible to me, particularly expanding to all RR types. I find 
creating DNS entries now not at all straightforward. This will help 
immensely despite exploding the number of commands. I think it is a 
worthy trade-off.

rob




More information about the Freeipa-devel mailing list