From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Thu, 28 Apr 2011 12:22:16 +0400 Message-ID: From: Sergey Kornilovich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd257de4e621404a1f6416b Subject: [9fans] dns SRV records Topicbox-Message-UUID: d735cd46-ead6-11e9-9d60-3106f5b1d025 --000e0cd257de4e621404a1f6416b Content-Type: text/plain; charset=ISO-8859-1 Investigating the possibility of replacing the MS DNS on Plan9 DNS,not found in the man ndb mention of records of type SRV. It is necessary to support Microsoft Active Directory. Maybe I missed something? http://en.wikipedia.org/wiki/SRV_record --000e0cd257de4e621404a1f6416b Content-Type: text/html; charset=ISO-8859-1
Investigating the possibility of replacing the MS DNS on Plan9 DNS,not found in the man ndb mention of records of type SRV.
It is necessary to support Microsoft Active Directory. Maybe I missed something?
http://en.wikipedia.org/wiki/SRV_record

--000e0cd257de4e621404a1f6416b-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Sergey Zhilkin Date: Thu, 28 Apr 2011 13:38:32 +0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: d73a05f0-ead6-11e9-9d60-3106f5b1d025 Hello ! As far as I know, ndb have support for SRV, PTR, TXT resords. There is no sample, of cause :) I think tha it may look like this: ip=3D10.0.0.1 sys=3D_service dom=3D_tcp.local srv=3D1111 2011/4/28 Sergey Kornilovich : > Investigating the possibility of replacing the MS DNS on Plan9 DNS,not fo= und > in the man ndb mention of records of type SRV. > It is necessary to support Microsoft Active Directory. Maybe I missed > something? > http://en.wikipedia.org/wiki/SRV_record > --=20 =D0=A1 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=D0=BC=D0=B8 =D0=BF= =D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=D0=B8 =D0=96=D0=B8=D0=BB=D0=BA=D0=B8=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 With best regards Zhilkin Sergey From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: "Steve Simon" Date: Thu, 28 Apr 2011 18:18:17 +0100 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: d78e72fc-ead6-11e9-9d60-3106f5b1d025 There is a package called zonefresh in my contrib, this doea and axfr transfer from the given host/domain and writes an ndb file with the results. This understands srv records though I have never tried re-exporting the info from ndb and checking the results agains msdns. you should be able to do this however. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Thu, 28 Apr 2011 14:39:38 -0400 From: geoff@plan9.bell-labs.com To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: d7ae626a-ead6-11e9-9d60-3106f5b1d025 See ndb(6). From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Huntsman To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Thu, 28 Apr 2011 23:49:10 +0000 Message-ID: <5782C16A7C920E469B74E11B5608B8E708A30DFE@Kriegler.ntdom.cupdx> References: In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: d7d496e2-ead6-11e9-9d60-3106f5b1d025 >Investigating the possibility of replacing the MS DNS on Plan9 DNS,not fou= nd in the man ndb mention of records of type SRV. >It is necessary to support Microsoft Active Directory. Maybe I missed some= thing? >http://en.wikipedia.org/wiki/SRV_record I got AD to work with Plan 9 DNS just last year. It didn't work very well,= and I had problems with the DNS service dying from time to time and I'd have to go restart it. Much as I'd= preferred to have stayed on Plan 9 DNS, I switched to BIND 9 on OpenBSD and have had far fewer problems. But anywa= y, here's the Active Directory support=20 portion of my /ndb/local. This supported a domain whose domain was "testad= ". Like I said, it works, but not as seamlessly as MS DNS or BIND 9 with dynamic updates enabled... (pardon the= excessive comments) ################################################# # # Active Directory support # See http://technet.microsoft.com/en-us/library/dd316373.aspx # ################################################# # # Domain Controllers: # ip=3D10.0.0.20 sys=3Dkfdc1 dom=3Dkfdc1.testad.test.local ether=3D ip=3D10.0.0.21 sys=3Dkfdc2 dom=3Dkfdc2.testad.test.local ether=3D005056b36086 # # requisite CNAME aliases # cname=3Dkfdc2.testad.test.local dom=3Dtestad.test.local cname=3Dkfdc2.testad.test.local dom=3D8df1f9af-8c89-4263-9c30-a40ad5ac728f._msdcs.testad.test.local # # SRV records, etc # dom=3Dtestad.test.local soa=3D refresh=3D3600 ttl=3D3600 ns=3Dns2.test.local #ns=3Dns1.test.local dnsdomain=3Dtestad.test.local dom=3D_ldap._tcp.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 dom=3D_kerberos._tcp.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D88 srv=3Dkfcd2.testad.test.local pri=3D1 weight=3D1 port=3D88 dom=3D_kpasswd._udp.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D464 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D464 dom=3D_kpasswd._tcp.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D464 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D464 dom=3D_ldap._tcp.dc._msdcs.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 dom=3D_ldap._tcp.gc._msdcs.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 # only one PDC dom=3D_ldap._tcp.pdc._msdcs.testad.test.local soa=3D srv=3Dkfdc2.testad.test.local pri=3D0 weight=3D0 port=3D389 dom=3D_ldap._tcp.KlamathFalls._sites.gc._msdcs.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 dom=3D_kerberos._tcp.dc._msdcs.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D88 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D88 dom=3Dgc._msdcs.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D3268 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D3268 dom=3D_gc._tcp.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D3268 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D3268 dom=3D_ldap._tcp.e3514235-4b06-11d1-ab04-00c04fc2dcd2.domains._msdcs.testad= .test.local srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 # Key Management Service dom=3D_VLMCS._tcp.testad.test.local soa=3D srv=3Dkfdc2.testad.test.local pri=3D0 weight=3D0 port=3D1688 dom=3D_ldap._tcp.KlamathFalls._sites.domaindnszones.testad.test.local soa= =3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 dom=3D_ldap._tcp.domaindnszones.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 dom=3D_ldap._tcp.KlamathFalls._sites.forestdnszones.testad.test.local soa= =3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 dom=3D_ldap._tcp.forestdnszones.testad.test.local soa=3D srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389 srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 ################################################# # # End Active Directory Support # #################################################= From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5782C16A7C920E469B74E11B5608B8E708A30DFE@Kriegler.ntdom.cupdx> References: <5782C16A7C920E469B74E11B5608B8E708A30DFE@Kriegler.ntdom.cupdx> From: Sergey Zhilkin Date: Fri, 29 Apr 2011 11:04:57 +0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: d7ff729a-ead6-11e9-9d60-3106f5b1d025 Greate example ! :) Thanks :) 2011/4/29 Benjamin Huntsman : >>Investigating the possibility of replacing the MS DNS on Plan9 DNS,not fo= und in the man ndb mention of records of type SRV. >>It is necessary to support Microsoft Active Directory. Maybe I missed som= ething? >>http://en.wikipedia.org/wiki/SRV_record > > I got AD to work with Plan 9 DNS just last year. =C2=A0It didn't work ver= y well, and I had problems with the DNS > service dying from time to time and I'd have to go restart it. =C2=A0Much= as I'd preferred to have stayed on Plan 9 DNS, > I switched to BIND 9 on OpenBSD and have had far fewer problems. =C2=A0Bu= t anyway, here's the Active Directory support > portion of my /ndb/local. =C2=A0This supported a domain whose domain was = "testad". =C2=A0Like I said, it works, but not as > seamlessly as MS DNS or BIND 9 with dynamic updates enabled... =C2=A0(par= don the excessive comments) > > > > ################################################# > # > # Active Directory support > # See http://technet.microsoft.com/en-us/library/dd316373.aspx > # > ################################################# > > # > # Domain Controllers: > # > ip=3D10.0.0.20 sys=3Dkfdc1 dom=3Dkfdc1.testad.test.local > =C2=A0 =C2=A0 =C2=A0 =C2=A0ether=3D > ip=3D10.0.0.21 sys=3Dkfdc2 dom=3Dkfdc2.testad.test.local > =C2=A0 =C2=A0ether=3D005056b36086 > > # > # requisite CNAME aliases > # > cname=3Dkfdc2.testad.test.local > =C2=A0 =C2=A0 =C2=A0 =C2=A0dom=3Dtestad.test.local > > cname=3Dkfdc2.testad.test.local > =C2=A0 =C2=A0 =C2=A0 =C2=A0dom=3D8df1f9af-8c89-4263-9c30-a40ad5ac728f._ms= dcs.testad.test.local > > # > # SRV records, etc > # > dom=3Dtestad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0refresh=3D3600 ttl=3D3600 > =C2=A0 =C2=A0 =C2=A0 =C2=A0ns=3Dns2.test.local > =C2=A0 =C2=A0 =C2=A0 =C2=A0#ns=3Dns1.test.local > =C2=A0 =C2=A0 =C2=A0 =C2=A0dnsdomain=3Dtestad.test.local > > > dom=3D_ldap._tcp.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 > > dom=3D_kerberos._tcp.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D88 > =C2=A0 =C2=A0srv=3Dkfcd2.testad.test.local pri=3D1 weight=3D1 port=3D88 > > dom=3D_kpasswd._udp.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D464 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D464 > > dom=3D_kpasswd._tcp.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D464 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D464 > > dom=3D_ldap._tcp.dc._msdcs.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389 > > dom=3D_ldap._tcp.gc._msdcs.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D389 > > # only one PDC > dom=3D_ldap._tcp.pdc._msdcs.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D0 weight= =3D0 port=3D389 > > dom=3D_ldap._tcp.KlamathFalls._sites.gc._msdcs.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D389 > > dom=3D_kerberos._tcp.dc._msdcs.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D88 > =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D88 > > dom=3Dgc._msdcs.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D3268 > =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D3268 > > dom=3D_gc._tcp.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D3268 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D3268 > > dom=3D_ldap._tcp.e3514235-4b06-11d1-ab04-00c04fc2dcd2.domains._msdcs.test= ad.test.local > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D389 > > # Key Management Service > dom=3D_VLMCS._tcp.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D0 weight= =3D0 port=3D1688 > > dom=3D_ldap._tcp.KlamathFalls._sites.domaindnszones.testad.test.local soa= =3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D389 > > dom=3D_ldap._tcp.domaindnszones.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D389 > > dom=3D_ldap._tcp.KlamathFalls._sites.forestdnszones.testad.test.local soa= =3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D389 > > dom=3D_ldap._tcp.forestdnszones.testad.test.local soa=3D > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc1.testad.test.local pri=3D0 weight= =3D0 port=3D389 > =C2=A0 =C2=A0 =C2=A0 =C2=A0srv=3Dkfdc2.testad.test.local pri=3D1 weight= =3D1 port=3D389 > > > > ################################################# > # > # End Active Directory Support > # > ################################################# > --=20 =D0=A1 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=D0=BC=D0=B8 =D0=BF= =D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=D0=B8 =D0=96=D0=B8=D0=BB=D0=BA=D0=B8=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 With best regards Zhilkin Sergey From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5782C16A7C920E469B74E11B5608B8E708A30DFE@Kriegler.ntdom.cupdx> References: <5782C16A7C920E469B74E11B5608B8E708A30DFE@Kriegler.ntdom.cupdx> Date: Fri, 29 Apr 2011 17:14:18 +0400 Message-ID: From: Sergey Kornilovich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=00504502cb1b867d7404a20e73e0 Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: d8c9310c-ead6-11e9-9d60-3106f5b1d025 --00504502cb1b867d7404a20e73e0 Content-Type: text/plain; charset=ISO-8859-1 I took your example without any changes. But unfortunately it still does not return the correct value of srv hostname ... For example: C:\Documents and Settings\Administrator>nslookup Default Server: rit.com Address: 192.168.0.190 > server 192.168.0.193 > set q=srv > _ldap._tcp.testad.test.local Server: [192.168.0.193] Address: 192.168.0.193 _ldap._tcp.testad.test.local SRV service location: priority = 0 weight = 0 port = 389 svr hostname = kfdc1\.testad\.test\.local._ldap._tcp.testad.test.loc al *** Error: record size incorrect (32 != 30) *** [192.168.0.193] can't find _ldap._tcp.testad.test.local: Unspecified error And it should be: > server 192.168.0.2 Default Server: server64.rit.com Address: 192.168.0.2 > _ldap._tcp.rit.com Server: server64.rit.com Address: 192.168.0.2 _ldap._tcp.rit.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = server65.rit.com _ldap._tcp.rit.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = server64.rit.com server65.rit.com internet address = 192.168.0.5 server64.rit.com internet address = 192.168.0.2 2011/4/29 Benjamin Huntsman > >Investigating the possibility of replacing the MS DNS on Plan9 DNS,not > found in the man ndb mention of records of type SRV. > >It is necessary to support Microsoft Active Directory. Maybe I missed > something? > >http://en.wikipedia.org/wiki/SRV_record > > I got AD to work with Plan 9 DNS just last year. It didn't work very well, > and I had problems with the DNS > service dying from time to time and I'd have to go restart it. Much as I'd > preferred to have stayed on Plan 9 DNS, > I switched to BIND 9 on OpenBSD and have had far fewer problems. But > anyway, here's the Active Directory support > portion of my /ndb/local. This supported a domain whose domain was > "testad". Like I said, it works, but not as > seamlessly as MS DNS or BIND 9 with dynamic updates enabled... (pardon the > excessive comments) > > > > ################################################# > # > # Active Directory support > # See http://technet.microsoft.com/en-us/library/dd316373.aspx > # > ################################################# > > # > # Domain Controllers: > # > ip=10.0.0.20 sys=kfdc1 dom=kfdc1.testad.test.local > ether= > ip=10.0.0.21 sys=kfdc2 dom=kfdc2.testad.test.local > ether=005056b36086 > > # > # requisite CNAME aliases > # > cname=kfdc2.testad.test.local > dom=testad.test.local > > cname=kfdc2.testad.test.local > dom=8df1f9af-8c89-4263-9c30-a40ad5ac728f._msdcs.testad.test.local > > # > # SRV records, etc > # > dom=testad.test.local soa= > refresh=3600 ttl=3600 > ns=ns2.test.local > #ns=ns1.test.local > dnsdomain=testad.test.local > > > dom=_ldap._tcp.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > dom=_kerberos._tcp.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=88 > srv=kfcd2.testad.test.local pri=1 weight=1 port=88 > > dom=_kpasswd._udp.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=464 > srv=kfdc2.testad.test.local pri=1 weight=1 port=464 > > dom=_kpasswd._tcp.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=464 > srv=kfdc2.testad.test.local pri=1 weight=1 port=464 > > dom=_ldap._tcp.dc._msdcs.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > dom=_ldap._tcp.gc._msdcs.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > # only one PDC > dom=_ldap._tcp.pdc._msdcs.testad.test.local soa= > srv=kfdc2.testad.test.local pri=0 weight=0 port=389 > > dom=_ldap._tcp.KlamathFalls._sites.gc._msdcs.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > dom=_kerberos._tcp.dc._msdcs.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=88 > srv=kfdc2.testad.test.local pri=1 weight=1 port=88 > > dom=gc._msdcs.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=3268 > srv=kfdc2.testad.test.local pri=1 weight=1 port=3268 > > dom=_gc._tcp.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=3268 > srv=kfdc2.testad.test.local pri=1 weight=1 port=3268 > > > dom=_ldap._tcp.e3514235-4b06-11d1-ab04-00c04fc2dcd2.domains._msdcs.testad.test.local > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > # Key Management Service > dom=_VLMCS._tcp.testad.test.local soa= > srv=kfdc2.testad.test.local pri=0 weight=0 port=1688 > > dom=_ldap._tcp.KlamathFalls._sites.domaindnszones.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > dom=_ldap._tcp.domaindnszones.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > dom=_ldap._tcp.KlamathFalls._sites.forestdnszones.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > dom=_ldap._tcp.forestdnszones.testad.test.local soa= > srv=kfdc1.testad.test.local pri=0 weight=0 port=389 > srv=kfdc2.testad.test.local pri=1 weight=1 port=389 > > > > ################################################# > # > # End Active Directory Support > # > ################################################# > --00504502cb1b867d7404a20e73e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I took your example without any changes. But unfortunately it still doe= s not return the correct value of srv hostname ...
For example:
=
C:\Documents and Settings\Administrator>nslookup
Default S= erver: rit.com
Address: 192.168.0.190

