> -----Original Message-----
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas
> Sent: Saturday, May 21, 2016 1:27 PM
> To: bind-users@lists.isc.org
> Subject: Re: Forward zone not working
>
> On 20.05.16 21:09, Woodworth, John R wrote:
> >This is exactly what some colleagues and I are working to get a handle on.
> >We see this as becoming a larger and larger issue especially as IPv6
> >adoption increases. We have had several customers already request
> >generics at /96 and larger blocks as they are accustom to doing with
> >IPv4. From a sheer marketing perspective $GENERATEs with PTRs "brand"
> >the IPs to a network and a few other ISPs already have hacks in place
> >to provide similar functionality so why drive away potential customers?
> >Just because something seems silly? Why not go and give your money to
> >the provider that doesn't think your business is silly.
>
> $GENERATE is a master-only (and apparently even BIND-only) thing.
> it is not something that is transferred to the slaves - it generates
> records and those records are transferred to slaves.
Matus,
Thanks for your comment. This is entirely true. It is also a burden
for managing many zones (say roughly 100,000 zones) and difficult for
any of the slave zones to undo (especially depending on how or
what receives the zone). Haven't you ever received a huge zone of
generics and wished it were fewer records? Even if just to weed out
the noise of other records intermingled within the file?
> $GENERATE for /64 network would create 2^64=18,446,744,073,709,551,616
> records, needing ~30 bytes for each you would need about
> 590295810358705651712 bytes of RAM which is 590 295 810 358 705 651 712
> which it 590 exabyes. I doubt all computers on the earth have this
> much of memory.
This is addressed in the BULK I-D and one of the driving forces behind it.
The numbers simply do not scale without something changing.
> you would need to create whole new DNS protocol just to provide
> generic DNS records for each leaf (home) network...
This is also addressed in the I-D.
BULK records allow for a /8 (or even larger) IPv6 ranges to be easily
generated and transferred as a single RR (Yes, a single RR).
Both of us knowing the math 2^(128-8)="Big Freaking Number" and 2^(128-7)
is ("Big Freaking Number" * 2) so $GENERATE is likely not the correct
tool for this.
I admit, some problems may only be apparent at the ISP level or higher
but they truly do exist and I imagine to some extent even at the small
single-zone type shops.
If you are at all curious, please take a look at the I-D to see some of
the benefits of this capability and give us some feedback. If not,
we still welcome the feedback.
Thanks,
John
--
John Woodworth CenturyLink, Inc.
Q. Can a $GENERATE work for DNS on a /64 of reverse??
A. BULK CAN
[ http://tools.ietf.org/html/draft-woodworth-bulk-rr-01 ]
> yes, we need something new for IPv6. But not for creating bulks
> of useless generic records.
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Nothing is fool-proof to a talented fool.
> _______________________________________________
> 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
>
This communication is the property of CenturyLink and may contain confidential
or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication in
error, please immediately notify the sender by reply e-mail and destroy all
copies of the communication and any attachments.
_______________________________________________
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
