Solved Confused about PTR and BIND 99

I am building a new server using FreeBSD 10.2 and trying to establish DNS using BIND99

I am VERY confused on the establishment of PTR

my hosts in the namedb/master is as follows:

Code:
$ttl 38400

theoceanwindow.com.     IN      SOA     triggerfish.theoceanwindow.com. jason.theoceanwindow.com. (

                        2015101702

                        10800

                        3600

                        604800

                        38400 )

theoceanwindow.com.     IN      NS      triggerfish.theoceanwindow.com.

triggerfish.theoceanwindow.com. IN      A       209.160.23.29

ns.theoceanwindow.com.  IN      A       209.160.23.29

ns1.theoceanwindow.com. IN      A       209.160.23.29

ns2.theoceanwindow.com. IN      A       209.160.23.29

theoceanwindow.com.     IN      NS      ns.theoceanwindow.com.

theoceanwindow.com.     IN      NS      ns1.theoceanwindow.com.

theoceanwindow.com.     IN      NS      ns2.theoceanwindow.com.

theoceanwindow.com.     IN      MX      10 mail.theoceanwindow.com.

theoceanwindow.com.     IN      MX      10 imap.theoceanwindow.com.

theoceanwindow.com.     IN      MX      10 smtp.theoceanwindow.com.

mail.theoceanwindow.com.        IN      A       209.160.23.29

smtp.theoceanwindow.com.        IN      A       209.160.23.29

imap.theoceanwindow.com.        IN      A       209.160.23.29

www.theoceanwindow.com. IN      A       209.160.23.29

ftp.theoceanwindow.com. IN      A       209.160.23.29

theoceanwindow.com.     IN      A       209.160.23.29

29.23.160.209.  IN      PTR     mail.theoceanwindow.com.

29.23.160.209.  IN      PTR     ns.theoceanwindow.com.

29.23.160.209.  IN      PTR     ns1.theoceanwindow.com.

29.23.160.209.  IN      PTR     ns2.theoceanwindow.com.

29.23.160.209.  IN      PTR     triggerfish.theoceanwindow.com.

29.23.160.209.  IN      PTR     www.theoceanwindow.com.

29.23.160.209.  IN      PTR     theoceanwindow.com.

29.23.160.209.  IN      PTR     www.theoceanwindow.com.

29.23.160.209.   IN      PTR     theoceanwindow.com.

29.23.160.209.   IN      PTR     imap.theoceanwindow.com.

29.23.160.209.   IN      PTR     smtp.theoceanwindow.com.

theoceanwindow.com.     IN      TXT     "v=spf1 all"

In my previous server (FreeBSD 9.3 and BIND 8) I got it all working with setting similar to this.
In my research I have found references to this type approach but also to using different zones.
I am getting more and more confused originally I was getting bounces based on no PTR , now I am getting bounces for other reasons that are border line unintelligible.

Any suggestions would be appreciate or references to a a BIND 99 guide for dummies.
 
Typically PTR records are placed in a separate file and include only one PTR per IP address. I work for an ISP and we run BIND 9 in a jail. The directory under the jail includes ~/var/named/db/primary/ and ~/var/named/db/reverse/. Under /reverse/ are subdirectories for our various reverse zones that then contain the reverse zone files. Using your IP addresses in our setup it would look like:
Code:
~/var/named/db/reverse/23.160.209.in-addr.arpa/23.160.209.in-addr.arpa
The 23.160.209.in-addr.arpa file would look like this:
Code:
$TTL 24h
$ORIGIN 23.160.209.in-addr.arpa.
  IN  SOA triggerfish.theoceanwindow.com. jason.theoceanwindow.com. (
  2015101701  ; Serial YYYYMMDD##
  3h  ; Refresh
  1h  ; Retry
  1w  ; Timeout
  24h )  ; TTL

theoceanwindow.com. IN NS ns.theoceanwindow.com.

$ORIGIN 23.160.209.in-addr.arpa.
29  IN  PTR  smtp.theoceanwindow.com.
For the record, I have not used reverses in a primary zone file as you have. So, I have no idea if that is valid or not. I recommend running 'named-checkzone' against your zone file to see what it says. You would run it like this:
Code:
named-checkzone zone.file.name zone.file.name
Hopefully some of this will help you.
 
Most informative and clarifies a LOT I sort of understand the record format... gives me something to look at and try.
 
I tried playing with your suggestion , with which my level of knowledge ws like playing with a loaded gun

No simple fix to what I have done BUT in regards to your suggestion BIND doesn't seem to like your reverse file

  • Code:
    [*]/etc/namedb/reverse/23.160.209.in-addr.arpa:3: no current owner name
    [*]/etc/namedb/reverse/23.160.209.in-addr.arpa:10: ignoring out-of-zone data (theoceanwindow.com)
