Configuring DNS in AIX

— ny_wk

Configuring DNS in AIX means setting up the BIND named daemon to answer name lookups so your IBM Power LPARs can resolve hostnames to IP addresses (and back) without depending on an external resolver. This guide walks through building a primary (master) DNS server on AIX from scratch: the /etc/named.conf file, forward and reverse zone files, starting the daemon with the SRC, and verifying everything with dig.

AIX ships BIND as part of the base operating system, so no extra package install is normally required. The steps below produce a small authoritative server for the example domain my.example.com on the 192.168.1.0/24 network, and they correct several common mistakes that float around older AIX DNS notes.

The problem: AIX name resolution without a DNS server

Out of the box an AIX LPAR resolves names using /etc/hosts (and whatever /etc/resolv.conf points to). That is fine for one or two machines, but as soon as you have several LPARs, NIM clients, or application tiers that talk to each other by name, maintaining a flat hosts file on every box becomes error-prone. A local DNS server gives you one authoritative place for forward (name to IP) and reverse (IP to name) lookups.

The solution is to run the BIND name server, whose daemon on AIX is named, managed by the System Resource Controller (SRC). You define your zones in /etc/named.conf, write the records in zone files under /var/named, start the daemon, and point clients at it.

What you need before you start

• Root access on the AIX LPAR that will become the DNS server.
• A static IP for the server (this example uses 192.168.1.1).
• A chosen domain name (here my.example.com).
• The BIND fileset installed (it is part of bos.net.tcp.client / bos.net.tcp.server on most AIX levels). Confirm named exists with which named or lssrc -s named.

Step-by-step: configure the DNS server in AIX

Follow these steps in order. Every command is run as root. Substitute your own domain, network, and IP addresses for the example values.

1. Set a fully qualified hostname. A name server should identify itself by its FQDN. Set it for the running session and make it persistent across reboots:
   • Temporary: hostname lpar1.my.example.com
   • Persistent: chdev -l inet0 -a hostname=lpar1.my.example.com
2. Create the zone-file directory. BIND on AIX expects its zone files in a working directory; /var/named is the conventional choice:
   mkdir -p /var/named
