Question about RFC-2317
Joseph S D Yao
jsdy at center.osis.gov
Fri Jan 5 01:33:51 UTC 2007
On Thu, Jan 04, 2007 at 12:42:06PM -0800, Clenna Lumina wrote:
...
> I still don't see why that is.
>
> Take again the example from RFC-2317, parent zone:
>
> -----------------------------------------------------------------------
> $ORIGIN 2.0.192.in-addr.arpa.
> @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
> ;...
> ; <<0-127>> /25
> 0/25 NS ns.A.domain.
> 0/25 NS some.other.name.server.
> ;
> 1 CNAME 1.0/25.2.0.192.in-addr.arpa.
> 2 CNAME 2.0/25.2.0.192.in-addr.arpa.
> 3 CNAME 3.0/25.2.0.192.in-addr.arpa.
...
> -----------------------------------------------------------------------
>
> What I want to know is why it can't just be written as:
> -----------------------------------------------------------------------
> $ORIGIN 2.0.192.in-addr.arpa.
> @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
> ;...
> ; <<0-127>> /25
> 0/25 NS ns.A.domain.
> 0/25 NS some.other.name.server.
...
> -----------------------------------------------------------------------
>
> I mean from how I understand how deligation otherwise works, when a
> request comes down the line for, say, 192.0.2.34, wouldn't it just see
> the NS record for 0/25 (which is authoritive for IPs 0-127) and move on
> there to complete the query?
>
> In normal cases this is how it seems to work. Why would this be any
> different? If the PTRs are on another server, it seems somewhat
> redundant and uneeded to CNAME thme in the parent zone, when they are in
> another zone which is athorative.
I think there is one thing that must be made very clear before you can
understand anything.
"0/25" is just a name. It could be Phred or Butterball or PhineasFogg.
It has NO INHERENT MEANING.
In particular, it is NOT a range. Of anything.
I don't use "0/25", I use something more obviously without internal
semantics, while still retaining some meaning, such as "0-25".
There is a second thing that must be made clear.
You must also remember that ALL DOMAINS, whether forward or reverse,
must either be in the same zone as their parent domain, or at the base
of a zone and delegated from a parent. The string of delegations must
go all the way back to the root.
Let's look at that example while using "Phred" instead of "0/25".
-----------------------------------------------------------------------
;;;$ORIGIN 2.0.192.in-addr.arpa. ; this is a bad habit and unneeded
$TTL 86400 ; this is new since RFC 2317
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
;...
; <<0-127>> /25
Phred NS ns.A.domain.
Phred NS some.other.name.server.
-----------------------------------------------------------------------
OK, if we stop here, and I try to look for a PTR record for
1.2.0.192.in-addr.arpa [192.0.2.1], what do I find? NOTHING. NXDOMAIN.
Nil, zip, nada. There is nothing there.
-----------------------------------------------------------------------
1 CNAME 1.Phred.2.0.192.in-addr.arpa.
2 CNAME 2.Phred.2.0.192.in-addr.arpa.
3 CNAME 3.Phred.2.0.192.in-addr.arpa.
-----------------------------------------------------------------------
OK, now this says [as all CNAMEs say], if you are looking for something
for "1", there are no records here, BUT any and all records you want can
be found if you only go look for the name servers for the domain
"Phred.2.0.192.in-addr.arpa." [which, incidentally, this zone file has
just given you], and ask there for "1".
Let's get rid of all the numbers and concentrate on how "CNAME works for
just a minute. Let's look at a domain "flintstone.family". It starts
out:
----------------------------------------------------------------
; This is intended for domain "flintstone.family".
$TTL 86400
@ SOA ...
NS ns1
NS ns2
fred A 1.1.1.1
wilma A 1.1.1.2
; delegate a subdomain
rubble NS ns1.rubble.family.
rubble NS ns2.rubble.family.
pebbles CNAME peb.rubble.flintstone.family.
----------------------------------------------------------------
What is this saying? There are NO records here for
"pebbles.flintstone.family". But if you want any records for
"pebbles.flintstone.family", you can go to the name servers
"ns1.rubble.family" or "ns2.rubble.family" [defined elsewhere], which
have the DELEGATED SUBDOMAIN "rubble.flintstone.family". In this
subdomain, you will find a record "peb". All of the records for
"peb.rubble.flintstone.family" are records that apply to
"pebbles.flintstone.family".
I hope you understand this. And if you do, either you have just had an
"ah-ha" experience over RFC 2317, or you think I am completely crazy
because you don't see where I am going with this. So just in case,
let's take it back to RFC2317 and start from scratch.
In our example reverse DNS domain, "2.0.192.in-addr.arpa", we could be
very controlling and say that we will make all the entries, thank you.
----------------------------------------------------------------
; This is intended for domain "2.0.192.in-addr.arpa".
$TTL 86400
@ SOA ...
NS ns1.example.com.
NS ns2.example.com.
0 PTR network-0-25
1 PTR first.clennas.org.
2 PTR second.clennas.org.
...
126 PTR onehundredtwentysixth.clennas.org.
127 PTR broadcast-0-25
;
128 PTR network-128-25
129 PTR first.joes.org.
130 PTR second.joes.org.
...
254 PTR onehundredtwentysixth.joes.org.
255 PTR broadcast-128-25
----------------------------------------------------------------
But after Clenna and Joe independently plead to be allowed to control
their own subdomains, we change this so that the CANONICAL NAME of each
of these pointer records is actually something else.
But what?
I know! I'll have Joe and Clenna each create a "reverse" subdomain, and
use those:
----------------------------------------------------------------
; This is intended for domain "2.0.192.in-addr.arpa".
$TTL 86400
@ SOA ...
NS ns1.example.com.
NS ns2.example.com.
0 PTR network-0-25
1 CNAME first.reverse.clennas.org.
2 CNAME second.reverse.clennas.org.
...
126 CNAME onehundredtwentysixth.reverse.clennas.org.
127 PTR broadcast-0-25
;
128 PTR network-128-25
129 CNAME first.reverse.joes.org.
130 CNAME second.reverse.joes.org.
...
254 CNAME onehundredtwentysixth.reverse.joes.org.
255 PTR broadcast-128-25
----------------------------------------------------------------
Then Clenna has:
----------------------------------------------------------------
; This is intended for domain "clennas.org".
$TTL 86400
@ SOA ...
NS ns1
NS ns2
first A 192.0.2.1
first.reverse PTR first.clennas.org.
second A 192.0.2.2
second.reverse PTR second.clennas.org.
...
onehundredtwentysixth A 192.0.2.126
onehundredtwentysixth.reverse PTR onehundredtwentysixth.clennas.org.
----------------------------------------------------------------
[Yes, those PTR records could be minimalised to:
first.reverse PTR first
second.reverse PTR second
...
onehundredtwentysixth.reverse PTR onehundredtwentysixth
either way allows you to look up a PTR record with
"first.reverse.clennas.org" on the left-hand side, and come up the
record that has "first.clennas.org" on the right-hand side.]
But this is messy! I know. Instead of making all the Canonical Names
be in a subdomain of "clennas.org", I'll have her make a separate
domain, that LOOKS LIKE a reverse DNS domain. And _I_ will delegate it
to _her_. Her domain will look like this:
----------------------------------------------------------------
; This is intended for domain "0-25.2.0.192.in-addr.arpa",
; a pseudo-reverse-DNS (RFC 2317) domain.
$TTL 86400
@ SOA ...
NS ns1.clennas.org.
NS ns2.clennas.org.
1 PTR first.clennas.org.
2 PTR second.clennas.org.
...
126 PTR onehundredtwentysixth.clennas.org.
----------------------------------------------------------------
And now MY reverse DNS domain will look like this:
----------------------------------------------------------------
; This is intended for domain "2.0.192.in-addr.arpa".
$TTL 86400
@ SOA ...
NS ns1.example.com.
NS ns2.example.com.
0 PTR network-0-25
1 CNAME 1.0-25.2.0.192.in-addr.arpa.
2 CNAME 2.0-25.2.0.192.in-addr.arpa.
...
126 CNAME 126.0-25.2.0.192.in-addr.arpa.
127 PTR broadcast-0-25
;
; Now let's delegate the above pseudo-reverse-DNS domain,
; "0-25.2.0.192.in-addr.arpa".
0-25 NS ns1.clennas.org.
0-25 NS ns2.clennas.org.
;
128 PTR network-128-25
129 CNAME 129.128-25.2.0.192.in-addr.arpa.
130 CNAME 130.128-25.2.0.192.in-addr.arpa.
...
254 CNAME 254.128-25.2.0.192.in-addr.arpa.
255 PTR broadcast-128-25
;
; Now let's delegate the above pseudo-reverse-DNS domain,
; "128-25.2.0.192.in-addr.arpa".
128-25 NS ns1.joes.org.
128-25 NS ns2.joes.org.
----------------------------------------------------------------
The fact that I put the delegating NS records AFTER the CNAME records
means nothing. I did it solely to reduce any confusion!
Incidentally, the "$GENERATE" pseudo-op can be used to generate the
above CNAMEs.
$GENERATE 1-126 $ CNAME $.0-25
$GENERATE 129-254 $ CNAME $.128-25
I hope that this helps!
--
Joe Yao
-----------------------------------------------------------------------
This message is not an official statement of OSIS Center policies.
More information about the bind-users
mailing list