[9fans] DNS... don't ask

[9fans] DNS... don't ask

[Benjamin Huntsman]

I don't suppose anyone's ever tried using Plan 9's DNS server with Active Directory?  (as the primary DNS server)
Appologies in advance if anything below sounds overly confused, and for trying this in the first place!!

There are a few articles around indicating that it's possible to host AD with 3rd-party DNS servers, so long as you create the necessary SRV records.  Indeed, I got quite far, but some things just aren't right.  In particular, I'm concerned about PTR records and reverse lookups.  A post on this list by Geoff says that if you specify an in-addr.arpa zone, the correct PTR's will get generated automatically.  How does it know which PTR to generate, if I have more than one dom= pointing to the same ip?  The MS DNS seems to use more than one A record for a host (ie, it's regular hostname, a guid host name, and sometimes a "(same as parent)" record allowing resolution of a zone name to a specific host), but the PTR in the reverse lookup zone always points back to the "normal" hostname.  Here's some output from nslookup from a Windows system talking to the Plan 9 DNS:

C:\>nslookup -type=srv _kpasswd._udp.testdom.test.local
Server:  ns2.test.local
Address:  10.0.0.102

_kpasswd._udp.testdom.test.local  SRV service location:
          priority        = 0
          weight          = 0
          port            = 464
          svr hostname    = dc1\.testdom\.test\.local._kpasswd._udp.testdom.test.local

*** Error: record size incorrect (39 != 37)

*** ns2.test.local can't find _kpasswd._udp: server failed

C:\>nslookup -type=srv _kpasswd._udp
Server:  ns2.test.local
Address:  10.0.0.102

*** ns2.test.local can't find _kpasswd._udp: Server failed

C:\>

The equivalent query run through ndb/dnsquery on Plan 9 works correctly.  On some queries, I get "Invalid Name at offset 72!" on the "svr hostname" line.  I suspect this is part of the problem.  Additionally, the short form "_kpasswd._tcp" fails, but specifying the fully-qualified name works.  This behavior is also seen on the Plan 9 host, where the short lookup also fails.

Below is most of my ridiculously complicated /lib/ndb/local, in the hopes that someone might spot anything that looks fishy.  You can see where I have a CNAME to testdom.test.local, which should probably be an A name...  Many thanks in advance!

-Ben



authdom=test.local auth=ns2

ipnet=internal ip=10.0.0.0 ipmask=255.255.0.0
	ipsubmask=255.255.255.0
	dns=ns2.test.local
	#dns=ns1.test.local
	dnsdomain=test.local
	ipgw=10.0.0.1
	authdom=test.local auth=ns2
	
dom=test.local soa=
	refresh=3600 ttl=3600
	ns=ns2.test.local
	#ns=ns1.test.local
	dnsdomain=test.local

dom=0.0.0.10.in-addr.arpa soa=
	refresh=3600 ttl=3600
	ns=ns2.test.local
	#ns=ns1.test.local

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

#
# Domain Controllers:
#
ip=10.0.0.20 sys=dc1 dom=dc1.testdom.test.local
	ether=
ip=10.0.0.21 sys=dc2 dom=dc2.testdom.test.local
    ether=005056b36086

cname=dc2.testdom.test.local
	dom=testdom.test.local

cname=dc2.testdom.test.local
	dom=8df1c9af-8e80-4263-9a40-a40ad5af728f._msdcs.testdom.test.local

#
# SRV records, etc
#
dom=testdom.test.local soa=
	refresh=3600 ttl=3600
	ns=ns2.test.local
	#ns=ns1.test.local
	dnsdomain=testdom.test.local

dom=_ldap._tcp.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
    srv=dc2.testdom.test.local pri=1 weight=0 port=389

dom=_kerberos._tcp.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=88
	srv=kfcd2.testdom.test.local pri=1 weight=0 port=88

dom=_kpasswd._udp.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=464
	srv=dc2.testdom.test.local pri=1 weight=0 port=464

dom=_kpasswd._tcp.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=464
	srv=dc2.testdom.test.local pri=1 weight=0 port=464

dom=_ldap._tcp.dc._msdcs.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
	srv=dc2.testdom.test.local pri=1 weight=0 port=389

dom=_ldap._tcp.gc._msdcs.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
	srv=dc2.testdom.test.local pri=1 weight=0 port=389

dom=_ldap._tcp.pdc._msdcs.testdom.test.local soa=
	srv=dc2.testdom.test.local pri=0 weight=0 port=389

dom=_ldap._tcp.Default-Site._sites.gc._msdcs.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
	srv=dc2.testdom.test.local pri=1 weight=0 port=389

dom=_kerberos._tcp.dc._msdcs.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=88
	srv=dc2.testdom.test.local pri=1 weight=0 port=88

dom=gc._msdcs.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=3268
	srv=dc2.testdom.test.local pri=1 weight=0 port=3268

dom=_gc._tcp.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=3268
	srv=dc2.testdom.test.local pri=1 weight=0 port=3268

dom=_ldap._tcp.e3510231-4b06-11c1-ab34-01c04dc2ded2.domains._msdcs.testdom.test.local
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
	srv=dc2.testdom.test.local pri=1 weight=0 port=389

dom=_vlmcs._tcp.testdom.test.local soa=
	srv=dc2.testdom.test.local pri=0 weight=0 port=1688

dom=_ldap._tcp.Default-Site._sites.domaindnszones.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
	srv=dc2.testdom.test.local pri=1 weight=0 port=389

dom=_ldap._tcp.domaindnszones.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
	srv=dc2.testdom.test.local pri=1 weight=0 port=389

dom=_ldap._tcp.Default-Site._sites.forestdnszones.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
	srv=dc2.testdom.test.local pri=1 weight=0 port=389

dom=_ldap._tcp.forestdnszones.testdom.test.local soa=
	srv=dc1.testdom.test.local pri=0 weight=0 port=389
	srv=dc2.testdom.test.local pri=1 weight=0 port=389



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


On a side note, I DHCP is provided by isc-dhcpd, and I have the following in the configuration, which seems to work:

option domain-search-order code 119 = string;
option domain-search-order "testdom.test.local test.local";

Re: [9fans] DNS... don't ask

[erik quanstrom]

> A post on this list by Geoff says that if you specify an in-addr.arpa zone,
> the correct PTR's will get generated automatically.  How does it know which
> PTR to generate, if I have more than one dom= pointing to the same ip?

it makes all of them. e.g.

> 7.0/27.113.51.12.in-addr.arpa any
7.0/27.113.51.12.in-addr.arpa ptr	imap.coraid.com
7.0/27.113.51.12.in-addr.arpa ptr	smtp.coraid.com

there's a bug in dns that prevents this query from working
alone.  you'll have to do this query first:

> 7.113.51.12.in-addr.arpa any
2.113.51.12.in-addr.arpa cname	7.0/27.113.51.12.in-addr.arpa

- erik

Re: [9fans] DNS... don't ask

[Benjamin Huntsman]

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

Also, what do you make of this?

>       svr hostname    = dc1\.testdom\.test\.local._kpasswd._udp.testdom.test.local
>
>*** Error: record size incorrect (39 != 37)
>
>*** ns2.test.local can't find _kpasswd._udp.testdom.test.local: server failed

The query should return an "svr hostname" of dc1.testdom.test.local, minus the backslashes and the extra iteration of ._kpasswd._udp...
I also still don't understand why the short lookup of _kpasswd._tcp fails, even on the Plan 9 system.

Is this a bug in Plan 9 DNS, or a misconfiguration?

Thanks again!!

-Ben

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2637 bytes --]

Re: [9fans] DNS... don't ask

[Steve Simon]

I have not tried serving srv records fromplan9 but i do host my
domain (quintile.net) from plan9, and I do use plan9 in a domain
served by AD at work.

I (with some help from geoff) wrote zonefresh which sucks up a domain
(using axfr) and spits it out as an ndb file. This could be useful to
check that you are serving what you think you are.

I use this to keep a local copy of my work AD DNS which I find easier
to debug when problems arise. If you have a real AD server which you are
trying to replace this could automate the process a little.

Contact me off-list if you want to specifics.

-Steve