[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(usagi-users 01331) Re: [project6] does linux resolve ip6.int addresses?


--On Friday, March 22, 2002 07:27:18 PM +0100 Arkadiusz Miskiewicz
<misiek@xxxxxxxxxx> wrote:

> Mauro Tortonesi <mauro@xxxxxxxxxxxxxxxx> writes:
> 
>> i have been told that linux only resolves ip6.arpa addresses. is
>> this true? i am actually skimming glibc-2.2.4 code to find this
>> out.
> http://sources.redhat.com/ml/libc-alpha/2002-02/msg00030.html
> http://lists.debian.org/debian-ipv6/2001/debian-ipv6-200111/msg0004
> 0.html

Major problem is that delegations not working proper :-(

My current opinion: reverse delegation is very strange at the moment
(I don't say "chaos" but think a little bit so...)

Example:

ip6.arpa. contains reverse delegations for productive space 2001::/16
(reverse nibbles)

you can see this here:
        dig AXFR ip6.arpa @SVC00.APNIC.NET.

But didn't contain 6bone space.



ip6.int. contains reverse delegation for 6bone space 3ffe::/16

See here for example:
        dig AXFR ip6.int @129.88.30.1

This zone also contains some NS entries for 2001::/20, but looks like
they are not working.

Try e.g.: dig ANY 0.1.0.0.2.ip6.int. @ns.ripe.net.

Also very interesting are following:

f.5.ip6.int.            86400   IN      NS   NS.ISI.EDU.
f.5.ip6.int.            86400   IN      NS   zesbot.ipv6.surfnet.nl.
f.5.ip6.int.            86400   IN      NS   munnari.oz.au.

dig AXFR f.5.ip6.int. @zesbot.ipv6.surfnet.nl.

This zone still contain the historic provider based IPv4 addresses
4000::/3


Result: glibc has to ask both zones for reverse lookup to get a
result.


BTW: someone told me that in fact "ip6.arpa" should be used with
reverse nibble and "ip6.int" should be going obsolete because TLD is
used for something else.

DNAME completly and A6 with prefix length !=  0 is throwing back to
[very?] experimental, and only supported by BIND and not supported by
other DNS software programmers...also during programming "ipv6calc"
it shows me that bitstring labels aren't a unique representation for
bit lengths mod 4 != 0.

        Peter