Delegating /24's from a /19

>> Um, why?
> Firstly he does NOT have authority for the /16 reverse. Lots
> of latent problems there.

Nor is he claiming it. Nowhere on the internet is there anything saying
that the entire /16 should be looked up against his nameserver. No=20
should exist pointing to his nameserver as authoritative for the /16.
The convenience of having a zone file that is based on a /16 that he owns
part of does not create authority out of thin air, nor does it make any
meaningful claim to authority except to a system which (mistakenly) =
to use those nameservers as resolvers. Yes, if you are going to do this, =
is a prerequisite that your nameserver _NOT_ be anyone's resolver.

> Secondly sideways delegations don't work.

Huh? I'm not sure what you mean by "sideways delegations". It is
perfectly acceptable, for example, for: returns IN NS returns IN NS returns IN NS returns IN PTR=20

  Actually it isn't. Nameservers can and do detect this as it
  looks like a classic lame delegation. It also a sideways
  delgation, the zone depth didn't impove between

This does work. This is what is being proposed.

> Thirdly I'm sick and tired of having to debug stupid
> schemes ISP's come up with to try to avoid SWIPing the
> nameservers in situations like this. They don't work
> or they don't meet the customers expectations (i.e.
> they have a /24 and should just be able to use
> and have it work reliably).
So don't debug them. As long as ARIN has all of the /24s within the /19
pointing as NS records to the nameserver which contains the partially
populated /16 zone file (or which secondaries each of the relevant /24 =
from their true owners), things work just fine. Nothing really to debug.

  Well when you have a bug report saying that your nameserver
  doesn't work because someone tried to do a sideways delegation
  you have to go in there and show what is broken.

  This is not expected to work.