ipv4-mapped reverse lookups

Lawrence K. Chen, P.Eng. lkchen at ksu.edu
Tue Jul 9 19:59:15 UTC 2013


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-2BE8BA30DB8A at 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 <marka at 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."
> > > <lkchen at 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:
> > >> lkchen at 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 at 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 at 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 at 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: marka at 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: lkchen at ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library


More information about the bind-users mailing list