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;
}
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
add a comment |
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
Just use179 IN PTR smtp.grupojbv.cl.
(instead of179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.
) in RR declaration.
– heemayl
Aug 9 '17 at 6:00
add a comment |
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
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
linux dns bind
edited 6 hours ago
Rui F Ribeiro
42.2k1484142
42.2k1484142
asked Aug 9 '17 at 2:12
Jonnathan ClayJonnathan Clay
61
61
Just use179 IN PTR smtp.grupojbv.cl.
(instead of179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.
) in RR declaration.
– heemayl
Aug 9 '17 at 6:00
add a comment |
Just use179 IN PTR smtp.grupojbv.cl.
(instead of179.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
add a comment |
1 Answer
1
active
oldest
votes
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.
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
answered Aug 9 '17 at 9:50
cascas
39.6k456103
39.6k456103
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Just use
179 IN PTR smtp.grupojbv.cl.
(instead of179.163.54.200.in-addr.arpa. IN PTR smtp.grupojbv.cl.
) in RR declaration.– heemayl
Aug 9 '17 at 6:00