(cross-cc'd to the RIPE LIR working group list for potential interest/comment) I suspect that solving this correctly would depend on the ICANN DNSO recognising the authentication mechanisms of the databases of the RIR's under the ICANN ASO (RIPE, ARIN, APNIC). Unfortunately, no-one thought of this problem when they let registrars inject host records. The only way to verify automatically that a host record is allowed from a given netblock is to use the same authentication mechanisms that (say) RIPE do for reverse delegations. I doubt that the RIR databases would take the strain of continuous lookups in that fashion. Futhermore, the RIPE database only defines password and PGP access controls for the LIR allocated space, not the assigned space used by nameserver operators. (no need to speculate upon the hazards of mail-from authentication). One possible solution, probably even manageable is that the DNSO/NSI Registry accepts host updates (or even just withdrawals) from an automated RIR system that can be triggered by correctly authenticated LIR maintainers, in the way that in-addr mappings already are. This satisfies the point-of-control requirements, and could probably be implemented without a change to the existing RRP. I don't know whether the situation arises often enough to motivate such a solution, but I would bet a (small) amount of money on some scriptkiddie reading this thread and trying it out for their dubious kicks. (you may guess correctly that I'm more familiar with RIPE systems than ARIN/APNIC :)) -[ Joshua Goodall ]----------------------------------------------- -[ IP Systems Architect ]---------------- Cook, Geek, Lover ------ -[ joshuag@interxion.com ]--------------- joshua@roughtrade.net -- On Fri, 18 Aug 2000, John O Comeau wrote:
Obviously I didn't make it clear what is the problem in my previous post. So far I got the following 2 replies:
"The NIC should allow for dummy [default] nameservers and allow the technical contact of a nameserver to remove his or her nameservers from a domain without requiring an administrative ack."
Yes, but we are not the technical nor the admin contact for these domains; we just provide the IPs. What I propose is that the tech or admin contact of the NETBLOCK has authority to delete the host registration by virtue of the IP being his.
"If the IP's are allocated to you, what's it matter where your old customer still points their NS? Just remove the old customer from all of your db's and reallocate your IP's elsewhere."
We've been doing precisely that, and that's where the problem comes in. The new customer cannot register his nameservers because the IP is already registered as a nameserver. Then he complains, we look like idiots, and we have to give him other IPs to use.
jcomeau@world.std.com aka John Otis Lene Comeau Home page: http://world.std.com/~jcomeau/ Disclaimer: Don't risk anything of value based on free advice. "Anybody can do the difficult stuff. Call me when it's impossible."
Why not this? Registrars only accept to create a glue record if there already exists a PTR entry for the requested address that points to the right name. -Phil
I suspect that solving this correctly would depend on the ICANN DNSO recognising the authentication mechanisms of the databases of the RIR's under the ICANN ASO (RIPE, ARIN, APNIC).
Unfortunately, no-one thought of this problem when they let registrars inject host records. The only way to verify automatically that a host record is allowed from a given netblock is to use the same authentication mechanisms that (say) RIPE do for reverse delegations.
that's great at creation time, but what about when Customer-A leaves ISP-A to go to ISP-B, but doesn't bring his host records along with him? ISP-A needs the ability to say "Attention $REGISTRAR, $HOSTNAME is no longer valid, as evidenced by the current lack of a PTR record. Please remove it". The lack of a PTR record covers the case where PTR and host-record may not match so someone impersonates ISP-A asking the host name be destroyed. The PTR record has to completely not exist. Of course, this is a great idea, but can we actually get it implemented by the relevant agencies? ;-) D At 2:56 PM -0400 8/18/00, Phillip Vandry wrote:
Why not this?
Registrars only accept to create a glue record if there already exists a PTR entry for the requested address that points to the right name.
-Phil
I suspect that solving this correctly would depend on the ICANN DNSO recognising the authentication mechanisms of the databases of the RIR's under the ICANN ASO (RIPE, ARIN, APNIC).
Unfortunately, no-one thought of this problem when they let registrars inject host records. The only way to verify automatically that a host record is allowed from a given netblock is to use the same authentication mechanisms that (say) RIPE do for reverse delegations.
ISP-A needs the ability to say "Attention $REGISTRAR, $HOSTNAME is no longer valid, as evidenced by the current lack of a PTR record. Please remove it".
Indeed. Insist on a true NXDOMAIN response to authorize removing of the record, so that records cannot be removed due to nameservers having technical problems.
Of course, this is a great idea, but can we actually get it implemented by the relevant agencies? ;-)
I think it has the best chance, because at least it does not require coordination between agencies! -Phil
On Fri, 18 Aug 2000, Phillip Vandry wrote:
Why not this?
Registrars only accept to create a glue record if there already exists a PTR entry for the requested address that points to the right name.
-Phil
off the top of my head, I'd say a) DNS is very spoofable b) there's a catch-22; for sensible management, most LIR's create reverse delegations at RIPE using the FQHN of their nameservers. Without the host-record glue already in place, resolvers won't be able to find that PTR record. c) not everyone wants the reverse to match the forward (is this an RFC violation? I hope not :)). d) this doesn't help the original problem where outdated glue blocks the creation of correct glue. J
participants (4)
-
Derek J. Balling -
Joshua Goodall -
Phillip Vandry -
Phillip Vandry