> server 192.168.0.193
>= set q=3Dsrv
> _ldap._tcp.testad.test.local
Server: [192.168.0.19= 3]
Address: 192.168.0.193

_ldap._tcp.testad.test.local SRV se= rvice location:
priority =3D 0
weight =3D 0
= port =3D 389
svr hostname =3D kfdc1\.testad\.te= st\.local._ldap._tcp.testad.test.loc
al

*** Error: record size in= correct (32 !=3D 30)

*** [192.168.0.193] can't find _ldap._tcp.testad.test.local: Unspec= ified error

And it should be:
> s= erver 192.168.0.2
Default Server: s= erver64.rit.com
Address: 192.168.0.2

> _ldap._tcp= .rit.com
Server: server64.rit.c= om
Address: 192.168.0.2

_ldap._tcp.rit.com SRV service location:
priority =3D 0
weight =3D 100
= port =3D 389
svr hostname =3D server65.rit.com
_ldap._tcp.rit.com SRV service location:
priority =3D 0
weight =3D 100
= port =3D 389
svr hostname =3D server64.rit.com
server65.rit.com internet address =3D 192.168.0.5
server64.rit.com internet ad= dress =3D 192.168.0.2

2011/4/29 Ben= jamin Huntsman <BHuntsman@mail2.cu-portland.edu>
>Investigating the pos= sibility of replacing the MS DNS on Plan9 DNS,not found in the man ndb ment= ion of records of type SRV.
>It is necessary to support Microsoft Active Directory. Maybe I missed s= omething?
>h= ttp://en.wikipedia.org/wiki/SRV_record

