[Freeipa-devel] Structured DNS record API proposal - summary
Adam Young
ayoung at redhat.com
Fri Sep 23 02:05:17 UTC 2011
On 09/22/2011 08:31 PM, Endi Sukma Dewata wrote:
> On 9/22/2011 7:24 AM, Martin Kosek wrote:
>>> 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?
>
> This is how the DNS record list page could be redesigned:
> http://edewata.fedorapeople.org/images/dns-record-list-page.png
>
> It should resemble what you see in the zone file. The content can be
> obtained with a single dnsresource-find operation.
>
> If you click one of the data, it would open a dialog box for that
> particular record type. We will use the raw data as a primary key to
> execute the dnsresource-<rrtype>-show command. Each attribute in this
> record type will be displayed in separate fields:
> http://edewata.fedorapeople.org/images/dns-record-edit-dialog.png
>
> When you save it will call dnsresource-<rrtype>-mod and put the values
> in separate parameters. It will still use the original raw data as
> primary key, but we don't need to encode the new values into raw data.
>
> If we use a dialog box like this none of the attributes need to be
> added into the URL. It will be passed internally via variables. If we
> use a separate edit page (with a unique URL for each record), we might
> need to specify the entire raw data in the URL, but maybe we can find
> a workaround for CERT record. I'd prefer to use a dialog box because
> it can be used for both add and modify.
>
>> 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
>
> If we have this for all record types the UI can use a generic code to
> figure out which command to use. Everything will be in this pattern:
> dnsrecord-<rrtype>-add/mod/del <primary keys> [parameters*]
We won't have it for all types, so we will need a map. Most will use
the old API, and a few will use the pattern above
>
>> 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?
>
> Depending on the UI design, it might not be needed. But it won't hurt
> to have one in case the UI changes, for example suppose we want to
> have separate tabs for each record type.
Find can return the original Data, and probably should. We only need
the individual fields on edit, maybe on show.
>
>> 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
>
> The Web UI will use the JSON-RPC version of this command. As discussed
> already, the non-interactive mode for CLI will be useful for writing
> scripts or other applications that will invoke the CLI/API.
>
> Being able to specify the attributes in separate parameters means that
> the client doesn't have to figure out how to encode the attributes
> into a single raw data. They will be encoded consistently by the server.
>
>> 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>
>
> The interactive mode will be useful for people who have to use
> text-based terminal.
>
More information about the Freeipa-devel
mailing list