Does anyone know what's going on with DNS for 233.IN-ADDR.ARPA ?
I get:
233.IN-ADDR.ARPA. 86400 IN NS FLAG.EP.NET.
233.IN-ADDR.ARPA. 86400 IN NS NIC.NEAR.NET.
233.IN-ADDR.ARPA. 86400 IN NS STRUL.STUPI.SE.
233.IN-ADDR.ARPA. 86400 IN NS NS.ISI.EDU.
;; Received 138 bytes from 192.228.79.201#53(b.root-servers.net) in 91 ms
Of these, only FLAG.EP.NET actually seems to work;
NIC.NEAR.NET no longer seems to exist
STRUL.STUPI.SE returns SERVFAIL
NS.ISI.EDU returns REFUSED
I also tried to send email to hostmaster@ep.net to have a delegation
updated, but got a bounce...
I wonder if DNS for GLOP/RFC3180 is still expected to work/be supported,
or should I just give up 
Thanks,
--Gabriel
I think this has been broken for a while now. But if you ever figure out who can delegate the zones let me know
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony@lava.net
I am not sure, but I believe as a best practice, RFC3180 is
considered basically defunct at this point, it's obvious that at least
the RDNS is neglected. The problem is that it relied on mapping bits
from the AS number into the IP address bitspace.
Now that AS numbers have been extended to 4 bytes in length, and RIRs
are even about to stop differentiating between them when allocating
AS numbers, or allowing anyone to request and be sure of getting a new
16-bit ASN.
It seems that it will be impossible for the scheme to be followed in IPv4.
A more sensible BCP at this point would be to designate the entire
223/8 to IRRs, like was suggested by the BCP for 64512 -- 65535,
since most ASNs are not using GLOP addressing.
Mapping ASN bits onto multicast IP ranges is convenient but wasteful
too, once you consider >2^16 ASNs.
Now that AS numbers have been extended to 4 bytes in length, and RIRs
are even about to stop differentiating between them when allocating
AS numbers, or allowing anyone to request and be sure of getting a new
16-bit ASN.
Then you may be interested to see this Last Call:
(draft-ietf-mboned-ipv4-uni-based-mcast)
It seems that it will be impossible for the scheme to be followed in IPv4.
A more sensible BCP at this point would be to designate the entire
223/8 to IRRs, like was suggested by the BCP for 64512 -- 65535,
since most ASNs are not using GLOP addressing.
Uhh. Take away the numbers from those who have already started using them? Are you serious?
There were multiple attempts to the private etc. ASN parts of 233/8 to RIRs but these have failed (lack of interest?). The current situation (RFC5771) is that this has been designated as "AD-HOC Block III" and is assignable from IANA.
The curious minds may also want to take a look at:
(Comments welcome, this has been waiting the completion of abovementioned draft.)
I wonder if DNS for GLOP/RFC3180 is still expected to work/be supported,
or should I just give up 
> Thanks,
I am not sure, but I believe as a best practice, RFC3180 is
considered basically defunct at this point, it's obvious that at least
the RDNS is neglected. The problem is that it relied on mapping bits
from the AS number into the IP address bitspace.
Now that AS numbers have been extended to 4 bytes in length, and RIRs
are even about to stop differentiating between them when allocating
AS numbers, or allowing anyone to request and be sure of getting a new
16-bit ASN.
It seems that it will be impossible for the scheme to be followed in IPv4.
A more sensible BCP at this point would be to designate the entire
223/8 to IRRs, like was suggested by the BCP for 64512 -- 65535,
since most ASNs are not using GLOP addressing.
Look at RFC 5771
While it is no longer automatic, entities with 4 byte ASN can get multicast addresses from the
AD-HOC Block III (the old extended GLOP space).
Regards
Marshall