i consider every example in that draft to be implied by the current
2317, and all are in wide use. it's a better-written document, though
lacking coverage of some common use cases such as comcast's delegation
to my house of a /24.
;; ANSWER SECTION:
1.150.104.24.in-addr.arpa. 3600 IN CNAME 1.0-255.150.104.24.in-addr.arpa.
1.0-255.150.104.24.in-addr.arpa. 3600 IN PTR internal.gw1.rits.tisf.net.
the /24 and /16 subdelegation cases follow directly from 2317's claims,
even though i had to have this told to me by comcast at the time before
i could see that.
i sort of regret $GENERATE, it would be better if the zone did not have
to be macro-expanded in this way before it could be axfr'd (or ixfr'd).
if i had it to do over again i'd have proposed some kind of RR-encoded
metadata to show the desired $GENERATE-like effect. but let's not take
that on right now, ok?
so:
Tim Wicinski wrote on 2022-12-08 09:52:
Some time back Tony Finch proposed a 2317bis -
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00
which the WG adopted but died for lack of interest.
It would be useful to revise this document
tim
+1, and i'll commit to reviewing it.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
