other experiments

[Kevin Darcy]

Quadri, Jay wrote:

> Do you agree with this:
> 1.Slave zone takes  precedence over the root server,i.e slave statement is
> like the 'GOTO' in the old Pascal programs.  The authoritative server looks
> in its own zone file if it can't find the request, it looks in the slave
> zones, if it can't find the request in the slave, then uses the hint file
> in-order to query the root server.
> The order is this:
> a. own zone
> b. slave zones
> c. hints file or in my case master (for internal root server)

No, it doesn't work like that. When the nameserver starts up, it fills its
memory with data from master and slave zones, and it also does a
"priming" query to the root servers to get root-server information. This
"priming" query will either use a forwarder, if global forwarding is
configured, or the hints file.

Once it is running, the nameserver will always look at its cache and
authoritative (master and slave) data first for an answer. If the answer isn't
there, and it is performing recursion for the client, it'll either use

A) forwarding, if it is configured to do so, or

B) whatever NS information it can, via iterative querying

to get the answer, or possibly some combination of both, depending on how you
have things configured. If it has no forwarder and absolutely *no* relevant
NS information other than root-zone data (like if it just started up), then it
may need to actually query the root servers as the first step in resolving the
query. But this is only *indirectly* related to the "hints" file -- "hints" is
used to get the root-zone information initially, but once it is obtained, the
"hints" data is ignored. named certainly doesn't consult the hints file during
normal operation.

So there is no simple "precedence order" between master, slave and hints zones.
Master and slave zone data are considered equally authoritative, and a
"hints" zone is used, if at all, just at startup to get root zone information,
and then ignored. So it has no precedence at all -- it's "off".

> 2. Do agree that Internic root servers have nothing in their hints file.

Root servers are, by definition, already authoritative for the root zone, so
I can't imagine why they would need hints files.

> 3. When you register a domain name with Internic, can you summarise what
> files gets updated on the internic root server.  My mind keeps conflicting
> on this.

The root servers don't need to be updated for a regular domain registration.
Adding a new TLD, however, does require an update to the root servers.

On the other hand, when a new domain is registered under a TLD like "com", the
TLD servers, e.g. the "com" servers, would need to be updated with delegations
to the new domain, and possibly glue records for one or more nameserver(s) of
the domain. So only the "com" (or other TLD) master file would need to be
updated in that case.

> 4.
> Content of my hint file on the root server (intra.net: 10.50.1.5) , in this
> case it's not hint file it's defined as type master in the named.conf  on my
> internal root server

Then don't even call it a "hint" file. It's a master file for the root zone.
Call it what it is.

> .       IN      SOA     global-dnsa.intra.net.        dns-admin.intra.net.
> (
>                                 15      ; serial
>                                 10800   ; Refresh after 3hrs
>                                 3600    ; retry after 1 hr
>                                 604800  ; Expire after 1 Week
>                                 86400   ; Minimum TTL of 1 day
>
>         IN      NS      global-dnsa.intra.net.

As I believe Joe Yao already pointed out, you should have an A record for this
name in this zone.

> intra.net.            86400  IN      A       10.50.1.5

This "intra.net" A record is "out of zone data", since you delegate intra.net
below and this particular name "intra.net" is not necessary as a "glue record".
This A record should be added to the intra.net master file, not here.

> intra.net.    86400   IN      NS      global-dnsa.intra.net.
>
> annika.intra.net.        86400   IN      NS      annika.intra.net.
> jayuk.intra.net.        86400  IN      NS      jayuk.intra.net.
> annika.intra.net.    60400  IN      A            142.135.132.202
> iris.intra.net.    60400  IN      A            142.135.132.222

> jayuk.intra.net.    60400  IN      A            148.185.50.51

All of these "intra.net" entries, with the exception of the
"intra.net" delegation itself, are "out of zone data". They belong in the
intra.net master file.

> 15.1.10.in-addr.arpa   86400   IN      NS      jayuk.intra.net.
> 132.135.142.in-addr.arpa    86400   IN      NS      annika.intra.net.
>
> ;is it alright to do this, with co.uk zone
> other.co.uk.                 804800  IN      NS   wtnv16.other.co.uk.
>                          60400  IN      A     135.185.11.5
> 185.148.in-addr.arpa   86400   IN      NS      wtnv16.other.co.uk.

Sure. As long as "wtnv16.co.uk" reliably gives you the answers you want for
that domain.

The "other.co.uk" A record is "out of zone data".

You should also have "glue records" in that root zone for "wtnv16.other.co.uk".


- Kevin