I got AD to work with Plan 9 DNS just last year. =A0It didn't wor= k very well, and I had problems with the DNS
service dying from time to time and I'd have to go restart it. =A0Much = as I'd preferred to have stayed on Plan 9 DNS,
I switched to BIND 9 on OpenBSD and have had far fewer problems. =A0But any= way, here's the Active Directory support
portion of my /ndb/local. =A0This supported a domain whose domain was "= ;testad". =A0Like I said, it works, but not as
seamlessly as MS DNS or BIND 9 with dynamic updates enabled... =A0(pardon t= he excessive comments)



#################################################
#
# Active Directory support
# See http://technet.microsoft.com/en-us/library/dd316373.aspx<= /a>
#
#################################################

#
# Domain Controllers:
#
ip=3D10.0.0.20 sys=3Dkfdc1 dom=3Dkfdc1.testad.test.local
=A0 =A0 =A0 =A0ether=3D
ip=3D10.0.0.21 sys=3Dkfdc2 dom=3Dkfdc2.testad.test.local
=A0 =A0ether=3D005056b36086

#
# requisite CNAME aliases
#
cname=3Dkfdc2.testad.test.local
=A0 =A0 =A0 =A0dom=3Dtestad.test.local

cname=3Dkfdc2.testad.test.local
=A0 =A0 =A0 =A0dom=3D8df1f9af-8c89-4263-9c30-a40ad5ac728f._msdcs.testad.te= st.local

