[9fans] Authoritative Name Server

[9fans] Authoritative Name Server

[Akshat Kumar]

I'm trying to setup an authoritative name server for a domain
in Plan 9. Not all of the available ndb(6) directives for this task
are documented, so I have some questions:

The secondary name servers all run BIND on UNIX, and I need
to do zone transfers to them, from Plan 9. Will simple zone
transfers (given the -n flag to ndb/dns) suffice, or does the
outgoing ndb file somehow need to be reformatted for BIND?

If I have subdomains for the domain I'm managing, do those
subdomains get their own dom=... blocks? If so, do I need to
specify soa=, dnsslave=, ns=, etc. for each subdomain entry,
or will the specifications for the main domain satisfy?
(E.g.:
dom=example.com soa=
  serial=2009150901
  refresh=10800 retry=3600 ttl=86400 expire=2592000
  ip=x.x.x.x
  ns=ns1.example.com
  ns=myexample.com
  ns=yaexample.com
  dnsslave=myexample.com
  dnsslave=yaexample.com

dom=mail.example.com soa=
  mx=... pref=1
  mx=... pref=5
  ...

dom=sub.mail.example.com cname=mail.example.com

here, does the mail.example.com block need to also have ns=,
refresh=, and the other entries found in the example.com block?)

In zone transfers, is everything that is included by /lib/ndb/local sent,
or can one specify what (or which file) to send? For these purposes,
I'm keeping the whole domain configuration in a separate file:
/lib/ndb/zone


Thanks,
ak

Re: [9fans] Authoritative Name Server

[erik quanstrom]

> The secondary name servers all run BIND on UNIX, and I need
> to do zone transfers to them, from Plan 9. Will simple zone
> transfers (given the -n flag to ndb/dns) suffice, or does the
> outgoing ndb file somehow need to be reformatted for BIND?

looks like it should work.  if you should need an bind-comptable
zone file (and i do), contrib quanstro/ndbtozone is a program that
converts ndb format to dns format.  it tosses out-of-balliwick stuff
and ndb tuples that have no bearing on dns.

> If I have subdomains for the domain I'm managing, do those
> subdomains get their own dom=... blocks? If so, do I need to
> specify soa=, dnsslave=, ns=, etc. for each subdomain entry,
> or will the specifications for the main domain satisfy?

this depends entirely if you want to have the subdomains
as seperate zones or not.  dns is really wierd.  imagine if
you could have "/" in a file name.  then x/y could be either
the directory x containing file y or just the file named x/y.
replace "/" with "." and that's how dns zones work.

i wouldn't bother breaking up the zones if there's no
particular adminstative reason to do so.

- erik

Re: [9fans] Authoritative Name Server

[Akshat Kumar]

Thanks, Erik.

> i wouldn't bother breaking up the zones if there's no
> particular adminstative reason to do so.

I have MX records that pertain only to certain subdomains.
In BIND speak:
mail.example.com MX 1 mx.server.com
so, in this case, I suppose I would need a separate dom=
block for mail.example.com? I'm not sure how I would specify
that mx record from the main domain block.


Best,
ak

Re: [9fans] Authoritative Name Server

[erik quanstrom]

> I have MX records that pertain only to certain subdomains.
> In BIND speak:
> mail.example.com MX 1 mx.server.com
> so, in this case, I suppose I would need a separate dom=
> block for mail.example.com? I'm not sure how I would specify
> that mx record from the main domain block.

standard bind idioms are misleading.  mx records
stand by themselves.  the mx record can be the
only reference to the name, e.g.

# no other references
dom=frozzle.coraid.com
	mx=frazzle.coraid.com pref=1

atlas; ndb/dnsquery frozzle.coraid.com mx
frozzle.coraid.com mx	1 frazzle.coraid.com

i- erik

Re: [9fans] Authoritative Name Server

[Akshat Kumar]

I've got the basic setup going, and have tested it for appropriate
information using ndb/dnsquery in Plan 9 (on the same computer
that is running `ndb/dns -rns`).

