- dns-wg - mailman.ripe.net

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Jim Reid 15 Jul '04

15 Jul '04

>>>>> "Niall" == Niall O'Reilly <Niall.oReilly(a)ucd.ie> writes: Niall> OTOH, there's a balance to be struck between allowing Niall> people to be responsible for their own mistakes and Niall> engaging in the diminishing-returns game of protecting them Niall> from everything. Indeed. And in this case, sharp instruments need to be kept well away from the children. That means avoiding some of the obvious rat-holes when it comes to DNS administration. Note too Niall that lots of ISPs can't get RFC2317-style delegation right and these are the guys who should have DNS skills as a core competency. Niall> If registrars or T2 registries can't do their job, how long Niall> will they stay in business ? Long enough to kill off ENUM by making it seem less robust and dependable than it could be? Consumer confidence is going to be critical for ENUM to become widely used. Cheap calls over VoIP may get everyone's attention. But if DNS lookups fail and phones don't ring reliably, nobody's going to use it.

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Jim Reid 15 Jul '04

15 Jul '04

>>>>> "Niall" == Niall O'Reilly <Niall.oReilly(a)ucd.ie> writes: >> You lose the granularity of control and the flexibility to let >> customers manage their delegations. I'm presuming you plan to >> have all your numbers CNAME'd into a single zone file rather >> than discrete zone files for each zone. Niall> I see it quite the other way around: you _gain_ Niall> flexibility. Is the glass half-empty or half-full? It depends on where you look from. Niall> The customer has a single point of administration for Niall> announcing the delegation and changes thereto. Once the Niall> CNAME has aged out from resolver caches, there is no trace Niall> left of obsolete data in the 'golden tree'. If the T2 Niall> provider which the customer has just deserted delays (or Niall> neglects) removing the relevant RRsets, so what ? With NS, Niall> on the other hand, you have to make sure that all the Niall> obsolete data on still authoritative servers is eliminated. Niall, I don't understand what you're saying. Perhaps you could explain your envisaged scheme with some examples: ie what's in zone files. You're now talking about T2 provider. From your earlier posting I'm confused if this is a registry, DNS provider, registrar (or some combination of these) and what RR/zone data they may hold and manipulate. So please, draw me an idiot-proof picture. The roles and interfaces you're outlining seem rather fuzzy. Niall> Are you saying that the opportunity for restrictive Niall> practices is significantly different according to which Niall> method you choose for implementing delegation ? YES! It's not just about how delegation gets implemented. The roles and responsibilities in that process matter too. This is why the UK ENUM Group factored out the DNS Provider as a distinct role in its overall ENUM architecture. [Read its 2002 report.] That meant DNS content and service wasn't necessarily under the control of a registrar, ISP or application service provider. This is a very important distinction IMO. We also envisaged a market for different levels of DNS service. Some might be happy with a no-guarantees free service, while others want something super-robust with 24x7 support, anycasting, DNSSEC and so on. Your CNAME scheme could make it harder to establish that market. Suppose my number is delegated from the T1 registry with a CNAME to some zone of yours. You have the trust relationship with the T1. I have a trust relationship with you. In this scenario, the T1 doesn't know or care about me. So they won't change the CNAME if I asked them to do this. That won't happen unless you tell them. And if we've had a falling out, you're not likely to make that hassle-free. Now suppose you're a telco and I'm a customer wanting to switch to another telco. Or I want to shift my mail URIs from the telco's mail server to say hotmail. Does this help clarify the context now? >> For something like a DDI block for an organisation, this >> shouldn't be an issue. But if it was for all numbers in the >> Dublin area code (say), there would be a problem. Niall> How is this different between the NS and CNAME Niall> implementations ? It's not about that. It's about what can be put in the zone and how that's done. If all the numbers in one block are "delegated" -- for some loose definition of that term -- to a single zone file, there will be less flexibility and granularity of control over the zone's contents. I have to use whatever tools you've provided and onlyaccess ENUM services you'll let me add to the zone for that number. This is tolerable for a number block under one authority where common rules and policy can be enforced -- say the DDI block for an employer. But for the general case, this isn't acceptable. The entity holding that zone file shouldn't be allowed to restrict what NAPTR records exist for my number. Or my neighbour's. For maximum flexibility and fine-grained granularity of control (plus making sure delegations carefully follow the national numbering plan), the T1 registry should delegate individual numbers to discrete zone files that are notionally controlled by the owner of that number. Introducing CNAMEs will add a layer of indirection. [A needless one IMO.] That could mean boundaries of responsibility get blurred and/or more complicated. Which could give an unscrupulous provider enough wiggle room for unsavoury practices.

1 0

