date:20091105

Re: PTR zone /28 not working

2009-11-05 Thread Kevin Darcy


joans4nz wrote:

Hi,

Thank you Mr Mark Andrews for your answer, and yes, I want help. I am 
sorry about my first message, I repeat bellow, so I change all 
CCC.BBB.AAA.in-addr.arpa's to my real numbers. Thank you one more 
time, but i don't understand very well your answers.


You said: Well you don't serve 66.6.190.in-addr.arpa and you don't 
allow recursion. You should make yourself a stealth slave for 
66.6.190.in-addr.arpa. That way reverse lookups will continue to work 
when your external link goes down. It will also allow remote tools to 
not require recursion to be enabled to find the CNAME records when 
they query your server.




So do I must configure the zone 66.6.190.in-addr.arpa. as slave in my 
named.conf, and in the zone file do I must write the same SOA 
configuration of my ISP for this zone with the same serial, mail 
address, . and in NS records write this?


 IN   NS   ns1.etecsa.net    ;My ISP name 
server
 IN   NS   ns2.etecsa.net    ;My ISP name 
server
 IN   NS   ns3.etecsa.net    ;My ISP name 
server
 IN   NS   ns4.etecsa.net    ;My ISP name 
server

 IN   NS   ns1.mincex.cu    ;My name server # 1
 IN   NS   ns2.mincex.cu    ;My name server # 2
You don't write records manually into a slave zone. You replicate the 
entire contents of the zone from the master server(s).


Is that correct? Because I don't know if my ISP allow transfer a copy 
of this zone to my DNS servers, I think is not allowed.
Mark was making a suggestion, it's not strictly necessary to get your 
reverse lookups working. But it is highly recommended, for redundancy 
and performance. Your ISP should open up zone transfers. You have, after 
all, been assigned part of that address range for your use. You are a 
legitimate "stakeholder", and should already have a business and trust 
relationship with your ISP. Get them to do it.


Unless you slave 66.6.190.in-addr.arpa or otherwise make a specific 
exception for it in your config, then queries for those names will fall 
into your default "deny" rule and you'll continue to get REFUSED responses.


You said: The zone's name is 224/28.66.6.190.in-addr.arpa, 
226.66.6.190.in-addr.arpa in not part of the zone.


Why not? If my new ip range address are from 190.6.66.25 to 
190.6.66.238, I think 224/28.66.6.190.in-addr.arpa include 
226.66.6.190.in-addr.arpa address. Please explain me more about it?
Here's the key insight: BIND and DNS aren't treating those 
label-concatenations as addresses, only as names.


As a *name*, 226.66.6.190.in-addr.arpa is *not* contained within the 
224/28.66.6.190.in-addr.arpa subdomain any more than 
now.is.the.time.for.all.good.men is contained in 
heed/well.the.time.for.all.good.men. They share a common point in the 
hierarchy, but neither one contains the other.


Understand? They're *names*. There is no "address intelligence" or "CIDR 
intelligence" by DNS with respect to the in-addr.arpa tree. It's treated 
just a sequence of labels that happens to follow a particular naming 
convention.


You don't even need to use CIDR ("slash") notation as the convention, by 
the way. Read RFC 2317.  Some folks even opt -- in co-operation with 
their ISP -- to point those CNAMEs to PTRs residing in their "forward" zone:


In 3.2.1.in-addr.arpa;
4.3.2.1.in-addr.arpa. cname 4.3.2.1.rev.example.com.

In example.com:
4.3.2.1.rev.example.com. ptr foo.example.com.

which is perfectly legal.

They're just names. You can put them anywhere, the CNAMEs just need to 
point to the right place. Since your ISP maintains the CNAMEs they get 
the final say on where they point, but you can make suggestions.



- Kevin




-

Hi,

I use Bind-9.4.2 running on FreeBSD-7.2.

Last week my DNS was reconfigured to a new IP address pool by my ISP 
and by me from a /29 to /28 address range.


Using "How is my DNS" I check my domain and all is good except reverse 
lookup. My ISP also reconfigured the PTR zone and delegate the reverse 
zone like RFC-2317 and this is the change executed by my ISP.


224/28   IN   NS   ns1.mincex.cu 
224/28   IN   NS   ns2.mincex.cu 
225IN   CNAME   225.224/28.66.6.190.in-addr.arpa.
226IN   CNAME   226.224/28.66.6.190.in-addr.arpa.
227IN   CNAME   227.224/28.66.6.190.in-addr.arpa.
228IN   CNAME   228.224/28.66.6.190.in-addr.arpa.
229IN   CNAME   229.224/28.66.6.190.in-addr.arpa.
230IN   CNAME   230.224/28.66.6.190.in-addr.arpa.
231IN   CNAME   231.224/28.66.6.190.in-addr.arpa.
232IN   CNAME   232.224/28.66.6.190.in-addr.arpa.
233IN   CNAME   233.224/28.66.6.190.in-addr.arpa.
234IN   CNAME   234.224/28.66.6.190.in-addr.arpa.
235IN   CNAME   235.224/28.66.6.

