1
1
I'm trying to configure a zone for a 10.0.1.0/24 network.
I have rfc1918 zones defined, but then I commented out 10.in-addr.arpa network, since I'm neading it.
I then configured a db.1.0.10 file (reverse for 10.0.1.0/24 network)...
But then had to create a db.10 file for all the other 10. networks not being 10.0.1.1/24 - That's a 4Mb file with this content:
zone "0.0.10.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
//zone "1.0.10.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "2.0.10.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
zone "3.0.10.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
... (65531 more lines)
zone "255.255.10.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
This seems unreasonable to me and it takes forever for bind to start. Plus, it now consumes 79.7% of my scarce 512Mb of memory.
After you stop laughing, could you please tell me how I could tell bind something like:
Hey, man, 10.something is empty, except for 10.0.1.something which you can look up in 1.0.10.db file.
Why don't you just leave "10.in-addr.arpa" active, create no other zones, and put everything in there? – Celada – 2013-06-30T13:37:19.653
I'm not sure what you mean, but I tryed to have both: the line containing "10.in-addr.arpa" and another for "1.0.10.in-addr.arpa" and bind would not start complaining about having already defined something for "10.in-addr.arpa" and not being able to accept "1.0.10.in-addr.arpa". – Ninguém – 2013-06-30T19:08:58.757
That makes no sense. There is absolutely nothing wrong with having a zone "10.in-addr.arpa" and another zone "1.0.10.in-addr.arpa" (in most cases you should have a proper delegation in "10.in-addr.arpa"). But in any case what I was asking was why you want to create a new zone at all. Why don't you just put
PTR
records directly in "10.in-addr.arpa"? That's really much simpler! – Celada – 2013-06-30T19:26:27.963Hum... regarding bind complaining about having both (10.0.0.0/8 and 10.0.1.0/24) defined, I'll have to double-check that, I don't have access to the server ATM, but I was pretty shure it aborted with a message in syslog stating that error. About putting PTR records directly in the 10.0.0.0/8 reverse zone, you should be right, but then... I would be configuring a 10.0.0.0/8 reverse zone when in fact I only wanted to configure a 10.0.1.0/24. I might be confused, here. maybe if you know of a good doc... – Ninguém – 2013-06-30T21:00:25.063
But you already have the 10.0.0.0/8 zone configured (which is fine), so if you just add reverse DNS entries to that zone you wouldn't be changing that. – Celada – 2013-07-01T01:47:43.427
Thank you for your help. I still didn't have the opportunity to test with 10.in-addr.arpa and 1.0.10.in-addr.arpa at the same time. Meanwhile I came across the notion of stub zones, also... so I'll keep looking, but really define everything in 10.in-addr.arpa seems to be, by far, the most simple approach. – Ninguém – 2013-07-03T22:16:55.303
By the way, stub zones are totally unrelated in this context. And yes, just putting everything in the 10.in-addr.arpa zone is the easiest way. – Celada – 2013-07-03T22:18:33.233