- dns-wg - mailman.ripe.net

Last Warning: Termination of <auto-inaddr@ripe.net>
by Olaf M. Kolkman 14 Jul '04

14 Jul '04

Dear Colleagues, [Apologies for the duplicate messages] As announced previously (e.g. [1]), we will discontinue the use of the <auto-inaddr(a)ripe.net> e-mail interface for reverse delegation requests as of tomorrow (July 15, 2004). From tomorrow, all mails sent to this address will be returned to sender. Reverse delegation requests can only be submitted to the RIPE Whois Database by using the <auto-dbm(a)ripe.net> e-mail interface or by using one of the other update mechanisms such as web-updates[2]. For more information about the authentication mechanism, please see http://www.ripe.net/reverse -- Olaf Kolkman New Projects, RIPE NCC [1] http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00042.html [2] Webupdates interface to the RIPE Whois Database. http://www.ripe.net/perl/webupdates.pl If you are reading this or related posts from the archive all occurrences of ripe.net in e-mail addresses have been replaced by localhost -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC

1 0

Re: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue
by geoff＠nominet.org.uk 13 Jul '04

13 Jul '04

Stephane Bortzmeyer <bortzmeyer(a)nic.fr> writes: > On Tue, Jul 13, 2004 at 10:51:55AM +0200, > Jeroen Valcke <jeroen.valcke(a)belnet.be> wrote > a message of 18 lines which said: > > > Now, I was wondering whether IPv6 glue records have already been > > added in the root zone. To my knowledge not, is that correct? > > Correct. ftp://rs.internic.net/domain/root.zone.gz > > > Are there TLDs who already submitted IPv6 glue records? > > We did, on 17th February 2003. At the CENTR GA Meeting last month, Doug Barton announced that AAAA RRs would be introduced into the root zone by the end of June, but this has not yet happened. Regards Geoff

1 0

Re: [dns-wg] Policy for Reverse DNS for End-User PA Addresses?
by Jim Reid 09 Jul '04

09 Jul '04

Jørgen, you raise an interesting question. This subject is certainly something for the WG to consider. How about presenting something at the next RIPE meeting? My personal opinion is that a mandatory policy is likely to be too cumbersome. It could also be painful for ISPs and the NCC: creating inetnum objects for every /29 or whatever an ISP gives to its DSL customers. That might also open the door to other complications. If some DSL user is in the NCC database because of an inetnum object for reverse delegation, maybe that user should be paying NCC fees? And does that user become responsible for maintaining that inetnum and related objects in the database? I've also got a gut feel that reverse delegation is really an issue between an ISP and its customer. If some ISP won't do reverse delegation properly (or at all), the customer is free to pick another ISP that does. Economic Darwinism should sort this out, just like it eliminates the clueless ISPs with lousy service. A document advising about reverse delegations which customers can put in front of their ISP would be no bad thing though. That said, I would welcome a discussion about the subject and encourage the WG, especially those at DSL providers, to speak up. I would also be pleased for the WG to produce some document on reverse delegation and strongly recommends this gets done properly. Making reverse delegation mandatory for all customer IP addresses may be a step too far IMO, but let the WG decide this. Perhaps you could start the ball rolling by preparing an initial draft with a view to starting a work item? I'm a great believer in delegation (excuse the pun), so over to you.... and the WG.

7 9

Re: [dns-wg] Policy for Reverse DNS for End-User PA Addresses?
by Jim Reid 09 Jul '04

09 Jul '04

>>>>> "Brad" == Brad Knowles <brad.knowles(a)skynet.be> writes: Brad> But we're not talking about the general solution. Brad> We're talking about issues with DSL providers. So incorrect reverse delegation for customer IP addresses only happens with DSL providers, does it?

3 2

Re: [dns-wg] Policy for Reverse DNS for End-User PA Addresses?
by Jim Reid 09 Jul '04

09 Jul '04

