Re: the well-known address approach

[Alain Durand <Alain.Durand@Sun.COM>]

Being the last author of the well known address document
in the v6 wg, I feel I can answer for the sake of clarification.
I do not intend to reopen the discussion, so I will try to limit
myself to this post only.

See inline.

Rob Austein wrote:

>- How does this interact with LLMNR?  Eg, how is a node supposed to
>  know whether it should be doing LLMNR or not?  (NB: I'm no fan of
>  LLMNR, but it's out there and people are using it.)
>
This is an orthogonal issue. Any DNS discovery mechanism will
have to face this. Beside, this is an LLMNR issue.

>- There are layering and administrative issues.  This approach puts
>  the DNS configuration information into the routing system.  It's not
>  immediately obvious that the local routing system and the local
>  recursive name servers are necessarily controlled by the same
>  administrators, so there are issues with how updates get into the
>  routing system, with how (and whether) the routing system reflects
>  recursive name servers that die or move, and so forth.
>
This is the same issue with DHCP-lite or RA. The routing folks
have to put some configuration in their routers, and this configuration
is derived from what the DNS folks tells them.

>- There are also fate sharing and coupling issues.  Using well-known
>  addresses hides the binding between the addresses and the particular
>  recursive name servers in question, which may matter if one or more
>  of the recursive name servers starts flaking out.  In the "normal"
>  (not well-known-address) case, a resolver can keep track of which of
>  the recursive name servers it's using is performing, and might
>  conceivably inititate some form of recovery action (eg, probing for
>  a new set of recursive name servers) if something bad happens.  In
>  the well-known-address case, none of that is likely to work well.
>  
>
Fate sharing is not specific to the well know address.
With RA or DHCP-lite, there is also fate sharing on the local router
between the routing process and the RA/DHCP-lite one.

The loss of strong binding with the DNS server is anl issue.
With the well known address, you somehow lose track of who
you're talking to, especially if that address is an anycast one.
Note that the latest draft was especially not using the term anycast
and was reserving 3 addresses, so you could somehow mitigate
the issue by placing 3 servers with 3 different addresses. That way
the DNS client/stub resolver could try another server if the current
one started to behave badly.

Generally speaking, sevral people were uncomfortable
with the idea of overloading IP addresses with service semantic.
For example, it is common practice in IPv4 to use x.x.x.1/24 or y.y.y.254/24
for the local router on the link, but there is no protocol that makes
this assumption. People were reluctant to make this step in IPv6.

    - Alain.

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.