Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.42!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!news.glorb.com!usenet.stanford.edu!not-for-mail From: Kevin Darcy Newsgroups: comp.protocols.dns.bind Subject: Re: Subdomain Issue Date: Wed, 09 Nov 2011 17:17:57 -0500 Lines: 177 Approved: bind-users@lists.isc.org Message-ID: References: <20111109094543.GA22541@fantomas.sk> NNTP-Posting-Host: lists.isc.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040706030404080101060605" X-Trace: usenet.stanford.edu 1320877131 21834 149.20.64.75 (9 Nov 2011 22:18:51 GMT) X-Complaints-To: action@cs.stanford.edu To: bind-users@lists.isc.org Return-Path: X-Original-To: bind-users@lists.isc.org Delivered-To: bind-users@lists.isc.org X-AuditID: 8109a822-b7f316d000000b10-18-4ebafc3595ca User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 In-Reply-To: X-Brightmail-Tracker: H4sIAAAAAAAAA11TbUhTURjubGNdzVN3V53H68q6ZETlbGUUfUqBReBIrKCi9Go3t5y67r1L jX5kH2gLXR8gOcIiEU0qIxNti8phPxKtRoEWIRWV0RdFYPYFnbPd2V3/3vM873ue93nuPZSW eUCxlL1MFsQy3sHpY3VLTDOXpy/57bMu7KqGywLf0rLAhoEXf3SbwPbYlbsFh32/IGasLoi1 vX31Ru+szasM1qcfAsNZbkBRiM5E30edbhCDSyN6NNKhd4NYiqEfAnSn1asPE5mop+sWCBOj AB0LNiqHEYCOetyhLkjPR576UUBqHZ2G/B+faEitp2cj37PWyaROpO3o5OeHSr8B3W98rSN1 Am1CHZ9uh/B4XF/3X1bW8AH06mO9nqwaQ+eiU/15pEdLb0Vf++o04e1moDbPVXASGLyqa72q Ni+e1tIr0JhfDMOpqPvTOW24no/a6wY1avwC0LeDFMlWWMo7F1rMQqUs8uYim1glOQTRXFRe eh3g1Ktj2rgecN8LA6CE0nCJ0PzDZ2WmFpbvrrLxki1fdDkEiUuAwz8xDCfgQpejhGPhbILG T6BlQgW+XMbflJsBF1gwlzTBSS7JaS+yl7ukfJfoCIAUSsclwYEPnVaGLuZloUQQnIIY1guA CoriEOwax1cYRKFYqNxjd8gRGs/d23ITz6mZ0EbT4ZVsPGJUE6qlZkFU221lWDX9/14aKiYA iqk47DnrF/EsOflSyV6sSMfDx8RzXAQNySbDlg8YZCKgSnI6XE9yMEaoaLl+UMUmwfVEhyYd NlfZhEvWCDvPYmKaiiBqrAlmN/ZYmUQV/k+QnQlTRjCbrGKjNUNvbbRg/D0oogD2s5Sox+GX +M8kAz8Tk1MUMOQRwXfkzzAomMqiCVYSi4kKE632HmepwVmmWUJZyryszvJbTTfJUkGVLMcI yETAqCzHCWWMUNFK7CGQsc58pvW4P9j/dKx3yjbftbHMSaahGxtz24ZWb1+b2uC+2ORJbmnp 23rYcMpYUdO8k9t75Km7g73QPKc/dW7vohMvD871nN+loXJyTsjNbzWbvzQFtRk/brxIF4J1 cpI/rWPNrwPP0zdlvtu1mB603L2073ZXw8WcatSzY1VTQmfuaU4n2XjLPK0o8X8BVMTvxuEE AAA= X-Brightmail-Tracker: AAAAAA== X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.ams1.isc.org X-BeenThere: bind-users@lists.isc.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: BIND Users Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: x330-a1.tempe.blueboxinc.net comp.protocols.dns.bind:78 This is a multi-part message in MIME format. --------------040706030404080101060605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/9/2011 4:59 PM, trm asn wrote: > > > On Wed, Nov 9, 2011 at 3:15 PM, Matus UHLAR - fantomas > > wrote: > > Now I have only one question: > > > On 08.11.11 20:27, trm asn wrote: > > The moment I have done the "rndc reload example.com > ", the domain and all > subdomain were became not resolvable. > > > what does the named's log say? > > -- > > > Is there any thing wrong if I declare my zone like this as below... > > $TTL 300 > @ IN SOA ns4.example.com . > postmaster.example.com . ( > 2011110806 ; Serial Number > 10800 ; Refresh after 3 hours > 3600 ; Retry after 1 hour > 604800 ; Expire after 1 week > 300 ) ; Minimum TTL of 1 day > ; Name servers > IN NS ns4.example.com . > IN NS ns2.example.com . > IN NS ns1.example.com . > *test IN NS ns1973.hostgator.com . > test IN NS ns1974.hostgator.com .* > IN A 203.39.45.19 > IN MX mail.goole.com . > www IN CNAME example.com . > a IN A 203.39.45.20 > b IN A 203.39.45.21 > Yeah, that's likely to be a problem. Those "test" lines have (inadvertantly?) renamed an A record and your MX record from the name "example.com" to the name "test.example.com", and then "hid" them under the delegation for test.example.com (since all non-glue records are served from the child zone, not the parent; those records would only be visible on a zone transfer). Hopefully you understand that in master-zone syntax, leading whitespace "inherits" the last non-whitespace owner name. That's why those 2 records got implicitly renamed, since putting an owner name of "test" above them caused them to inherit that name instead of "@". As a general rule, you want to put all of your apex records at the top of the zone file, and add new stuff at the end of the zone file, so as to completely avoid such whitespace-inheritance "accidents". - Kevin --------------040706030404080101060605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/9/2011 4:59 PM, trm asn wrote:


On Wed, Nov 9, 2011 at 3:15 PM, Matus UHLAR - fantomas <uhlar@fantomas.sk> wrote:
Now I have only one question:


On 08.11.11 20:27, trm asn wrote:
The moment I have done the "rndc reload example.com", the domain and all
subdomain were became not resolvable.

what does the named's log say?

--

Is there any thing wrong if I declare my zone like this as below...

$TTL 300
@       IN      SOA     ns4.example.com. postmaster.example.com. (
                                2011110806      ; Serial Number
                              
                                10800           ; Refresh after 3 hours
                                3600            ; Retry after 1 hour
                                604800          ; Expire after 1 week
                                300 )         ; Minimum TTL of 1 day
; Name servers
        IN      NS      ns4.example.com.
        IN      NS      ns2.example.com.
        IN      NS      ns1.example.com.
test    IN    NS    ns1973.hostgator.com.
test    IN    NS    ns1974.hostgator.com.
        IN    A    203.39.45.19
        IN    MX    mail.goole.com.
www        IN    CNAME    example.com.
a        IN    A    203.39.45.20
b        IN    A    203.39.45.21

Yeah, that's likely to be a problem. Those "test" lines have (inadvertantly?) renamed an A record and your MX record from the name "example.com" to the name "test.example.com", and then "hid" them under the delegation for test.example.com (since all non-glue records are served from the child zone, not the parent; those records would only be visible on a zone transfer).

Hopefully you understand that in master-zone syntax, leading whitespace "inherits" the last non-whitespace owner name. That's why those 2 records got implicitly renamed, since putting an owner name of "test" above them caused them to inherit that name instead of "@". As a general rule, you want to put all of your apex records at the top of the zone file, and add new stuff at the end of the zone file, so as to completely avoid such whitespace-inheritance "accidents".

                                                                                                                                                                                                            - Kevin
--------------040706030404080101060605--