#
# SRV records, etc
#
dom=3Dtestad.test.local soa=3D
=A0 =A0 =A0 =A0refresh=3D3600 ttl=3D3600
=A0 =A0 =A0 =A0ns=3Dns2.test.local
=A0 =A0 =A0 =A0#ns=3Dns1.test.local
=A0 =A0 =A0 =A0dnsdomain=3Dtestad.test.local


dom=3D_ldap._tcp.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389

dom=3D_kerberos._tcp.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D88<= br> =A0 =A0srv=3Dkfcd2.testad.test.local pri=3D1 weight=3D1 port=3D88

dom=3D_kpasswd._udp.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D464=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D464=

dom=3D_kpasswd._tcp.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D464=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D464=

dom=3D_ldap._tcp.dc._msdcs.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389

dom=3D_ldap._tcp.gc._msdcs.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389=

# only one PDC
dom=3D_ldap._tcp.pdc._msdcs.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D0 weight=3D0 port=3D389=

dom=3D_ldap._tcp.KlamathFalls._sites.gc._msdcs.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389=

dom=3D_kerberos._tcp.dc._msdcs.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D88<= br> =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D88

dom=3Dgc._msdcs.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D326= 8
=A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D3268

dom=3D_gc._tcp.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D326= 8
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D326= 8

