Re: Reverse lookup for classless networks

[Mark Andrews]

Because it requires the parent zone with the CNAME records to also be set up 
which maps the well known query names to the alternate names. 


-- 
Mark Andrews

> On 27 Dec 2018, at 21:01, Nagesh Thati  wrote:
> 
> Hello,
> I have been trying to make the reverse zones for the classless networks. I 
> was able to create such zones by following an online guide. The guide says to 
> create a reverse zone for a classless network as following,
> Network: 28.0.0.0/27
> Reverse Zone: 0-27.128.0.0.28.in-addr.arpa.
> Example PTR record: 130.0-27.128.0.0.28.in-addr.arpa. PTR test.example.com.
> 
> Now the zone is up, but I have problem in looking up the IP address using the 
> below method,
> dig @localhost -x 28.0.0.130
> 
> While the above lookup is not working, the below method is working,
> > dig @localhost 130.0-27.128.0.0.28.in-addr.arpa. PTR +short
> > 3G2Phone.adparent.com.
> 
> Now can someone tell me why the first method is not working, will my reverse 
> zone work properly in the real world?
> 
> Thanks for your help.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Reverse lookup for classless networks

[Nagesh Thati]

Thanks Mark,
But is there any other way without using any CNAMEs?

On Thu, Dec 27, 2018 at 4:45 PM Mark Andrews  wrote:

> Because it requires the parent zone with the CNAME records to also be set
> up which maps the well known query names to the alternate names.
>
>
> --
> Mark Andrews
>
> On 27 Dec 2018, at 21:01, Nagesh Thati  wrote:
>
> Hello,
> I have been trying to make the reverse zones for the classless networks. I
> was able to create such zones by following an online guide. The guide says
> to create a reverse zone for a classless network as following,
> Network: *28.0.0.0/27 *
> Reverse Zone: *0-27.128.0.0.28.in-addr.arpa.*
> Example PTR record: *130.0-27.128.0.0.28.in-addr.arpa. PTR
> test.example.com .*
>
> Now the zone is up, but I have problem in looking up the IP address using
> the below method,
> *dig @localhost -x 28.0.0.130*
>
> While the above lookup is not working, the below method is working,
> *> dig @localhost 130.0-27.128.0.0.28.in-addr.arpa. PTR +short*
> *> 3G2Phone.adparent.com .*
>
>
>
> *Now can someone tell me why the first method is not working, will my
> reverse zone work properly in the real world?*
> Thanks for your help.
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Reverse lookup for classless networks

[Barry Margolin]

In article ,
 Nagesh Thati  wrote:

> Thanks Mark,
> But is there any other way without using any CNAMEs?

The alternative is to have a separate zone for each address, and 
delegate each of them to your server. So the parent zone would have:

0 IN NS ns1.yourdomain.com.
  IN NS ns2.yourdomain.com.
1 IN NS ns1.yourdomain.com.
  IN NS ns2.yourdomain.com.
and so on...

Either way, the parent zone needs to have specific records for each of 
the addresses in the subnet. The client always tries to look up 
w.x.y.z.in-addr.arpa, and only supports delegation at "." boundaries in 
the name. There's no way for it to know automatically that different "w" 
values are delegated to different servers.

-- 
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Reverse lookup for classless networks

[Grant Taylor via bind-users]

On 12/27/18 9:01 AM, Barry Margolin wrote:
The alternative is to have a separate zone for each address, and delegate 
each of them to your server. So the parent zone would have:


It does not require a separate zone for each address.  But it does 
require some creative zone work.


; 1.0.192.in-addr.arpa.zone on parent nameservers ns{1,2}.parent.example.
$ORIGIN 1.0.192.in-addr.arpa.
0   IN NS  ns1.yourdomain.com.
IN NS  ns2.yourdomain.com.
1   IN NS  ns1.yourdomain.com.
IN NS  ns2.yourdomain.com.
...
128 IN PTR host128.example.net.
129 IN PTR host129.example.net.
...