3. Create /etc/named.conf. This is the master configuration file. It lists the working directory plus one stanza per zone — a forward zone, a reverse zone for your subnet, a reverse zone for loopback, and the root hints. Open it with vi /etc/named.conf and enter:
   options {
    directory "/var/named";
};
zone "my.example.com" {
    type master;
    file "named.my.example.com";
};
zone "1.168.192.in-addr.arpa" {
    type master;
    file "named.192.168.1";
};
zone "0.0.127.in-addr.arpa" {
    type master;
    file "named.local";
};
zone "." {
    type hint;
    file "named.ca";
};
   Use straight ASCII quotes ("), not curly typographic quotes — BIND will refuse to parse smart quotes. The reverse-zone name 1.168.192.in-addr.arpa is the network 192.168.1 written backwards, which is how PTR lookups work.
4. Create the forward zone file /var/named/named.my.example.com. This holds the SOA, the NS record, and the A (address) records that map names to IPs:
   $TTL 86400
@ IN SOA lpar1.my.example.com. root.my.example.com. (
    2009010901 ; Serial
    3600 ; Refresh
    300 ; Retry
    360000 ; Expire
    86400 ) ; Minimum / Negative-cache TTL
@ IN NS lpar1.my.example.com.
lpar1 IN A 192.168.1.1
lpar2 IN A 192.168.1.2
lpar3 IN A 192.168.1.3
   The trailing dot on fully qualified names is mandatory: lpar1.my.example.com. is absolute, while lpar1 without a dot is treated as relative to the zone origin.
5. Create the reverse (PTR) zone file /var/named/named.192.168.1. Note the filename must match the file directive you set in step 3. PTR records map the last octet of each address back to a hostname:
   $TTL 86400
@ IN SOA lpar1.my.example.com. root.my.example.com. (
    2009010901 ; Serial
    3600 ; Refresh
    300 ; Retry
    360000 ; Expire
    86400 ) ; Minimum
@ IN NS lpar1.my.example.com.
1 IN PTR lpar1.my.example.com.
2 IN PTR lpar2.my.example.com.
3 IN PTR lpar3.my.example.com.
6. Create the loopback reverse file /var/named/named.local so reverse lookups of 127.0.0.1 resolve cleanly:
   $TTL 86400
@ IN SOA lpar1.my.example.com. root.my.example.com. (
    2009010901 3600 300 360000 86400 )
@ IN NS lpar1.my.example.com.
1 IN PTR localhost.
7. Create the root-hints (cache) file /var/named/named.ca. For lookups outside your own zones, the server needs to know where to start. On an Internet-connected server, populate this with the real root servers (dig . NS > /var/named/named.ca, or fetch https://www.internic.net/domain/named.root). For an isolated lab that simply forwards everything upstream, point at your gateway resolver instead:
   . IN NS ns.example.com.
ns.example.com. IN A 192.168.0.1
   For a closed network it is usually cleaner to add a forwarders { 192.168.0.1; }; line inside the options {} block in named.conf rather than faking root hints.
8. Start the named daemon and confirm it is active. AIX uses the System Resource Controller, not systemctl:
   startsrc -s named
lssrc -s named
   The status should show active. To start named automatically at every boot, make sure the entry in /etc/rc.tcpip is uncommented (start /usr/sbin/named "$src_running").
9. Test resolution with dig. Query the server directly at localhost for a forward A record and for the reverse PTRs:
   dig @localhost lpar1.my.example.com A
dig @localhost -x 192.168.1.1
dig @localhost -x 127.0.0.1
   You can also write the reverse name out longhand: dig @localhost 1.1.168.192.in-addr.arpa PTR. In each case the data you want appears in the ANSWER SECTION; the AUTHORITY/ADDITIONAL sections are normal background detail and can be ignored.
10. Make the server a client of itself. Once the queries return correct answers, point the box at its own resolver by editing /etc/resolv.conf:
    domain my.example.com
nameserver 192.168.1.1
nameserver 192.168.1.2
    Add the same nameserver lines to every client LPAR that should use this DNS server. Names now resolve to IPs across your network.

Common pitfalls when configuring DNS in AIX

Most failed AIX BIND setups come down to a handful of recurring mistakes. The original procedure this guide is based on contained several of them, so they are worth calling out explicitly.

• Curly/smart quotes in named.conf or zone files. If you copy configuration from a word processor or web page, “ and ” sneak in. BIND only accepts straight quotes. Retype them in vi.
• The bogus TTL value 9999999. Older notes show 9999999 in front of every record. That is not a valid per-record TTL convention — use a sensible $TTL directive at the top of each zone (for example $TTL 86400 for one day) and let records inherit it.
• Zone filename does not match the file directive. If named.conf says file "named.192.168.1"; the file on disk must be exactly /var/named/named.192.168.1. A mismatched name (for example creating named.192.168.1.1 instead) makes the zone load fail silently.
• The f file typo. A stray character before file in the root-hint stanza is a syntax error. The directive is simply file "named.ca";.
• Missing trailing dots. An FQDN in a zone file without the final dot becomes relative and silently expands into the wrong name (for example lpar1.my.example.com turns into lpar1.my.example.com.my.example.com.).
• Forgetting to bump the SOA serial. Every time you edit a zone, increase the Serial (the YYYYMMDDnn convention is standard). Secondaries and caches ignore changes if the serial did not move.
• Using systemd commands. AIX is not Linux. There is no systemctl; use startsrc, stopsrc, refresh, and lssrc against the named subsystem.

SRC command quick reference

Verification: confirm the AIX DNS server is healthy

Do not assume the server works just because startsrc returned without an error. Verify in layers:

1. Syntax check before starting. If your AIX BIND level includes the BIND utilities, validate first: named-checkconf /etc/named.conf and named-checkzone my.example.com /var/named/named.my.example.com. A clean run prints OK.
2. Daemon is running. lssrc -s named shows active, and ps -ef | grep named lists the process.
3. Port 53 is listening. netstat -an | grep '\.53 ' should show the UDP and TCP listeners.
4. Forward lookup answers. dig @localhost lpar2.my.example.com A returns 192.168.1.2 in the ANSWER SECTION with status NOERROR.
5. Reverse lookup answers. dig @localhost -x 192.168.1.2 returns lpar2.my.example.com.
6. Resolution through resolv.conf. After updating /etc/resolv.conf, plain host lpar3 or nslookup lpar3 should resolve, proving the system is now using its own server.

If a query returns SERVFAIL or REFUSED, re-run named-checkzone on the relevant file, confirm the filename/SOA serial, and check the system log for the exact parse error. Almost every problem is a typo in a zone file, not a defect in BIND itself.

A note on BIND versions and the modern equivalent

The classic named.conf layout shown here works on long-standing AIX releases and on virtually any BIND deployment. On current systems you would typically run a more recent BIND (BIND 9.x), which adds views, DNSSEC, and stricter defaults. The configuration syntax is compatible, but two habits are worth adopting on modern installs: use a real, regularly updated root-hints file (or forwarders) instead of a hand-written stub, and prefer named-checkconf/named-checkzone for validation. For brand-new infrastructure many teams now reach for unbound (a caching resolver) or managed DNS, but for an authoritative AIX server inside a Power environment, BIND named as configured above remains the standard, supported choice.

Key Takeaways

• BIND named is the DNS server on AIX, managed by the SRC with startsrc/stopsrc/refresh/lssrc — never systemctl.
• /etc/named.conf defines the zones; the actual records live in zone files under /var/named, and each file name must exactly match its file directive.
• You need both forward (A) and reverse (PTR) zones, plus loopback and root hints, for complete, well-behaved resolution.
• Use straight quotes, real $TTL values, trailing dots on FQDNs, and bump the SOA serial on every edit — these typos cause most failures.
• Always verify with dig @localhost for both forward and reverse lookups, then point clients at the server via /etc/resolv.conf.

Frequently Asked Questions

How do I start and stop the DNS server on AIX?

AIX manages named through the System Resource Controller. Start it with startsrc -s named, stop it with stopsrc -s named, reload zone changes without a full restart using refresh -s named, and check its state with lssrc -s named. To survive reboots, ensure the named start line in /etc/rc.tcpip is uncommented.

Where are the AIX DNS configuration and zone files located?

The main configuration file is /etc/named.conf. The zone files (forward A records, reverse PTR records, loopback, and root hints) live in the directory named by the directory option in named.conf — conventionally /var/named. Client resolution settings are in /etc/resolv.conf, and the static name database fallback is /etc/hosts.

Why does my AIX DNS server return SERVFAIL or fail to load a zone?

The usual causes are a zone-file typo, a filename that does not match the file directive in named.conf, smart/curly quotes copied from a document, a missing trailing dot on an FQDN, or an unchanged SOA serial after an edit. Run named-checkconf and named-checkzone to pinpoint the exact line, fix it, then refresh -s named.

What is the difference between a forward and a reverse DNS zone?

A forward zone (for example my.example.com) holds A records that map a hostname to an IP address. A reverse zone (for example 1.168.192.in-addr.arpa) holds PTR records that map an IP address back to a hostname. Many services — mail, logging, and security tools — expect both to exist and to agree with each other.

For more hands-on AIX and Unix system administration walkthroughs, subscribe to @explorenystream on YouTube.