Re: [dns-dir] Fwd: Re: Review request

[Martin Stiemerling <[e-mail]>]

Hi Olafur, all,

It would be good to get further feedback about Sebastian's email.

The draft is intended to become a WG draft but this depends on the 
outcome of the DNS directorate review, i.e., if this is something that 
breaks or not.

It is also good to get early expert feedback and not just at the end 
when we go for IETF last call and IESG revoew.

Thanks,

   Martin

On 05/21/2013 10:53 PM, Sebastian Kiesel wrote:
> Dear Olafur,
>
> first of all, thanks for the extensive review of the Third-Party ALTO Server
> Discovery draft.  Martin Stiemerling, who is very busy these days, has
> forwarded your comments to me as I am the main author.
>
> Let's start with your question #6 because it may have an impact
> on the other questions:
>
>> This boat has probably sailed but I will ask  it anyway:
>> Question #6 Why not place the NAPTR records in the reverse tree?
>
> There were two reasons why we chose a two-step lookup
> IP address --(PTR lookup)--> host name(s) --(U-NAPTR lookup(s))--> ALTO URI(s)
>
>
> First, this draft is a spin-off from draft-ietf-alto-server-discovery.
> Because of different deployment scenarios with different requirements,
> the original plan was to specify a two-stage discovery procedure with
> three options for the first stage:
>
> 1) Get a domain name by means of
>      1a) manual configuration
>      1b) DHCP option
>      1c) PTR or SOA-mname lookup in in-addr.arpa. / ip6.arpa.
> 2) Do a U-NAPTR lookup for the name yielded by step 1
>
> Some WG members raised doubts whether 1c) would be feasible at all.
> Therefore, it was decided to move 1c) into a seperate draft in order to
> allow working on and finalizing the documents at different paces.
>
>
>
> Second, we (the draft authors) had some hallway discussions with DNS
> operators at IETF meetings about two years ago, and we were told that
> putting non-PTR records in the reverse tree has deployment issues, e.g.,
> with management software that creates the reverse tree automatically
> from the forward tree.  On the other hand, RFCs 4025, 4255, and 4322
> already do specify non-PTR records in the reverse trees.
>
>
>
> Now that the first argument does not apply anymore we don't feel strong
> about the second one.  We have running proof-of-concept client-side code
> and BIND 9 based server-side configuration files for both variants (see
> flow charts at the end of this email), but what is the DNS experts'
> advise regarding deployment issues? Should we stick with the PTR+NAPTR
> variant, or switch to searching the NAPTR in the reverse tree?
>
>
>
> For more answers and counter questions, please see inline:
>
>
> On Tue, Apr 02, 2013 at 11:40:31AM +0200, Martin Stiemerling wrote:
>>
>>
>>
>> -------- Original Message --------
>> Subject: Re: [dns-dir] Review request
>> Date: Fri, 29 Mar 2013 10:13:37 -0400
>> From: Olafur Gudmundsson <[e-mail]>
>> To: Brian Haberman <[e-mail]>
>> CC: IETF DNS Directorate <[e-mail]>rg>, Ted Lemon
>> <[e-mail]>om>, Martin Stiemerling
>> <[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.
>
> thanks.
>
>> 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.
>
> Our point of view is that for the ALTO application we need a delegation
> hierarchy for ALTO servers, which corresponds to the delegation of
> IP address ranges to ISPs or other organisations.
>
> As the DNS reverse tree delegation already follows the address space
> delegation (more or less), we think it is natural to use it as a basis
> for our discovery problem.  We sequentially try two different discovery
> approaches: first PTR/NAPTR to allow fine-grained discovery, then
> SOA/NAPTR to allow function without having to add many resource records
> to the DNS.
>
>> 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 short answer is:
>
> Dual stack and multihoming basically is the same situation:
> The third party usually will use 3pdisc only after receiving an
> inbound connection from the actual client.  It uses the connection's
> source address as parameter for 3pdisc and it will not be aware
> of the fact that the client has other addresses as well.
>
>
> For a longer discussion, please see Section 3.1.2. of
> draft-kist-alto-3pdisc-03, which we have published recently
> (you have reviewed the -02 version; the -03 version has several
> clarifications and deployment considerations but the algorithm
> didn't change).
>
>
>> 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?
>
> The algorithm is called with one IP address as parameter, even in the
> case of multihoming/dual stack (see above). Finding the PTRs associated
> with said IP address is one lookup. Then, we do a NAPTR lookup on every
> yielded host name. This is the only loop in the algorithm. If all of
> that fails, we do at most two more lookups for the SOA/NAPTR-based
> "Plan B".  So, if there are N PTR records associated with an IP address,
> the procedure causes at most N+3 DNS lookups.
>
>> 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.
>
> We are fully aware of that.  Indeed, we never try to contact the master
> server.  We just use its name for further lookups.  We decided to use
> the SOA-MNAME instead of the NS records for the respective
> in-addr.arpa/ip6.arpa. zone, because there is only one SOA but there
> could be several NS, which would cause even more iterating over lists.
>
>> 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,
>
> Why do you think this name is obviously useless? According to whois,
> 185/8 is managed by RIPE. Maybe they will provide an ALTO server in the
> future. Anyway, it is a single NAPTR lookup to find out.
>
>> 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.
>
> We have no data on the percentage of IP addresses that have PTRs in the
> reverse tree. The first optimization target for ALTO is P2P
> applications, with the peers mostly in DSL/cable access networks. At
> least in the U.S. and Europe most of these IP addresses seem to have PTRs.
>
> In the worst case the algorithm causes 3+N DNS lookups, with N being the
> number of PTR records assigned to an IP address (usually 0 or 1).
>
> Do you think this procedure will cause a significant burden for the DNS
> as a whole?
>
>
>> Question #4: Why MNAME but not the owner name of the SOA ? (explain
>> or point to explanation)
>
> What is "the owner name of the SOA"?
>
> Do you mean the RNAME field defined in RFC 1035, Sec 3.3.13?  If so,
> that would be an option as well but we think the MNAME is the more
> natural choice as this is a real host name.
>
>> 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 ?
>
> The explicit SOA query is used only if the answer to the PTR query did
> not contain an authority section (and there were no PTRs or they did
> not produce ALTO-specific U-NAPTR lookup results).
>
>> 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
>>
>
> If we are in the "second half" of the algorithm, i.e., the PTR stuff
> has failed, we do at most two further lookups: one to get the SOA if
> we don't already have it, the second to check whether there are NAPTR
> records associated with the SOA's MNAME.  There are no loops around it!
>
>> This boat has probably sailed but I will ask  it anyway:
>> Question #6 Why not place the NAPTR records in the reverse tree?
>
> see above.
>
>> 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
>
> ------------------------------------------------------------------------
> Flow chart taken from draft-kist-alto-3pdisc-03
> (equivalent to variant 1 in -02, but more detailed):
>
>                   (-------------------------------------)
>                   ( START 3pdisc with parameters        )
>                   ( IP address IP, Service Parameter SP )
>                   (------------------+------------------)
>                                      V
>                   +- T1 -------------+------------------+
>                   | R:=<IP>.in-addr.arpa./<IP>.ip6.arpa.|
>                   | X:=lookup(PTR,R)                    |
>                   +------------------+------------------+
>                                      V
>                         / B1 --------+------------\
>                   /----< One or more PTR(s) in X   >----\
>                   | yes \-------------------------/ no  |
>                   |                                     V
>     +- T2 --------|-------------+    /----------------->+
>     |             V             |    |                  V
>     | /-> FOREACH Y:=PTR in X   |    |     /- B3 -------+------------\
>     | |  +--------+-----------+ |    |    < AuthSect with SOA RR in X >
>     | |  |lookup(U-NAPTR,Y,SP)| |    |     \--+---------+------------/
>     | |  |add results to Z    | |    |    yes |         V no
>     | |  +--------+-----------+ |    |        |  +- T3 -+-------------+
>     | \-----------+             |    |        |  | X:=lookup(SOA,R)   |
>     +-------------|-------------+    |        |  +------+-------------+
>                   V                  |        |         V
>      /- B2 -------+------------\     |        |   /- B4 +------------\ no
>     < One or more results in Z  >----/        |  <Lookup OK, SOA in X >-\
>      \------------+------------/ no           |   \-----+------------/  |
>                   |                           \-------->V yes           |
>                   | yes                   +- T4 --------+-------------+ |
>                   |                       | Y:=extract MNAME from X   | |
>                   V                       | Z:=lookup(U-NAPTR,Y,SP)   | |
>                   +<-----------------\    +-------------+-------------+ |
>                   V                  |                  V               |
>     +- T5 --------+-------------+    |     /- B5 -------+------------\  |
>     | sort Z acc. to order,pref |    \----< One or more results in Z  > |
>     +-------------+-------------+      yes \------------+------------/  |
>                   V                                  no V<--------------/
>     (-------------+-------------)         (-------------+-------------)
>     ( END 3pdisc with result Z  )         ( 3pdisc FAILED, no result  )
>     (---------------------------)         (---------------------------)
>
>
>
>
> ------------------------------------------------------------------------
> Alternative solution with NAPTR records in the reverse tree
> (see discussion above):
>
>                  (---------------------------------------)
>                  ( START 3pdisc with parameters          )
>                  ( IP_address IP, Service_Parameter SP   )
>                  (-------------------+-------------------)
>                                      V
>                  +- T1 --------------+-------------------+
>                  | R:=<IP>.in-addr.arpa. / <IP>.ip6.arpa.|
>                  +-------------------+-------------------+
>                                      V
>                  +- T2 --------------+-------------------+
>                  | X:=DNSlookup(R,U-NAPTR,SP)            |
>                  +-------------------+-------------------+
>                                      V
>                   / B1 --------------+------------------\
>        /---------< One or more U-NAPTR results in X      >
>        |      yes \------------------+------------------/
>        |                             V no
>        |          /- B2 -------------+------------------\
>        |    /----< Authority sect. with SOA record in X  >
>        |    | yes \------------------+------------------/
>        |    |                        V no
>        |    |    +- T3 --------------+-------------------+
>        |    |    | X:=DNSlookup(R,SOA)                   |
>        |    |    +-------------------+-------------------+
>        |    |                        V
>        |    |     /- B3 -------------+------------------\
>        |    |    < Lookup OK, SOA record present in X    >----\
>        |    |     \------------------+------------------/ no  |
>        |    |                        V yes                    |
>        |    \----------------------->+                        |
>        |                             V                        |
>        |         +- T4 --------------+-------------------+    |
>        |         | M:=extract MNAME from SOA record in X |    |
>        |         | X:=DNSlookup(M,U-NAPTR,SP)            |    |
>        |         +-------------------+-------------------+    |
>        |                             V                        |
>        |          /- B4 -------------+------------------\     V
>        \--->+<---< One or more U-NAPTR results in X      >--->+
>             | yes \-------------------------------------/ no  |
>             V                                                 V
>     (-------+-------)                                 (-------+-------)
>     ( END, result X )                                 ( END, failure  )
>     (---------------)                                 (---------------)
>
> ------------------------------------------------------------------------
>
>
> Thanks again
> Sebastian
>

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