Yes.  This works perfectly from everything I've tested.  I've had issues 
in the past with Classless IN-ADDR.ARPA delegation.  (Particularly with 
not-small-name RBL providers not liking it 15+ years ago.)


Either way, the parent zone needs to have specific records for each 
of the addresses in the subnet. The client always tries to look up 
w.x.y.z.in-addr.arpa, and only supports delegation at "." boundaries 
in the name. There's no way for it to know automatically that different 
"w" values are delegated to different servers.


This is simply re-using the same standard delegation we use for 
(sub)domains elsewhere in the hierarchy.


As for the zones themselves:

1)  The parent zone needs to have the delegation like Barry depicted above.
2)  The child zone needs to have records for the name being looked up. 
Nothing specifically translates to them needing to be in separate zones.


I could easily create a zone like this:

; 1.0.192.in-addr.arpa.zone on local nameservers ns{1,2}.yourdomain.com
$ORIGIN 1.0.192.in-addr.arpa.
0   IN PTR web.yourdomain.com.
1   IN PTR ftp.yourdomain.com.
...
128 IN NS  ns1.parent.example.
IN NS  ns2.parent.example.
129 IN NS  ns1.parent.example.
IN NS  ns2.parent.example.
...

In essence, you end up with two independent zones for the same domain 
name, 1.0.192.in-addr.arpa, cross delegating /different/ records to each 
other.  Thus, both are perfectly happy to answer authoritatively with 
PTR records for the IPs that they are ""responsible for, while 
""delegating (redirecting) to the other name servers for the IPs that 
they aren't locally responsible for.


IMHO it's a neat trick and avoids needing to have 10s, 100s, 1,000s of 
little tiny zone files on a DNS server.


I have yet to find any reason that this won't work.  I'm confident that 
you could even make it work with DNSSEC /if/ there is proper 
coordination between consenting parties.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Reverse lookup for classless networks

[John Levine]

From: John Levine 
To: bind-users@lists.isc.org
Subject: Re: Reverse lookup for classless networks
In-Reply-To: 
Organization: Taughannock Networks
Cc: gtay...@tnetconsulting.net
Bcc: johnl-sent
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit

In article  you write:
>1)  The parent zone needs to have the delegation like Barry depicted above.
>2)  The child zone needs to have records for the name being looked up. 
>Nothing specifically translates to them needing to be in separate zones.

Well, there's those pesky old DNS standards, but we're used to software
working around screwed up zones.

If the parent delegates a name to a child server, the child server
must have an SOA at that name, along with whatever else you might
want to put there.  BIND will generally forgive what you're doing,
but I wouldn't expect it to work on other name server software.

>I could easily create a zone like this:
>
>; 1.0.192.in-addr.arpa.zone on local nameservers ns{1,2}.yourdomain.com
>$ORIGIN 1.0.192.in-addr.arpa.
>0   IN PTR web.yourdomain.com.
>1   IN PTR ftp.yourdomain.com.
>...
>128 IN NS  ns1.parent.example.
> IN NS  ns2.parent.example.
>129 IN NS  ns1.parent.example.
> IN NS  ns2.parent.example.
>...

>In essence, you end up with two independent zones for the same domain 
>name, 1.0.192.in-addr.arpa, cross delegating /different/ records to each 
>other.  Thus, both are perfectly happy to answer authoritatively with 
>PTR records for the IPs that they are ""responsible for, while 
>""delegating (redirecting) to the other name servers for the IPs that 
>they aren't locally responsible for.

I see a delegation loop.   What's the lookup chain supposed to be
for 128.0.192.in-addr.arpa?

R's,
John

PS: What's wrong with using $GENERATE in the parent zone like everyone
else who uses BIND does?

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Reverse lookup for classless networks

[Grant Taylor via bind-users]

On 12/27/18 11:24 AM, John Levine wrote:
Well, there's those pesky old DNS standards, but we're used to software 
working around screwed up zones.


Agreed.  Which standard(s) does this run afoul of?

If the parent delegates a name to a child server, the child server must 
have an SOA at that name, along with whatever else you might want to 
put there.


