Re: [dns-dir] Review request

[Olafur Gudmundsson <[e-mail]>]

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