Reverse DNS fail Announcing the arrival of Valued Associate #679: Cesar Manara ...

What's the meaning of "fortified infraction restraint"?

What is "gratricide"?

Converted a Scalar function to a TVF function for parallel execution-Still running in Serial mode

Hangman Game with C++

Find 108 by using 3,4,6

Why do we bend a book to keep it straight?

Can the Great Weapon Master feat's damage bonus and accuracy penalty apply to attacks from the Spiritual Weapon spell?

AppleTVs create a chatty alternate WiFi network

Take 2! Is this homebrew Lady of Pain warlock patron balanced?

Why wasn't DOSKEY integrated with COMMAND.COM?

Dating a Former Employee

Time to Settle Down!

Is it possible for SQL statements to execute concurrently within a single session in SQL Server?

Is there a kind of relay that only consumes power when switching?

What does it mean that physics no longer uses mechanical models to describe phenomena?

Why does the remaining Rebel fleet at the end of Rogue One seem dramatically larger than the one in A New Hope?

Significance of Cersei's obsession with elephants?

Do wooden building fires get hotter than 600°C?

Why do we need to use the builder design pattern when we can do the same thing with setters?

How to install press fit bottom bracket into new frame

How do I find out the mythology and history of my Fortress?

Central Vacuuming: Is it worth it, and how does it compare to normal vacuuming?

Sum letters are not two different

Most bit efficient text communication method?



Reverse DNS fail



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern)
2019 Community Moderator Election Results
Why I closed the “Why is Kali so hard” questionBIND9 as a DNS server refuses requestsBind dns zone will not workGenerate IPv6 reverse PTR records for /64 subnetClosed network DHCP+DNS - updating in-addr.arpa side works, forward side refuses to updateUnable to resolve 1.2.3.4.list.dsbl.orgWhy is BIND not automatically trying all nameservers, especially when an IPv6 nameserver is unreachable?Bind - proper reverse configBIND / old DNS entries in Google cacheHave unexpected hostname and IPBIND9 DNS zone file check reveals “ignoring out-of-zone data”





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







1















I have an installation of Zimbra 8.7 CS multi server



Server A: single-server installation (mail.jbv.cl 200.54.163.182) with two domains (jbv.cl and grupojbv.cl)



Server B: a second MTA (smtp.grupojbv.cl 200.54.163.179)



Server C: external dns (ns.jbv.cl 200.54.163.178)



I configured it this way since I need the mails from jbv.cl to exit from server A and the mails from grupojbv.cl to exit from server B.
The configuration works on the server without problem and each one uses the assigned mta, the problem is in my public DNS (ns.jbv.cl) which I manage, the point that does not solve the reverse of server B (smtp.grupojbv.cl)



If I make a query to the Google servers (8.8.8.8) throw me this:



Dig -x 200.54.163.179 @8.8.8.8



;; QUESTION SECTION:
;179.163.54.200.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
163.54.200.in-addr.arpa. 1799 IN SOA qip1.redip.cl. root.redip.cl. 2017062801 21600 3600 604800 86400


But if I do the same query my public dns throws this:



Dig -x 200.54.163.179 @ns.jbv.cl



;; QUESTION SECTION:
;179.163.54.200.in-addr.arpa. IN PTR
;; ANSWER SECTION:
179.163.54.200.in-addr.arpa. 38400 IN PTR smtp.grupojbv.cl.
;; AUTHORITY SECTION:
179.163.54.200.in-addr.arpa. 38400 IN NS ns.jbv.cl.
;; ADDITIONAL SECTION:
ns.jbv.cl. 38400 IN A 200.54.163.178


If I make the same query to (jbv.cl) returns the reverse without problems



What is the problem with my DNS? I've waited a week waiting for it to spread but nothing.



Here the configuration of my DNS server Ubuntu server 16.04



Named.conf.local



zone "jbv.cl" {
type master;
file "/var/lib/bind/jbv.cl.hosts";
};
zone "grupojbv.cl" {
type master;
file "/var/lib/bind/grupojbv.cl.hosts";
};
zone "163.54.200.in-addr.arpa" {
type master;
file "/var/lib/bind/200.54.163.rev";
};


/var/lib/bind/jbv.cl.hosts (jbv.cl)