Which of the other records that must be there are actually queried as 
part of a normal lookup?


Sure, they should be there or expect failure when someone / something 
explicitly looks for the SOA record.


BIND will generally forgive what you're doing, but I wouldn't expect it 
to work on other name server software.


I'm about 80% certain that I've also done this with MS-DNS.  But, that's 
two (unknown versions of) many different DNS servers / resolver libraries.


I see a delegation loop.   What's the lookup chain supposed to be for 
128.0.192.in-addr.arpa?


192.0.128.0/24 is outside of the zone in question (192.0.2.0/24).  ;-)

Other than that, I'm going to claim poor documentation on my part while 
typing a reply before I've finished my coffee.


PS: What's wrong with using $GENERATE in the parent zone like everyone 
else who uses BIND does?


There's nothing wrong with $GENERATE per say.  I advocate using it. 
That being said, I find that $GENERATE, and other similar shortcuts, can 
hinder teaching.  I don't want someone to have to learn multiple 
concepts at the same time (if they aren't already familiar with $GENERATE).


I've long appreciated having control of my own reverse DNS.  It allows 
me to make changes at /my/ whim.  Meaning that I don't have to submit a 
ticket to my /provider/ for /them/ to make a change at /their/ whim.  - 
Hence the motivation for RFC 2317 Classless IN-ADDR.ARPA Delegation.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Reverse lookup for classless networks

[John Levine]

In article  you write:
>-=-=-=-=-=-
>
>On 12/27/18 11:24 AM, John Levine wrote:
>> Well, there's those pesky old DNS standards, but we're used to software 
>> working around screwed up zones.
>
>Agreed.  Which standard(s) does this run afoul of?
>
>> If the parent delegates a name to a child server, the child server must 
>> have an SOA at that name, along with whatever else you might want to 
>> put there.
>
>Which of the other records that must be there are actually queried as 
>part of a normal lookup?
>
>Sure, they should be there or expect failure when someone / something 
>explicitly looks for the SOA record.

Well, yeah, like I said it's wrong but you can often get away with it.
The DNS specs are a mess and the SOA at the top is poorly described in
1034 and 1035 (as is a lot of other stuff.)  You'll definitely lose if
your reverse zones are signed like mine are.

>> I see a delegation loop.   What's the lookup chain supposed to be for 
>> 128.0.192.in-addr.arpa?
>
>192.0.128.0/24 is outside of the zone in question (192.0.2.0/24).  ;-)

I can't type either.  Try 128.2.0.192 which in your example appears to
have an NS in the parent zones pointing at yourdomain, and in
yourdomain pointing back at the parent.

>> PS: What's wrong with using $GENERATE in the parent zone like everyone 
>> else who uses BIND does?
>
>There's nothing wrong with $GENERATE per say.  I advocate using it. 
>That being said, I find that $GENERATE, and other similar shortcuts, can 
>hinder teaching.  I don't want someone to have to learn multiple 
>concepts at the same time (if they aren't already familiar with $GENERATE).

I agree that $GENERATE is a kludge, but since we agree that we want to
control our own rDNS, it's the kludge that gets the job done.  Just
use it.

R's,
John
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Reverse lookup for classless networks

[Grant Taylor via bind-users]

On 12/27/18 12:14 PM, John Levine wrote:

Well, yeah, like I said it's wrong but you can often get away with it.


}:-)

I'll admit that it's not 100% proper.

The DNS specs are a mess and the SOA at the top is poorly described in 
1034 and 1035 (as is a lot of other stuff.)  You'll definitely lose if 
your reverse zones are signed like mine are.


How would DNSSEC fail if both versions of the zone used used a common ZSK?

Then again, it's entirely possible that I don't know the intricacies of 
DNSSEC as well as I perhaps need to.



I can't type either.


Typingg can be hard.

Try 128.2.0.192 which in your example appears to have an NS in the 
parent zones pointing at yourdomain, and in yourdomain pointing back at 
the parent.


I must be misunderstanding what you're saying.

It looks like 128.2.0.192.in-addr.arpa. is a PTR record in the following 
zone (copied from my original reply).


