In message <[email protected]>, 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 <[email protected]> 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." <[email protected]> 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: [email protected]
> >> 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
> >> [email protected]
> >> 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
> > [email protected]
> > 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
> [email protected]
> 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: [email protected]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
