[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