IO attribute this to that in your IP schema it would appear that each alias IP was in fact a new IP under subnet
209.160.23. In my server the only IP i have is 209.160.23.29
 
no current owner name
The above may happen from whitespace being in front of certain lines in the file. Make sure any line beginning with "$" does not have a space or a tab at the beginning of it. Do the same for "29 IN PTR smtp.theoceanwindow.com.".
ignoring out-of-zone data (theoceanwindow.com)
This is due to this line:
Code:
theoceanwindow.com. IN NS ns.theoceanwindow.com.
Change it to this:
Code:
        IN        NS        ns.theoceanwindow.com.
Try again after those changes and let us know what happens.
 
Hmmmm I don't seem to be making any progress and in fact pretty much have killed all external DNS


My named.conf is as follows:

Code:
options {
        directory "/";
        pid-file "/var/run/named.pid";
  listen-on { 209.160.23.29 ;};
                        };
controls {
        inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { dnsadmin; };
        };
key "dnsadmin" {
        algorithm hmac-md5;
        secret "secret";
        };
zone "." {
        type hint;
        file "/etc/namedb/named.root";
        };
zone "theoceanwindow.com" {
        type master;
        file "/etc/namedb/master/theoceanwindow.com.hosts
};
zone "23.160.209.in-addr.arpa" {
      type master;
 file "/etc/namedb/reverse/23.160.209.in-addr.arpa";
};


My reverse record

Code:
$TTL 24h
$ORIGIN 23.160.209.in-addr.arpa.        
IN SOA triggerfish.theoceanwindow.com. jason.theoceanwindow.com. (
                        2015103005;
                        3h;
                        1h;
                        1w;
                        24h );
IN NS ns.theoceanwindow.com.                                             
$ORIGIN 23.160.209.in-addr.arpa.                                         
29 IN PTR smtp.theoceanwindow.com.

The errors have changed but continued from the log file

Code:
Oct 30 14:46:30 triggerfish named[12987]: command channel listening on 127.0.0.1#953
Oct 30 14:46:30 triggerfish named[12987]: /etc/namedb/reverse/23.160.209.in-addr.arpa:3: SOA record not at top of zone (IN.23.160.209.in-addr.arpa)
Oct 30 14:46:30 triggerfish named[12987]: zone 23.160.209.in-addr.arpa/IN: loading from master file /etc/namedb/reverse/23.160.209.in-addr.arpa failed: not at top of zone
Oct 30 14:46:30 triggerfish named[12987]: zone 23.160.209.in-addr.arpa/IN: not loaded due to errors.
Oct 30 14:46:30 triggerfish named[12987]: all zones loaded
Oct 30 14:46:30 triggerfish named[12987]: running


I am sure I must be messing up something I don't really understand as my other server is BIND 8 ()on Freebsd 9.3 and this new was is 99 on 10.2
 
Hmmm, we are running 9.5.0 here on SunOS 5.8. I do not have a FreeBSD with bind 9.9 install to test and do not have time to spin up a test VM today. However, I can probably do that next week and see what is different in 9.9.

