Does this site look plain?

This site uses advanced css techniques

Steve Friedl's Unixwiz.net Tech Tips

Setting up inverse DNS for SBC/Pacific*Bell Internet

• Home
• Contact
• About
• TechTips
• Tools&Source
• Evo Payroll
• CmdLetters
• Research
• AT&T 3B2
• Advisories
• News/Pubs
• Literacy
• Calif.Voting
• Personal
• Tech Blog
• Evo Blog

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

Unlike many internet service providers, SBC / Pacific*Bell Internet (PBI) will host inverse DNS (the in-addr.arpa 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:

• This effort is not endorsed or approved by PBI, and I don't speak for them.
• You must have access to your own DNS server to make this work: I don't believe PBI will actually maintain your zone file for you.
• You really do need to understand how DNS works -- this is not a tutorial in nameservers (sorry).
• These instructions are for BIND 9 under UNIX. Your mileage may vary.
• I've not actually had to do any of this since the Pac*Bell-to-SBC transition, so these instructions may be out of date. I welcome updates with more recent experiences.

Introduction

Normal DNS queries work by sending the domain name ("www.unixwiz.net") 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 in-addr.arpa. 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 63.203.17.35, the inverse query would for 35.17.203.63.in-addr.arpa.. 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 63.203.17.32 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 adsl-63-203-17-X.dsl.lsan03.pacbell.net., 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     ns1.pbi.net. dns.pbi.net. ( SOA STUFF )

        IN      NS      ns1.pbi.net.
        IN      NS      ns2.pbi.net.

1	IN	PTR	 adsl-63-203-17-1.dsl.lsan03.pacbell.net.
2	IN	PTR	 adsl-63-203-17-2.dsl.lsan03.pacbell.net.

;-----------------------------------------------------------------
; unixwiz.net delegated

32	IN	NS	a.unixwiz.net.
	IN	NS	ns1.pbi.net.
	IN	NS	ns2.pbi.net.

33	IN	CNAME	33.32.17.203.63.in-addr.arpa.
34	IN	CNAME	34.32.17.203.63.in-addr.arpa.
35	IN	CNAME	35.32.17.203.63.in-addr.arpa.
36	IN	CNAME	36.32.17.203.63.in-addr.arpa.
37	IN	CNAME	37.32.17.203.63.in-addr.arpa.
38	IN	CNAME	38.32.17.203.63.in-addr.arpa.
39	IN	CNAME	39.32.17.203.63.in-addr.arpa.

; back to the normal business

40	IN	PTR	adsl-63-203-17-40.dsl.lsan03.pacbell.net.
...
254	IN	PTR	adsl-63-203-17-254.dsl.lsan03.pacbell.net.

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 ns1.pbi.net. and ns2.pbi.net. 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.63.203.17.32
;
$TTL    86400

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

@               IN      NS      ns1.pbi.net.
                IN      NS      ns2.pbi.net.
                IN      NS      a.unixwiz.net.

33              IN      PTR     dsl-gw.unixwiz.net.
34              IN      PTR     host-34.unixwiz.net.
35              IN      PTR     www.unixwiz.net.
36              IN      PTR     host-36.unixwiz.net.
37              IN      PTR     host-37.unixwiz.net.
38              IN      PTR     c.unixwiz.net.
39		IN	PTR	bcast.unixwiz.net.

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

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 "32.17.203.63.in-addr.arpa" {
        type master;
        file "db.63.203.17.32";
};

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 206.13.28.11 and 206.13.29.11.

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 sbis.sbc.com with this information:

• the address range you wish to maintain yourself
• the IP address of the DNS server
• some way of proving that you're allowed to do this

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.