[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[6bone] .int / .arpa
On 16-feb-05, at 18:49, John Fraizer wrote:
>> I have working revDNS zone for my subnet (.ip6.arpa), but i still
>> need ip6.int.
> sed 's/ip6.arpa/ip6.int/g' source.ip6.arpa > destination.ip6.int
Ok, so what happens now is that d.e.a.d.b.e.e.f.ip6.arpa and
d.e.a.d.b.e.e.f.ip6.int are equivalent. However, this doesn't seem to
be in line with the RFCs I'm reading.
In the beginning, there was RFC 1886, and we had the x.x.x.x.ip6.int
reverse mapping and life was good.
Then at some point a whole bunch of RFCs was published with a whole new
way of doing things, in the RFC 2[8|6]7x range. However, those RFCs DO
NOT mandate the use of x.x.x.x.ip6.arpa, as far as I can tell from a
According to those RFCs, looking up the reverse mapping should be done
the way the host and nslookup commands on my Mac do:
[alumange:~] iljitsch% host 2001:200::8002:203:47ff:fea5:3085
Host \[x2001020000008002020347FFFEA53085/128].ip6.arpa not found:
[alumange:~] iljitsch% nslookup -silent
** server can't find \[x2001020000008002020347FFFEA53085/128].ip6.arpa:
Now RFC 3364 says the RFC 2874 is better, but the additional benefit
over the RFC 1886 way is too small to warrant the trouble of the
gruesome upgrade cycle that's needed.
So how did we end up in the current x.x.x.x.ip6.arpa situation? I
haven't been able to find any document that mandates this, what gives?