$ttl 38400
jbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1500432573
10800
3600
604800
38400 )
jbv.cl. IN NS ns.jbv.cl.
www.jbv.cl. IN CNAME jbv.cl.
jbv.cl. IN MX 10 mail.jbv.cl.
jbv.cl. IN A 200.54.163.181
ns.jbv.cl. IN A 200.54.163.178
mail.jbv.cl. IN A 200.54.163.182


/var/lib/bind/grupojbv.cl.hosts (grupojbv.cl)



$ttl 38400

grupojbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1500432643
10800
3600
604800
38400 )
grupojbv.cl. IN NS ns.jbv.cl.
grupojbv.cl. IN MX 20 smtp.grupojbv.cl.
smtp.grupojbv.cl. IN A 200.54.163.179


/var/lib/bind/200.54.163.rev



$ttl 38400
jbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1501037500
10800
3600
604800
38400 )
163.54.200.in-addr.arpa. IN NS ns.jbv.cl.
179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.
182.163.54.200.in-addr.arpa. IN PTR mail.jbv.cl.


Why the other dns servers do not solve the reverse of smtp.grupojbv.cl










share|improve this question

























  • Just use 179 IN PTR smtp.grupojbv.cl. (instead of 179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.) in RR declaration.

    – heemayl
    Aug 9 '17 at 6:00


















1















I have an installation of Zimbra 8.7 CS multi server



Server A: single-server installation (mail.jbv.cl 200.54.163.182) with two domains (jbv.cl and grupojbv.cl)



Server B: a second MTA (smtp.grupojbv.cl 200.54.163.179)



Server C: external dns (ns.jbv.cl 200.54.163.178)



I configured it this way since I need the mails from jbv.cl to exit from server A and the mails from grupojbv.cl to exit from server B.
The configuration works on the server without problem and each one uses the assigned mta, the problem is in my public DNS (ns.jbv.cl) which I manage, the point that does not solve the reverse of server B (smtp.grupojbv.cl)



If I make a query to the Google servers (8.8.8.8) throw me this:



Dig -x 200.54.163.179 @8.8.8.8



;; QUESTION SECTION:
;179.163.54.200.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
163.54.200.in-addr.arpa. 1799 IN SOA qip1.redip.cl. root.redip.cl. 2017062801 21600 3600 604800 86400


But if I do the same query my public dns throws this:



Dig -x 200.54.163.179 @ns.jbv.cl



;; QUESTION SECTION:
;179.163.54.200.in-addr.arpa. IN PTR
;; ANSWER SECTION:
179.163.54.200.in-addr.arpa. 38400 IN PTR smtp.grupojbv.cl.
;; AUTHORITY SECTION:
179.163.54.200.in-addr.arpa. 38400 IN NS ns.jbv.cl.
;; ADDITIONAL SECTION:
ns.jbv.cl. 38400 IN A 200.54.163.178


If I make the same query to (jbv.cl) returns the reverse without problems



What is the problem with my DNS? I've waited a week waiting for it to spread but nothing.



Here the configuration of my DNS server Ubuntu server 16.04



Named.conf.local



zone "jbv.cl" {
type master;
file "/var/lib/bind/jbv.cl.hosts";
};
zone "grupojbv.cl" {
type master;
file "/var/lib/bind/grupojbv.cl.hosts";
};
zone "163.54.200.in-addr.arpa" {
type master;
file "/var/lib/bind/200.54.163.rev";
};


/var/lib/bind/jbv.cl.hosts (jbv.cl)



$ttl 38400
jbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1500432573
10800
3600
604800
38400 )
jbv.cl. IN NS ns.jbv.cl.
www.jbv.cl. IN CNAME jbv.cl.
jbv.cl. IN MX 10 mail.jbv.cl.
jbv.cl. IN A 200.54.163.181
ns.jbv.cl. IN A 200.54.163.178
mail.jbv.cl. IN A 200.54.163.182


/var/lib/bind/grupojbv.cl.hosts (grupojbv.cl)



$ttl 38400

grupojbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1500432643
10800
3600
604800
38400 )
grupojbv.cl. IN NS ns.jbv.cl.
grupojbv.cl. IN MX 20 smtp.grupojbv.cl.
smtp.grupojbv.cl. IN A 200.54.163.179


/var/lib/bind/200.54.163.rev