dom=3D_ldap._tcp.e3514235-4b06-11d1-ab04-00c04fc2dcd2.domains._msdcs.testad= .test.local
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389=

# Key Management Service
dom=3D_VLMCS._tcp.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D0 weight=3D0 port=3D168= 8

dom=3D_ldap._tcp.KlamathFalls._sites.domaindnszones.testad.test.local soa= =3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389=

dom=3D_ldap._tcp.domaindnszones.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389=

dom=3D_ldap._tcp.KlamathFalls._sites.forestdnszones.testad.test.local soa= =3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389=

dom=3D_ldap._tcp.forestdnszones.testad.test.local soa=3D
=A0 =A0 =A0 =A0srv=3Dkfdc1.testad.test.local pri=3D0 weight=3D0 port=3D389=
=A0 =A0 =A0 =A0srv=3Dkfdc2.testad.test.local pri=3D1 weight=3D1 port=3D389=



#################################################
#
# End Active Directory Support
#
#################################################

--00504502cb1b867d7404a20e73e0-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 3 May 2011 12:30:43 +0400 Message-ID: From: Sergey Kornilovich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001636e0a59ebb953a04a25af46d Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: db758b9e-ead6-11e9-9d60-3106f5b1d025 --001636e0a59ebb953a04a25af46d Content-Type: text/plain; charset=ISO-8859-1 So far, everything looks like a bug in the dns ... Take a simple local file: cat /lib/ndb/local database= file=/lib/ndb/local file=/lib/ndb/common dom=test.local soa= refresh=3600 ttl=3600 ns=server.test.local dom=_ldap._tcp.test.local soa= refresh=3600 ttl=3600 srv=server.test.local pri=0 weight=0 port=389 ip=192.168.0.193 sys=server dom=server.test.local >>From plan9 everything looks fine: cpu% dnsquery > server.test.local server.test.local ip 192.168.0.193 > _ldap._tcp.test.local srv _ldap._tcp.test.local srv 0 0 389 server.test.local But not from linux, not from windows, access to SRV records can not be obtained .. Linux output(Gentoo, bind-tools 9.7.3): krok@krok ~ $ nslookup > server 192.168.0.193 Default server: 192.168.0.193 Address: 192.168.0.193#53 > set q=srv > _ldap._tcp.test.local ;; Warning: Message parser reports malformed message packet. Server: 192.168.0.193 Address: 192.168.0.193#53 *** Can't find _ldap._tcp.test.local: No answer Windows output(Windows Server 2003): Address: 192.168.0.193 > set q=srv > _ldap._tcp.test.local Server: ns.rit.com Address: 192.168.0.193 _ldap._tcp.test.local SRV service location: priority = 0 weight = 0 port = 389 svr hostname = Invalid Name at offset 57! *** Error: record size incorrect (-391819 != 24) _ldap._tcp.test.local SRV service location: priority = 0 weight = 0 port = 389 svr hostname = Invalid Name at offset 57! *** Error: record size incorrect (-391819 != 24) *** ns.rit.com can't find _ldap._tcp.test.local: Unspecified error Does anyone have ideas how to fix the situation? --001636e0a59ebb953a04a25af46d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So far, everything looks like a bug in the dns ...
Take a simple lo= cal file:
cat /lib/ndb/local
database=3D
file=3D/lib/n= db/local
file=3D/lib/ndb/common

