In message <7e9af5e9-7b3a-4767-a1d3-8eab64031...@delong.com>, Owen DeLong write s: > > On Nov 1, 2010, at 4:40 PM, Mark Andrews wrote: > > >=20 > > In message = > <aanlktinumzyp9qe0i5phyz72al3xyctvaqhjzhutk...@mail.gmail.com>, Mich > > el de Nostredame writes: > >> On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart <jer...@mompl.net> = > wrote: > >>> I battled for a few hours getting IPv6 rDNS to work. The following = > tool > >>> proved to be quite helpful: > >>> http://www.fpsn.net/?pg=3Dtools&tool=3Dipv6-inaddr > >>> Just in case anyone else would run into similar problems. It's not = > as > >>> straightforward as IPv4 rDNS. > >>> Greetings, > >>> Jeroen > >>> -- > >>> http://goldmark.org/jeff/stupid-disclaimers/ > >>> http://linuxmafia.com/~rick/faq/plural-of-virus.html > >>=20 > >> Forgive me if this is a stupid question. > >>=20 > >> I am curious that if BIND ever tried to make the DB file easier to > >> operate under pure text-based environment. > >> For example, allow something like following format inside zone file, > >>=20 > >> $ORIGIN 1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. > >> 48ff:fe35:d1bc PTR server.example.com. > >=20 > > Firstly you don't have enough bits for a IPv6 address specified and > > secondly how would you distingish that from wanting the following? > >=20 > > 48ff:fe35:d1bc.1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa. PTR = > server.example.com. > >=20 > What would be the point of wanting that?
The point is that you are CHANGING the meaning of something that already exists. > It's not a legitimate ip6.arpa name. Why not? It's a perfectly legal name in the DNS. > While I realize BIND will dutifully parse it in its current state > and happily await a query for that particular name, it's not a = > legitimate > ip6.arpa entry and no such query is going to arise from anything > other than an error or abuse. > In other words, while it is syntactically within the bounds of the > RFC, it is semantically useless. How do you know I don't have a use for it? > > If you feel like writing a $6REVERSE directive please go ahead. We > > would be happy to accept such a patch. I would however make it > > take full IPv6 addresses and also take prefix syntax ((prefixlen % 4) = > =3D=3D 0, > > as only nibble boundaries make sense) and allow $ORIGIN to be = > specified. > >=20 > > e.g. > > $6REVERSE fd78:8413:830:1::/64 SOA .... > > $6REVERSE fd78:8413:830:1::/64 NS .... > > $6REVERSE fd78:8413:830:1::/64 NS .... > > $6REVERSE fd78:8413:830:1::48ff:fe35:d1bc PTR server.example.com. > >=20 > > $6REVERSE $ORIGIN fd78:8413:830:1::/64 > > @ SOA ... > > @ NS ... > > @ NS ... > >=20 > > one could make it more general and do both IPv4 and IPv6 ($REVERSE). > >=20 > I agree that a $REVERSE directive would be a better solution. (v4 and = > v6) > > Owen > >=20 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
