This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/dns-wg@ripe.net/
[dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)]
- Previous message (by thread): [dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Janos Zsako
zsako at iszt.hu
Fri Mar 28 10:30:15 CET 2014
Dear Eric, > OOC, was any thought given to this approach? > http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-01 I may be wrong, but my understanding is that this I-D focuses on storing and retrieving information associated with a given (known) IP address range. Such information could be related to BGP routing, IRT and abuse, secure mail servers, etc. The problem I see here if you want to use this naming convention for "traditional" reverse queries is that you have to _know_ the address block you are trying to find information about, before starting the query. In case of a "traditional" reverse query for 192.168.1.1 for example, in order to use the above approach one would have to first query the RIR database (or perhaps some other place?) to find out the assignment the given IP address belongs to (e.g. 192.168.1.0/25) and _then_ we could query something like 1.0.m.1.168.192.in-addr.arpa. Did I misunderstand the I-D? Best regards, Janos > IIRC, there is a treatise in that draft that relates its proposal to RFC 2317. > > Eric
- Previous message (by thread): [dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]