Re: PTR zone /28 not working

2009-11-05 Thread Chris Thompson


On Nov 5 2009, joans4nz wrote:


Hi,

Thank you Mr Mark Andrews for your answer, and yes, I want help. I am sorry
about my first message, I repeat bellow, so I change all
CCC.BBB.AAA.in-addr.arpa's to my real numbers. 


That certainly helps. Look at this:

$ dig +trace soa 224/28.66.6.190.in-addr.arpa.

; <<>> DiG 9.7.0b1 <<>> +trace soa 224/28.66.6.190.in-addr.arpa.
;; global options: +cmd
.   318331  IN  NS  F.ROOT-SERVERS.NET.
.   318331  IN  NS  M.ROOT-SERVERS.NET.
.   318331  IN  NS  J.ROOT-SERVERS.NET.
.   318331  IN  NS  E.ROOT-SERVERS.NET.
.   318331  IN  NS  B.ROOT-SERVERS.NET.
.   318331  IN  NS  A.ROOT-SERVERS.NET.
.   318331  IN  NS  K.ROOT-SERVERS.NET.
.   318331  IN  NS  D.ROOT-SERVERS.NET.
.   318331  IN  NS  G.ROOT-SERVERS.NET.
.   318331  IN  NS  C.ROOT-SERVERS.NET.
.   318331  IN  NS  H.ROOT-SERVERS.NET.
.   318331  IN  NS  L.ROOT-SERVERS.NET.
.   318331  IN  NS  I.ROOT-SERVERS.NET.
;; Received 376 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

190.in-addr.arpa.   86400   IN  NS  SEC3.APNIC.NET.
190.in-addr.arpa.   86400   IN  NS  NS3.AFRINIC.NET.
190.in-addr.arpa.   86400   IN  NS  NS2.LACNIC.NET.
190.in-addr.arpa.   86400   IN  NS  NS-SEC.RIPE.NET.
190.in-addr.arpa.   86400   IN  NS  NS2.DNS.BR.
190.in-addr.arpa.   86400   IN  NS  NS.LACNIC.NET.
190.in-addr.arpa.   86400   IN  NS  TINNIE.ARIN.NET.
;; Received 218 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 175 ms

66.6.190.in-addr.arpa.  86400   IN  NS  ns1.etecsa.net.
66.6.190.in-addr.arpa.  86400   IN  NS  ns2.etecsa.net.
;; Received 92 bytes from 2001:dc0:1:0:4777::140#53(SEC3.APNIC.NET) in 312 ms

224/28.66.6.190.in-addr.arpa. 2000 IN   NS  
ns1.mincex.cu.66.6.190.in-addr.arpa.
224/28.66.6.190.in-addr.arpa. 2000 IN   NS  
ns2.mincex.cu.66.6.190.in-addr.arpa.
;; Received 92 bytes from 200.55.128.4#53(ns2.etecsa.net) in 676 ms

;; connection timed out; no servers could be reached

The delegation of 224/28.66.6.190.in-addr.arpa from 66.6.190.in-addr.arpa
has been mangled. It reports the authoritative nameservers for the subzone
as

  ns1.mincex.cu.66.6.190.in-addr.arpa.
  ns2.mincex.cu.66.6.190.in-addr.arpa.

(and of course they do not exist) whereas they are almost certainly
meant to be

  ns1.mincex.cu.
  ns2.mincex.cu.

Classic case of "leaving out the trailing dot".

But even if that were corrected, it turns out that ns1.mincex.cu and
ns2.mincex.cu have never heard of 224/28.66.6.190.in-addr.arpa. and
also have an entirely different version of 66.6.190.in-addr.arpa than
ns1.etecsa.net and ns2.etecsa.net do. You have a lot of errors to
correct.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: PTR zone /28 not working

2009-11-05 Thread Mark Andrews


First you should ask your ISP to fix the names of the nameservers
in the delegation of 224/28.66.6.190.in-addr.arpa.  It looks like
they left the final period off the names.  This is a relatively
common stuff up.

225.66.6.190.in-addr.arpa. 2000 IN  CNAME   
225.224/28.66.6.190.in-addr.arpa.
224/28.66.6.190.in-addr.arpa. 2000 IN   NS  
ns2.mincex.cu.66.6.190.in-addr.arpa.
224/28.66.6.190.in-addr.arpa. 2000 IN   NS  
ns1.mincex.cu.66.6.190.in-addr.arpa.
;; Received 114 bytes from 200.55.128.3#53(ns1.etecsa.net) in 1536 ms

[Note: I only found this because you have now given me the real domain names
involved.]

Next you should configure your nameservers to be stealth slaves for
66.6.190.in-addr.arpa.  If your ISP blocks this, find another ISP
as they don't know what they are doing.  You *need* this to allow
internal reverse lookups to succeed when the external link is down.

