[9fans] dns SRV records

[9fans] dns SRV records

[Sergey Kornilovich]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 352 bytes --]

Re: [9fans] dns SRV records

[Sergey Zhilkin]

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=10.0.0.1 sys=_service
dom=_tcp.local
srv=1111


2011/4/28 Sergey Kornilovich <root81@gmail.com>:
> 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
>



-- 
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey

Re: [9fans] dns SRV records

[Steve Simon]

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

Re: [9fans] dns SRV records

[geoff]

See ndb(6).

Re: [9fans] dns SRV records

[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
#
#################################################

Re: [9fans] dns SRV records

[Sergey Zhilkin]

Greate example ! :) Thanks :)

2011/4/29 Benjamin Huntsman <BHuntsman@mail2.cu-portland.edu>:
>>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
> #
> #################################################
>



-- 
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey

Re: [9fans] dns SRV records

[Sergey Kornilovich]

[-- Attachment #1: Type: text/plain, Size: 6041 bytes --]

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 <BHuntsman@mail2.cu-portland.edu>

> >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
> #
> #################################################
>

[-- Attachment #2: Type: text/html, Size: 7557 bytes --]

Re: [9fans] dns SRV records

[Sergey Kornilovich]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 2207 bytes --]

Re: [9fans] dns SRV records

[Pavel Klinkovsky]

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...

Pavel

Re: [9fans] dns SRV records

[erik quanstrom]

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

Re: [9fans] dns SRV records

[Sergey Kornilovich]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

I understand it correctly? The problem is 5 months and a speedy solution can
not hope for? Sad ..


2011/5/4 erik quanstrom <quanstro@quanstro.net>

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 1598 bytes --]

Re: [9fans] dns SRV records

[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

Re: [9fans] dns SRV records

[Sergey Kornilovich]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

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 <quanstro@quanstro.net>

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 912 bytes --]

Re: [9fans] dns SRV records

[erik quanstrom]

> 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