>>>>> "Brad" == Brad Knowles <brad.knowles(a)skynet.be> writes: >> Brad, please re-read what I said. I spoke about ISPs, not DSL >> providers. Brad> At least in some countries, the DSL provider owns the Brad> reverse DNS, not the ISP. To repeat myself: please re-read what I said. If bit-shifter A won't do reverse DNS to a customer's liking, the customer can go to bit-shifter B who does. How A and B shift bits is irrelevant: DSL, avian carriers, cable modems, whatever. It all comes down to a trade-off between cost, QoS, bandwidth and reverse DNS. If reverse DNS is the over-riding concern for someone, they can always find an ISP who will do this. Though it may be from an ISP that doesn't do DSL. >> If working reverse DNS is a very important consideration for >> some customer, they can always find an ISP who can accommodate >> that. Brad> Not all ISPs provide their own access. In Belgium, I Brad> believe that Belgacom is the only DSL access provider that Brad> is allowed by law. Everyone else has to resell DSL access Brad> from Belgacom, and Belgacom owns the reverse DNS. So what? If they won't do reverse DNS to your liking, try a cable company. Or get Level3 (say) to run fibre into your basement. Or do dialup over your GSM. There's always a solution. But it might not be as cheap or convenient as DSL from the incumbent. That's why I said people can always vote with their wallets. In the case of a monopoly provider, a "Correct Reverse DNS Is A Very Good Thing" document from the WG might be helpful if their policies are not addressing their customer's needs and those customers have nowhere else to go.

2 1

Re: [dns-wg] Policy for Reverse DNS for End-User PA Addresses?
by Jim Reid 09 Jul '04

09 Jul '04

>>>>> "Brad" == Brad Knowles <brad.knowles(a)skynet.be> writes: >> I've also got a gut feel that reverse delegation is really an >> issue between an ISP and its customer. If some ISP won't do >> reverse delegation properly (or at all), the customer is free >> to pick another ISP that does. Economic Darwinism should sort >> this out, just like it eliminates the clueless ISPs with lousy >> service. Brad> I disagree. In many cases, there is one and only one Brad> DSL provider for a given address -- the old telephone Brad> monopoly continues to have a stranglehold here. Brad, please re-read what I said. I spoke about ISPs, not DSL providers. If working reverse DNS is a very important consideration for some customer, they can always find an ISP who can accommodate that. This might of course mean choosing some other way of shifting bits from what any monopoly DSL provider has to offer. So the customer makes their choice and pays their money. This probably is a much more effective way of getting results than writing up a BCP. Please note that I'm not saying monopoly DSL (or whatever) providers should be encouraged to ignore reverse DNS for their customers.

2 1

Re: [dns-wg] Policy for Reverse DNS for End-User PA Addresses?
by Jim Reid 08 Jul '04

08 Jul '04

>>>>> "Peter" == Peter Koch <pk(a)TechFak.Uni-Bielefeld.DE> writes: Peter> Well, does the recipient of assigned address space now Peter> (directly) pay an NCC fee? Well I'm not even though my ISP gave me a /28. I suppose some percentage of my DSL bill goes towards my ISP's contributions to the NCC. >> about reverse delegations which customers can put in front of >> their ISP would be no bad thing though. Peter> What I've read between the lines is that in the case of DSL Peter> the classless delegation method may not be sufficient, even Peter> if the ISP is able and willing. Due to dynamic nature of Peter> address assignments they'd need something similar to dyndns Peter> (and friends) for the reverse mapping. So, is anyone doing Peter> this already? No idea. Anyone?

1 0

Policy for Reverse DNS for End-User PA Addresses?
by Jørgen Elgaard Larsen 08 Jul '04

08 Jul '04

