I battled for a few hours getting IPv6 rDNS to work. The following tool proved to be quite helpful:
http://www.fpsn.net/?pg=tools&tool=ipv6-inaddr
Just in case anyone else would run into similar problems. It's not as straightforward as IPv4 rDNS.
Greetings,
Jeroen
Yes, you need to be able to spell Hex backward 
Yo Jeroen!
I battled for a few hours getting IPv6 rDNS to work.
See also sipcalc.
# sipcalc -r 2001:470:b:4a:230:48ff:fe35:d1bc
- -[ipv6 : 2001:470:b:4a:230:48ff:fe35:d1bc] - 0
[IPV6 DNS]
Reverse DNS (ip6.arpa) -
c.b.1.d.5.3.e.f.f.f.8.4.0.3.2.0.a.4.0.0.b.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa.
RGDS
GARY
- ---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
gem@rellim.com Tel:+1(541)382-8588
How so? It's just longer owner names. There are enough tools that will
covert IPv6 addresses to the corresponding reverse name. You most probably
already have the tools on your machines.
dig, nslookup, arpaname
And if you are running Mac OS or Windows they will add the PTR records for
themselves. I just wish all the other OS's did that so I don't have to do
them by hand.
Mark
windows mentality, wrap it all in a complex gui that also washes your
car.
use simple hack that just takes an ipv6 address and makes the bleeping
reversed dotted to death lhs of the ptr record.
rmac.psg.com:/Users/randy> host 2001:418:1::61
Host 1.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.8.1.4.0.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)
randy
But Randy, everyone has a web browser installed. Not everyone has perl, python,
cc, or such installed.
Adrian
(I wonder if FreeBSD-1.0's complete, non-X install footprint (sub-40meg) was smaller
than an install of Firefox.
But Randy, everyone has a web browser installed. Not everyone has
perl, python, cc, or such installed.
and i thought this was an operators' list. silly me.
randy, who did see the smiley
But Randy, everyone has a web browser installed. Not everyone has
perl,
python,
cc, or such installed.
apt-get install ipv6calc
ipv6calc -q --out revnibbles.arpa 2001::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.2.ip6.arpa
.
We developed a web/mysql-based front-end that our noc uses for all DNS
ops, so the NOC never touches zone files directly. So it was easy to
just add a feature that provides additional syntax for ipv6 PTRs...
So for example in zone
0.0.0.0.d.c.b.a.8.B.D.0.1.0.0.2.ip6.arpa
we can enter
0000:0000:0000:0003 PTR foo.com.
and it will reverse the nibbles/remove the ":"s and put in the "."s
and get generated into a zone file as needed:
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.c.b.a.8.B.D.0.1.0.0.2.ip6.arpa PTR foo.com.
(of course you can enter x.x.x.x... syntax too)
Having a front-end also lets you do all sorts of other sanity-checking
with instant feedback to avoid choking up BIND, depending on the skill
level of your target "DNS admin".
-Will
Since there's a thread here, I'll mention rDNS for residential users.
I'm not sure there's consensus about whether forward and reverse ought
to match (how strong a "should" is that?). I know you can't populate
every potential record in a reverse zone, as in IPv4. You can generate
records on the fly, or just not provide PTRs.
I've described options in draft-howard-isp-ip6rdns-04 but I'm not sure
enough people care whether it's published as an RFC. Discuss on
IETF's dnsop list.
https://www.ietf.org/mailman/listinfo/dnsop
Lee
Forgive me if this is a stupid question.
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,
$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.
And when load the zone file, automatically (internally) interpret it as
c.b.1.d.5.3.e.f.f.f.8.4.1.0.0.0.3.f.8.0.3.1.4.8.8.7.d.f.ip6.arpa.
inside memory.
Regards,
Gary E. Miller wrote:
See also sipcalc.
Thanks, I wasn't aware of the various commandline tools available yet. Except the dig option to convert IPv6 rDNS. But the tool I mentioned also creates a whole zone file for you based on what you entered, which I then used to correct the zone file I created.
I found that it helped me a lot more than lots and lots of wiki and gewgle searched pages which only explained bits and pieces and failed to give proper, or even incorrect and/or dated examples. So once I found that tool it took me a few minutes to get the syntax right.
Greetings,
Jeroen
> I battled for a few hours getting IPv6 rDNS to work. The following tool
> proved to be quite helpful:
> http://www.fpsn.net/?pg=tools&tool=ipv6-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.htmlForgive me if this is a stupid question.
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,$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.
Firstly you don't have enough bits for a IPv6 address specified and
secondly how would you distingish that from wanting the following?
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.
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) == 0,
as only nibble boundaries make sense) and allow $ORIGIN to be specified.
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.
$6REVERSE $ORIGIN fd78:8413:830:1::/64
@ SOA ...
@ NS ...
@ NS ...
one could make it more general and do both IPv4 and IPv6 ($REVERSE).
If you're going to do that, why not make it possible to declare:
$ORIGIN fd78:8413:38f:1::.ip6.arpa as well?
Owen
I battled for a few hours getting IPv6 rDNS to work. The following tool
proved to be quite helpful:
http://www.fpsn.net/?pg=tools&tool=ipv6-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.htmlForgive me if this is a stupid question.
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,$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.Firstly you don't have enough bits for a IPv6 address specified and
secondly how would you distingish that from wanting the following?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.
What would be the point of wanting that? It's not a legitimate ip6.arpa
name. 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.
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) == 0,
as only nibble boundaries make sense) and allow $ORIGIN to be specified.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.$6REVERSE $ORIGIN fd78:8413:830:1::/64
@ SOA ...
@ NS ...
@ NS ...one could make it more general and do both IPv4 and IPv6 ($REVERSE).
I agree that a $REVERSE directive would be a better solution. (v4 and v6)
Owen
In message <7E9AF5E9-7B3A-4767-A1D3-8EAB64031DAF@delong.com>, Owen DeLong write
s:
>=20
>>> 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?
Lee Howard wrote:
Since there's a thread here, I'll mention rDNS for residential users.
I'm not sure there's consensus about whether forward and reverse ought
to match (how strong a "should" is that?). I know you can't populate
every potential record in a reverse zone, as in IPv4. You can generate
records on the fly, or just not provide PTRs.I've described options in draft-howard-isp-ip6rdns-04 but I'm not sure
enough people care whether it's published as an RFC. Discuss on
IETF's dnsop list.
https://www.ietf.org/mailman/listinfo/dnsop
Presuming that signed wildcarding in ip6.arpa is achieveable under
DNSSEC (use of the LABELS field), would be interested in anybody other
than IRC operators who feel they still require forward and reverse DNS
to match,
I feel this preferable than either not providing PTRs or dynamically
creating them on query (which would be cool but another headache DoS
vector to manage well)
Thoughts?
I'm not sure there's consensus about whether forward and reverse ought
to match (how strong a "should" is that?).
that's pretty much of a "should" for IRC, and various anti-spam crap on SMTP, furthermore, the entries should be (to a certain extend) unique
(hosted-by.provider.com resolving to everything you have and/or the other way around (reverse) fucks things up
I know you can't populate
every potential record in a reverse zone, as in IPv4.
indeed.. ipv6 seems to call for some changes in the way dns servers handle things... no more files people.. preferably no more "zones" either.
(never liked the concept of zones anyway
if no database entry (cached in ram!) -> automatically generate one based on ip (like a84-22-96-1.cb3rob.net. on ipv4 if there is no more specific database entry for that ip present, such as www.customer.com))
(or just forget about reverse dns alltogether)
but then again, quite sure you already figured out bind and zone-based (files) dns have had their days anyway.
just write a few lines of c or perl that talk to a database and cache results in ram, if they can't find anything in ram with a recent enough timestamp and there is nothing in the database or the database isn't responding, just generate one based on the ip requested with your domain added (or in-addr.arpa. added, works too, if you don't want -your- domain in reverse dns (and therefore forward!) entries for customers, or its equivalent for ipv6
yes, you -can- actually make A records in in-addr.arpa and its ipv6 equivalent, so there is no need to use -your- domain for it, and you can still make unique -working- -valid- and resolving both ways entries for each ip, also on ipv6, and generate them on the fly (although that requires a move away from bind, don't think you want to load a zonefile with a few billion entries, although generating it would not be such an issue (loading and searching it would).
a84-22-97-10:~# nslookup 84.22.99.1
Server: 84.22.96.10
Address: 84.22.96.10#53
1.99.22.84.in-addr.arpa name = 1.99.22.84.in-addr.arpa.
a84-22-97-10:~# nslookup 1.99.22.84.in-addr.arpa
Server: 84.22.96.10
Address: 84.22.96.10#53
Name: 1.99.22.84.in-addr.arpa
Address: 84.22.99.1
a84-22-97-10:~#
would be interested in anybody other
than IRC operators who feel they still require forward and reverse DNS
to match,
SMTP, email-2 (don't ask ;), and preferably (though not required) anything that has to do with /bin/login on *nix systems (as it shows the reverse dns host name in who and w and last unless specified otherwise).
although smtp -itself- does note require it to match, the various "anti-spam" things -do-.
Sven Olaf Kamphuis wrote:
would be interested in anybody other
than IRC operators who feel they still require forward and reverse DNS
to match,SMTP, email-2 (don't ask ;), and preferably (though not required)
anything that has to do with /bin/login on *nix systems (as it shows the
reverse dns host name in who and w and last unless specified otherwise).
Well, at least with DNSSEC, you can assure the end user that the
wildcarding was intentional (through validation), I dont see why those
systems shouldn't be acceptant of intentionally obscured hosts in the
future ?
Saying that, I quite like the idea of dynamically providing a response
to both AAAA and PTR queries but question how safe it would be to cache
these without a robust resource-managing implementation...
Dave.