$ttl 38400
jbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1501037500
10800
3600
604800
38400 )
163.54.200.in-addr.arpa. IN NS ns.jbv.cl.
179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.
182.163.54.200.in-addr.arpa. IN PTR mail.jbv.cl.


Why the other dns servers do not solve the reverse of smtp.grupojbv.cl










share|improve this question

























  • Just use 179 IN PTR smtp.grupojbv.cl. (instead of 179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.) in RR declaration.

    – heemayl
    Aug 9 '17 at 6:00














1












1








1








I have an installation of Zimbra 8.7 CS multi server



Server A: single-server installation (mail.jbv.cl 200.54.163.182) with two domains (jbv.cl and grupojbv.cl)



Server B: a second MTA (smtp.grupojbv.cl 200.54.163.179)



Server C: external dns (ns.jbv.cl 200.54.163.178)



I configured it this way since I need the mails from jbv.cl to exit from server A and the mails from grupojbv.cl to exit from server B.
The configuration works on the server without problem and each one uses the assigned mta, the problem is in my public DNS (ns.jbv.cl) which I manage, the point that does not solve the reverse of server B (smtp.grupojbv.cl)



If I make a query to the Google servers (8.8.8.8) throw me this:



Dig -x 200.54.163.179 @8.8.8.8



;; QUESTION SECTION:
;179.163.54.200.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
163.54.200.in-addr.arpa. 1799 IN SOA qip1.redip.cl. root.redip.cl. 2017062801 21600 3600 604800 86400


But if I do the same query my public dns throws this:



Dig -x 200.54.163.179 @ns.jbv.cl



;; QUESTION SECTION:
;179.163.54.200.in-addr.arpa. IN PTR
;; ANSWER SECTION:
179.163.54.200.in-addr.arpa. 38400 IN PTR smtp.grupojbv.cl.
;; AUTHORITY SECTION:
179.163.54.200.in-addr.arpa. 38400 IN NS ns.jbv.cl.
;; ADDITIONAL SECTION:
ns.jbv.cl. 38400 IN A 200.54.163.178


If I make the same query to (jbv.cl) returns the reverse without problems



What is the problem with my DNS? I've waited a week waiting for it to spread but nothing.



Here the configuration of my DNS server Ubuntu server 16.04



Named.conf.local



zone "jbv.cl" {
type master;
file "/var/lib/bind/jbv.cl.hosts";
};
zone "grupojbv.cl" {
type master;
file "/var/lib/bind/grupojbv.cl.hosts";
};
zone "163.54.200.in-addr.arpa" {
type master;
file "/var/lib/bind/200.54.163.rev";
};


/var/lib/bind/jbv.cl.hosts (jbv.cl)



$ttl 38400
jbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1500432573
10800
3600
604800
38400 )
jbv.cl. IN NS ns.jbv.cl.
www.jbv.cl. IN CNAME jbv.cl.
jbv.cl. IN MX 10 mail.jbv.cl.
jbv.cl. IN A 200.54.163.181
ns.jbv.cl. IN A 200.54.163.178
mail.jbv.cl. IN A 200.54.163.182


/var/lib/bind/grupojbv.cl.hosts (grupojbv.cl)



$ttl 38400

grupojbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1500432643
10800
3600
604800
38400 )
grupojbv.cl. IN NS ns.jbv.cl.
grupojbv.cl. IN MX 20 smtp.grupojbv.cl.
smtp.grupojbv.cl. IN A 200.54.163.179


/var/lib/bind/200.54.163.rev



$ttl 38400
jbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1501037500
10800
3600
604800
38400 )
163.54.200.in-addr.arpa. IN NS ns.jbv.cl.
179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.
182.163.54.200.in-addr.arpa. IN PTR mail.jbv.cl.


Why the other dns servers do not solve the reverse of smtp.grupojbv.cl










share|improve this question
















I have an installation of Zimbra 8.7 CS multi server



Server A: single-server installation (mail.jbv.cl 200.54.163.182) with two domains (jbv.cl and grupojbv.cl)



Server B: a second MTA (smtp.grupojbv.cl 200.54.163.179)



Server C: external dns (ns.jbv.cl 200.54.163.178)



I configured it this way since I need the mails from jbv.cl to exit from server A and the mails from grupojbv.cl to exit from server B.
The configuration works on the server without problem and each one uses the assigned mta, the problem is in my public DNS (ns.jbv.cl) which I manage, the point that does not solve the reverse of server B (smtp.grupojbv.cl)



