[Freeipa-devel] DNS use cases

[Dmitri Pal]

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.

This is the main use IPA case and we should focus on it.

>
> An online service provider that maps subdomains from their clients to
> small number servers providing cutomized content.

I do not think it is the use case where IPA will be used. A stand alone
DNS is better for such use case.

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

IMO same as above.

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

How this is different from use case 1 with desktops?

What about cloud and VMs? I suspect that is also similar to use case 1
and this one.
So I would generalize it as IPA DNS as a primary name server for manged
and not managed VM/BM hosts (servers/desktops)
>
> 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
>

Ack.

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

IMO not a use case to worry about at least now.

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

Ack with the correction from Simo.

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


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/