On the SOA line try this:
Code:
23 IN SOA triggerfish.theoceanwindow.com. jason.theoceanwindow.com. (
In the meantime, try doing some web searches with those errors and "bind 9.9" to see if you can get this working.
 
The searched pointed at the same stuff you mentioned white spaces But again I am wondering

The record iI have adapted from you is referring a different subnet.

All of my records in have an IP address of 209.160.23.29 which is my server.

Looking at he way the reverse records is written using the origin substitution it would appear
that it implies the server is 209.160.23.0 with each record having an IP under that subnet.

With this zone removed BIND runs with out errors.
 
Firstly make sure that you actually need to be running reverse DNS. At the moment your IP address resolves to theoceanwindow.com, which is coming from name servers at hopone.net. It's highly likely that they are running reverse DNS for you, and you just need to contact the support of whoever provides your internet connection and get them to update it. The only reason you would need to run your own reverse DNS is if they actually delegate the reverse DNS to you, which is rare unless you have a large block of addresses. Usually I find that if people are big enough, and have enough addresses that they've had DNS delegated to them, they usually already know enough that they wouldn't need help setting the DNS up.

Going back to your zone file in post #6:

In line 2 you set the $ORIGIN to 23.160.209.in-addr.arpa. The origin is set to the zone name by default, so you don't really need that.

In line 3, the first field on the line should be the name that the record applies to, not IN. Usually people just put @ here, which basically means use the ORIGIN:
Code:
@ IN SOA ....
I'm also not sure about the semicolons in this record. Not sure if bind will allow those, but you don't have them in the other zone file and none of my zones have any either.

On the following NS lines, the records apply to the same name, so you could put @ for those as well. However, you can also leave it blank, which means use the same value as the previous record:
Code:
  IN NS ...
Note that there is a space at the start of the line. If there isn't a space, it will assume you want the record to apply to 'in'. Because there's no dot on the end, that would then expand to in.23.160.209.in-addr.arpa. (The current value of ORIGIN gets appended)

Further down you set $ORIGIN again, to the exact same value which is obviously not required. The line below that looks ok.
 
Just another note about reverse DNS. The IP can only resolve to one name. You can't have lots of PTR records for one address. As you may know mail servers can be funny about DNS, so I would do the following:

Server real host name: xyz.theoceanwindow.com
Make sure xyz.theoceanwindow.com resolves to the correct IP
Make sure reverse DNS for IP resolves to xyz.theoceanwindow.com
Make sure your mail server uses the server host name for all its connections, which it will be default unless you change it.

That way your server has a real host name, and everything ties up nicely. If you then want to create mail.thoceanwindow.com or smtp.theoceanwindow.com to use in MX records or for users to access, you can.

You can make the reverse DNS map to smtp.theoceanwindow.com (or another name), then configure the mail software to use that, but I generally think it makes more sense to just use the actual server name.
 
OK couple of thoughts /questions...

usdmatt sees to be confirming what i was beginning to think from UnixRocks examples. These examples seem to based on the presumption I controlled the 209.160.23.0/27 block... I do not, my host does. This seems to go with the
Firstly make sure that you actually need to be running reverse DNS. At the moment your IP address resolves to theoceanwindow.com, which is coming from name servers at hopone.net. It's highly likely that they are running reverse DNS for you, and you just need to contact the support of whoever provides your internet connection and get them to update it.

I did quiet the error messages on BIND load . It now loads appears to function normally but named-checkzone still hates the attempt at the reverse starting with 'out of zone" which for the reason above, i think is an appropriate error

Code:
$TTL 24h
$ORIGIN 23.160.209.in-addr.arpa. 
23.160.209.in-addr.arpa. IN SOA triggerfish.theoceanwindow.com. jason.theoceanwindow.com. (
       2015103005;
       3h;
       1h;
       1w;
       24h );
@ IN NS triggerfish.theoceanwindow.com.
29 IN PTR mail.theoceanwindow.com.


I do not use the host name for the mail as, when operating, I have about six domains hosted on my server and I try to use server alias that their techies are comfortable with
The rate I am going with this new server, it will never see production
 
If you're not running reverse DNS then you may as well just forget about the reverse zones.

Having said that I can't see anything obviously wrong with the zone as it is. Here's one of mine for comparison:
Code:
zone "3.2.1.in-addr.arpa" {
        type master;
        file "master/3.2.1.in-addr.arpa.zone";
};
Code:
@               43200   IN   SOA     ns.domain.net. hostmaster.domain.net. (
                        2008041401 3600 600 1209600 3600 )
                43200   IN   NS      ns.domain.net.
                43200   IN   NS      ns2.domain.net.
8               43200   IN   PTR     ptr1.domain.com.
14              43200   IN   PTR     ptr1.domain.com.
Code:
# named-checkzone 3.2.1.in-addr.arpa 3.2.1.in-addr.arpa.zone
zone 3.2.1.in-addr.arpa/IN: loaded serial 2008041401
OK
(I don't have a $TTL variable in mine but specify the TTL on every record, as mine's all generated automatically. You should be fine to leave the TTL out of the records and just use a global $TTL variable like you already have)

Regarding running multiple domains off the same server, there's no problem with having DNS entries like the following for theirdomain.com.
Code:
theirdomain.com.      IN MX mail.theirdomain.com.
mail.theirdomain.com. IN A  your.server.ip
smtp.theirdomain.com. IN A  your.server.ip
If anyone looks up MX records for the domain, they will see the customers domain name in the MX record. You customer can also use mail.theirdomain.com and smtp.theirdomain.com in their email clients. In fact this is actually beneficial, because if you ever need to move a customers email to another server, you can move the email, update their DNS entries, and they shouldn't need to change any settings.

However, I would still highly advise that your mail server uses its real hostname in SMTP transactions, and the reverse DNS for the IP address resolves to the real hostname (or you can use something more generic like mail.yourdomain.com if you want to, as long as you configure the smtp software to use that name).

There is no way you can actually make the mail server itself pretend to be multiple different domains. The reverse DNS can only map back to one name, and that's the one your mail server needs to use.
 
If you're not running reverse DNS then you may as well just forget about the reverse zones.

In the end I think you are right. I also see your point on the using the host name in lieu of the domain name except I will have to have client change their setup when they are transitioned to the new server

I think most of my issues may also be caused by trying to run dns/bind99 on FreeBSD 10 in a chroot() environment. Missed the issue

I am still puzzled by your IP assignments. It would appear the your server is at the notional 1.2.3.0. Since you are reverse 1.2.3.8 and 1.2.3.14. In my case using your notional my server is at 1.2.3.29

This is more my education. Since I made the mistake of trying to install with chroot() with out editing the port I have to uninstall and go back to start anyway
 
although I have gone with letting my host handle the PTR I am still curious about the format and how to to handle the octet for a single IP server

I am still puzzled by your IP assignments. It would appear the your server is at the notional 1.2.3.0. Since you are reverse 1.2.3.8 and 1.2.3.14. In my case using your notional my server is at 1.2.3.29


can anyone provide any insight?
 
I am still puzzled by your IP assignments. It would appear the your server is at the notional 1.2.3.0. Since you are reverse 1.2.3.8 and 1.2.3.14. In my case using your notional my server is at 1.2.3.29
I'm not really sure what you're getting at here. This is the second PTR post I've been involved with almost simultaneously, where people seem to be overcomplicating how IP addresses are converted to DNS entries. It is literally a string made up of the IP address in reverse. The DNS server isn't doing any IP maths on the octets that make up the record. The reason it's in reverse is to allow the owner of each IP block to delegate the next block to someone else ->

Code:
in-addr.arpa -> Run by global IP providers
1.in-addr.arpa -> Delegated to Big ISP A

Big ISP A can then give 1.2.x.x to Medium ISP B and delegate 2.1.in-addr.arpa DNS to them
Medium ISP B can then give 1.2.3.x to Small ISP C and delegate 3.2.1.in-addr.arpa DNS to them
In the old classful system this worked out perfectly.

If you owned the entire 209.160.23.x network, your ISP would create a DNS zone like the below and delegate it to you
Code:
23.160.209.in-addr.arpa.   IN   NS   ns.yourdomain.com.

You would then create a zone for 23.160.209.in-addr.arpa on ns.yourdomain.com, containing records for each IP address you were using. If you wanted reverse DNS for 209.160.23.29 & 209.160.23.199, you would have the following
Code:
$ORIGIN 23.160.209.in-addr.arpa.
@       IN SOA ...
        IN NS ...
29      IN PTR server1.domain.com.
199     IN PTR server2.domain.com.
In the case of the first PTR record above, "29" gets $ORIGIN appended, just like any normal DNS entry (because it doesn't end in a dot), and becomes 29.23.160.209.in-addr.arpa, which is 209.160.23.29 backwards, with .in-addr.arpa stuck on the end.

It gets a bit more complicated when you have classless ranges, such as when you have less than 256 IP addresses. The normal DNS system of delegating DNS at each dot can't be used, because obviously your ISP can't delegate DNS for the entire 209.160.23.x network to you. In order to do this many ISPs use a clever 'hack' which was discussed in the other PTR post on here recently.

I don't know if you've understood everything above so far, but if you don't know about classless routing or CIDR you probably won't get this very easily. What the ISP does is to delegate a subdomain to you, where the name of the subdomain references your IP range, then CNAME all the PTR records to new records under that subdomain. So if you only have one IP address, they might do the following
Code:
$ORIGIN 23.160.209.in-addr.arpa.
29/32.23.160.209.in-addr.arpa. IN NS ns.yourdomain.com.
29.23.160.209.in-addr.arpa. IN CNAME 29.29/32.23.160.209.in-addr.arpa.

You would then have a zone on your server like the below:
(zone 29/32.23.160.209.in-addr.arpa.)
Code:
$ORIGIN 29/32.23.160.209.in-addr.arpa.
29.29/32.23.160.209.in-addr.arpa.  IN  PTR   server1.domain.com.

Maybe it needs someone else to step in any try and explain things better than me...
Personally I think it's all incredibly simple if you just remember that a reverse DNS record is literally just the IP backwards with in-addr.arpa on the end, and is treated exactly like forward DNS records otherwise. I have been doing it 15 years though, there's a point where it all just clicks.
 
Maybe it needs someone else to step in any try and explain things better than me...
Personally I think it's all incredibly simple if you just remember that a reverse DNS record is literally just the IP backwards with in-addr.arpa on the end, and is treated exactly like forward DNS records otherwise. I have been doing it 15 years though, there's a point where it all just clicks.

This is what I had thought that was what threw. I will admit the classless discussion throw me for a loop
Now looking upon how you did the PTR suggestion I now see what you were doing with using the .29 where you did I had though that it had to be in the zone name and origin too.

Thanks for taking the time and again I apologize for my ignorance


another thing I don't know is how to mark this as 'solved'
 
captcurrent, to mark the thread as solved, click on "Thread Tools" at the top right of the thread page, then click on "Edit Thread". You can then change the thread title prefix to "Solved".
 
Back
Top