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.html
Yes, you need to be able to spell Hex backward ;) ----- Original Message ----- From: "Jeroen van Aart" <jeroen@mompl.net> To: "NANOG list" <nanog@nanog.org> Sent: Saturday, 30 October, 2010 2:06:32 PM Subject: IPv6 rDNS 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Jeroen! On Fri, 29 Oct 2010, Jeroen van Aart wrote:
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFMy3LeBmnRqz71OvMRAoaxAJ9XrEpV8+QLwJDenMwn4oCTmu6D9gCgpeEb nszaFE+jTA1rn4ZgTDFCanQ= =NNMg -----END PGP SIGNATURE-----
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 -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
In message <4CCB6F98.6090103@mompl.net>, Jeroen van Aart writes:
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.
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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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
On Sat, Oct 30, 2010, Randy Bush wrote:
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)
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. :-)
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 On Fri, Oct 29, 2010 at 06:06:32PM -0700, Jeroen van Aart wrote:
Date: Fri, 29 Oct 2010 18:06:32 -0700 From: Jeroen van Aart <jeroen@mompl.net> To: NANOG list <nanog@nanog.org> Subject: IPv6 rDNS
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.html
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
-----Original Message----- From: Jeroen van Aart [mailto:jeroen@mompl.net] Sent: Friday, October 29, 2010 9:07 PM To: NANOG list Subject: IPv6 rDNS
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.html
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? -- David Freedman Group Network Engineering Claranet Group
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:~# On Tue, 2 Nov 2010, David Freedman wrote:
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?
--
David Freedman Group Network Engineering Claranet Group
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-. On Tue, 2 Nov 2010, David Freedman wrote:
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?
--
David Freedman Group Network Engineering Claranet Group
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. -- David Freedman Group Network Engineering Claranet Group
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...
quite safe.. its not dns caching... in fact, we'd put the ttl on 1 second or something, but rather a ram caching on the authorative servers. now the stuff that hardly gets resolved, like, most of your ip space, doesn't cause a problem, even if it does have an entry in the database for PTR www.customer.com. (as http clients don't generally use reverse dns) dns caching downstream causes more problems than its good for since people no longer use slow links, you do want to be albe to change them real-time nowadays (not to mention dns poisoning issues). you would want to keep database results for lets say your smtp servers and your nameservers themselves in RAM cache for 10-60 seconds or so or your database will go nuts (and people could dos your database even ;) getting rid of bind has various other advantages, such as no longer needing tcp to transfer "zone files" (Retarded concept to say the least) so there are no more "tcp issues" related to anycasting your authorative dns servers, as you can simply have them talk to your central database over their bgp session ip, which isn't anycasted, no more port 53/tcp therefore! yay, good riddance! no more "zones", just individual records, anything thats not a "record" in the db gets automatically generated on the fly, and no more dns cache downstream (well we can't help it if resolvers try anyway but it wont bring them much ;). ofcourse, should the database, at any point, become unreachable, the authorative servers should use the ram cached entries -regardless- of their timestamp until they can reach the database again. the way bind handles things.. isn't really suitable for bigger ipv4 and it definately isn't suitable for ANY ipv6 network, and the whole thing with files being transferred.. well.. ahem... "primitive". bind was coded in a time when the internet ran on 64kbit links.. caching downstream back then was desired and things weren't so "large", and it really didn't matter much if things took hours. (why do we STILL have to wait for new domains... just drop the whole concept of -files- and -zones- domain registrations should work -instantly-! not after a "reload" of something that should not be used anymore anyway). with ipv6, it has =finally- become impossible to maintain that outdated model! yay! good riddance :P On Tue, 2 Nov 2010, David Freedman wrote:
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.
--
David Freedman Group Network Engineering Claranet Group
In a message written on Tue, Nov 02, 2010 at 06:21:14PM +0000, Sven Olaf Kamphuis wrote:
the way bind handles things.. isn't really suitable for bigger ipv4 and it definately isn't suitable for ANY ipv6 network, and the whole thing with files being transferred.. well.. ahem... "primitive".
bind was coded in a time when the internet ran on 64kbit links.. caching downstream back then was desired and things weren't so "large", and it really didn't matter much if things took hours. (why do we STILL have to wait for new domains... just drop the whole concept of -files- and -zones- domain registrations should work -instantly-! not after a "reload" of something that should not be used anymore anyway).
I'll note that most of the behavior you describe here is deeply rooted in the RFC's. The concepts of zone transfers for instance are not unique to BIND, but rather in the definition of how interoperable DNS is supposed to work. That said, there is clearly room for improvement, and in fact there are a lot of folks working on it. Indeed, some of them have funding BIND 10, a ground-up rewrite of BIND that I think based on the tone of your message may please you with the direction that it is going. For more information... http://www.isc.org/bind10 http://bind10.isc.org/ -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
I'll note that most of the behavior you describe here is deeply rooted in the RFC's. The concepts of zone transfers for instance are not unique to BIND, but rather in the definition of how interoperable DNS is supposed to work.
That said, there is clearly room for improvement, and in fact there are a lot of folks working on it. Indeed, some of them have funding BIND 10, a ground-up rewrite of BIND that I think based on the tone of your message may please you with the direction that it is going.
For more information...
the documentation has some very glaring omissions like the structure of the sqlite3 zone files. --Curtis
On Tue, 02 Nov 2010 18:21:14 -0000, Sven Olaf Kamphuis said:
getting rid of bind has various other advantages, such as no longer needing tcp to transfer "zone files" (Retarded concept to say the least) so there are no more "tcp issues" related to anycasting your authorative dns servers, as you can simply have them talk to your central database over their bgp session ip, which isn't anycasted, no more port 53/tcp therefore! yay, good riddance!
Till the first time you have to answer a query that's over 512 bytes that doesn't have the EDNS0 bit set... Yes, such beasts still live out there.
On Tuesday, November 02, 2010 02:21:14 pm Sven Olaf Kamphuis wrote:
getting rid of bind has various other advantages, such as no longer needing tcp to transfer "zone files" (Retarded concept to say the least) so there are no more "tcp issues" related to anycasting your authorative dns servers, as you can simply have them talk to your central database over their bgp session ip, which isn't anycasted, no more port 53/tcp therefore! yay, good riddance!
Performing zone transfers is not the only reason for 53/tcp; it can also be needed for long (>512 byte) query responses. Thanks to the one-two punch of DNSSEC and IPv6, the probability of a DNS reponse needing TCP on port 53 is much greater now.
On 11/3/2010 at 1:10 PM, Lamar Owen <lowen@pari.edu> wrote: On Tuesday, November 02, 2010 02:21:14 pm Sven Olaf Kamphuis wrote: getting rid of bind has various other advantages, such as no longer needing tcp to transfer "zone files" (Retarded concept to say the least) so there are no more "tcp issues" related to anycasting your authorative dns servers, as you can simply have them talk to your central database over their bgp session ip, which isn't anycasted, no more port 53/tcp therefore! yay, good riddance!
Performing zone transfers is not the only reason for 53/tcp; it can also be needed for long (>512 byte) query responses. Thanks to the one-two punch of DNSSEC and IPv6, the probability of a DNS reponse needing TCP on port 53 is much greater now.
That's mitigated by the fact EDNS0 is required for DNSSEC allowing for larger queries to go over UDP. Still, blocking 53/tcp is perhaps second only to dropping all incoming ICMP in the quest to be the most widely deployed and severely broken thing done in the name of Internet security. -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387
On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart <jeroen@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=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.html
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, -- Michel~
In message <AANLkTinUMZYp9qe0i5pHYZ72aL3XyCtvaqHjzHuTkpo2@mail.gmail.com>, Mich el de Nostredame writes:
On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart <jeroen@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=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.html
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.
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).
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, -- Michel~
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Nov 1, 2010, at 4:40 PM, Mark Andrews wrote:
In message <AANLkTinUMZYp9qe0i5pHYZ72aL3XyCtvaqHjzHuTkpo2@mail.gmail.com>, Mich el de Nostredame writes:
On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart <jeroen@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=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.html
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.
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:
On Nov 1, 2010, at 4:40 PM, Mark Andrews wrote:
=20 In message = <AANLkTinUMZYp9qe0i5pHYZ72aL3XyCtvaqHjzHuTkpo2@mail.gmail.com>, Mich el de Nostredame writes:
On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart <jeroen@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: marka@isc.org
On Nov 1, 2010, at 11:20 AM, Michel de Nostredame wrote:
On Fri, Oct 29, 2010 at 6:06 PM, Jeroen van Aart <jeroen@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=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.html
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.
If you're going to do that, why not make it possible to declare: $ORIGIN fd78:8413:38f:1::.ip6.arpa as well? Owen
participants (18)
-
Adrian Chadd -
Crist Clark -
Curtis Maurand -
David Freedman -
Franck Martin -
Gary E. Miller -
George Bonser -
Jeroen van Aart -
Lamar Owen -
Lee Howard -
Leo Bicknell -
Mark Andrews -
Michel de Nostredame -
Owen DeLong -
Randy Bush -
Sven Olaf Kamphuis -
Valdis.Kletnieks＠vt.edu -
Will Orton