What this says to me is that we should put less effort into the records page as seen below the zone. and put more effort into a page that shows the records associated with a specific host.

So: For the page dns->zone->records: we'll use a similar view as that shown by search results, a modal "add", delete is done off the list, and edit is done as a details type page, one per record. This is, I think, the easiest result.

We will also want a way to link from the host tab to the DNS records search result, with an option to create a DNS entry if there is not yet one. The option should create an A ( and eventually AAAA ) record for the host.

Of course, right now we don't seem to track IP addresses for hosts, so the host -> A record mapping is going to be tricky.

I'm guessing that, long term, we will need to be able to couple the host to the A record, and provide a DHCP tie in as well.

We'll probably want to track a set of MAC addresses for the host (one per NIC that can potentially DHCP), IPv4 address (again, per NIC) and IPv6 addresses.

This is, of course, not going to happen for January.

In the interim, there should be a link from host to DNS record fetched from ipa dns-show-rr where zone is the Hostname minus the value up to the first '.' and resource is the the hostname up to the first '.'

On 10/13/2010 01:58 PM, Dmitri Pal wrote:
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
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


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

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

Reply via email to