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

[Endi Sukma Dewata]

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*]

> 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.

> 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.

-- 
Endi S. Dewata