Class-less Reverse DNS

English Network/Internet
#1

Hello, I’m new to the forum, intermediate with Linux.

We have set up a DNS on SuSe 11.1 to provide rDNS services. We have a subclass-c address space and we’re told by our ISP (AT&T) that for delegation to pass from them to us we must configure the DNS server as a Class-Less server per RFC-2317.

AT&T said the following:

You have set up the IP block wrong. It is currently set up as:

> set type=any
> cc.bb.aa.in-addr.arpa.
Server: aa.bb.cc.231
Address: aa.bb.cc.231#53

cc.bb.aa.in-addr.arpa
origin = ns1.ourdomain.com
mail addr = root.ns1.ourdomain.com
serial = 2009061500
refresh = 3600
retry = 600
expire = 604800
minimum = 86400
cc.bb.aa.in-addr.arpa nameserver = 231.cc.bb.aa.in-addr.arpa.
>

Because you were not assigned the full c-class, it needs to be

224/28.cc.bb.aa.in-addr.arpa.
origin = ns1.ourdomain.com
mail addr = root.ns1.ourdomain.com
serial = 2009061500
refresh = 3600
retry = 600
expire = 604800
minimum = 86400
224/28.cc.bb.aa.in-addr.arpa. nameserver = 231.cc.bb.aa.in-addr.arpa.

Here is where our problems begin, the “/” (slash) is not an allowable character on the Yast autoconfigurator. So I edited the file /var/lib/named/master/224-28.cc.bb.aa.in-addr.arpa to contain the “/” character and the server stops responding to rdns requests.

Question: How can we implement the Sub-Class-C network in the named zone file for it to work? What character should we use in liew of “/”.

Thanks for your help.

Our zone file before the “/”

$TTL 1h
@ IN SOA ns1.ourdomain.com root.ns1.ourdomain.com.(
2009061501 ; serial
1h ; refresh
10m ; retry
1w ; expiry
1d ) ; minimum

              IN NS      231.cc.bb.aa.in-addr.arpa.

238.cc.bb.aa.in-addr.arpa. IN PTR mx.ourdomain.com.
231.cc.bb.aa.in-addr.arpa. IN PTR ns1.ourdomain.com.
229.cc.bb.aa.in-addr.arpa. IN PTR www.ourdomain.com.

Our zone file with the “/” we used “-” dash instead.

$TTL 1h
$ORIGIN .
224-28.cc.bb.aa.in-addr.arpa IN SOA ns1.ourdomain.com root.ns1.ourdomain.com.(
2009061501 ; serial
1h ; refresh
10m ; retry
1w ; expiry
1d ) ; minimum

224-28.cc.bb.aa.in-addr.arpa. IN NS 231.cc.bb.aa.in-addr.arpa.
238.cc.bb.aa.in-addr.arpa. IN PTR mx.ourdomain.com.
231.cc.bb.aa.in-addr.arpa. IN PTR ns1.ourdomain.com.
229.cc.bb.aa.in-addr.arpa. IN PTR www.ourdomain.com.
231.cc.bb.aa.in-addr.arpa.224-28.cc.bb.aa.in-addr.arpa. IN NS 224-28.cc.bb.aa.in-addr.arpa.

Hope this helps show the confusion.

This is the recommended config from our ISP (AT&T)

/27.2.1.12.in-addr.arpa. 3600 SOA dns2.anydomain.com. administrator.anydomain.com.
1999091702 ; serial
3600 ; refresh (1 hour)
600 ; retry (10 mins)
expire = 600000 (6 days 22 hours 40 mins)
86400 ) ; minimum (1 day)
0/27.2.1.12.in-addr.arpa. 3600 NS dns2.anydomain.com.
0/27.2.1.12.in-addr.arpa. 3600 NS cbru.br.ns.els-gms.att.net.
0/27.2.1.12.in-addr.arpa. 3600 NS dbru.br.ns.els-gms.att.net.
1 3600 PTR gw.anydomain.com.
10 3600 PTR hidden4.anydomain.com.
11 3600 PTR hidden5.anydomain.com.
12 3600 PTR hidden6.anydomain.com.
13 3600 PTR www.anydomain.com.

0/27.2.1.12.in-addr.arpa. 3600 SOA dns2.anydomain.com. administrator.anydomain.com.
1999091702 ; serial
3600 ; refresh (1 hour)
600 ; retry (10 mins)
86400 ; expire (1 day)
3600 ) ; minimum (1 hour)

#2

Have a look in the example in the RFC to see how the zone file should be coded.

RFC 2317 (rfc2317) - Classless IN-ADDR.ARPA delegation

#3

On Mon, 2009-06-15 at 23:26 +0000, carpicker wrote:
…
> Here is where our problems begin, the “/” (slash) is not an allowable
> character on the Yast autoconfigurator. So I edited the file
> /var/lib/named/master/224-28.cc.bb.aa.in-addr.arpa to contain the “/”
> character and the server stops responding to rdns requests.

