Reverse lookup for classless networks

[Grant Taylor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181227/a8a3043c/attachment.bin>