Hi there, I would like to share some thoughts on reverse DNS with you. In my experience, reverse DNS often works well with larger organisations that have been assigned a /24 IPv4 range or greater. On the other hand, it almost never works with smaller organisations using smaller ranges, e.g. on ADSL lines. As I see it, there is a general trend that more and more small and mid-size businesses uses ADSL lines for connectivity. Since IPv4 addresses are scarce, these businesses are often assigned IPv4 ranges smaller than /24 - many only get a /30 range. Nevertheless, they still operates servers for various purposes. The problem is that ISPs typically are very hesitant to administer reverse DNS for these addresses. Either these addresses have no reverse DNS at all, or they resolve to a semi-random host name (e.g. address aaa.bbb.ccc.ddd resolves to aaa.bbb.ccc.ddd.adsl.isp-name.com) If the ISP (or whoever administers reverse DNS for the /24 range) do not wish to help out, there is really nothing the end user can do. Apart from being _really_ annoying to the end user, it also undermines reverse DNS as such: It is already difficult to convince everybody to set up reverse DNS, but even if an end user wants to do it, it may not be possible for him. I am aware that it would take some work for RIPE NCC to force every ISP to properly administer reverse DNS, but there are several costless methods that would help a lot. Please consider these suggestions: a) Make it mandatory for ISPs to offer classless reverse delegation to end users with RIPE-assigned IP ranges (i.e. for PA IP ranges that has a inetnum object with an end user as admin-c). Even if this would not be actively enforced, it would be a great help to end users if they could point to an official RIPE policy on this. Even a web page saying that LIRs _should_ do so would be a help. b) Make it mandatory for ISPs to offer either classless delegation or reverse DNS at IP-level for all its assigned addresses. Again, if there are no ressources to enforce it, it would still help to make it official RIPE NCC policy. c) Extend the new reverse delegation system to include classless delegation of PA addresses. For this to work, it would probably be necessary to move master DNS for all split ranges to RIPE NCC, which of course would increase the load on RIPE NCC. Administration, on the other hand, could be fully automatised. There are probably many other ways, too. Anyhow, I would really like a solution to this. Sincerely, Jørgen E. Larsen CTO Elgaard Data jel(at)elgaard.net

1 0

Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 07 Jul '04

07 Jul '04

Hello, I wouldn't cross-post, but there seems to be nobody home over on the enum-wg list, and it is related to DNS ... /Niall Begin forwarded message: > From: Niall O'Reilly <niall.oreilly(a)ucd.ie> > Date: 7 July 2004 10:48:56 IST > To: enum-wg(a)ripe.net > Cc: Niall O'Reilly <niall.oreilly(a)ucd.ie> > Subject: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME > > Hello ENUMmers, > > I'm about to become responsible for a Tier-2 ENUM registry, part of > the Irish ENUM > Trial. I expect to use BIND as the name server platform for this > purpose. I have > supposed (perhaps naïvely) that the conventional delegation mechanism, > using NS > records in the parent zone, would be appropriate. This involves > creating a new > zone as each new telephone number is registered, and configuring the > zone specifically > on each of Tier-2 name servers. > > I'm not sure I really want to buy in to this level of per-number > provisioning > activity, and see apparently significant advantages in using the > technique of RFC2317 > (Classless IN-ADDR.ARPA delegation) to make life simpler. > > The advantages I see are the following. > > The Tier-1 zone file becomes smaller, with just one CNAME (or DNAME) > record per > delegation, rather than two or more NS records. > > At Tier 2, the named configuration file needs only per-server, rather > than per-number- > per-server provisioning activity, and propagation of newly-registered > numbers is driven > by NOTIFY rather than by reloading the updated configuration file on > each server. > > This looks like the way to go, but perhaps I'm missing something ? > > Best regards, > > Niall O'Reilly > UCD Computing Services

1 0

Deprecation of <auto-inaddr@ripe.net>
by Olaf M. Kolkman 05 Jul '04

05 Jul '04

Dear Colleagues, (Apologies for duplicate messages) Further to our message sent on April 26[1] we would like to inform you that we will discontinue use of the <auto-inaddr(a)ripe.net> e-mail interface for reverse delegation requests as of July 14, 2004. Starting from this date, any mail sent to <auto-inaddr(a)ripe.net> will receive an appropriate redirection message. Reverse delegation requests can only be submitted to the RIPE Whois Database by using the <auto-dbm(a)ripe.net> e-mail interface or by using one of the other update mechanisms such as web-updates[2]. For more information about the authentication mechanism, please see http://www.ripe.net/reverse -- Olaf Kolkman New Projects, RIPE NCC [1] Announcement: New Policy and Procedures for Reverse DNS Requests http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00024.html [2] Webupdates interface to the RIPE Whois Database. http://www.ripe.net/perl/webupdates.pl If you are reading this or related posts from the archive all occurrences of ripe.net in e-mail addresses have been replaced by localhost.

1 0