> looks like it should work.  if you should need an bind-comptable
> zone file (and i do), contrib quanstro/ndbtozone is a program that
> converts ndb format to dns format.  it tosses out-of-balliwick stuff
> and ndb tuples that have no bearing on dns.

However, when I test the name server using:

dig @ns1.nanosouffle.net nanosouffle.net axfr

I get partial data back, but the transfer fails with:
;; Warning: Message parser reports malformed message packet.
; Transfer failed.

Does this indicate that I should use your ndbtozone program?
How do you automate the process of converting to dns format
and then sending the data, when doing a zone transfer?
My secondary nameservers are running BIND on UNIX.


Thanks,
ak

Re: [9fans] Authoritative Name Server

[Akshat Kumar]

Further testing shows that the problem is with
my srv entries. Is it my ndb configuration, or
just a problem with ndb/dns? Here's the
portion that causes the above problem
(if uncommented) with a zone transfer using dig
on Linux:

#dom=_jabber._tcp.mail.nanosouffle.net
#	srv=xmpp-server.l.google.com pri=5 weight=0 port=5269
#	srv=xmpp-server1.l.google.com pri=20 weight=0 port=5269
#	srv=xmpp-server2.l.google.com pri=20 weight=0 port=5269
#	srv=xmpp-server3.l.google.com pri=20 weight=0 port=5269
#	srv=xmpp-server4.l.google.com pri=20 weight=0 port=5269
#
#dom=_xmpp-server._tcp.mail.nanosouffle.net
#	srv=xmpp-server.l.google.com pri=20 weight=0 port=5269
#	srv=xmpp-server1.l.google.com pri=20 weight=0 port=5269
#	srv=xmpp-server2.l.google.com pri=20 weight=0 port=5269
#	srv=xmpp-server3.l.google.com pri=20 weight=0 port=5269
#	srv=xmpp-server4.l.google.com pri=20 weight=0 port=5269

If I have this commented, zone transfers with dig work just fine.
What's the proper setup here?


Thanks,
ak

Re: [9fans] Authoritative Name Server

[erik quanstrom]

> Does this indicate that I should use your ndbtozone program?
> How do you automate the process of converting to dns format
> and then sending the data, when doing a zone transfer?
> My secondary nameservers are running BIND on UNIX.

ndbtozone creates a textual zone file that's compatable
with bind.  axfr uses a binary format.

- erik

Re: [9fans] Authoritative Name Server

[Lyndon Nerenberg - VE6BBM/VE7TFX]

You don't need to do anything special for BIND to slave from your
Plan9 master. I have a BIND slaving from a Plan 9 master without any
issues.

On the Plan 9 master, start ndb/dns with the -n flag, and add dnsslave
entries to /lib/ndb/local for each of your slave hosts.  Here are the
relevant entries from my /lib/ndb/local.  Gandalf is the Plan 9 DNS
master, legolas is the BIND slave.

dom=yyc.orthanc.ca soa=
	refresh=3600 ttl=14400
	ns=gandalf.yyc.orthanc.ca
	ns=legolas.yyc.orthanc.ca
	mbox=lyndon@orthanc.ca
	dnsslave=legolas.yyc.orthanc.ca

dom=0.168.192.in-addr.arpa soa=
	refresh=3600 ttl=3600
	ns=gandalf.yyc.orthanc.ca
	ns=legolas.yyc.orthanc.ca
	mbox=lyndon@orthanc.ca
	dnsslave=legolas.yyc.orthanc.ca

Also, make sure /rc/bin/service/tcp53 is enabled on the DNS master
host and that the slave can get a connection to it; the slave needs
a TCP connection to the master to do the zone transfer.

--lyndon

Re: [9fans] Authoritative Name Server

[Akshat Kumar]

Thanks. This is all fine, now.

The remaining problem is regarding my earlier post about
SRV records. Using ndb/dnsquery, I get proper output:

