Re: [dns-dir] Review request

[Martin Stiemerling <[e-mail]>]

Thanks for the review and we are currently working through it!

   Martin

On 03/29/2013 03:13 PM, Olafur Gudmundsson wrote:
> I reviewed the document and this is a well written clear document with some deficiencies.
>
> The introduction is real good at explaining what the document is attempting.
>
> The procedure(s) proposed are based of the implicit assumption that provisioning of reverse DNS is
> somehow related to service provision for another protocol, which may or may not be the case.
>
> Question #1: How is dual stack handled in queries?
> in sequence or in parallel ?
> if sequence which one first ?
>
> Question #2 What about hosts with multiple links?
>
> The procedures expect hope to get back PTR records and the name in the PTR record
> is used for further lookups.  (good)
> The fundamental question is are all attempts to find PTR exhausted before going to next step?
>
> Question #3: what about the case when there are multiple PTR records in the answer?
>
> If the lookup fails the procedure hopes to find SOA record in the negative answer,
> extracts from the SOA record the name of the "Master DNS server" MNAME,
> and uses that name to do further lookups.
>
> Comment #1: Master DNS servers are not always reachable, as they are hidden masters or
> traffic protected. Frequently there is no correlation between the zone name and the Mname
> I did  a randomly selected reverse lookup on 185.55.55.55
>    185.in-addr.arpa.	3600	IN	SOA	pri.authdns.ripe.net. dns.ripe.net. …….
>
> In this case it is obvious (to a human) the SOA is useless and the algorithm should terminate,
> what the procedure as specified will do is to cause many queries to the RIR name servers for lots of names that have
> no PTR records and no delegations.
>
> Question #4: Why MNAME but not the owner name of the SOA ? (explain or point to explanation)
>
> Question #5: What is the point of the explicit SOA query for reverse name and why do editors expect to get a different answer than in the PTR question ?
>
> Section #4:
> there is no mention about the expected extra traffic to RIR (and or ISP) DNS server when the PTR lookup fails,
> I would like to see some text on how to abort the algorithms early I.e.
> SOA present --- useful    SOA ---> do lookup
>                 +-------- useless SOA ---> algorithm failed
>
>
> This boat has probably sailed but I will ask  it anyway:
> Question #6 Why not place the NAPTR records in the reverse tree?
>
> Editing comment: It would be helpful if the text from section 3 bullet 1 about what address to look up was included in section 2 before the
> diagrams of the algorithms (or at least pointer to address selection).
>
> 	Olafur
>
>
>
> On Mar 28, 2013, at 6:01 PM, Brian Haberman <[e-mail]> wrote:
>
>> Hi all,
>>      The ALTO WG is considering the adoption of a draft focused on the discovery of an ALTO server using DNS (but not SRV records).  Martin (TSV AD) has requested an early DNS Directorate review.  Could I get a volunteer (or two) to review the draft for DNS sanity?
>>
>> https://datatracker.ietf.org/doc/draft-kist-alto-3pdisc/
>>
>> Regards,
>> Brian
>> _______________________________________________
>> dns-dir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dns-dir
>

-- 
[e-mail]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014