dom=3Dtest.local soa=3D
refr= esh=3D3600 ttl=3D3600
ns=3Dserver.test.local

dom=3D_ldap._tcp.test.local soa=3D
refre= sh=3D3600 ttl=3D3600
srv=3Dserver.test.local pri=3D0 weight=3D0 port=3D= 389

ip=3D192.168.0.193 sys=3Dserver dom=3Dserver.test.local

From plan9 everything looks fine:

cpu% dnsquery
> server.test.local
server.test.local ip 19= 2.168.0.193
> _ldap._tcp.test.local srv
_ldap._tcp.test.local srv = 0 0 389 server.test.local

But not from linux, not from windows, acce= ss to SRV records can not be obtained ..
Linux output(Gentoo, bind-tools 9.7.3):

krok@krok ~ $ nslookup
> server 192.168.0.193
Default server: 192= .168.0.193
Address: 192.168.0.193#53
> set q=3Dsrv
> _ldap._= tcp.test.local
;; Warning: Message parser reports malformed message packet.
Server: = 192.168.0.193
Address: 192.168.0.193#53

*** Can't= find _ldap._tcp.test.local: No answer

Windows= output(Windows Server 2003):

Address: 192.168.0.193

> set q=3Dsrv> _ldap._tcp.test.local
Server: ns.r= it.com
Address: 192.168.0.193

_ldap._tcp.test.local SRV se= rvice location:
priority =3D 0
weight =3D 0
= port =3D 389
svr hostname =3D Invalid Name at o= ffset 57!


