Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt

[Dean Anderson <dean@av8.com>]

On Tue, 8 Apr 2003, Markus Stumpf wrote:

> On Mon, Apr 07, 2003 at 04:30:05PM -0400, Dean Anderson wrote:
> > > There is a much easier way to find out all the domains hosted by us than
> > > to ask for the PTR records of each and every IP of e.g. our /16.
> >
> > Really? What is it?
>
> Know your tools and ask your LIRs.

Most registries won't give this information out anymore. (for the obvious
reason).  One can't easily get copies of the com or net zones (to look for
domains with certain nameservers).

> > So, you expect everyone to give out their customer lists?  Not every ISP
> > shares your hubris.
>
> That's not our fault. And if you mean that it's impossible, if I want
> Example Co Ltd as a customer, to find out where they have Internet
> connectivity from, just because you don't add reverse records, you're
> rather naive.

Thats the reverse of what I stated. Given a company, Of course, I can
certainly find out something about its IP addresses, for some obvious
public names, anyway.  Certain agencies host their public sites on
different connections just to hide this information.

You have done something different: This proposal maks possible an easy
answer to the question: Given an ISP, who are the customers?

> Oh btw. the example I made is one customer, so adding one or 100 PTR
> records doesn't make much difference in matters of losing customers
> and it was the explicit wish of that customer to add the records.

I don't have too many customers ask for in-addr. I usually give it to them
if they ask, but I frequently don't setup anything that isn't convenient,
or isn't useful traceroutes.  I know of a number of very large ISPs that
refuse such requests flat out.  If you have one or more /8's, it gets to
be a lot of work to manage 16 million reverse entries. Most places don't
want to fully populate that.  Maybe that's why few or none of the big
ISP's are asking for this.

Ok, lets play along. Assuming for the moment that in-addr could be
trusted, lets look at the proposal:

> > > > Perhaps you want to rethink that long PTR list. And at
> > > > some point, it will be too big for a UDP reply.  I hadn't even thought
> > > > about that until I looked at your big list.  Then what?
> > >
> > > Then we don't add other names.
> >
> > If you don't add them, then their reverse is broken, according to this
> > proposal.
>
> 1) it isn't, according to this proposal

Not every IP and domain needs forward and reverse?  Really?  I must have
misunderstood the proposal somewhere.  If you drop xcust.com from your PTR
list, then when I see a message from xcust.com in my logs, and I do a
forward/reverse/forward test on xcust.com, that test will fail.  That
violates this proposal, right?

> 2) the software knows about reverse resolving first, as it gets the IP
>    address, looks up the PTR and validates the info by doing a forward
>    lookup of the name(s) it got from the PTR.
>    If it doesn't get names in the PTR it will not lookup these names.

So if you have a thousand domains on one IP, and I have to do this test, I
have to test a thousand domains?

What happens if you have a PTR record (say ycust.com), that you haven't
removed yet, and ycust.com has changed the forward address, so that when I
test the forward (having gotten it on your list of PTRs), the test fails.
Then what?  I should keep doing the test until it succeeds?  Or should I
reject it as "not completely working according to this draft"?

> 3) if UDP buffer is too small DNS software automatically switches to TCP
>    (or at least it should).

Ok, but that adds a lot of overhead. Now we have to consider many more tcp
connections on servers, leading to resource starvation.

Sounds pretty complicated, for such a "simple" proposal.

I'm not convinced that even if there were trust in in-addr, that your
scheme works in common cases.

		--Dean

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