Recursive DNS problem

[Kevin Darcy]

On 1/28/2011 5:11 AM, Torinthiel wrote:
> Dnia 2011-01-28 10:52 bangla desh napisał(a):
>
>
>>> I believed so that com.bd is broken. It only has 1 ns server and
>> hsbc.com.bd, whois.com.bd and even google.com.bd they are all delegate
>> directly from bd and not from com.bd.
>>
>> I am wondering, is there a dns rule/standard (or RFC) that explains about
>> delegation?
> For the fact that com.bd is broken - that's just how DNS works. Zone cuts
> are there for purpose. Most of this can be read from RFC 1034 and 1035,
> which form the grounds for DNS standards. Also RFC 2181 clarifies:
> <quote>
> A server for a zone should not return authoritative answers for queries
> related to
>     names in another zone, which includes the NS, and perhaps A, records
>     at a zone cut, unless it also happens to be a server for the other
>     zone.
> </quote>
> And a mere presence of NS records indicates a zone cut (again, RFC 2181):
> <quote>
> The existence of a zone cut is indicated in the parent zone by the
>     existence of NS records specifying the origin of the child zone.
> </quote>
>
> As for number of authorative servers per domain, I don't remember where, but
> at leas one RFC stated that there should be at least two, and preferably 3-7
> nameservers per domain. It's quite possible that one of those I've already
> pointed to contains this information, but also that a different one states
> this information. But it was RFC for certain.

RFC 1034, Section 4.1:

    A given zone will be available from several name servers to insure
    its availability in spite of host or communication link failure. By
    administrative fiat, we require every zone to be available on at
    least two servers, and many zones have more redundancy than that.

                                                                         
                                                                         
                         - Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110131/65522722/attachment.html>