Question about RFC-2317 (Wow I think I got it now!)

Clenna Lumina savagebeaste at yahoo.com
Fri Jan 5 04:44:51 UTC 2007


Joseph S D Yao wrote:
> 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".

Ok everything up to hear has all made sense. I thik we're making 
progress :)

(On kind of a side note, is this based on Pebbles and Bam-Bam getting 
married, as I seem to recall something of it but it's been too longto 
remember for sure. That would expalin why have pebbles as a part of 
rubble :) )



> 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.

Actually I'm finally understand this.


> 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
> ----------------------------------------------------------------


(Oi-vey, thank god for $GENERATE, which would apply to the CNAME 
statements for the classless deligation I'm sure.)


> 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.
> ----------------------------------------------------------------


Ok while I understand this, I wasn't really aware you could have both 
forward and reverse in the same zone file (well, at least until I read 
RFC-2317), and even so, I find that to be anything but elegant, imho. 
But I get the feeling that was part of the point you were illustrating 
:)


> [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!


Looks good to me. Is it better (either in practice or by convention) for 
the parent to handle the Network & Broadcast entries itself (as you have 
done here) rather than deligate it with the best of the pool ? I can see 
how it's better this way, though I susepct some customers could possibly 
want to handle thoses too they are someone who just has to customize 
everything :)

If thats the case, could "network-0-25" and "broadcast-0-25" (or what 
ever naming convention the parent want to us) be CANAMEd instead if the 
parent still wants to keep that naming convention in addition to what 
ever the customer has in their zone file?

I mean I know you can have multiple PTRs for a single IP address (and 
end up with a round-robin when doing reverse lookups on it, though I'm 
not sure that can work in this case, if the Net and BC are deligated 
with the rest of the block.


> 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


Amen to that.


> I hope that this helps!


Oh, you've helped so much, many thanks. That first bit about how the 
"0/25" on te NS record in that example was little more than a label, for 
lack of a better term - and I'm also assuming thats the same thing in 
normal Foward zones as well, which I believe could be viewed like this:

   Lookup foo.bar.com ..
   check root, then .com. TLD,
      no A/CNAMEs for foo.bar.com.
      got:  bar  NS  bar.com
   check NS @ bar.com.
      no A/CNAMEs for foo.bar.com.
      got:  foo  NS  foo.bar.com.
   check NS @ foo.bar.com.
      got:  foo  A   1.2.3.4

Am I correct that the big difference in RFC-2317's example that
   0/25            NS      ns.A.domain.

the "0/25" simply doesn't match the main query (ie, dig -x 192.0.2.34), 
but the CNAME catches it, which points to something which doesn't exist, 
but happens to match that NS entry and thus *THEN* goes down that route, 
right?

Again, thank you very much, you've been a great help. 




More information about the bind-users mailing list