Does this site look plain?

This site uses advanced css techniques

This Tech Tip is mostly obsolete; SBC has an entirely different procedure for managing DNS, but we're leaving this behind for posterity.

[SBC Logo]

Unlike many internet service providers, SBC / Pacific*Bell Internet (PBI) will host inverse DNS (the zone) for subnets smaller than class C. They currently host a /27 and even a /29 for me, and I've been asked about this often enough to prompt these instructions.

NOTE - if you're just looking for which Pac*Bell nameserver you should use in your internet setup, and aren't looking for inverse DNS, then see the section on resolving nameservers at the bottom of this page.

A few key notes:


Normal DNS queries work by sending the domain name ("") to a DNS server, and we request an "A" (Address) record that turns the name into an IP address. This is extremely common and relatively straightforward to understand. But there is also a procedure for turning an IP address back into a name, though the procedure is quite peculiar. The IP address is reversed and turned into a domain name in the zone, then a query is made for a "PTR" record that should produce a domain name. This is used by programs such as ping that take the responding IP address and mapping it back into a name.

For instance, if my web server is at, the inverse query would for This seems terribly strange, but it's one of those things that really makes sense if you give some thought to how it all has to work. The bigger picture of inverse DNS is beyond the scope of this document.

If you own the entire class C address block, setting up the zone file for inverse is straightforward, but delegating a sub-class C is a bit more work. This involves multiple zone files and coordination with the master domain owner (in this case, Pac*Bell Internet).

My range at home is through .39, but it's not possible to directly delegate a part of a range -- the entire last "dot" is all in the same zone. But a clever solution of "Classless IN-ADDR.ARPA Delegation" (described in RFC 2317) that allows this to work is to create yet another zone to delegate, and this is done by Pac*Bell by naming the zone the base address of the range. The last octet being queried is added to that.

The main PBI zone file for the class C block I'm in contains mostly PTR records of the form, where "X" is the lower octet of the IP address. This is the usual format. But for the few addresses they are delegating to me

; db.63.203.17
@       IN      SOA ( SOA STUFF )

        IN      NS
        IN      NS


; delegated

32	IN	NS


; back to the normal business

254	IN	PTR

It turns out that the first IP address of my range is now its own zone, and the individual PTR elements are aliases to addresses in that zone. The zone file for the little subnet is maintained by me on my own servers, and I get to manage what the final PTR records are. This is a straightforward process.

Your local zone file

Your zone file should be a regular text file containing a full, authoritative DNS zone, though it will necessarily be fairly small. It requires an SOA record, a handful of NS records, plus a PTR record for each address in your range. The NS records must contain and because these are the primary DNS servers as pointed to by the Internic, and you can include your own server name as well if you like.

Leaving out the details of the SOA record -- you should know how to do this already -- a BIND 9 zone file for a /29 network could look like:

; db.
$TTL    86400

@       IN      SOA (
                        127     ; serial
                        10800   ; Refresh       3 hours
                        3600    ; Retry         1 hour
                        604800  ; Expire        1 week
                        86400 ) ; Minimum       1 day

@               IN      NS
                IN      NS
                IN      NS

33              IN      PTR
34              IN      PTR
35              IN      PTR
36              IN      PTR
37              IN      PTR
38              IN      PTR
39		IN	PTR

In my case, I name the file for the IP range: db.

The BIND zone directive

Now that the zone file is in place, the named.conf file must be told about the zone. This is a simple "master" directive that looks like:

zone "" {
        type master;
        file "db.";

After reloading my nameserver, it's now live for this zone. If you use ACLs to limit access to zone transfers -- you should -- be sure to permit the two PBI nameservers to contact yours via TCP port 53. Their IP addresses are and

Remember that the named.conf file is very sensitive to precise placement of semicolons!

Contacting the PBI DNS folks

The Pacific*Bell Internet DNS department is very much on the ball, and they have operated entirely by email with me. Once you have finished setting up your When you're ready to have them slave your zone, send an email to dnsadmin at with this information:

For the latter, a source IP address from within the block in question may be sufficient, but I don't know for sure what rules they have. I also typically include the ARIN listing for my block as well.

They typically respond within a day by slaving your zone and making it live for all to see. Once they have done this, as long as you update your SOA serial number, changes on your end will be automatically reflected on their public DNS servers without their direct involvement. It's been a very smooth process.

Pac*Bell Resolving Nameservers

Though not really related to setting up inverse DNS, enough people find this page via Google searches looking for Pac*Bell's resolving nameservers that I'll include them here.

This list is current as far as I know, as of Feb 2003. It's in roughly North to South order.

Location IP Address Nameserver name
Reno, NV
San Francisco
Santa Clara
San Luis Obispo
Los Angeles
San Diego