cpu% ndb/dnsquery
> _jabber._tcp.mail.nanosouffle.net srv
_jabber._tcp.mail.nanosouffle.net srv	5 0 5269 xmpp-server.l.google.com
_jabber._tcp.mail.nanosouffle.net srv	20 0 5269 xmpp-server1.l.google.com
_jabber._tcp.mail.nanosouffle.net srv	20 0 5269 xmpp-server2.l.google.com
_jabber._tcp.mail.nanosouffle.net srv	20 0 5269 xmpp-server3.l.google.com
_jabber._tcp.mail.nanosouffle.net srv	20 0 5269 xmpp-server4.l.google.com

However, using dig, there is a problem:

linux$ dig @ns1.nanosouffle.net _jabber._tcp.mail.nanosouffle.net srv
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.5.0a6 <<>> @ns1.nanosouffle.net
_jabber._tcp.mail.nanosouffle.net srv
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14236
;; flags: qr aa ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Messages has 207 extra bytes at end

;; QUESTION SECTION:
;_jabber._tcp.mail.nanosouffle.net. IN  SRV

;; Query time: 5 msec
;; SERVER: 75.58.233.40#53(75.58.233.40)
;; WHEN: Wed Sep 16 16:17:54 2009
;; MSG SIZE  rcvd: 270


The relevant portion of the ndb file looks like this:

dom=_jabber._tcp.mail.nanosouffle.net
	srv=xmpp-server.l.google.com pri=5 weight=0 port=5269
	srv=xmpp-server1.l.google.com pri=20 weight=0 port=5269
	srv=xmpp-server2.l.google.com pri=20 weight=0 port=5269
	srv=xmpp-server3.l.google.com pri=20 weight=0 port=5269
	srv=xmpp-server4.l.google.com pri=20 weight=0 port=5269


Ideas?
ak

Re: [9fans] Authoritative Name Server

[erik quanstrom]

try this patch

/n/dump/2009/0916/sys/src/cmd/ndb/convDNS2M.c:260,266 - convDNS2M.c:260,270
  		USHORT(rp->srv->pri);
  		USHORT(rp->srv->weight);
  		USHORT(rp->port);
- 		STRING(rp->host->name);	/* rfc2782 sez no name compression */
+ 		/*
+ 		 * rfc2782 sez no name compression, but
+ 		 * but bind (dig) disagree.  we'll go with bind.
+ 		 */
+ 		NAME(rp->host->name);
  		break;

- erik

Re: [9fans] Authoritative Name Server

[Lyndon Nerenberg - VE6BBM/VE7TFX]

> linux$ dig @ns1.nanosouffle.net _jabber._tcp.mail.nanosouffle.net srv
> ;; Warning: Message parser reports malformed message packet.

Is ns1 the Plan9 master? What do the zone files on the BIND slave look like?
I.e. did the SRV entries transfer correctly?

Re: [9fans] Authoritative Name Server

[Akshat Kumar]

> Is ns1 the Plan9 master? What do the zone files on the BIND slave look like?
> I.e. did the SRV entries transfer correctly?

Yes, ns1 is the Plan 9 master. The zone file has not yet been transferred, for
some reason. I'm running `ndb/dns -rns` and have run `echo refresh >/net/cs`
each time I've updated the file. I'm supposing the NOTIFY that was supposed
to be sent to the slaves has not yet been sent. I have no idea why that is.


ak

Re: [9fans] Authoritative Name Server

[Akshat Kumar]

I thought it'd have something to do with source.

Thanks very much, Erik! The SRV entries don't pose a problem with dig, now.


Best,
ak


On Wed, Sep 16, 2009 at 7:40 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> try this patch
>
> /n/dump/2009/0916/sys/src/cmd/ndb/convDNS2M.c:260,266 - convDNS2M.c:260,270
>                USHORT(rp->srv->pri);
>                USHORT(rp->srv->weight);
>                USHORT(rp->port);
> -               STRING(rp->host->name); /* rfc2782 sez no name compression */
> +               /*
> +                * rfc2782 sez no name compression, but
> +                * but bind (dig) disagree.  we'll go with bind.
> +                */
> +               NAME(rp->host->name);
>                break;
>
> - erik
>
>