*** Error: record size incorrect (-391819 !=3D 24)
=
_ldap._tcp.test.local SRV service location:
priority =3D 0
weight =3D 0
= port =3D 389
svr hostname =3D Invalid Name at o= ffset 57!


*** Error: record size incorrect (-391819 !=3D 24)
=
*** ns.rit.com can't find _ldap._= tcp.test.local: Unspecified error

Does anyone have ideas how to fix the situation?<= /div>

--001636e0a59ebb953a04a25af46d-- From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Wed, 4 May 2011 11:41:06 +0000 From: Pavel Klinkovsky Message-ID: <2ef2821c-eb63-427a-95c5-0e36a6c73b28@j26g2000yqa.googlegroups.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: , Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: dbac60ec-ead6-11e9-9d60-3106f5b1d025 On 3 kv=C4=9B, 10:33, roo...@gmail.com (Sergey Kornilovich) wrote: > So far, everything looks like a bug in the dns ... > Does anyone have ideas how to fix the situation? The behavior is very similar to my problematic situation: http://groups.google.com/group/comp.os.plan9/browse_thread/thread/a6aeb2ea5= 1aad59a/a995246515877b86?lnk=3Dgst&q=3DDNS+problem#a995246515877b86 I think the DNS in plan9 has a problem. But up to now, I did not find where... Pavel From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 4 May 2011 09:10:20 -0400 To: 9fans@9fans.net Message-ID: <8a4451166089e95bda3bcaa598ccaec0@brasstown.quanstro.net> In-Reply-To: <2ef2821c-eb63-427a-95c5-0e36a6c73b28@j26g2000yqa.googlegroups.co> References: <2ef2821c-eb63-427a-95c5-0e36a6c73b28@j26g2000yqa.googlegroups.co> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: dc122968-ead6-11e9-9d60-3106f5b1d025 On Wed May 4 07:46:40 EDT 2011, pavel.klinkovsky@gmail.com wrote: > On 3 kvě, 10:33, roo...@gmail.com (Sergey Kornilovich) wrote: > So > far, everything looks like a bug in the dns ... > Does anyone have > ideas how to fix the situation? > > The behavior is very similar to my problematic situation: > http://groups.google.com/group/comp.os.plan9/browse_thread/thread/a6aeb2ea51aad59a/a995246515877b86?lnk=gst&q=DNS+problem#a995246515877b86 > > I think the DNS in plan9 has a problem. But up to now, I did not find > where... it's broken, as are many things dns. dns needs some maintence, and a race-resistant database model. long srv records may also crash or hopelessly confuse your dns server. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8a4451166089e95bda3bcaa598ccaec0@brasstown.quanstro.net> References: <2ef2821c-eb63-427a-95c5-0e36a6c73b28@j26g2000yqa.googlegroups.co> <8a4451166089e95bda3bcaa598ccaec0@brasstown.quanstro.net> Date: Thu, 5 May 2011 13:42:00 +0400 Message-ID: From: Sergey Kornilovich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd28db851c3b804a2842f85 Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: dd3135b4-ead6-11e9-9d60-3106f5b1d025 --000e0cd28db851c3b804a2842f85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I understand it correctly? The problem is 5 months and a speedy solution ca= n not hope for? Sad .. 2011/5/4 erik quanstrom > On Wed May 4 07:46:40 EDT 2011, pavel.klinkovsky@gmail.com wrote: > > On 3 kv=C4=9B, 10:33, roo...@gmail.com (Sergey Kornilovich) wrote: > So > > far, everything looks like a bug in the dns ... > Does anyone have > > ideas how to fix the situation? > > > > The behavior is very similar to my problematic situation: > > > http://groups.google.com/group/comp.os.plan9/browse_thread/thread/a6aeb2e= a51aad59a/a995246515877b86?lnk=3Dgst&q=3DDNS+problem#a995246515877b86 > > > > I think the DNS in plan9 has a problem. But up to now, I did not find > > where... > > it's broken, as are many things dns. dns needs some > maintence, and a race-resistant database model. > > long srv records may also crash or hopelessly confuse > your dns server. > > - erik > > --000e0cd28db851c3b804a2842f85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I understand it correctly? The problem is 5 months and a speedy soluti= on can not hope for? Sad ..


