"Empty zones" and BIND 9.4

[Clenna Lumina]

Mark Andrews wrote:
>> Mark Andrews wrote:
>>>> For the loopback subnet reverse zone, if you want to create a PTR
>>>> record for each possible IP, use a wildcard. So instead of this
>>>> from Mark's example:
>>>>
>>>> 1.0.0 PTR localhost.
>>>>
>>>> use this:
>>>>
>>>> *     PTR localhost.
>>>>
>>>> Chris Buxton
>>>> Men & Mice
>>>
>>> Normally you only need "1.0.0 PTR localhost." as that
>>> is usually the only address in use.
>>>
>>> If you don't use it then you don't need a PTR.  If you do
>>> use it but forget the PTR then you want to stop the query
>>> leaking so that why the zone is 127.IN-ADDR.ARPA and not
>>> 1.0.0.127.IN-ADDR.ARPA, 0.0.127.IN-ADDR.ARPA or 0.127.IN-ADDR.ARPA.
>>> NXDOMAIN will be returned if there is no PTR record.
>>
>> Maye I'm confused, but why is it 0.0.127.IN-ADDR.ARPA cannot be used?
>> Why/how would that cause "query leaking" (and what is that exactly?)
>
> If you use address 127.1.1.1 and do a reverse lookup on it
> then it is will not be answered from 0.0.127.IN-ADDR.ARPA.
> The query instead will go to the IN-ADDR.ARPA servers and
> a NXDOMAIN will be returned.  The query is supposed to be
> answered locally and 127/8 is a purely local resource.
>
>> I guess I jsut want to understand the logic & reasoning behind all
>> this.
>>
>>> Additionally the PTR from the wildcard will be rejected by
>>> may applications / libraries as there is not a corresponding
>>> A record.
>>
>> Wouldn't it just map ever IP that starts with 127. to localhost? How
>> would that break anything? Looking up, say, 127.0.0.21 would yield
>> localhost, would it not? Sorry, I just don't see how this could be a
>> problem.
>
> localhost has a well known values (127.0.0.1 and ::1).
> To make "21.0.0.127.IN-ADDR.ARPA PTR localhost." effective
> you need to have a "localhost A 127.0.0.21" record on the
> search path.  Lookups for localhost would then return
> 127.0.0.1, 127.0.0.21 and ::1.  Not all applictions will
> cope well with this especially as 127.0.0.21 may not exist
> on all the machines that get this answer.


Well, wouldn't be better to have the '* IN PTR localhost' and just have 
'localhost IN A 127.0.0.1', that way localhost resolves to 127.0.0.1 
like expected and 127.0.0.1 (any anything else 127.*) comes back as 
localhost, as all 127/8 addresses are technically "localhost" addresses?

-- 
CL



>>> I DO NOT recommend adding all the possible A records in this
>>> space.  It will only cause applications to break.
>>>
>>> Mark
>>>
>>>> On Jun 18, 2007, at 7:33 AM, Mark Andrews wrote:
>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> There was big discussion about empty-zones feature in BIND >= 9.4
>>>>>> on Red
>>>>>> Hat's bugzilla. We have found two problems around this.
>>>>>>
>>>>>> - RFC 3330 says that loopback could be 127/8. Does anybody here
>>>>>> know how
>>>>>> configure 127.in-addr.arpa. zone as described in RFC? $GENERATE
>>>>>> directive isn't sufficient for solve this problem.
>>>>>
>>>>> Why would one want to use $GENERATE.
>>>>>
>>>>> zone "127.IN-ADDR.ARPA" {
>>>>> };
>>>>>
>>>>> @ SOA ..
>>>>> @ NS ..
>>>>> 1.0.0 PTR localhost.
>>>>>
>>>>>> - RFC 2181, section 7.3 tells about MNAME record in SOA. It's
>>>>>> name of primary server. All empty zones returns name of zone
>>>>>> instead primary nameserver (could be "localhost.")
>>>>>
>>>>> No.  It's the name of the primary (only) nameserver.  It just
>>>>> happens to be the name of the zone as well.  The zone names
>>>>> are all legal hostnames.
>>>>>
>>>>> draft-ietf-dnsop-default-local-zones-02.txt
>>>>>
>>>>> There are also named.conf options to change what is returned.
>>>>>
>>>>>> Thanks for any hints,
>>>>>> Adam