In message <20141106152435.7ad4caa0...@fafnir.remote.dragon.net>, Paul Ebersman
writes:
>
> marka> For in-addr.arpa you already have a PTR records. Allowing the
> marka> end user to set its content does not increase the amount of data
> marka> you are serving. It does increase the amount of churn in the
> marka> zone.
>
> This draft isn't talking about v4. And $GENERATE or equiv already works
> in that most customers don't scream. I have no incentive to change to a
> more risky and complicated and hard to maintain system for v4.
>
> I'd contend that the folks who check v4 PTRs will have the same level of
> trust with auto-gen'ed v6 that they do with v4. Folks that don't trust
> it now still won't and those that find it acceptible in v4 will accept
> it in v6.
And why can't we improve IPv4 at the same time using the same
mechanisms?
Also the examples are easier to type into a 80 column window. The
only difference between IPv4 and IPv6 on the client node is the
name of the PTR record.
> marka> The occasional customer will add a offensive PTR record which
> marka> won't be seen by 99.99999% of the world.
> [...]
> marka> If we recommend that this is only done when a forward record is
> marka> also successfully added UPDATE + TSIG (yes, this does scale for
> marka> this use) you get rid of the PTR/A mis-match issues.
>
> And we're definitely not talking about allowing customers to do dynamic
> updates of forward records in this draft.
With IPv4 most ISPs supply both fake/generic forward and reverse
zones for those that check PTR records with A lookups.
> If you want that currently, you get a business account or use one of the
> many services that allows that. Yes, it costs money. But most folks
> don't seem to miss it in the consumer world and those that do find
> someone willing to do it.
Actually it is often impossible to find a ISP "willing + same or
better speed" let alone for a reasonable price. Sometimes you can't
get it for any price at any speed because the end point of the
connection is in a residence and the only ISP's servicing the area
won't sell a "business class" connection to the address.
So no, "get a business account" is *not* a viable alternative.
I'm and sick and tired of "Were the phone company and you just have to
lump it" which is all this alternative is.
> marka> For ip6.arpa you delegate to the customer along with the prefix
> marka> delegation. The customer has to deal with the space issues but
> marka> uses the same mechanisms to add the PTR records and cleanup.
>
> Because the mythical grandmother wants to deal with their own address
> space. Right...
>
> Most customers don't even know what DNS is, much less PTRs. They want to
> get content, send emails and pictures of cats. As an ISP, it's our job
> to make sure this works. $GENERATE in v4 does work. Auto-gen'ed PTRs in
> v6 works as well as $GENERATE, no better, no worse.
>
> marka> You get the equivalent of $GENERATE with customer settable
> marka> overrides using UPDATE over TCP.
>
> And I want 10s of millions of users doing TCP to my auth servers? I
> think not. Certainly not for something of so little gain to my
> customers.
Well I can also do a solution which uses KEY's submitted via DHCP and
works over UDP.
TCP happens to work well for SLAAC in the home but it is conceptually
trivial to send KEY rdata via DHCP and have the DHCP server add the
record so that the DNS update can be done over UDP for those using
DHCP. Yes, I have written a draft on how to do this with PD but
similar logic works for a single address.
DHCP servers already do dynamic updates of reverse zones so this
is just adding a different record compared to the PTR record they
currently do. I would expect it would take about a day to add the
logic to do this once a code point for the DHCP option is assigned.
Nameservers already support updating of records based on self
referential KEY records for the name alone or the name and subzone
beneath it. We have shipped one which does this for over a decade
now.
update-policy {
grant <dhcp-server-key> subzone * ANY;
grant * self * PTR KEY; // explict list of type updatable
// grant * self * ANY; // all types except NSEC and NSEC3
// grant * self *; // all types except RRSIG, NS, SOA,
// NSEC and NSEC3
// grant * selfsub *; // Allow the key name and anything
// under it.
};
The KEY record is in the zone so it is already trusted. This doesn't
require the zone to be signed.
The rest of the cleanup logic still works.
One could simulate this today with just named and nsupdate.
Simulate DHCP server add/update of KEY record (I'm using in-addr.arpa
because it is easier to type).
nsupdate -k Kdhcp-server-key
update add 4.3.2.1.in-addr.arpa 3600 IN KEY ...
send
Simulate node update
nsupdate -k K4.3.2.1.in-addr.arpa
update add 4.3.2.1.in-addr.arpa 3600 IN PTR ....
send
> ebersman> Anti-spam folks *like* it that it's not trivial to get
> ebersman> "correct" rDNS/PTRs. It's easy to find consumer connections
> ebersman> based on the ISP doing bulk/lazy PTR generation and just
> ebersman> reject SMTP traffic from them.
>
> marka> Which won't work in IPv6 unless you syntesize the records on
> marka> demand.
>
> And that's the plan, at least for $DAYJOB. And sign on the fly for those
> of us signing our zones.
Then you are telling me that you intend to break reverse lookups
done by home users that setup ip6.arpa zones for the address space
delegated to them with PD. Or are you telling me that you customers
are not allowed to even setup PTR records within the home for the
address space delegated to them?
> ebersman> Large ISPs don't care about clean PTRs as long as no customers
> ebersman> complain and they don't care if end customers can't do SMTP
> ebersman> without having to ask for it in some special way.
>
> marka> Except autogenerated PTR records don't solve the problem.
>
> How not? Works fine for v4 right now. Customers that want to do their
> own email usually have to make a special request to their ISP but can
> do it. Biz connections are allowed to do their own PTRs at most ISPs,
> assuming the customers want and need it. And if they do "clean" PTRs as
> part of this, the anti-spam folks are happy.
>
> ebersman> What else in the way of tradeoffs is missing?
>
> marka> That people want IP to name mappings for their internal networks.
>
> Get a biz connection or a service to allow this.
>
> marka> With things like DNSSEC you need break DNSSEC trust chains at the
> marka> ISP level for this to work.
>
> Even our biz customers mostly don't do or want DNSSEC on PTRs. As this
> changes, we'll figure out how to do this as a service. But all the work
> of getting in DS and doing clean zone cut and delegation has nothing to
> do with this draft either.
But it has to be considered.
> marka> We also don't know what else will come along to use the reverse
> marka> namespace. It is a good place to hang keying material which is
> marka> tied to IP address.
>
> So you're volunteering to work on a draft mentioned documenting how
> folks are using PTR space? Thanks!
>
> marka> Having a well defined method to update this name space will be
> marka> useful.
>
> Another draft. But not this one. If such a method did already exist,
> worked and had at least reference implementations, it would certainly be
> worth mentioning in this draft.
update-policy tcp-self exists and is available in millions
of servers today. It just needs to be turned on.
I've implemented
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