--8<--
; 1.0.192.in-addr.arpa.zone on parent nameservers ns{1,2}.parent.example.
$ORIGIN 1.0.192.in-addr.arpa.
...
128 IN PTR host128.example.net.
...
-->8--

It looks like 128.2.0.192.in-addr.arpa. is a pair of NS records delegating.

--8<--
; 1.0.192.in-addr.arpa.zone on local nameservers ns{1,2}.yourdomain.com
$ORIGIN 1.0.192.in-addr.arpa.
...
128 IN NS  ns1.parent.example.
IN NS  ns2.parent.example.
...
-->8--

I'm not seeing the circular delegation.

Remember that both servers are hosting the same zone, 
1.0.192.in-addr.arpa.  It's not going back and forth between a parent 
and child zone.  It's going between two (functionally) sibling zones.


Aside:  I see where I mis-typeed 192.0.*1*.0/24 instead of 
192.0.*2*.0/24.  But I suspect you can do the correction in your head.


I agree that $GENERATE is a kludge, but since we agree that we want 
to control our own rDNS, it's the kludge that gets the job done. 
Just use it.


I don't see how $GENERATE changes anything here.  Sure, it can be used 
to make creating the records easier.  But that doesn't change the fact 
that the records must exist.  Nor does it change that the records must 
do the delegation (or CNAME if you use RFC 2317).  IMHO /how/ the 
records are populated is much less of a concern with /what/ the records are.


They must still be NS for delegation (to what ever type of zone) or 
CNAME for RFC 2317.


If the OP's goal is to have control of their reverse DNS (via direct NS 
delegation or via CNAME delegation), then something has to be in place 
to do said delegation.  The OP doesn't really care what, much less how, 
the ""parent does as long as they do something.


My point being that the ""parent using generic $GENERATE (or otherwise) 
without some form of delegation doesn't give the OP the desired control.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Reverse lookup for classless networks

[Grant Taylor via bind-users]

It has come to my attention that my answer to the following question 
might not have been clear.  So I'll try again.


First I want to be clear that I was discussing what the records should 
be, RFC 2317 Classless IN-ADDR.ARPA Delegation (read: CNAME) or standard 
NS delegation.  I don't care how the records (CNAME or NS) are 
generated.  I care what the records are, CNAME vs NS.


On 12/27/18 11:24 AM, John Levine wrote:
PS: What's wrong with using $GENERATE in the parent zone like everyone 
else who uses BIND does?


I have zero problems with actually using $GENERATE in the parent zone 
(or anywhere else).


I do have concerns about using $GENERATE to describe a concept to 
someone who may not be as familiar with DNS, or BIND, much less 
$GENERATE.  As such, I tend to not use $GENERATE when answering questions.


Take the following examples.  Which do you think someone that is new to 
DNS will have an easier time understanding?


--8<--
$GENERATE 1-4 $ CNAME $.bob.example.net.
$GENERATE 5-8 $ NS ns1.example.com.
-->8--

Or

--8<--
1.localhost.  604800  IN  CNAME  1.bob.example.net.
2.localhost.  604800  IN  CNAME  2.bob.example.net.
3.localhost.  604800  IN  CNAME  3.bob.example.net.
4.localhost.  604800  IN  CNAME  4.bob.example.net.
5.localhost.  604800  IN  NS ns1.example.com.
6.localhost.  604800  IN  NS ns1.example.com.
7.localhost.  604800  IN  NS ns1.example.com.
8.localhost.  604800  IN  NS ns1.example.com.
-->8--

IMHO, the latter is easier to understand.  As a bonus, it conforms to 
standard zone file format.  Something that any DNS administrator should 
be able to recognize and interpret.  I'm unwilling to say the same about 
$GENERATE.


I trust that people that are comfortable with $GENERATE will recognize 
it's use case when they see it.


I learned a long time ago to think about how the person learning 
receives and understands things.  As such, if there is a simple change I 
can do as a teacher to make it easier for them as the student learn, 
then I should do that.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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