Hosting own domain - newb questions.
Chris Buxton
cbuxton at menandmice.com
Tue Aug 22 21:52:23 UTC 2006
The problem is that there's a typo in the registered address of the
server - the glue record. I said, "... assuming its address is
202.172.129.5". But it's not. It's 202.173.129.5, as evidenced by
your server log entries. That's 173, not 172.
As for why the slave isn't getting the zone, could it also be
expecting to find your server at the wrong address?
Chris Buxton
Men & Mice
On Aug 22, 2006, at 2:36 PM, 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.
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
More information about the bind-users
mailing list