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."
(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.
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
Yo Joshua! On Fri, 18 Aug 2000, Joshua Goodall wrote:
c) not everyone wants the reverse to match the forward (is this an RFC violation? I hope not :)).
RFC 1912, Sec 2.1: " Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data." I have yet to hear a convincing argument why this RFC should be ignored. I have seen many problems when this is ignored. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
www ---> 10.0.0.2 ns1 ---> 10.0.0.2 servershostname ---> 10.0.0.2 10.0.0.2 ---> servershostname.domain.com I think this is the situation Joshua is describing, where you might rev-map to a server name (Whatever hostnames you assign locally to your boxen), but where that hostname is NOT "ns1.domain.com") At 12:33 PM -0700 8/18/00, Gary E. Miller wrote:
Yo Joshua!
On Fri, 18 Aug 2000, Joshua Goodall wrote:
c) not everyone wants the reverse to match the forward (is this an RFC violation? I hope not :)).
RFC 1912, Sec 2.1:
" Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data."
I have yet to hear a convincing argument why this RFC should be ignored. I have seen many problems when this is ignored.
RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
exactly - as long as the PTR record exists and returns a FQHN with a resolvable and identical A record, rfc1912 seems satisfied. back to the thread, I wouldn't feel comfortable with using PTR nonexistence (or otherwise) to prove that an address is no longer used. After all, that address *is* about to be used (hence the problem). In other words, you'd have to violate rfc1912 on an authoritative nameserver (of all devices to violate it on) just to prove re-use. -[ Joshua Goodall ]----------------------------------------------- -[ IP Systems Architect ]---------------- Cook, Geek, Lover ------ -[ joshuag@interxion.com ]--------------- joshua@roughtrade.net -- On Fri, 18 Aug 2000, Derek J. Balling wrote:
www ---> 10.0.0.2 ns1 ---> 10.0.0.2 servershostname ---> 10.0.0.2
10.0.0.2 ---> servershostname.domain.com
I think this is the situation Joshua is describing, where you might rev-map to a server name (Whatever hostnames you assign locally to your boxen), but where that hostname is NOT "ns1.domain.com")
On Fri, 18 Aug 2000, Gary E. Miller wrote:
RFC 1912, Sec 2.1:
" Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data."
I have yet to hear a convincing argument why this RFC should be ignored. I have seen many problems when this is ignored.
This raises a question that I've had for some time. This says that a "PTR record must point to a valid A record, not an alias defined by a CNAME". RFC 1035, Sec. 3.3.12 says that the PTRDNAME is a "<domain-name> which points to some location in the domain name space" and that "PTR records cause no additional section processing". Since RFC 1035, Sec. 3.3 states that a <domain-name> is just a label, and says nothing that the label has to have a corresponding A record. Since RFC 1912 is informational and does not update RFC 1035, it would seem that a PTR record does *not* have to point to a host that resolves. No? Am I getting lost in the fine print? Am I missing a later RFC that clarifies this? -- Alex Kamantauskas alexk@tugger.net
[ On Friday, August 18, 2000 at 15:55:42 (-0400), Alex Kamantauskas wrote: ]
Subject: Re: lame delegations
On Fri, 18 Aug 2000, Gary E. Miller wrote:
RFC 1912, Sec 2.1:
" Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data."
I have yet to hear a convincing argument why this RFC should be ignored. I have seen many problems when this is ignored.
This raises a question that I've had for some time. This says that a "PTR record must point to a valid A record, not an alias defined by a CNAME". RFC 1035, Sec. 3.3.12 says that the PTRDNAME is a "<domain-name> which points to some location in the domain name space" and that "PTR records cause no additional section processing". Since RFC 1035, Sec. 3.3 states that a <domain-name> is just a label, and says nothing that the label has to have a corresponding A record. Since RFC 1912 is informational and does not update RFC 1035, it would seem that a PTR record does *not* have to point to a host that resolves.
No? Am I getting lost in the fine print? Am I missing a later RFC that clarifies this?
I think all you're missing is the connection between second sentence and the fifth in the quoted paragraph -- i.e. all PTRs in the "in-addr.arpa" domain must point back directly to valid A RRs. PTRs in other domains may point elsewhere, and indeed I use them myself: $ host -t ptr -l weird.com weird.com. PTR 0.254.92.204.IN-ADDR.ARPA. weird.com. PTR 160.161.29.204.IN-ADDR.ARPA. inverse-weird-bcast.weird.com. PTR 255.254.92.204.IN-ADDR.ARPA. inverse-loopback.weird.com. PTR 0.0.0.127.IN-ADDR.ARPA. inverse-weird-net.weird.com. PTR 0.254.92.204.IN-ADDR.ARPA. This kind of usage is defined and documented in RFC 1101, and is very useful to do if you want tools like netstat to report useful names instead of boring old network numbers. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
RFC 1912, Sec 2.1:
Which is 'Informational', not standards track...
" Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one).
I have yet to hear a convincing argument why this RFC should be ignored. I have seen many problems when this is ignored.
The major problem here is software packages that can't deal with the possibility of setups like this: www.mycorp.com CNAME round-robin.server.mycorp.com round-robin.server.mycorp.com A 198.168.1,1 A 198.168.2.1 A 198.168.3.1 Yes, major software vendors are still managing to get this Totally Wrong. And when somebody at the VP level says something WILL be deployed in time for another non-negotiable deadline (for instance, 25K students returning to campus), you end up with some ugly ad-crockery with PTRs ;) Yes, we'll fix the PTRs. Soon as we get a patch from the vendor. 'Nuff said. ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
participants (8)
-
Alex Kamantauskas -
Derek J. Balling -
Gary E. Miller -
John O Comeau -
Joshua Goodall -
Phillip Vandry -
Valdis.Kletnieks＠vt.edu -
woods＠weird.com