Reverse lookup for classless networks

[Grant Taylor]

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

-------------- 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/da546e17/attachment-0001.bin>