Probably a bad assumption in the yast code that somehow associates a
zone name to the file for the zone data (oops). Anyhow, you can
manually edit your zone file and named.conf to fix this up I imagine.

First time I’ve heard of “classless” delegation like this. But I
suppose it does make sense. Alternatively, you could have a zone per
member… that would work as long as you didn’t mind all the extra zones
(and you net block provider didn’t mind the extra work on the delegation
side… which likely they would).

Very interesting. I’ll have to read that RFC.

#4

You might want to read this:

http://homepages.tesco.net/J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html

#5

ken_yap, thanks for the link.
I had actually looked at similar examples, the trouble is that most all examples deal with single octet subnets, not partial octet subnets that need to have the octect mask in them to determine the actual subnet. For example, 16 subnets of 16 hosts each will be addressed as 0/28.0.168.192, 16/28.0.168.192 … 240/28.0.168.192 with a supernet of 0/24.0.168.192.
That stinky “/” is the trouble that I’ve encountered and all the writings avoid or simply do not address that type of sub-class-C Class-Less subneting. Based on what my ISP is telling me to do, it all makes perfect sense. I just can’t get SuSE’s implementation of BIND to accept that nomenclature (syntax).
I was just hoping that someone had come accross this issue and had an idea what is the correct syntax for SuSE’s BIND.
So I continue to DIG into this issue…
Thanks

#6

cjcox, you’ve hit a nail…
That is exactly what I’m talking about. Great article.

The problem is still the same, how to tell BIND that this is a sub-class-C network? BIND seems to respond partially after some modifications to the zone file, but one thing that this article mentions is the inability for DIG to traverse this type of addressing.

So I continue to DIG into this some more…

Tkx

#7

There’s no such thing as a SUSE BIND. It’s the standard BIND, same as all other distros. The YaST frontend is SUSE’s though and if you can’t get that to accept the syntax, that’s not surprising, it doesn’t cater for everything. You may have to resort to a text editor.

#8

Ken_yap,
You are on track, the yast frontend is the first problem, but thanks to it, the forbiddance of using “/”, which is a restricted character as it denotes Directory Boundary, makes the user check the work first.

After testing some more, reading lots of posts, RFC-2317 and the DNS and BIND master of books, the reference to the use of “/” is as “… Pedantic…”.

With that said, Bind does not interpret a CNAME of 1.0/28.bb.aa.in-addr.arpa because in the zone file, references to a name/name… are interpreted as directory/file_name for some reason during parsing. For example, zone file {“master/0/28.bb.aa.in-addr.arpa”} will render a zone definition of 28.bb.aa.in-addr.arpa. If we change the nomenclature to use a “-” as it is the recomendation by the counless Bind and RFC authors on the subject, the following is a better way of doing it.

/etc/named.conf
…
zone “0-28.cc.bb.aa.in-addr.arpa” in {
…
file “master/0-28.cc.bb.aa.in-addr.arpa”;
…

then the file /var/lib/named/master/0-28.cc.bb.aa.in-addr.arpa will look like this
…
&TTL 1d
@ IN SOA …
…

  IN NS   nameserver.mydomain.com.

ddd IN PTR servername.mydomain.com.
…

What seems to be the issue is the ISP to have configured the CNAME in their name server to reply with .ddd.0/28.cc.bb.aa.in-addr.arpa. which can’t be traversed.

I’m now to attempt to convince the Green Giant (AT&T) to change their ways (for my subnet at least) to use a “-” instead of the dreaded “/”.

I set up a mock network and build 4 NS servers to try this out and was able to make the determination.

So that is my story. This problem is now with a possible solution. Or so I will try.

Thanks for your comments and input. Hope this helps others.

#9

Will it work if you manually create another level of directory?

zone "0/28.cc.bb.aa.in-addr.arpa" in {
...
file "master/0/28.cc.bb.aa.in-addr.arpa";

And then have a directory of 0 with 28.cc.bbb.aa.in-addr.arpa inside it?

#10

I will have to try. My thought was that it would not as the file picks the zone’s origin using the @ for the SOA from this name.

On the other hand, I have tried setting the $ORIGIN to 0/28.cc.bb.aa.in-addr.arpa. with out positive results, which is the reason I contemplated using the “-” instead.

The $ORIGIN directive is supposed to override the @ at the SOA statement from using the filename as the directive.

At this time, I’m having to look at the logs becasue I can’t see what is being exchanged between NS’ since we’re not getting responses other than SERVFAIL when requesting PTR records.

#11

As I suspected, it did not work since the actual file is named differently than the zone itself.

It should have worked using the $ORIGIN directive, but somehow it did not work for me.

#12

At last there is resolution.

Our ISP (AT&T) did as I requested to change the CNAME from 224/28.bb.aa.in-addr.arpa. to the CNAME of 224-28.bb.aa.in-addr.arpa.

Once they did per my request, it worked… and they admitted to it not so gracefully.

This is all on this subject. Make sure your ISP is on the same page as your server.