DNS Use cases in FreeIPA

The below is my notes on how DNS is used. This document is neither accurate nor authoritative, just meandering. You’ve been warned.

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 activities 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 records 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 only 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 approach to DNS. For an ISP, each customer is likely to have a Domain name and will need certain basic 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, the sign a record sets.

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

Here is the full list of Record ttypes supported in IPA, including my notes:

The ipa add dns-rr command takes the options:


Of these fields, Zone will be pre-populated with the Zone from the details page.

resource will be a string in one of the DNS style formats, but for our purposes can be freeform text.

This is the list of record types supported by IPA:

‘A’, ‘AAAA’, ‘A6’, ‘AFSDB’, ‘CERT’, ‘CNAME’, ‘DNAME’,
‘DS’, ‘HINFO’, ‘KEY’, ‘KX’, ‘LOC’, ‘MD’, ‘MINFO’, ‘MX’,
‘NAPTR’, ‘NS’, ‘NSEC’, ‘NXT’, ‘PTR’, ‘RRSIG’, ‘SSHFP’,
‘SRV’, ‘TXT’,

We are currently updating the DNS plugin to use the same baseldap functionality that the other plugins do.  Once that is done, the commands will change.  I’ll post an update once that gets committed.

6 thoughts on “DNS Use cases in FreeIPA

  1. hello friends :), nice article. I just want to ask, do you know where the ipa-server save the dns record files? I mean like ‘A’ record and others. thanks.

  2. Hi there,

    I’ve started hacking on FreeIPA. You seem like the DNS guy to ask. I was looking into using the DNS features, however the current DNS setup that I’ll need to replicate contains multiple BIND views. This is because certain servers (such as HTTP, cobbler, mail, or whatever) appear to have different IP addresses to their clients, depending on what zone they are in.

    For example: a client in the network sees server ‘foo2’ as however, a different client in sees server ‘foo2’ as having ip

    Any suggestions would be appreciated!


  3. The same DNS rules apply as have always: nothing changes just because you are using FreeIPA. However, it would recommend that you think about using Fully Qualified domain names and non-floating/routable IP addresses for services like mail that really should not be changing.

    If you are using NAT due to running out of IP address issues, you might consider using IPV6. Yes, a strange suggestion, I realize.

    You can always have multiple DNS subdomains for each of your subnets (as you call zones are really subnets) and a singel Host can map to multiple DNS entries. So you could do mail.onesevetwo.example.com and mail.tententen.example.com as two different A records both pointing at the same mail server.

    If you are going to insist on them having the same fully qualified domain names but different zones, you might want to think why that is. Is it for geographical dispersion? Then they really are different hosts, and you probably should treat them as such. If you are just looking to optimize “always go to the closest service” and you are trying to share host certificates, you are going to have trouble with the host certificates.

    This is a great question, and I suspect others in the FreeIPA community both have this question and have answered this question. If you can’t find where someone asked it in the public mailing list, you should ask it there.


  4. Hi I need help to find the where the DNS records are save
    dn: idnsname=client1,idnsname=example.com,cn=dns,dc=example,dc=com
    idnsname: client1
    aaaarecord: fc00::1
    objectclass: top
    objectclass: idnsrecord

    cuz I’ll manually input DNS records for Pc’s in my home

  5. You should not be directly creating DNS records by Hand. Use the ipa CLI or CURL to have the IPA server do them for you. This is a general rule on IPA. Just like you don’t do direct SQL to modify a SQL-based application, as it bypasses the business logic. In IPA, the data is stored in LDAP, but the logic is in Python

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.