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

[Sebastian Kiesel <[e-mail]>]

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]>, Ted Lemon
> <[e-mail]>, 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