If I make a query to the Google servers (8.8.8.8) throw me this:



Dig -x 200.54.163.179 @8.8.8.8



;; QUESTION SECTION:
;179.163.54.200.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
163.54.200.in-addr.arpa. 1799 IN SOA qip1.redip.cl. root.redip.cl. 2017062801 21600 3600 604800 86400


But if I do the same query my public dns throws this:



Dig -x 200.54.163.179 @ns.jbv.cl



;; QUESTION SECTION:
;179.163.54.200.in-addr.arpa. IN PTR
;; ANSWER SECTION:
179.163.54.200.in-addr.arpa. 38400 IN PTR smtp.grupojbv.cl.
;; AUTHORITY SECTION:
179.163.54.200.in-addr.arpa. 38400 IN NS ns.jbv.cl.
;; ADDITIONAL SECTION:
ns.jbv.cl. 38400 IN A 200.54.163.178


If I make the same query to (jbv.cl) returns the reverse without problems



What is the problem with my DNS? I've waited a week waiting for it to spread but nothing.



Here the configuration of my DNS server Ubuntu server 16.04



Named.conf.local



zone "jbv.cl" {
type master;
file "/var/lib/bind/jbv.cl.hosts";
};
zone "grupojbv.cl" {
type master;
file "/var/lib/bind/grupojbv.cl.hosts";
};
zone "163.54.200.in-addr.arpa" {
type master;
file "/var/lib/bind/200.54.163.rev";
};


/var/lib/bind/jbv.cl.hosts (jbv.cl)



$ttl 38400
jbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1500432573
10800
3600
604800
38400 )
jbv.cl. IN NS ns.jbv.cl.
www.jbv.cl. IN CNAME jbv.cl.
jbv.cl. IN MX 10 mail.jbv.cl.
jbv.cl. IN A 200.54.163.181
ns.jbv.cl. IN A 200.54.163.178
mail.jbv.cl. IN A 200.54.163.182


/var/lib/bind/grupojbv.cl.hosts (grupojbv.cl)



$ttl 38400

grupojbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1500432643
10800
3600
604800
38400 )
grupojbv.cl. IN NS ns.jbv.cl.
grupojbv.cl. IN MX 20 smtp.grupojbv.cl.
smtp.grupojbv.cl. IN A 200.54.163.179


/var/lib/bind/200.54.163.rev



$ttl 38400
jbv.cl. IN SOA ns.jbv.cl. admin.jbv.cl. (
1501037500
10800
3600
604800
38400 )
163.54.200.in-addr.arpa. IN NS ns.jbv.cl.
179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.
182.163.54.200.in-addr.arpa. IN PTR mail.jbv.cl.


Why the other dns servers do not solve the reverse of smtp.grupojbv.cl







linux dns bind






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 6 hours ago









Rui F Ribeiro

42.2k1484142




42.2k1484142










asked Aug 9 '17 at 2:12









Jonnathan ClayJonnathan Clay

61




61













  • Just use 179 IN PTR smtp.grupojbv.cl. (instead of 179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.) in RR declaration.

    – heemayl
    Aug 9 '17 at 6:00



















  • Just use 179 IN PTR smtp.grupojbv.cl. (instead of 179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.) in RR declaration.

    – heemayl
    Aug 9 '17 at 6:00

















Just use 179 IN PTR smtp.grupojbv.cl. (instead of 179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.) in RR declaration.

– heemayl
Aug 9 '17 at 6:00





Just use 179 IN PTR smtp.grupojbv.cl. (instead of 179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.) in RR declaration.

– heemayl
Aug 9 '17 at 6:00










1 Answer
1






active

oldest

votes


















1














The main fault I see with your .in-addr.arpa ("reverse DNS") domain is that the SOA record is wrong. You are declaring it to be the Start Of Authority record for the jbv.cl. domain, rather than for the 163.54.200.in-addr.arpa. domain.



In /var/lib/bind/200.54.163.rev, you need to replace this:



