Well, it seems to work testing it...

But, the systems that are having trouble are still having trouble.  Though 
taking a closer look at the logs of one of the systems, the problem started in 
April 2009 (and the system was rebooted shortly after that point, and the 
problem continued...)

Since it was only brought to my attention yesterday, and the admins that were 
regularly using it after the problem started aren't here anymore....just 
another thing left for us to find later.  And, I guess I haven't used it that 
much....probably since I stopped updating bind for servers of that OS version.

Something about bind not liking openssl-0.9.7d anymore.



----- Original Message -----
> 
> In message <9efac3c5-c5be-43f8-b7f4-2be8ba30d...@isc.org>, Mark
> Andrews writes:
> > One could also look at the dns64 reverse code to do this. It
> > synthesises
> > cname records on the fly.
> > 
> > Mark
> > 
> 
> e.g.
> 
>       zone "f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
>               type master;
>               database "_dns64 dns64 . .";
>       };
> 
>       One can also spectify the MNAME and RNAME fields of the SOA
>       record along with the NS name by replacing the last two fields
>       of the database description.
> 
>       database "_dns64 dns64 ns.example.net. hostmaster.example.net.";
> 
>       Mark
> 
> ; <<>> DiG 9.10.0pre-alpha <<>> +norec -p 5555 -x ::ffff:1.2.3.4
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48724
> ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;4.0.3.0.2.0.1.0.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
> IN PTR
> 
> ;; ANSWER SECTION:
> 4.0.3.0.2.0.1.0.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
> 600 IN CNAME 4.3.2.1.in-addr.arpa.
> 
> ;; AUTHORITY SECTION:
> .                     518400  IN      NS      A.ROOT-SERVERS.NET.
> .                     518400  IN      NS      B.ROOT-SERVERS.NET.
> .                     518400  IN      NS      L.ROOT-SERVERS.NET.
> .                     518400  IN      NS      D.ROOT-SERVERS.NET.
> .                     518400  IN      NS      C.ROOT-SERVERS.NET.
> .                     518400  IN      NS      K.ROOT-SERVERS.NET.
> .                     518400  IN      NS      H.ROOT-SERVERS.NET.
> .                     518400  IN      NS      M.ROOT-SERVERS.NET.
> .                     518400  IN      NS      I.ROOT-SERVERS.NET.
> .                     518400  IN      NS      E.ROOT-SERVERS.NET.
> .                     518400  IN      NS      G.ROOT-SERVERS.NET.
> .                     518400  IN      NS      F.ROOT-SERVERS.NET.
> .                     518400  IN      NS      J.ROOT-SERVERS.NET.
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#5555(127.0.0.1)
> ;; WHEN: Tue Jul 09 12:21:46 EST 2013
> ;; MSG SIZE  rcvd: 342
> 
> 
> > On 09/07/2013, at 8:27, Mark Andrews <ma...@isc.org> wrote:
> > 
> > > Getnameinfo and gethostbyaddr are supposed to lookup the
> > > in-addr.arpa recor
> > ds instead of ip6.arpa records for mapped addresses. If you only
> > have a limit
> > ed range of addresses one could use $generate to add cname records
> > which map
> > from ip6.arpa to in-addr.arpa.
> > > 
> > > Mark
> > > 
> > > On 09/07/2013, at 8:12, "Lawrence K. Chen, P.Eng."
> > > <lkc...@ksu.edu> wrote:
> > > 
> > >> For reasons unknown, some old Solaris servers are suddenly
> > >> seeing connecti
> > ons to them as ipv4-mapped ipv6 (ie: ::ffff:10.20.30.40 )  Which is
> > causing p
> > roblems because it needs the reverse lookup to be right.
> > >> 
> > >> So while we struggle between spending time to investigate why or
> > >> continue
> > to try to get people to upgrade from these old forgotten servers.
> > >> 
> > >> Is there an easy way for me to provide reverse lookups for
> > >> those?
> > >> 
> > >> --
> > >> Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems
> > >> Administrator
> > >> For: Enterprise Server Technologies (EST) -- & SafeZone Ally
> > >> Snail: Computing and Telecommunications Services (CTS)
> > >> Kansas State University, 109 East Stadium, Manhattan, KS
> > >> 66506-3102
> > >> Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email:
> > >> lkc...@ksu.edu
> > >> Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale
> > >> Library
> > >> _______________________________________________
> > >> Please visit https://lists.isc.org/mailman/listinfo/bind-users
> > >> to unsubscr
> > ibe from this list
> > >> 
> > >> bind-users mailing list
> > >> bind-users@lists.isc.org
> > >> https://lists.isc.org/mailman/listinfo/bind-users
> > > _______________________________________________
> > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > > unsubscri
> > be from this list
> > > 
> > > bind-users mailing list
> > > bind-users@lists.isc.org
> > > https://lists.isc.org/mailman/listinfo/bind-users
> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe
> >  from this list
> > 
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org
> 

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to