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

[Edward Warnicke <eaw@cisco.com>]

Peter,
	Would this make more sense if I were to point out that
I screwed up the last edit of the last sentence of paragraph 1
in the Introduction.  It reads:

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

The implication is that a host would be using the method of the draft
 to look up information about itself.  This is incorrect.  Rather that
 sentence should be replaced by:

 "It may be necessary for a third party server in the network to
 request some service related to the host from the first-hop router(s) for
 that host.  It would be useful to have a standard mechanism for such a
 server to find the first-hop router(s)"

The application I'd originally written the draft to deal with was
identification of the first-hop router as the intercept access point
for Lawful Intercept ( wiretapping ).  The intention is *not* for
a host to use this method to discover anything, but rather for
*other* servers in the network to use this method to be able to
discover the IP address of the first-hop router(s) so that they may
request some service from the first-hop router(s) related to the host.
Some method of identifying the intercept access point is necessary
for Lawful Intercept.

Does the above change in language clear up some of the confusion?

More comments inline...

On Sat, 5 Jul 2003, Peter Koch wrote:

> Rob Austein <sra+dnsop@hactrn.net> wrote
> 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.

The initial motivation for this draft was that I encountered some attempts
to use RFC 1101 to allow identification of the first-hop router(s) for a
host in order to request Lawful Intercept services ( wiretapping ) of the
host by the first-hop router(s).

> 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".

Cooperation of the upstream zones will sometimes be necessary, but care
has been taken to limit the amount of cooperation needed.

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

See comment above about this being an error introduced in the most
recent edit.  This is *not* a method for a host to discover anything
about itself, but rather a method for other servers in the network to
discover the first-hop router(s) of a host.

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

I was mostly refering to RFC 1035 section 3.5 paragraphs 5,6, and 8.

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

You are correct RFC 2317 doesn't need this extension for it's application
because it is dealing with using PTR records to map from an
IP number to a hostname ( the hostname of that IP address ).

For my application I need to be able to cleanly delegate on non-octet
boundaries in aggregate.

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

Some other server in the network is asking this question, like a mediation
device seeking to start a tap on a host using the hosts first hop gateway.

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

You are correct.  I will fix the error.

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

You are correct.  I will fix the error ( thanks for the pointer to 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).

Browsing lightly through the source for bind 8.3.0 it looks like
the rdata associated with ptr records is judged OK or not by ns_nameok
as being of context hostname_ctx, which causes it to drop through to
res_hnok, which checks the hostname in such a way as to allow allow
alphachar, digitchar, and hyphenchar, but not "/".  Perhaps I'm
misreading ( I only browsed lightly ), but it looks like there is some
potential for confusing bind 8.3 with RDATA for a PTR record that contains
a "/".  Would I rather use the "/" character?  Yes.  But I wasn't willing
to risk issues with DNS implementations over the issue.

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

Again, the host knows it's subnet, another server in the network needs to
look it up.  My fault for causing this confusion.

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

You are correct again, I will correct the error.

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

No.  In the past means as part of the same lookup process.  The resolution
of the IP address of the first-hop router for a host may span multiple DNS
lookups.  The algorithm *does* require maintaining state across multiple
DNS lookups, but not across multiple first-hop router resolutions.

>
> >        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/;

You are correct.  I will fix the error.

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

Yes, you will need the cooperation of your upstream zone.  Care was taken
to minimize the number of entries the upstream DNS would need to provide,
and to limit the churn of those records.

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

You are correct that the single NS is for brevity.  You are correct that
I used the incorrect RDATA type for the NS record.  I will fix the error.

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

Actually... the list is not incomplete here ( although it is further on ).
The 10.15.128/19 and others are subnetted from the 10.15.128/18 and
therefore are *not* the concern of the owner of the 10.15/16.  The
10.15/16 doesn't need to know anything about the way the 10.15.128/18 is
subnetted, because any RR for that subnetting will be off of the
128-18.15.10.in-addr.arpa. shim domain.  You see this in the entry:

   128-18.15.10.in-addr.arpa. IN PTR 128-19.128-18.15.10.in-addr.arpa.

where the 10.15.128/19 subnet is represented by the
128-19.128-18.15.10.in-addr.arpa. domain name.

For reasons of brevity I did not show the RR for
128-19.128-18.15.10.in-addr.arpa. in entity B's DNS tables as it isn't
pursued further in the example.

>
> >    ;; 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?

The names aren't reduced because that would require more work on behalf
of the 10.15/16 owner.  162-23.15.10.in-addr.arpa. would require more
RR entries be made by the 10.15/16 owner.  As you've pointed out
( correctly ) this is likely to make them grumpy :)  That's why
the shim zone is used.  It also means that if the owner of the
10.15.128/18 owner changes their subnetting it makes no difference
in what the upstream provider needs in their DNS tables.

I put a fair bit of thought into reducing the number of RR entries the
upstream provider would need to provision, and into reducing the
need for the upstream provider to change those entries if the
subnetting of the delegated network changed.

In the current scheme, when an upstream provider delegates a network
downstream, they would have to create:

1		PTR record entry for the delegating network
		( 0-16.15.10.in-addr.arpa.  IN  PTR 128-18.15.10.in-addr.arpa. )
1 or more 	NS records for the shim domain
		( 128-18.15.10.in-addr.arpa.  IN  NS ns1.example.net )
0 or more 	glue records for the NS records

So delegating a network requires 1 + n + m  where n is the number of NS
for the shim domain and m is the number of needed glue records.

Thank you very much for taking the time to provide such a detailed
critique, it has been quite helpful.  Hopefully I've answered ( or
acknowledged ) your criticism adequately.  If not, let me know.

Ed

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