Re: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue
by Jim Reid 15 Jul '04

15 Jul '04

>>>>> "Roy" == Roy Arends <roy(a)dnss.ec> writes: Roy> Your wild guess is wrong, there are no queries possible that Roy> exceeds > 512 udp size. A QNAME has a maximum length of 255. IIUC, there is nothing in the DNS protocol which limits the Question Section to one QNAME/QTYPE/CLASS tuple. QDCOUNT can be > 1. Though I suppose some could argue that a request which contained > 1 query was unreasonable. [ISTR BIND will reject these with a FORMERR.] And if we consider DDNS requests to be queries -- which in some sense they are -- these can easily be bigger than 512 bytes. Just throw in a few prerequisites and a handful of additions and deletions in the one DDNS transaction. Besides I think the original context of "unreasonable queries" was really about queries which were unreasonable because of the responses they'd provoke, not the size of the queries themselves. ie In the absence of EDNS0 the server is forced to send truncated replies, causing TCP retries. Come to think of it, a discussion of query size is somewhat academic. If a query is going to be more than 512 bytes, the client will have to either use TCP or EDNS0 to send it to the server.

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Jim Reid 15 Jul '04

15 Jul '04

>>>>> "Niall" == Niall O'Reilly <Niall.oReilly(a)ucd.ie> writes: >> 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. Actually I think it will make life harder. 2317-style delegation is trickier to set up and maintain than conventional delegation. >> 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. So what? Is disk space and RAM expensive? The T1 registry is going to be storing so much data about its registrations -- tech & admin contact details, billing info, authentication/validation tokens, whois tags, registrar data, etc, etc -- that shaving off a couple of resource records would be lost in the noise. For the T1, adding CNAMEs instead of conventional delegations might well be an unwanted complication: ie it requires changes and on-going support to the registry database and back-end scripts and tools. IIUC some registry systems only handle the RRs needed for conventional delegation: NS records and related glue. >> 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. You lose the granularity of control and the flexibility to let customers manage their delegations. I'm presuming you plan to have all your numbers CNAME'd into a single zone file rather than discrete zone files for each zone. This might also get you into trouble with the competition authorities because the people using these CNAME'd numbers are locked in to your way of doing things. For something like a DDI block for an organisation, this shouldn't be an issue. But if it was for all numbers in the Dublin area code (say), there would be a problem. Registrants won't have the freedom to choose and switch DNS providers. Or decouple DNS hosting from the ISP/registrar they use to get their ENUM delegation. Using some sort of CNAME/DNAME trickery may limit your options for the future. ie It imposes a certain way of working or mindset that seems reasonable today. But it may not be the case in a year or so. And then all sorts of silliness happens as the original CNAME/DNAME model gets perverted to support the then prevailing orthodoxy. How often have we met bizarre DNS setups that have been inherited from an earlier DNS administrator who kludged a configuration and then kept tweaking it instead of doing the job properly? >> This looks like the way to go, but perhaps I'm missing >> something ? Using CNAME trickery for ENUM is unwise. It opens the door to all sorts of evils, like the accommodation of alternate trees. And it will make DNSSEC deployment (hah!) much harder because the parent can't secure any delegations with DS records because there are no proper delegations. DNAME is even worse because there are plenty of name servers and resolvers out there that don't understand this RR. It's not impossible that some applications will get upset if they get CNAME-like referrals to their lookups when they only expected to get NAPTR RRs or conventional referrals. For instance think of someone who writes a minimal ENUM-aware resolver as a Java applet for their mobile phone. Another problem -- which won't apply to someone clueful like you -- is that the introduction of CNAMEs increases the likelihood of looping or very long CNAME chains. Or dangling CNAMEs that point at nothing. Even without these administrative errors, the introduction of CNAMEs will complicate ENUM lookups and could mean they take too long. This would be somewhat annoying when someone picks up their ENUM-aware phone, dials a number and then waits for an eternity while the resolver chases down umpteen CNAME chains before making a phone ring. IMO it's best not to give people access to that much rope to hang themselves.

3 5

Re: [dns-wg] Last Warning: Termination of <auto-inaddr@ripe.net>
by Jim Reid 14 Jul '04

14 Jul '04

>>>>> "Olaf" == Olaf M Kolkman <olaf(a)ripe.net> writes: Olaf> As announced previously (e.g. [1]), we will discontinue the Olaf> use of the <auto-inaddr(a)ripe.net> e-mail interface for Olaf> reverse delegation requests as of tomorrow (July 15, 2004). Olaf> From tomorrow, all mails sent to this address will be Olaf> returned to sender. I hope the bounce message tells the sender what email address they should have used or points them at a web page that gives this info.

1 0

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