reverse DNS considered pointless was: [6bone] Fwd: BCP 80,
RFC3681 on Delegation of E.F.F.3.IP6.ARPA
jeroen at unfix.org
Mon Feb 9 15:24:49 PST 2004
-----BEGIN PGP SIGNED MESSAGE-----
Matthew Luckie [mailto:mjl at luckie.org.nz] wrote:
> >>i did a DNS walk of ip6.int about 9 months ago.
> > The trick here is that you should taka a look at ip6.arpa.
> > ip6.int has been deprecated for over 2 years ago...
> > Please check ip6.arpa and test RIR space, not 6bone space as
> > can be seen yet again, ip6.arpa for 6bone will take quite some
> > time and even more time to get deployed under the many slumbering
> > and neglected pTLA's floating around.
> yeah, I know about that. I was going to do the same experiment on
> ip6.arpa. In theory the DNS for ip6.int was smaller than for
> ip6.arpa, so it was useful to run my code on ip6.int first. I was/am really
> worried about finding large numbers of autogenerated reverses, and
> wanted to get some indication as to what I was likely to hit
> on ip6.arpa.
> >>of the ~31k addresses i got, 21k were automatically generated
> >>(2x 10k, 1x 1k). i saw a fair amount of DNS spamming, but it did not
> >>feel like IRC lamers had taken over the DNS. From memory there was
> >>some kind of free DNS service behind a fair amount of the spam.
I know realize, after rereading the doc again, why you didn't came
across those dnsspammy addresses, this as you are tracerouting to
only 867+144+2445+123+11+486+153 = 4229 addresses, though these might
be spread apart, these are not the enduser IP addresses which are
mostly aliases on the same machine, thus the 'primary' IP of those
boxes might quite well be a clean address.
Using the traceroute way you only 'hit' backbone IP's, which is
actually a good thing as these are the IP's that should have working
forward and reverse DNS's as these are really useful.
You could axfr 0.0.0.2.18.104.22.168.e.f.f.3.ip6.int btw, which is the
3ffe:8114:2000::/48 prefix from which IPng.nl endusers get their
subnet space, it currently contains:
$ cat 0.0.0.2.22.214.171.124.e.f.f.3.ip6.int |grep Serial |wc -l
suballocations, which are gathered into this single zonefile
four times a day by a fancy dig script, and:
$ cat 0.0.0.2.126.96.36.199.e.f.f.3.ip6.int |grep PTR |wc -l
ptr records, thus 1136/155 = 7.32 hosts on average per /60 allocation.
Note that these are endusers, the infrastructure between the
big internet and them have autogenerated reverses, which resides
in the 3ffe:8114:1000::/48 (thus 0.0.0.1.188.8.131.52.e.f.f.3.ip6.arpa)
Which contains 5000 tunnels, 2 endpoints (POP and remote side) thus
10000 PTR records (and no we didn't want to type those in manually ;)
As your document heads "The focus of the current research is in
providing insight into the behaviour and growth patterns of the IPv6 Internet."
I wonder how you want to achieve this as you would require a very
large set of endnode addresses and even then you will mostly be
mapping the backbone, thus routers, and not the endsites where
the host reside. Randomly picking IP's to test is not a real
option with 128bits addresses to pick from :)
> > Do you have some more detailed output of these results. Also did
> > you mean you autogenerated 21k addresses or that you found 21k
> > autogenerated reverses?
> I found 21k autogenerated reverses. I can have a look at the
> data and report on other stats if you would like to suggest
> things to report on.
Where these addresses autogenerated in the:
2001:db8::1 -> PTR node-1.<lotsofzeros>.reverse.example.net
or better example'd using IPv4:
192.0.2.1 -> 184.108.40.206.in-addr.arpa PTR node-1-2.reverse.example.net
> I noticed a fair number of invalid addresses returned (as
> in addresses that are one byte too long or too short).
That would be an interresting item to report imho.
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / http://unfix.org/~jeroen
-----END PGP SIGNATURE-----
More information about the 6bone