zone "66.6.190.in-addr.arpa" {
type slave;
notify no;  // don't send notify messages to the offical servers
masters { 200.55.128.3; 200.55.128.4; 200.55.128.10; 200.55.128.11; };
file "66.6.190.in-addr.arpa.db";
allow-transfer { none; };
};

The PTR records go in the 224/28.66.6.190.in-addr.arpa zone for which one
of you machines will be master and the other slave.

On ns1.mincex.cu:

zone "224/28.66.6.190.in-addr.arpa" {
type master;
file "224-28.66.6.190.in-addr.arpa.db";
};

224-28.66.6.190.in-addr.arpa.db:
$TTL 38400
@ SOA ns1.mincex.cu. chismoso.mincex.cu. 2009110401 10800 3600 604800 38400
@ NS ns1.mincex.cu.
@ NS ns2.mincex.cu.
226 PTR ns1.mincex.cu.
227 PTR ns2.mincex.cu.

On ns2.mincex.cu:

zone "224/28.66.6.190.in-addr.arpa" {
type slave;
master { 190.6.66.226; };
file "224-28.66.6.190.in-addr.arpa.db";
};


In message <58636e100911051001u195d5c86rb80905a0e91c1...@mail.gmail.com>, joans
4nz writes:
> --===4159216347487687440==
> Content-Type: multipart/alternative; boundary=0015175defdc1141090477a385b9
> 
> --0015175defdc1141090477a385b9
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi,
> 
> Thank you Mr Mark Andrews for your answer, and yes, I want help. I am sorry
> about my first message, I repeat bellow, so I change all
> CCC.BBB.AAA.in-addr.arpa's to my real numbers. Thank you one more time, but
> i don't understand very well your answers.
> 
> You said: Well you don't serve 66.6.190.in-addr.arpa and you don't allow
> recursion. You should make yourself a stealth slave for
> 66.6.190.in-addr.arpa. That way reverse lookups will continue to work when
> your external link goes down. It will also allow remote tools to not require
> recursion to be enabled to find the CNAME records when they query your
> server.
> 
> So do I must configure the zone 66.6.190.in-addr.arpa. as slave in my
> named.conf, and in the zone file do I must write the same SOA configuration
> of my ISP for this zone with the same serial, mail address, . and in NS
> records write this?
> 
>  IN   NS   ns1.etecsa.net   ;My ISP name server
>  IN   NS   ns2.etecsa.net   ;My ISP name server
>  IN   NS   ns3.etecsa.net   ;My ISP name server
>  IN   NS   ns4.etecsa.net   ;My ISP name server
>  IN   NS   ns1.mincex.cu   ;My name server # 1
>  IN   NS   ns2.mincex.cu   ;My name server # 2
> 
> Is that correct? Because I don't know if my ISP allow transfer a copy of
> this zone to my DNS servers, I think is not allowed.
> 
> You said: The zone's name is 224/28.66.6.190.in-addr.arpa,
> 226.66.6.190.in-addr.arpa in not part of the zone.
> 
> Why not? If my new ip range address are from 190.6.66.25 to 190.6.66.238, I
> think 224/28.66.6.190.in-addr.arpa include 226.66.6.190.in-addr.arpa
> address. Please explain me more about it?

"226.66.6.190.in-addr.arpa" does not end in "224/28.66.6.190.in-addr.arpa"
so it is not part of the "224/28.66.6.190.in-addr.arpa" zone.  This
has nothing to do with which IP addresses you are using.  It is
related to which DNS namespaces are in use.

Mark

> -
> 
> Hi,
> 
> I use Bind-9.4.2 running on FreeBSD-7.2.
> 
> Last week my DNS was reconfigured to a new IP address pool by my ISP and by
> me from a /29 to /28 address range.
> 
> Using "How is my DNS" I check my domain and all is good except reverse
> lookup. My ISP also reconfigured the PTR zone and delegate the reverse zone
> like RFC-2317 and this is the change executed by my ISP.
> 
> 224/28   IN   NS   ns1.mincex.cu
> 224/28   IN   NS   ns2.mincex.cu
> 225IN   CNAME   225.224/28.66.6.190.in-addr.arpa.
> 226IN   CNAME   226.224/28.66.6.190.in-addr.arpa.
> 227IN   CNAME   227.224/28.66.6.190.in-addr.arpa.
> 228IN   CNAME   228.224/28.66.6.190.in-addr.arpa.
> 229IN   CNAME   229.224/28.66.6.190.in-addr.arpa.
> 230IN   CNAME   230.224/28.66.6.190.in-addr.arpa.
> 231IN   CNAME   231.224/28.66.6.190.in-addr.arpa.
> 232IN   CNAME   232.224/28.66.6.190.in-addr.a

PTR zone /28 not working

2009-11-05 Thread joans4nz

Thank you very much Kevin, Chris and Mark for your answers, you all has
given to me a good lesson about DNS and Bind.

Thank you very much one more time.

joans4nz.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: PTR zone /28 not working

Re: PTR zone /28 not working

Re: PTR zone /28 not working

PTR zone /28 not working

4 matches

Site Navigation

Mail list logo

Footer information