DNS for RFC3180 GLOP reverse zone ?
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
On Thu, 6 May 2010, L. Gabriel Somlo wrote:
Does anyone know what's going on with DNS for 233.IN-ADDR.ARPA ?
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 :)
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
On Thu, May 6, 2010 at 1:12 PM, L. Gabriel Somlo <gsomlo@gmail.com> wrote: ..
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. Mapping ASN bits onto multicast IP ranges is convenient but wasteful too, once you consider >2^16 ASNs. -- -J
On Thu, 6 May 2010, James Hess wrote:
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: http://www.ietf.org/mail-archive/web/mboned/current/msg01021.html (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: http://tools.ietf.org/html/draft-ietf-mboned-addrarch-06 (Comments welcome, this has been waiting the completion of abovementioned draft.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On May 6, 2010, at 11:14 PM, James Hess wrote:
On Thu, May 6, 2010 at 1:12 PM, L. Gabriel Somlo <gsomlo@gmail.com> wrote: ..
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
Mapping ASN bits onto multicast IP ranges is convenient but wasteful too, once you consider >2^16 ASNs.
-- -J
participants (5)
-
Antonio Querubin -
James Hess -
L. Gabriel Somlo -
Marshall Eubanks -
Pekka Savola