Records
Kevin Darcy
kcd at daimlerchrysler.com
Tue Jan 23 02:40:49 UTC 2007
Fanny Matamoros wrote:
> Suppose that we control the domain .ff , we have this case:
> hanglink.com.ff. IN NS ns.company.com.
> hanglink.com.ff. IN NS ns2.company.com.
>
> And other user wants:
> network.ff. IN NS ns1.hanglink.com.ff.
> network.ff. IN NS ns2.hanglink.com.ff.
>
>
> ns.company.com and ns1.hanglink.com.ff are cnames, same ns2.company.com and
> ns2.haglink.com.ff are cnames, what are the records that we must define as
> TLD?, because
> the user tells us that network.ff do not works, and he wants that define the
> IN A
> records
>
> I help him including this:
>
> hanglink.com.ff. IN NS ns.company.com.
> hanglink.com.ff. IN NS ns2.company.com.
> hanglink.com.ff. IN NS ns1.hanglink.com.ff.
> hanglink.com.ff. IN NS ns2.hanglink.com.ff.
> ns1.hanglink.com.ff. IN A 10.10.10.2
> ns2.hanglink.com.ff. IN A 10.10.10.4
>
>
> Where can we find the RFC for delegated records and glue records?
>
No, that won't work. If ns1.hanglink.com.ff and ns2.hanglink.com.ff
already have CNAME RRs in the .ff zone, then you can't add A records
with the same owner names: RFC 1034, Section 3.6.2:
If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
Also, you can't point NS records at aliases either (same RFC, same section):
Domain names in RRs which point at another name should always point at
the primary name and not the alias. This avoids extra indirections in
accessing information.
In each and every case, an NS record needs to point at a name which owns
one or more A records. Moreover, one or more A records will need to
provided as "glue" in a delegating zone, if the name to which a
delegating NS record points, is in the subzone being delegated, e.g. if
foo.example.com is being delegated from example.com to the nameserver
ns1.foo.example.com, then an A record will need to be provided in the
example.com as glue. See RFC 1034, Section 4.2.1:
In particular, if the
name of the name server is itself in the subzone, we could be faced with
the situation where the NS RRs tell us that in order to learn a name
server's address, we should contact the server using the address we wish
to learn. To fix this problem, a zone contains "glue" RRs which are not
part of the authoritative data, and are address RRs for the servers.
These RRs are only necessary if the name server's name is "below" the
cut, and are only used as part of a referral response.
- Kevin
More information about the bind-users
mailing list