Hosting own domain - newb questions.
Kevin Darcy
kcd at daimlerchrysler.com
Wed Aug 23 23:57:52 UTC 2006
Frank Hamersley wrote:
> Thanks for the prompt response Chris...responses inline...
>
>
>> -----Original Message-----
>> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
>> Behalf Of Chris Buxton
>> Sent: Tuesday, 22 August 2006 3:01 AM
>> To: Frank Hamersley
>> Cc: Bind-Users
>> Subject: Re: Hosting own domain - newb questions.
>>
>>
>> First, you appear to be misusing the term SIP, which is a voip and
>> video conferencing TLA.
>>
>
> In my book it was a Static IP before VoIP even dreamed of. :-)
>
>
>> A name server becomes authoritative for a zone by loading the zone
>> into memory from some source. Authority is declared unilaterally by
>> the server. However, nobody will know unless the zone is also
>> delegated to the server by the parent zone. In this case, your parent
>> zone is com.au; you have to register your zone with a domain
>> registrar for com.au, including specifying the name and address of
>> your name server.
>>
>
> OK - this is the "glue" I mentioned.
>
>
>> Ignore PTR records for the moment. They have no bearing on the problem.
>>
>> You should not name your server the same as your zone; doing so,
>> while valid, leads to confusion and isn't as flexible as using a name
>> such as 'ns' as your server name (meaning 'ns.gvmp.com.au.' as an FQDN).
>>
>
> OK - that is how I think I have it and I'm cool with that especially if it
> works.
>
>
>> I did some checking, and I found the following:
>>
>> - Your domain is properly registered.
>> - Your name server is properly registered (assuming its address is
>> 202.172.129.5).
>>
>
> That is correct.
>
>
>> - A query sent to your name server is not answered. This might be a
>> firewall issue, or it may be that named is not running.
>>
>
> I get an answer if I request it from the IP directly rather than FQDN
> "ns.gvmp.com.au".
>
>
>> - A query to your offsite slave (ns1.westnet.com.au) is answered with
>> an error, probably indicating that it can't get your zone from your
>> server. See previous item.
>>
>
> As I suspect the transfer has not ever happened.
>
>
>> So, first check whether named is running.
>>
>> ps ax | grep named | grep -v grep
>>
>
> Its definitely alive.
>
>
>> If there's any output, then named is running.
>>
>> Next, check the server logs (e.g. /var/log/syslog on Ubuntu, unless
>> you have either modified /etc/syslog.conf or added a logging
>> statement to /etc/named.conf or any included files). Is it
>> complaining about not being able to establish listeners? Is it able
>> to start a listener on either 202.172.129.5 or a private address for
>> which you have port 53 mapped (NAT or PAT) from the public address?
>>
>
> Aug 18 00:10:28 gvmp named[9071]: starting BIND 9.3.2
> Aug 18 00:10:28 gvmp named[9071]: found 1 CPU, using 1 worker thread
> Aug 18 00:10:28 gvmp named[9071]: loading configuration from
> '/etc/bind/named.conf'
> Aug 18 00:10:28 gvmp named[9071]: listening on IPv4 interface lo,
> 127.0.0.1#53
> Aug 18 00:10:28 gvmp named[9071]: listening on IPv4 interface eth1,
> 10.99.99.1#53
> Aug 18 00:10:28 gvmp named[9071]: listening on IPv4 interface eth0,
> 192.168.1.101#53
> Aug 18 00:10:28 gvmp named[9071]: listening on IPv4 interface ppp0,
> 202.173.129.5#53
> Aug 18 00:10:28 gvmp named[9071]: command channel listening on 127.0.0.1#953
> Aug 18 00:10:28 gvmp named[9071]: command channel listening on ::1#953
> Aug 18 00:10:28 gvmp named[9071]: zone 0.in-addr.arpa/IN: loaded serial 1
> Aug 18 00:10:28 gvmp named[9071]: zone 127.in-addr.arpa/IN: loaded serial 1
> Aug 18 00:10:28 gvmp named[9071]: zone 129.173.202.in-addr.arpa/IN: loaded
> serial 2006081701
> Aug 18 00:10:28 gvmp named[9071]: zone 255.in-addr.arpa/IN: loaded serial 1
> Aug 18 00:10:28 gvmp named[9071]: zone gvmp.com.au/IN: loaded serial
> 2006081701
> Aug 18 00:10:28 gvmp named[9071]: zone localhost/IN: loaded serial 1
> Aug 18 00:10:28 gvmp named[9071]: running
> Aug 18 00:10:28 gvmp named[9071]: zone gvmp.com.au/IN: sending notifies
> (serial 2006081701)
>
> "netstat -an" shows the ports are open - not sure about the 192 - thats on
> eth0 which is running pppoe for the 202 address.
>
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 0.0.0.0:3050 0.0.0.0:* LISTEN
> tcp 0 0 202.173.129.5:53 0.0.0.0:* LISTEN
> tcp 0 0 192.168.1.101:53 0.0.0.0:* LISTEN
> tcp 0 0 10.99.99.1:53 0.0.0.0:* LISTEN
> tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
> udp 0 0 0.0.0.0:53 0.0.0.0:*
> udp 0 0 202.173.129.5:53 0.0.0.0:*
> udp 0 0 192.168.1.101:53 0.0.0.0:*
> udp 0 0 10.99.99.1:53 0.0.0.0:*
> udp 0 0 127.0.0.1:53 0.0.0.0:*
> udp 0 0 0.0.0.0:68 0.0.0.0:*
> udp6 0 0 :::32789 :::*
>
> I wondered if it is down to Shorewall? It seems to say too much (IMO it
> shouldn't NAT 53 traffic) when I frame a request using the IP it logs....
>
> Aug 22 22:20:19 gvmp kernel: [649354.407480]
> Shorewall:mangle:PREROUTING:IN=ppp0 OUT= MAC= SRC=147.10.180.97
> DST=202.173.129.5 LEN=48 TOS=0x00 PREC=0xE0 TTL=118 ID=52071 DF PROTO=TCP
> SPT=2269 DPT=53 WINDOW=65535 RES=0x00 SYN URGP=0
> Aug 22 22:20:19 gvmp kernel: [649354.407540]
> Shorewall:nat:PREROUTING:IN=ppp0 OUT= MAC= SRC=147.10.180.97
> DST=202.173.129.5 LEN=48 TOS=0x00 PREC=0xE0 TTL=118 ID=52071 DF PROTO=TCP
> SPT=2269 DPT=53 WINDOW=65535 RES=0x00 SYN URGP=0
> Aug 22 22:20:19 gvmp kernel: [649354.407592] Shorewall:mangle:INPUT:IN=ppp0
> OUT= MAC= SRC=147.10.180.97 DST=202.173.129.5 LEN=48 TOS=0x00 PREC=0xE0
> TTL=118 ID=52071 DF PROTO=TCP SPT=2269 DPT=53 WINDOW=65535 RES=0x00 SYN
> URGP=0
> Aug 22 22:20:19 gvmp kernel: [649354.407634] Shorewall:filter:INPUT:IN=ppp0
> OUT= MAC= SRC=147.10.180.97 DST=202.173.129.5 LEN=48 TOS=0x00 PREC=0xE0
> TTL=118 ID=52071 DF PROTO=TCP SPT=2269 DPT=53 WINDOW=65535 RES=0x00 SYN
> URGP=0
>
> ...but is silent when I use the name which suggests it is not being resolved
> to an IP? When I do a traversal with www.dnsstuff.com it finds its way to
> 202.172.129.5 but chokes!!! Arggh!!
>
> Where to next Batman?
>
>
>> Chris Buxton
>> Men & Mice
>>
>> On Aug 21, 2006, at 5:43 AM, Frank Hamersley wrote:
>>
>>
>>> I have been faffing around trying to establish a BIND 9.3.2 on
>>> Ubuntu Dapper
>>> Server as the authorative NS for a single .com.au. domain...but
>>> with only
>>> partial success - most of which I suspect is due to my limited
>>> knowledge
>>> (just enough to be dangerous).
>>>
>>> I have Bind up and running and shorewall seems to be behaving
>>> itself too
>>> athough it is spitting more messages than I would like (previously
>>> I have
>>> cut the iptables script by hand).
>>>
>>> I can get a response when querying using the SIP but when using the
>>> FQDN of
>>> the NS it chokes ... which I presume signals a "lame" NS?
>>>
>>> I have by following various bits of net howto established the domain
>>> (gvmp.com.au) zone and indicated that the primary NS is to be
>>> ns.gvmp.com.au. After having communicated with the ISP they have
>>> established a PTR for gvmp.com.au to the SIP but this doesn't seem
>>> to help.
>>>
>>> Is this a viable arrangement or should I change the zone NS to be
>>> the same
>>> name as the domain so the PTR maps directly back to it?
>>>
>>> Can someone in a broad brush explain how a NS can become
>>> authorative for
>>> itself? I presume this is down to the "glue" but am left wondering
>>> just how
>>> the discovery process goes from the root servers to the delegation
>>> point
>>> (which I presume is my SIP).
>>>
>>> If needed I can post /etc/bind/* here.
>>>
>>> Regards, Frank.
>>>
I can query the name ns.gvmp.com.au successfully over the Internet. The
fact that you have the gvmp.com.au apex NS records and associated glue
set to a 5-minute TTL, and that the only other delegated nameserver for
the domain (ns1.westnet.com.au) is lame for it, means that there is
going to be a lot of glue-fetching, retries, etc. and folks with
marginal DNS connectivity, may not be able to resolve the domain at all.
This is a good illustration of why the Internet Standards dictate that
DNS domains be delegated to at least 2 nameservers, of course with the
assumption that both nameservers actually _work_. Why don't you try
fixing whatever is wrong with your master/slave replication (firewall
rules, allow-transfer ACLs or whatever)? Then see if your resolution
problems still persist even after you have 2 authoritative nameservers
fully functional for the zone.
- Kevin
More information about the bind-users
mailing list