2011/5/4 erik quanstrom <quanstro@quanstro.net>
On Wed May =C2=A04 07:46:40 EDT 2011, pavel.klinkovsky@gmail.com wro= te:
> On 3 kv=C4=9B, 10:33, roo...@gmail= .com (Sergey Kornilovich) wrote: > So
> far, everything looks like a bug in the dns ... =C2=A0> Does anyone= have
> ideas how to fix the situation?
>
> The behavior is very similar to my problematic= situation:
> http://groups.google.com/group/comp.os.plan= 9/browse_thread/thread/a6aeb2ea51aad59a/a995246515877b86?lnk=3Dgst&q=3D= DNS+problem#a995246515877b86
>
> I think the DNS in plan9 has a problem. =C2=A0But up to now, I did not= find
> where...

it's broken, as are many things dns. =C2=A0dns needs some
maintence, and a race-resistant database model.

long srv records may also crash or hopelessly confuse
your dns server.

- erik


--000e0cd28db851c3b804a2842f85-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 5 May 2011 08:45:53 -0400 To: 9fans@9fans.net Message-ID: <803cc23bfad936b76415c4517d2a40b2@brasstown.quanstro.net> In-Reply-To: References: <2ef2821c-eb63-427a-95c5-0e36a6c73b28@j26g2000yqa.googlegroups.co> <8a4451166089e95bda3bcaa598ccaec0@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: dd942598-ead6-11e9-9d60-3106f5b1d025 On Thu May 5 05:44:12 EDT 2011, root81@gmail.com wrote: > I understand it correctly? The problem is 5 months and a speedy solution can > not hope for? Sad .. why don't you take a look at the problem? - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <803cc23bfad936b76415c4517d2a40b2@brasstown.quanstro.net> References: <2ef2821c-eb63-427a-95c5-0e36a6c73b28@j26g2000yqa.googlegroups.co> <8a4451166089e95bda3bcaa598ccaec0@brasstown.quanstro.net> <803cc23bfad936b76415c4517d2a40b2@brasstown.quanstro.net> Date: Thu, 5 May 2011 19:35:59 +0400 Message-ID: From: Sergey Kornilovich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd28db84e10b604a289212e Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: ddc1f568-ead6-11e9-9d60-3106f5b1d025 --000e0cd28db84e10b604a289212e Content-Type: text/plain; charset=ISO-8859-1 Unfortunately I do not know C. .. My max - rc scripts. I can help testing, and bug reports. Perhaps somewhere there is a bugzilla? (or redmine) But, as I understand it, here the development is built on the principle: Do you find it, you fix it, send a patch. :) 2011/5/5 erik quanstrom > On Thu May 5 05:44:12 EDT 2011, root81@gmail.com wrote: > > > I understand it correctly? The problem is 5 months and a speedy solution > can > > not hope for? Sad .. > > why don't you take a look at the problem? > > - erik > > --000e0cd28db84e10b604a289212e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Unfortunately I do not know C. .. My max - rc scripts. I can help testi= ng, and bug reports. Perhaps somewhere there is a bugzilla? (or redmine)But, as I understand it, here the development is built on the principle: D= o you find it, you fix it, send a patch. :)

2011/5/5 erik quanstrom &l= t;quanstro@quanstro.net>
On Thu May =A05 05:44:12 EDT 2011, root81@gmail.com wrote:

> I understand it correctly? The problem is 5 months and a speedy soluti= on can
> not hope for? Sad ..

why don't you take a look at the problem?

- erik


--000e0cd28db84e10b604a289212e-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 5 May 2011 11:44:25 -0400 To: 9fans@9fans.net Message-ID: <34b590418e3d90a1f89870511e01a126@coraid.com> In-Reply-To: References: <2ef2821c-eb63-427a-95c5-0e36a6c73b28@j26g2000yqa.googlegroups.co> <8a4451166089e95bda3bcaa598ccaec0@brasstown.quanstro.net> <803cc23bfad936b76415c4517d2a40b2@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] dns SRV records Topicbox-Message-UUID: ddc8af70-ead6-11e9-9d60-3106f5b1d025 > Unfortunately I do not know C. .. My max - rc scripts. I can help testing, > and bug reports. Perhaps somewhere there is a bugzilla? (or redmine) > But, as I understand it, here the development is built on the principle: Do > you find it, you fix it, send a patch. :) almost, i think it's perfectly valid to not fix a bug for any reason. there's no obligation here. - erik