[Freeipa-devel] DNS use cases

[Adam Young]

Webmin is probably the oldest web based administrative platform.  Here 
is the Webmin documentation for BIND configuration.

http://doxfer.webmin.com/Webmin/BINDDNSServer


Some Highlights:

Creating a zone is pretty close to our concept, but with out the 
"Minimum info to create an entity" approach.

Creating a new Record is done with a new page, which for us would map to 
a modal.

When creating an A reocrd, there is an option to update the reverse 
record.  When updating a reverse record, it has a link to "update forward"

Second "Appy changes" pushes out all changes in bulk.  This then tells 
the BIND server to reread its config.  Doesn't map to our BIND 
implementation approach.

Records are not listed by default.  If you want to list the records, you 
have to sleelct the record type to show, or list all.


Other notable features:
Slave zone support
Partial Reverse Resolution.
Module Access Control:  allowing delegation of who can manage a zone.






On 10/12/2010 05:44 PM, Adam Young wrote:
> Here is what I have so far.  Sorry so long.  I'll work to get this 
> down to a more usable size, but would like feedback from any brave 
> soul willing to read through this wall of text.
>
> DNS administration is like the story of the blindmen and the 
> elephant.  Many people find that do a significant amount of DNS 
> administration only perform a subset of activites that map to their 
> companies business use of DNS.  Usage patterns include:
>
> A Large organization that provides a hostname for each users desktop 
> system.
>
> An online service provider that maps subdomains from their clients to 
> small number servers providing cutomized content.
>
> A ISP that hosts a large number of domains managed by the ISPs 
> clients, each on a virtual server that runs on a smaller number of 
> physical servers
>
> The clients of that ISP that need to create subdomains for specific 
> uses (CMS, web services etc).
>
> Software development shops that create subdomains for a small subset 
> of users who need to routinely create and destroy large numbers of 
> host entries.
>
> Typically, the usage falls into a small number of use cases:
>
> 1.  View and edit all of the records associated with a single host
> 2.  Create or edit a Zone based on a template or simple business rules
>
> Of the record types we handle, it makes sense to look at their 
> expected cardinality:
>
> A:  Typically, an A Record is canonical, not just for a public name, 
> but for man y CNAME recordfs pointing to that host.  It hast the split 
> identity of being the name that everyone uses to refer to some 
> resources, but also acts as an insulation layer between a large number 
> of CNAME record alias and a IPAddress that may change over time.
>
> CNAME:  Often these will refer to A records not even in the same 
> domain.  While the recommended usage states that a CNAMe should onluy 
> point to an A Record, in practice people can point one CNAME to 
> another CNAME record.  This usage is common when the first CNAME is 
> managed by one organization, and the second is managed by the ISP for 
> the first.
>
> SRV Records are rare, but require much more information than a A, 
> AAAA, CNAME, PTR etx record.  Like a CNAME or PTR, part of the SRC 
> record is a pointer to another host, and again, this should be a 
> Canonical target (A Record).
>
> It probably makes sense for us to force  A records to be HOST entries, 
> and to use those to populate the values for CNAME, SRC, PTR, SRV, etc 
> records.
>
> Certain large organizations are going to take a Zone based apporoach 
> to DNS.  FOr an ISP, each customer is likely to have a Domain name and 
> will need certain basica records.  At a minimum, they need an A or 
> CNAME record for the main host that they manage, even if this host is 
> shared buy other users.  Management of those Zones may be delegated to 
> the customers.  They are also likely to want MX record for their 
> domain.  This is likely to point to a centralized mail server for all 
> customers, where the mail will be sorted based on spam filtering 
> before delivery.  Again, it should point to an A record.  The RFC is 
> pretty clear on this point, so it is unclear whether people actually 
> have MX records which refer to CNAME records.
>
> PTR records typically are used for Reverse DNS lookups.  As such, DNS 
> should return only one record for a given hostname, although different 
> hostnames may all map to the same IP address.  It may not make sense 
> to force this onto an IPA Host object, as it is likely  that the end 
> user will want to move the IP address from one host to another, and 
> have all of the PTR records remain valid.   However, without forcing 
> it onto a host object, we have no way to say "show me all of the 
> hostnames that map to this IP address."
>
>
> Of the many forms of Key and certificate records, none of them seem to 
> point to other hosts, but are instead associated with a zone.  For 
> example, DNSSEC uses the Key record.  It is requested based on a 
> Hostname, and returns a key.  The IPSEC record is an exception, but we 
> do not currently support that record type.
>
>
> It is unlikely that we will need explicit records for NSEC* records, 
> as they basically say "The host you requested does not exist."  Since 
> DNS provides a Canonical answer about existence, denying the existence 
> of a host that does exist tends to break things.  Instead, I suspect 
> that these records are autogenerated based on the set of hostnames 
> that we *do* provide answers for.
>
> SIG records do not refer to hosts.  RRSIG records, which we support 
> use this format.  Instead, they sign a record set, or collection of 
> recrods of type  RR.  We don't seem to support type RR records, which 
> leaves me a little confused.  an RR record does have a hostname in it.
>
>
> SOA records are 1-to-1 with a zone.  As such, the CLI methods dns-add, 
> dns-mod etc modify the SOA for a given zone.  The MNAME is a server 
> that Manges the records.  In an ideal world, this would be a host in 
> IPA, so we can see all the  zones managed by a given DNS server.
>
>
> Really, there are two use cases for creating a zone:
>
> 1.  I want the IPA server to manage the zone.  it will be the MNAME 
> field for the DNS record.
>
> 2.   I want IPA to act as the caching server for the zone, which is 
> managed by a remote server.
>
> The two use cases are mutually exclusive.  It seems that really, only 
> the first makes sense.  The second case is really a degenerate case of 
> "act as a caching DNS server for remote server X"  where all 
> unresolved queries get forwarded to server X, and the results cached 
> for future use.
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel