Re: draft-warnicke-network-dns-resolution-02.txt

[Peter Koch <pk@TechFak.Uni-Bielefeld.DE>]

Rob Austein <sra+dnsop@hactrn.net> wrote

> I'd have to check my notes to be certain, but I think that the WG
> discussed this in San Francisco and decided not to make it a WG doc.

not having been in San Francisco I do not know what the decision(oops?) was
based upon, but here are some comments and more detailed remarks below:

While I'd agree that it would be nice to have an updated version of RFC 1101,
i'm not sure I understand the problem the draft really tries to address.
From what i guess it does, the solution IMHO seems too complicated to work
in practice. Additional information regarding the motivation of this kind
of solution would be welcome.
As an example: Is the proposed algorithm intended to be processed from
inside the particular network or from the outside? If the latter, then why?

The proposed method should support the address of the 'first hop router',
but there's nothing in the draft that restricts the algorithm to this
problem domain. It's broad enough to be applied to other services, which
is OK on the one hand, but on the other it means that here's another
approach to the service location problem. DNS is not really the best approach
to locally scoped service location.

So, it's not clear to me why the problem is tried to be solved via DNS in the
first place. For the algorithm to work, the asking system needs to contact a
resolver, i.e. it needs to know that system's address (unless link local name
resolution is used). Also, it needs an IP address and a working interface,
usually including a subnet mask (unless the local environment supports proxy
ARP). So, why does the system need to determine the/a router's address?
And even if it needs that address, why would it have to first find the
subnet mask? What about using DHCP?

Finally, due to the way the intermediate names are constructed, the
suggested algorithm would need too many additional zones, at least domain
names, including some, which can only be instantiated with cooperation
from upper level zones. IMHO this is affords too much interaction to be
used "out there".

So, finally, based on the information currently available I'd agree that the
draft not be adopted by the WG. An update of RFC 1101 would be interesting,
though.

Please find more detailed comments below (quoting from the draft).

-Peter

.............................................................................


>    host.  It would be useful to have a standard mechanism for such
>    a host to find the first-hop router(s).

If such host could be instructed to contact a particular resolver, why
can't it be told the address of it's router?

>    DNS-based mechanisms have been defined for the resolution of router
>    addresses for classful networks (RFC 1035 [1]) and of subnets (RFC

Is that "A" records? Otherwise I can't see what RFC 1035 does to answer
this particular question.

>    network.  This RFC also specifies an extension to the method of RFC
>    2317 to support delegation at non-octet boundaries.

RFC 2317 doesn't need this extension, because in the case the prefix length
is less than 24, you'd just delegate and populate a separate zone per octet.
You'll cover a single "network" by multiple zones, but that doesn't matter.
And that practice pre-dates RFC 2317.

So, the problem is: ``given an IP address, find "the" first hop router for
that address''
Who is to ask that question? I guess it's the system itself, but then,
why would it be necessary to answer that question by means of DNS instead
of, say, DHCP?

>    networkdomainname = maskedoctet "." *( decimaloctet / maskedoctet ".")
>                         ".in-addr.arpa."

That should read "in-addr.arpa". The first "." is already provided by the
other rule elements. The last is unnecessary because domain names don't end
in dots.

>    decimaloctet = ( *1("1") DIGIT DIGIT ) /
>                    ( "2" ( "1" / "2" / "3" / "4" ) DIGIT ) /
>                    ( "2" "5" ( "1" / "2" /"3" / "4" / "5" ) )

An element covering a single DIGIT is missing, and this rule would allow a
leading zero in e.g. "00". Either the rule would have to be extended or
the restrictions could be dealt within a comment (see definition of
"IPv4-address-literal" in RFC 2821.

>    A "-" is used as a delimiter in a maskedoctet instead of a "/" as in
>    RFC 2317 out of concern about compatibility with existing DNS
>    servers, many of which do not consider "/" to be a valid character in
>    a hostname.

That's not a matter of the server's opinion. On the other hand, it's only
relevant if address records have to be associated with a name (i.e., it's
really a hostname). That's not the case in this draft, so "/" could be
used (but see below).

>    In RFC 2317 there is no mechanism for non-octet boundary delegation.

And that's not necessary there, see above.

>    1.  Take the initial IP address x.y.z.w and create a candidate
>        network by assuming a 24 bit subnet mask.  Thus the initial
>        candidate network is x.y.z.0/24.

Why doesn't the system know the subnet mask for this interface? Is it
supposed to be multihomed?

>    4.  If the PTR records returned from looking up the candidate domain
>        name  are of the form of a domain name for a network as defined
>        previously (Section 2), then for each PTR record reduce that
>        returned domain name to the canonical form
>        p1-q1.z1.y1.x1.in-addr.arpa.  This represents a network
>        x1.y1.z.1.p1/q1.
               ~~~
Delete dot ----/

>        1.  If no candidate network PTR lookup for this IP address has
>            succeeded in the past and the netmask for the last candidate

What does the term "in the past" mean in this context? Is the system
supposed to keep state across multiple invocations of this algorithm?

>        2.  If no candidate network PTR lookup for this IP address has
>            succeeded in the past and the netmask for the last candidate
>            network was not 24 of 16 bits long, then increase the netmask

s/of/or/;

> 4.2 Example

[...]

>    7.   Lookup the PTR records for 0-16.15.10.in-addr.arpa.
>    8.   Lookup returns:
> 
>         1.  0-17.15.10.in-addr.arpa.
>         2.  128-18.15.10.in-addr.arpa.
>         3.  192-18.15.10.in-addr.arpa.

Obviously you need the cooperation of and interaction with the maintainer of
the /16 for this to work. That might even be an RIR!

>    0-17.15.10.in-addr.arpa.    IN  NS 10.15.0.50
>    128-18.15.10.in-addr.arpa.  IN  NS 10.15.128.50
>    192-18.15.10.in-addr.arpa.  IN  NS 10.15.192.50

The single NS RR per zone is due to brevity, I guess; but IP addresses
should not be used in the RDATA. It violates the protocol and although
the intention is almost obvious, errors like this are too easily copied.

>    In entity B's DNS zone files:
> 
>    ;; provide entries for the subnets of 10.15.128.0/18
> 
>    128-18.15.10.in-addr.arpa. IN PTR 128-19.128-18.15.10.in-addr.arpa.
>    128-18.15.10.in-addr.arpa. IN PTR 0-25.160.128-18.15.10.in-addr.arpa.
>    128-18.15.10.in-addr.arpa. IN PTR \
>                                    128-25.160.128-18.15.10.in-addr.arpa.
>    128-18.15.10.in-addr.arpa. IN PTR 0-24.161.128-18.15.10.in-addr.arpa.
>    128-18.15.10.in-addr.arpa. IN PTR 162-23.128-18.15.10.in-addr.arpa.
> 

The list is incomplete. 10.15.128/18 was further split into 10.15.128/19
an others, so you also need entries for "128-19.15.10.in-addr.arpa" and more.
So, the /16 reverse maintainer is again to be involved. I'd expect some
operational difficulties with this scheme. Instead one could try to make the
prefix part of the hierarchy, i.e. "/18.128.15.10.in-addr.arpa".
An APL RR might be more efficient than a large PTR RRSet.

>    ;; provide entries pointing to non in-addr.arpa hostnames for
>    ;; terminal network
>    162-23.128-18.15.10.in-addr.arpa.  IN  PTR gw1.example.com.
>    162-23.128-18.15.10.in-addr.arpa.  IN  PTR gw2.example.com.

Why are these owner names not reduced?

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