jbv.cl.                   IN      SOA      ns.jbv.cl. admin.jbv.cl. (


with this:



163.54.200.in-addr.arpa.  IN      SOA      ns.jbv.cl. admin.jbv.cl. (


Or, better yet:



@    IN      SOA      ns.jbv.cl. admin.jbv.cl. (


@ is an alias for the current $ORIGIN - bind knows what it is, you told it in named.conf.local when you defined the zone. Also, you don't have to specify the FQDN for every entry - any unqualified or incompletely-qualified name (i.e. one that doesn't end with a .) has $ORIGIN appended to it.



If you want, you can explicitly define $ORIGIN at the top of the file. That's optional, but serves nicely as self-documentation for the file. Setting $ORIGIN is mostly used when defining a domain and one or more subdomains in the same zonefile, changing $ORIGIN as needed to change what gets appended to non-FQDN names.



See, e.g., https://en.wikipedia.org/wiki/Zone_file, which says:




The zone file may also contain various directives that are marked with
a keyword starting with the dollar sign character. The most notable is
the $ORIGIN keyword, which specifies the starting point for the zone
in the DNS hierarchy. If this keyword is omitted from a zone file, the
origin is inferred by the server software from the reference to the
zone file in its server configuration.




Your 200.54.163.rev "reverse DNS" zonefile should look like this:



$ORIGIN 163.54.200.in-addr.arpa.
$TTL 38400
@ IN SOA ns.jbv.cl. admin.jbv.cl. (
1501037500
10800
3600
604800
38400 )

@ IN NS ns.jbv.cl.

179 IN PTR smtp.grupojbv.cl.
182 IN PTR mail.jbv.cl.


That's much easier to read and to work with when making changes.



The same is true for your other domains. Use @ in the SOA and NS records and ditch the FQDN on the LHS of each record.





I very strongly recommend you do some more reading about DNS and Zone Files - whether you look after your own DNS servers or outsource them to someone else. Understanding how DNS works is essential for anyone who manages a domain.



If you don't have a copy of the O'Reilly DNS and Bind book (IMO an almost essential book for anyone working with DNS servers. Even a second-hand older edition is very much worth having if you can't get the latest edition - the latest I own is the 2nd Edition from 1997), start with the Wikipedia Zone File page I linked to above.






share|improve this answer
























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f384863%2freverse-dns-fail%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    The main fault I see with your .in-addr.arpa ("reverse DNS") domain is that the SOA record is wrong. You are declaring it to be the Start Of Authority record for the jbv.cl. domain, rather than for the 163.54.200.in-addr.arpa. domain.



    In /var/lib/bind/200.54.163.rev, you need to replace this:



    jbv.cl.                   IN      SOA      ns.jbv.cl. admin.jbv.cl. (


    with this:



    163.54.200.in-addr.arpa.  IN      SOA      ns.jbv.cl. admin.jbv.cl. (


    Or, better yet:



    @    IN      SOA      ns.jbv.cl. admin.jbv.cl. (


    @ is an alias for the current $ORIGIN - bind knows what it is, you told it in named.conf.local when you defined the zone. Also, you don't have to specify the FQDN for every entry - any unqualified or incompletely-qualified name (i.e. one that doesn't end with a .) has $ORIGIN appended to it.



    If you want, you can explicitly define $ORIGIN at the top of the file. That's optional, but serves nicely as self-documentation for the file. Setting $ORIGIN is mostly used when defining a domain and one or more subdomains in the same zonefile, changing $ORIGIN as needed to change what gets appended to non-FQDN names.



    See, e.g., https://en.wikipedia.org/wiki/Zone_file, which says:




    The zone file may also contain various directives that are marked with
    a keyword starting with the dollar sign character. The most notable is
    the $ORIGIN keyword, which specifies the starting point for the zone
    in the DNS hierarchy. If this keyword is omitted from a zone file, the
    origin is inferred by the server software from the reference to the
    zone file in its server configuration.




    Your 200.54.163.rev "reverse DNS" zonefile should look like this:



    $ORIGIN 163.54.200.in-addr.arpa.
    $TTL 38400
    @ IN SOA ns.jbv.cl. admin.jbv.cl. (
    1501037500
    10800
    3600
    604800
    38400 )

    @ IN NS ns.jbv.cl.

    179 IN PTR smtp.grupojbv.cl.
    182 IN PTR mail.jbv.cl.


    That's much easier to read and to work with when making changes.



    The same is true for your other domains. Use @ in the SOA and NS records and ditch the FQDN on the LHS of each record.





    I very strongly recommend you do some more reading about DNS and Zone Files - whether you look after your own DNS servers or outsource them to someone else. Understanding how DNS works is essential for anyone who manages a domain.



    If you don't have a copy of the O'Reilly DNS and Bind book (IMO an almost essential book for anyone working with DNS servers. Even a second-hand older edition is very much worth having if you can't get the latest edition - the latest I own is the 2nd Edition from 1997), start with the Wikipedia Zone File page I linked to above.






    share|improve this answer




























      1














      The main fault I see with your .in-addr.arpa ("reverse DNS") domain is that the SOA record is wrong. You are declaring it to be the Start Of Authority record for the jbv.cl. domain, rather than for the 163.54.200.in-addr.arpa. domain.



      In /var/lib/bind/200.54.163.rev, you need to replace this:



      jbv.cl.                   IN      SOA      ns.jbv.cl. admin.jbv.cl. (


      with this:



      163.54.200.in-addr.arpa.  IN      SOA      ns.jbv.cl. admin.jbv.cl. (


      Or, better yet:



      @    IN      SOA      ns.jbv.cl. admin.jbv.cl. (


      @ is an alias for the current $ORIGIN - bind knows what it is, you told it in named.conf.local when you defined the zone. Also, you don't have to specify the FQDN for every entry - any unqualified or incompletely-qualified name (i.e. one that doesn't end with a .) has $ORIGIN appended to it.



      If you want, you can explicitly define $ORIGIN at the top of the file. That's optional, but serves nicely as self-documentation for the file. Setting $ORIGIN is mostly used when defining a domain and one or more subdomains in the same zonefile, changing $ORIGIN as needed to change what gets appended to non-FQDN names.



      See, e.g., https://en.wikipedia.org/wiki/Zone_file, which says:




      The zone file may also contain various directives that are marked with
      a keyword starting with the dollar sign character. The most notable is
      the $ORIGIN keyword, which specifies the starting point for the zone
      in the DNS hierarchy. If this keyword is omitted from a zone file, the
      origin is inferred by the server software from the reference to the
      zone file in its server configuration.




      Your 200.54.163.rev "reverse DNS" zonefile should look like this:



      $ORIGIN 163.54.200.in-addr.arpa.
      $TTL 38400
      @ IN SOA ns.jbv.cl. admin.jbv.cl. (
      1501037500
      10800
      3600
      604800
      38400 )

      @ IN NS ns.jbv.cl.

      179 IN PTR smtp.grupojbv.cl.
      182 IN PTR mail.jbv.cl.


      That's much easier to read and to work with when making changes.



      The same is true for your other domains. Use @ in the SOA and NS records and ditch the FQDN on the LHS of each record.





      I very strongly recommend you do some more reading about DNS and Zone Files - whether you look after your own DNS servers or outsource them to someone else. Understanding how DNS works is essential for anyone who manages a domain.



      If you don't have a copy of the O'Reilly DNS and Bind book (IMO an almost essential book for anyone working with DNS servers. Even a second-hand older edition is very much worth having if you can't get the latest edition - the latest I own is the 2nd Edition from 1997), start with the Wikipedia Zone File page I linked to above.






      share|improve this answer


























        1












        1








        1







        The main fault I see with your .in-addr.arpa ("reverse DNS") domain is that the SOA record is wrong. You are declaring it to be the Start Of Authority record for the jbv.cl. domain, rather than for the 163.54.200.in-addr.arpa. domain.



        In /var/lib/bind/200.54.163.rev, you need to replace this:



        jbv.cl.                   IN      SOA      ns.jbv.cl. admin.jbv.cl. (


        with this:



        163.54.200.in-addr.arpa.  IN      SOA      ns.jbv.cl. admin.jbv.cl. (


        Or, better yet:



        @    IN      SOA      ns.jbv.cl. admin.jbv.cl. (


        @ is an alias for the current $ORIGIN - bind knows what it is, you told it in named.conf.local when you defined the zone. Also, you don't have to specify the FQDN for every entry - any unqualified or incompletely-qualified name (i.e. one that doesn't end with a .) has $ORIGIN appended to it.



        If you want, you can explicitly define $ORIGIN at the top of the file. That's optional, but serves nicely as self-documentation for the file. Setting $ORIGIN is mostly used when defining a domain and one or more subdomains in the same zonefile, changing $ORIGIN as needed to change what gets appended to non-FQDN names.



        See, e.g., https://en.wikipedia.org/wiki/Zone_file, which says:




        The zone file may also contain various directives that are marked with
        a keyword starting with the dollar sign character. The most notable is
        the $ORIGIN keyword, which specifies the starting point for the zone
        in the DNS hierarchy. If this keyword is omitted from a zone file, the
        origin is inferred by the server software from the reference to the
        zone file in its server configuration.




        Your 200.54.163.rev "reverse DNS" zonefile should look like this:



        $ORIGIN 163.54.200.in-addr.arpa.
        $TTL 38400
        @ IN SOA ns.jbv.cl. admin.jbv.cl. (
        1501037500
        10800
        3600
        604800
        38400 )

        @ IN NS ns.jbv.cl.

        179 IN PTR smtp.grupojbv.cl.
        182 IN PTR mail.jbv.cl.


        That's much easier to read and to work with when making changes.



        The same is true for your other domains. Use @ in the SOA and NS records and ditch the FQDN on the LHS of each record.





        I very strongly recommend you do some more reading about DNS and Zone Files - whether you look after your own DNS servers or outsource them to someone else. Understanding how DNS works is essential for anyone who manages a domain.



        If you don't have a copy of the O'Reilly DNS and Bind book (IMO an almost essential book for anyone working with DNS servers. Even a second-hand older edition is very much worth having if you can't get the latest edition - the latest I own is the 2nd Edition from 1997), start with the Wikipedia Zone File page I linked to above.






        share|improve this answer













        The main fault I see with your .in-addr.arpa ("reverse DNS") domain is that the SOA record is wrong. You are declaring it to be the Start Of Authority record for the jbv.cl. domain, rather than for the 163.54.200.in-addr.arpa. domain.



        In /var/lib/bind/200.54.163.rev, you need to replace this:



        jbv.cl.                   IN      SOA      ns.jbv.cl. admin.jbv.cl. (


        with this:



        163.54.200.in-addr.arpa.  IN      SOA      ns.jbv.cl. admin.jbv.cl. (


        Or, better yet:



        @    IN      SOA      ns.jbv.cl. admin.jbv.cl. (


        @ is an alias for the current $ORIGIN - bind knows what it is, you told it in named.conf.local when you defined the zone. Also, you don't have to specify the FQDN for every entry - any unqualified or incompletely-qualified name (i.e. one that doesn't end with a .) has $ORIGIN appended to it.



        If you want, you can explicitly define $ORIGIN at the top of the file. That's optional, but serves nicely as self-documentation for the file. Setting $ORIGIN is mostly used when defining a domain and one or more subdomains in the same zonefile, changing $ORIGIN as needed to change what gets appended to non-FQDN names.



        See, e.g., https://en.wikipedia.org/wiki/Zone_file, which says:




        The zone file may also contain various directives that are marked with
        a keyword starting with the dollar sign character. The most notable is
        the $ORIGIN keyword, which specifies the starting point for the zone
        in the DNS hierarchy. If this keyword is omitted from a zone file, the
        origin is inferred by the server software from the reference to the
        zone file in its server configuration.




        Your 200.54.163.rev "reverse DNS" zonefile should look like this:



        $ORIGIN 163.54.200.in-addr.arpa.
        $TTL 38400
        @ IN SOA ns.jbv.cl. admin.jbv.cl. (
        1501037500
        10800
        3600
        604800
        38400 )

        @ IN NS ns.jbv.cl.

        179 IN PTR smtp.grupojbv.cl.
        182 IN PTR mail.jbv.cl.


        That's much easier to read and to work with when making changes.



        The same is true for your other domains. Use @ in the SOA and NS records and ditch the FQDN on the LHS of each record.





        I very strongly recommend you do some more reading about DNS and Zone Files - whether you look after your own DNS servers or outsource them to someone else. Understanding how DNS works is essential for anyone who manages a domain.



        If you don't have a copy of the O'Reilly DNS and Bind book (IMO an almost essential book for anyone working with DNS servers. Even a second-hand older edition is very much worth having if you can't get the latest edition - the latest I own is the 2nd Edition from 1997), start with the Wikipedia Zone File page I linked to above.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Aug 9 '17 at 9:50









        cascas

        39.6k456103




        39.6k456103






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f384863%2freverse-dns-fail%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

            Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

            Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...