July 2004 - dns-wg - mailman.ripe.net

Re: [dns-wg] AAAA lookup misbehaviour
by David Malone 08 Sep '04

08 Sep '04

I hadn't planned on covering the sort of client side issues mentioned by Alvaro and Colm, but maybe I should consider it? I think I understand the issue mentioned by Colm, and would be interested in the details of Alvaro's problem. If people think it is a good idea to cover these problems, then I'll write some text. The only feedback that I've got so far is from Peter, and I've made the changes that he suggested. The last paragraph mentions trying to automatically nag someone regarding problem servers - I'm not sure if we should be advocating this or if we should be saying it is a bad idea. David. This document is a short description of problems with certain DNS systems that have come to light with the deployment of IPv6 enabled software. --- One of the services that DNS provides is a facility for mapping host names to IPv4 addresses. This is probably the most common used service that DNS provides, and is achieved requesting a record of type "A" for the host name. Records of type A can only store an IPv4 address, and so with the introduction of IPv6, a new record type, AAAA has been introduced. It is becoming increasingly common for software to first issue a request of type AAAA, and if no record of that type is found then to issue a request for a record of type A. A request for a record of type AAAA causes no problems for most DNS servers, however some DNS servers implementations have been found that have problems answering other queries. Some DNS implementations have problems will only new types, such as AAAA, and others have problems with any query not of type A. The technical details of these problems are explained in the IETF draft document draft-ietf-dnsop-misbehavior-against-aaaa-01.txt. In Q1 2004, a survey of nameservers for 24000 hostnames mentioned in web proxy logs found about 0.5--1% of name servers seem to have to have a problem of this nature. The end result of these issues is that connecting to a site using a problematic name server may be impossible, intermittent or significantly delayed. To prevent introducing more DNS servers with such issues, testing of new DNS equipment should include checking that the response for records is in accordance with the RFCs (in particular RFC 1035, RFC 3597 and the draft mentioned above). As DNS load balancing software has often fallen foul of these problems, particular care should be taken in testing and validating such systems. The fact that problematic nameservers exist is in itself a problem. Where these issues cause direct inconvenience, the maintainers of the server and the maintainers of the DNS data should be notified to allow a normal service to be restored. However, often it is difficult for end users to identify the source of these problems, (for example, where an image embedded in a web page being served from a host with a problem hostname). It is also possible to automatically produce lists of names and nameservers that exhibit these problems. Clearly it is possible to automatically mail hostmaters or to publish "hall of shame" lists based on such data. It is unclear if such actions would achieve any useful effect, as service maintainers are usually primarily concerned about complaints directly from paying users!

6 8

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 22 Jul '04

22 Jul '04

>>>>> "Joao" == Joao Damas <Joao_Damas(a)isc.org> writes: >> Have you forgotten the IPv6 migration issues that Johan Ihren >> and others have mentioned at previous WG meetings? Joao> No, I have discussed them with Johan on occasion. Does that Joao> mean we are to seat down and do nothing? No, of course not. Doing nothing is not an option. >> For instance, what will my IPv6 web browser do when lookups >> over IPv6 for www.google.com return only A records? Joao> What do you mean "your IPv6 web browser"? I would have thought this was obvious from the context: a browser running on some IPv6-only device or only had DNS transport over IPv6. Joao> Of course changes need to be done in a responsible way and I Joao> am taking personal offence if you would suggest that I would Joao> not follow that path. I made no such suggestion. [I said some TLDs might be pressured into doing IPv6 things before they were ready to do that. They may well be acting responsibly based on the limited resources and info they have available to them.] And anyway, how can you take personal offence? AFAIK, you're not personally responsible for any TLD AAAA glue or the contents of the root zone. Please note too that I'm not impugning those who do have that responsibility either. What I am saying is that making well-intentioned changes to critical DNS infrastructure may have unexpected consequences if the impact of those changes isn't fully understood. This applies to other horrors like DNSSEC deployment, not just these IPv6 issues. BTW, the IANA document which sparked this discussion talks about changing TLD delegations when there are "serious operational problems". Presumably these arise after the TLD and IANA have acted responsibly by applying some carefully considered (but not fully thought out?) change to the delegation. >> Finally, by encouraging the IPv6-only people to go off into >> their own little world, we fragment the internet and its name >> space. Joao> No, you just are not getting it. I am talking about Joao> enabling, you are talking about limiting. I'm doing no such thing. Though I may well not be "getting it". What we seem to be disagreeing about is tactics and strategy, not policy. ie We agree IPv6 has to be deployed in the DNS. Where we differ is in how to achieve that. You seem to be saying "just do it". I'm saying "let's first try to understand what we're getting ourselves into". IMO the internet today is too big and too important for the "just do it" approach that was possible 10 or more years ago. >> At the very least, it will mean some IPv6-ers are likely to >> develop a mindset that DNS migration to IPv6 is done and >> there's nothing more for them to do as far as IPv6 and the DNS >> is concerned. Joao> Since when has that been possible for any protocol that is Joao> used on the Internet? DNS, the protocol, keeps changing and Joao> adding new possibilities, just like most other Internet Joao> protocols. DNS protocol development has been stalled for years. But that's beside the point. Whenever something new comes along, care needs to be taken that it doesn't introduce interoperability problems or operational issues. [eg Sending resolvers into an infinite tight loop beating up root or TLD servers for the same non-existent names.] I'm sure we agree on this. What we're disagreeing about appears to be the extent that these potential problems have been analysed and documented. Perhaps an IPv6-only island on the internet would bring DNS problems for the rest of the net that the people in this island never see? Or care to fix? In a sense, this can be compared to the DSL users who have Windows boxes that get hijacked by spammers. The end user might not be aware of that, so can't/won't plug the holes that give rise to the operational problems. It's a bad analogy because someone will eventually blackhole the spammer and give an incentive for the end user to fix the problem. That sort of corrective mechanism might not be possible in an IPv6 only island that's pounding the life out of the world's name servers.

4 3

FYI: IANA delegation procedure for the root zone and ipv6 glue
by Andrei Robachevsky 22 Jul '04

22 Jul '04

Colleagues, The final version of the new IANA delegation data procedure is now on-line at http://www.iana.org/procedures/delegation-data.html. Regards, Andrei Robachevsky RIPE NCC

7 12

Re: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone
by geoff＠nominet.org.uk 22 Jul '04

22 Jul '04

Stephane Bortzmeyer <bortzmeyer(a)nic.fr> writes: > Do note that the IPv6 server of ".fr", requested in February 2003, is > still not announced. Maybe only coincidence: JPNIC = ccNSO member KRNIC = ccNSO member AFNIC = ccNSO non-member Regards Geoff

4 5

IPv6 glue AAAA RRs in the root zone
by Peter Koch 22 Jul '04

22 Jul '04

Haven't seen an announcement right here, so FYI: as of SOA# 2004072000 the following AAAA RRs (aka "IPv6 glue") are available from within the root zone: A.DNS.JP. AAAA 2001:DC4:0:0:0:0:0:1 D.DNS.JP. AAAA 2001:240:0:0:0:0:0:53 E.DNS.JP. AAAA 2001:200:0:1:0:0:0:4 F.DNS.JP. AAAA 2001:2F8:0:100:0:0:0:153 G.DNS.KR. AAAA 2001:DC5:A:0:0:0:0:1 -Peter

8 21

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 22 Jul '04

22 Jul '04

>>>>> "Joao" == Joao Damas <Joao_Damas(a)isc.org> writes: BN: cc list has been trimmed as everyone there is already on dns-wg(a)ripe.net >>> Well, what other choice is there? :-) And anyway, since the >>> overwhelming bulk of the world's name servers are IPv4-only, >>> resolution over IPv6 doesn't seem to be a particularly >>> productive exercise. >> True enough. Joao> True enough for what subset of users? If the a user is Joao> interested in only a few and those provide the service that Joao> user needs and uses, what does he/she care about a million Joao> servers out there? It's not that simple Joao. If only it could be that simple... Have you forgotten the IPv6 migration issues that Johan Ihren and others have mentioned at previous WG meetings? Some IPv6 users will drop DNS over IPv4 as soon as they see AAAAs for TLD name servers. Or, worse, for the root servers. They may not realise or understand that this will cut them off from most of the internet. Which you seem to be saying is fine. If all they're interested in is the IPv6 internet, let them just get access to that. I'd agree with that sentiment if we knew for sure we were talking about informed, knowledgeable users. But I'm not convinced that's the case. Even so this approach brings more problems. Firstly, it highlights the lack of a migration strategy for introducing DNS over IPv6. We still don't know what's going to break, how those failures will manifest themselves and what the consequences of that will be. Both for applications/resolvers and for name servers. For instance, what will my IPv6 web browser do when lookups over IPv6 for www.google.com return only A records? Or SERVFAIL? Second of all, a piecemeal introduction of AAAA glue could be destablising for the DNS and the internet. We just don't know either way, so we should proceed carefully with a good understanding of the consequences of these changes. Thirdly, this could also put pressure on other TLDs to add AAAA glue -- "because others are doing this" -- before they're ready to do so. Finally, by encouraging the IPv6-only people to go off into their own little world, we fragment the internet and its name space. At the very least, it will mean some IPv6-ers are likely to develop a mindset that DNS migration to IPv6 is done and there's nothing more for them to do as far as IPv6 and the DNS is concerned.

3 2

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 22 Jul '04

22 Jul '04

>>>>> "Jeroen" == Jeroen Massar <jeroen(a)unfix.org> writes: >> Wrong, several root name servers (of course, not ICANN's one) >> are reachable over IPv6: read http://www.root-servers.org/ >> and edit your db.root. Jeroen> I know those addresses and I also know that all of those Jeroen> boxes have a latency over at least 200ms and very odd Jeroen> routability and those are far far far from to be called Jeroen> production. This could be a good topic for presenting to the WG. Want to volunteer to write up a document and/or presentation on the state of IPv6 deployment in the root and TLD name servers, routing anomalies, etc, etc? It would be good to hear someone's first-hand experiences with this stuff: what went wrong, how it was worked around or solved, what could be done better, future directions. Personally, I don't see why you care about the RTT to a root server. A well-behaved name server will make 4-5 queries to a root server once a week or so. Why optimise that? Please note I'm not suggesting that it's OK for root servers to have lousy RTTs. My name server is in regular, frequent contact with other name servers that have RTTs longer than 200ms. Jeroen> One really doesn't want to use those, just to be able to Jeroen> say that one can use IPv6.... Well, what other choice is there? :-) And anyway, since the overwhelming bulk of the world's name servers are IPv4-only, resolution over IPv6 doesn't seem to be a particularly productive exercise. Jeroen> BTW that list is missing i.root-servers.org which is Jeroen> located in Sweden, but that is a testing address and Jeroen> routes over the US instead of staying inside Europe... Why does it matter where a root name server is physically located? Sorry, I should rephrase that: why does it matter where a route for a root name server gets announced? IMO a 200ms RTT over IPv6 has to be better than an infinite RTT.

6 7

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 21 Jul '04

21 Jul '04

>>>>> "Stephane" == Stephane Bortzmeyer <bortzmeyer(a)nic.fr> writes: >> Unless I completely mis-understood, but isn't that article >> talking about *root* servers and not GTLD servers, which Peter >> showed... Stephane> No, Peter was talking about root name servers I thought he was talking about the name servers for .jp. Which happen to be in the root zone that's served by the root servers.... no?

1 0

Reverse checker out-of-sync with RIPE-203
by Andre Oppermann 19 Jul '04

19 Jul '04

The reverse delegation checker on www.ripe.net seems to be out-of-sync with the recommended values in RIPE-203 (or vice-versa). For example RIPE-203 recommends 3600000 seconds (1000 hours = 5 weeks and something) for the SOA expire value. However if I actually put this into my zone file the checker at http://www.ripe.net/cgi-bin/nph-dc.cgi complains that this is too high and suggests a value between 2-4 weeks. Which is is right? One of these should be changed/corrected to resolve this discrepancy. PS: What are the current actual officially recommended SOA values for revese zones? -- Andre

2 1

Stale restricted IPv6 information at Verisign/IANA
by Bernhard Schmidt 16 Jul '04

16 Jul '04

Good evening, perhaps slightly off-topic, but nethertheless... I've been trying to readd an AAAA glue record to one of my nameservers in .net after the server moved from M"net space (2001:a60::/32) to TNIB (2001:1b18::/32). It worked before, after the move the registrar (dd24.net if anyone is curious) could not add the appropriate record: | [COMMAND] | command=ModifyNameserver | delipaddress0=212.90.120.82 | addipaddress0=81.92.162.8 | delipaddress1=2001:a60:9000:1000::1:11 | addipaddress1=2001:1B18:202:FFFF::53:1:1 | nameserver=auth01.dns.mucip.net | EOF | [RESPONSE] | code = 535 | description = Restricted IP address a quick query of the registrar at Verisign GRS resulted in Verisign claiming | The IPv6 you were trying to add is currently in a restricted range by | IANA. | | The IP 2001:1B18:202:FFFF::53:1:1 falls into the below restricted | range. | | 2001:1A00:: 2001:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF Well, 1b18 is slightly older than a60, so I decided to give Verisign a small hint that their list is out of date. Verisign although claims | WE are currently following the restricted v6 IP list which is mandated | by IANA and is current. | | We recommend that you contact IANA directly in regards to your matter. I tried to contact/blame IANA but I haven't received any reply so far. Anyone having an idea who the culprit is in this game? Bernhard

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: Niall> IMHO such registry systems are not suited to the ENUM Niall> business, and a T1 which takes this approach is unlikely to Niall> be winning many tenders for national infrastructure. Of Niall> course, that depends on the clue-level available to the Niall> local awarding agency. Niall> I'm happy to say that, here in +353-land, our trial T1 is Niall> taking a more helpful approach. Good. The key thing here is you have a trial. So you can try different delegation approaches and see what works and what doesn't. And aside from the DNS mechanics, you can consider things like the impact of a particular approach on interfaces, roles & responsibilities as well as stuff like competition policy and the public interest. IMO it's far more important to learn about these things than focus on which name server(s) some zone sits on.

2 1

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

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

draft minutes from RIPE 48 DNS WG sessions
by Peter Koch 04 Jul '04

04 Jul '04

Dear all, please find below the draft minutes for our RIPE 48 sessions. Thanks to Timur Bakeyev and Alessandro Bassi from the RIPE NCC for being the scribes. Please read these minutes and send in any necessary corrections either to the list or, if minor, to the chairs at dns-wg-chair(a)ripe.net. We plan to have the minutes taken to the wg's files by July, 25th. There's also an action items list at http://www.ripe.net/ripe/wg/dns/action-list.html -Peter ======================================================== RIPE Meeting: 48 Working Group: DNS Working Group Status: 2nd Draft Revision Number: 3 * content to the Chair of the working group. * format to webmaster(a)ripe.net. ======================================================== DNS Working Group, Session 1 (DRAFT) RIPE 48 Amsterdam Date: Tuesday, 4 May 2004 Time: 16:00 - 17:30 Location: Grand Ballroom Chair: Jim Reid Scribe: Timur Bakeyev, RIPE NCC - Administrivia. Introduction Session is going to be Web casted as well as reflected in Jabber. Request to participants to hold their question till the end of presentation. Thanks to Nominet, who sponsored the chair of this group. Swap of the presentations: Instead of "DNSSEC forum" by Suzanne Woolf -> "DNS an MCI, another type of large DNS server" by Andre Koopal. - "Proposed new charter", Peter Koch http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-charter.… The DNS Working Group discusses current DNS related issues in technology and operations. The WG encourages deployment of DNS and DNS-related protocol components by collecting experience and documenting current practice and recommendations. It therefore provides a mechanism for exchanging practical and operational experience with organizations like CENTR and the IETF. The WG discusses DNS software implementations, especially security and scalability aspects as well as performance and interoperability considerations. DNS quality and other factors that may affect the stability of the DNS system are also discussed by the WG. The DNS WG provides a forum for the Registry and Registrar community. It discusses the technical and operational issues arising from registration policies with a specific focus on the deployment of new and emerging features. Charter was approved by the meeting. - "CENTR news", Kim Davies; CENTR http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-centr.pdf - "Implementation of the BACK ORDER service", Andrzej Bartosiewicz; NASK http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-backorde… This will be launched on 1st June, 2004. System of options - similar to stock exchange options. - "EPP implementation", Patrycja Wegrzynowicz; NASK http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-backorde… XML based Extensive Provision Protocol Q: Can you explain the slide: Registrar buys option for the Registrant. What are the terms used? A: Registrar is the agent of Registrant. Q: (Jim) What is the reaction of the customers on the new schema and how Registrars like it? A: As for Registrants, they hardly even notice the change. It's more attractive to the Registrars. They are quite happy :) - "Deploying IDNs in the .no domain", Jarle Greipsland; NorID. http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idns-no.… Q: (Jaap) What do you exactly register in your forms - UNICODE, Punycode or just US encoding? A: When register you have to fill out both in the forms. On update you can supply any of them. Q: And what is your Whois server accepts? A: It is either US-ASCII, ISO-Latin1 or UTF8. Q: And the input for the request? A: US-ASCII or Latin1 by default, but you can supply switch to use UTF8. Q: (Carsten) Speaking about legal terms - what is registration contract about? Is it about IDN in UTF8 or in Punycode? A: Both versions are on contract. Q: So, the contract actually is about bundle of two names? A: Yes, both names are defined there(Get two for the price of one:) - "IDN deployment in Germany", Marcos Sanz; DENIC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idn-de.p… Q: (Peter) That binary queries, you talked about - did you take a look onto second level labels or all the labels? A: All the labels(of course in .de) Q: And for those queries your DNS server received - did you try to cross check whether that binary, UTF, Latin1 names, what ever you found there - were that names actually registered within .de? A: I didn't do it systematically, but yes, most of them there registered? Q: Question remains, what names where queried before they have chance to be registered? A: Random words, general terms... In the last week we saw, that people mostly tried to reach that MAY exist on their opinion. - ".info support for German script", Desiree Miloshevic; Afilias http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idn-laun… Q: There have been reports, that there is a project to make IDN available without software upgrade? A: That was misinterpretation of our announces in the press. C: (Jaap) Charset names, used for IDNs should be standardized, possibly through the IANA or other Internet official bodies... - "DNS at MCI", Andre Koopal; MCI http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-mci.pdf Q: (Peter) You are acting as a secondary for customers. What happens when primary(at your customer) disappears? That should lead to the lame delegations and query storms... A: We do remove them from the configs after certain amount of time. No special actions are taken against query storms, though. C: (Jaap) You've said, that you don't use Bind 9 for NL TLD, because it's too picky about the standards. But that's the goal - to enforce standards for those lame delegations! Q: (Olaf) Are you sure that Bind 9 doesn't accept '/' in the domain names? A: Not really, maybe some other quite popular symbol, but the problem exists.. Q: (Jim) Are you making efforts to move to Bind 9? A: Not right now, at least. C: (Peter) there is clearly problem with disappearing customers for DNS integrity. Registrars refuse to remove them on ISPs requests. What can be done in such situation? What is the common practice? Would it be OK to make it an action point for WG? R: (Jim) That's a good idea! Peter, you've just volunteered to bring in to the DNS WG :) [ACTION 48.1] on Peter Koch: Collect experience with lameness problems, initiate BCP style document and wishlist for support by TLD registries. ======================================================== DNS Working Group, Session 2 (DRAFT) RIPE 48 Amsterdam Date: Thursday, 6 May 2004 Time: 9:00 - 12:30, Location: St. Johns II Chair: Peter Koch (09:00 - 10:30), Jim Reid (11:00 - 12:30) Scribe: Alessandro Bassi, RIPE NCC - "IETF Reports", Sam Weiler; TIS Labs http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-ietf.pdf Last IETF was held in Seoul, apparently was quite "boring". Next meeting in August, in San Diego. DNS discovery for IPv6: a summary comparing the alternatives must be done before august, otherwise the item will be removed. DNSOP: business as usual, several drafts in progress, several ones stopped or in stand by. DNSEXT: 9 open drafts DNSSEC: No recent problems. It has to be noted that there are no major protocol issues in the last year DNSEXT: most milestones are advanced to draft standards. There is an RFC 3597 interoprability testing coordinated by Jakob Schlyter Mailing list: https://www.rfc.se/mailman/listinfo/interop3597 or interop3597-request(a)rfc.se - "K-Root operations update", Dave Knight; RIPE NCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-kroot-up… Status: Global instances are in London and A'dam. Recently two more secondary have been installed in Frankfurt and Athens. Web site has been renewed completely, and a stats page has been added. More stats will come in the near future. The current query load is 7000 queries/second. Of these, the great majority is directed to London and Amsterdam. Future plans: - to have 4 more instances of primary servers, two in the US and two in Asia. - to deploy IPv6. Q: (Jim) Has any traffic analysis been done? Are the Greeks using the Athens server? A: Those kind of stats will be available in a couple of months. - "Reverse DNS status report", Olaf Kolkman; RIPE NCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-rdns-upd… New reverse DNS, for more fine-grain control, multiple interfaces, and simplification of policies. Today, because of the current policies, there might be inconsistencies and confusion. Policies will change drastically. Status: the cleanup (prerequisite) was made the first week of April. April 26, the new interface and new policy were put live. Marvin will die the 1st of July. the DNSSEC implementation has been deferred. In the new policy, there is no need for assignment (as before), and anybody authorized can do the Rev DNS. Another change is mnt-by, which becomes mandatory. When submitting the request, points will be added for warnings and errors; over a certain limit, the request will be rejected. Q: (Jim) Any plans to introduce TSIG ... A: No plans Q: Do people care about it? Why not? A: (Peter): Zone transfer restrictions are useless anyway for most zones. Restrictions can be IP based. [ACTION 48.2] An action item was created on Mans Nilsson to write up a proposal for the use of TSIG for zone transfers, when ns.ripe.net acts as a secondary. [ACTION 48.3] Olaf Kolkman was kindly asked to send to the list a pointer to the predelegation checks currently applied and to initiate review of those checks and, if necessary, propose changes. - "DNS-MODA", Jim Reid http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-moda.pdf There is a growing frustration with the IETF process, something different is needed. Something similar to what W3C is, so a W3C for DNS, no profit, impartial. MODA will not be a standards-making body, or introduce proprietary solutions, but will work with IETF to improve the current procedures. Q: (Geoff Huston) This is alien to what IETF does. IETF also hates Intellectual Rights problems, and being considered like a rubber stamp to somebody else's solution, especially if it's half-baked ideas. IETF must discuss things. A: The idea is to speed things up, not to have IETF as rubber stamp body. The work that comes out of MODA will be well-thought out and shouldn't be half-baked. Q: (Geoff Huston) IETF has a bad record in working with industry. IETF task is to work on new things; the risk is exacerbating problems and making alliances outside. Q: (Patrik) W3C is not a good example. For instance, let's take HTTP (IETF) and XML (W3C), there were lots of problems not to make the same thing twice and work on the same issues. Also, what is the decision making process of MODA? It is not clear at the moment. A: True enough: those processes will be determined by the membership. Q: (Rob Blokzijl) I agree in what Patrick just said, In IETF there's an open, unconditional participation. MODA is more like a closed Club. MODA is needed, but it's a bad idea to throw out the free participation. some re-thinking is needed. Q: (Patrik Faltstrom) If there is a need for MODA, then IETF does not work. You have to say it clearly. A: we are trying to to be collaborative and cooperative, not seeking confrontation. . Q: (Rob Blokzijl) There is no logo yet? And, what is the IETF reaction to this idea? A: The important thing was to announce MODA at this meeting and so start the efforts to recruit members. The web site and logo will come later. Discussions have been held with the IETF about MODA for some time. While there's been no formal response yet, the signs are good. Though both parties will need to see how things work out in practice. - "DNS AAAA measurements: How many sites have problems with IPv6",David Malone; CNRI http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-malone.p… Q: (Jim) Delegation -> capture the info and document it. Write a document about how to avoid config problems. [ACTION 48.4]: David agreed to write a document about this for the WG to consider. - "6over4 reverse Delegation",Geoff Huston; ICANN http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-sixxto4.… Individual draft submitted. Keith Moore submitted also some work in the past, with ideas ranging from reasonable to bizarre. Q: (Bernard Tuy) which kind of draft did you submit? A: Individual submission. Not against all the work that has already been done, but there has been a request to the reverse delegation community to do some more work on it. - "Reverse delegation in ip6.int", Andrei Robachevsky; RIPE NCCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-reverse-… Q: (Peter) You suggested to remove ip6.int delegation. What is the current load? A: around 3 queries per minute. == BREAK == - "ISC News", Joao Damas; ISC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-isc.pdf Advancement on Bind 9.3 Q: (Bernard Tuy) What does OARC mean? A: Operation Analysis Research Centre. Q: (Jim) What is the timescale for the release of 9.3? Does it depend on IETF work on DNSSEC? A: No, it does not. It will probably be next week. NLNet update - "DNSSEC forum",Suzanne Woolf; ISC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-dnssec-r… DNSSEC specs are done, but deployment is less formal and less well documented. There are problems in deployment. Privacy issues also still have to be tackled. Q: (Peter Koch) You mentioned a discussion of zone walking, which may be considered a deployment obstacle. Any solutions? A: Not yet. We are identifying issues but we don't know how serious they are and what needs to be done. A: (Olaf Kolkman) A protocol change at this point would mean that we'll be back to the drawing board. Changing the protocol would mean a delay of one year. There is no obvious solution in sight. - "Query load variation on ccTLD servers during delegation phases", Mans Nilsson; KTH http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-f2f.pdf Problems, delay introduced because of IANA. Q: (Doug Barton) First, some good news, we are working on v6; the board meeting in May will discuss it. About the delay, when was the request submitted? A: Well, not yet submitted Q: Then I accept your apologies for not blaming IANA to be late when no request have been submitted. Normally it takes 2 days. - "DNS Survey",Peter Koch; Universitaet Bielefeld http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-survey.p… Looking into the .de; Bind 8 by number has only 30%, but 60% by delegation, and 72% by weighted delegation. Q: (Jim) Why lots of people are still running Bind 8? A: Not really lots. Some of them are very large providers. There is a concern about load. Also, Bind until version 9.2 has a protocol problem, fixed with 9.3; so maybe, in the near future figures will change. - AOB Patrik Faltstrom is standing down as DNS WG co-chair. He will probably have some role in the ENUM WG that is expected to be formed. Jim thanked Patrik for his efforts in the DNS WG. He said that since this created a vacancy for a co-chair, he invited anyone who was interested in becoming a co-chair to get in touch. ========================================================

1 0

AAAA lookup misbehaviour
by David Malone 03 Jul '04

03 Jul '04

At the last RIPE meeting I was given an action item: Write up a draft RIPE document summarizing the observations made regarding AAAA resolution problems. Circulate to the list, initiate discussion what to, i.e. whom to approach with the list of errors/problems seen. I checked with Peter, and he says the documents are pretty freeform, so I've written a few paragraphs, included below. David This document is a short description of problems with certain DNS systems that have come to light with the deployment of IPv6 enabled software. --- One of the services that DNS provides is a facility for mapping host names to IPv4 addresses. This is probably the most common used service that DNS provides, and is achieved requesting a record of type "A" for the host name. Records of type A can only store an IPv4 address, and so with the introduction of IPv6, a new record type, AAAA has been introduced. It is becoming increasingly common for software to first issue a request of type AAAA, and if no record of that type is found then to issue a request for a record of type A. A request for a record of type AAAA causes no problems for most DNS servers, however some DNS servers have been found that have problems answering queries not of type A. The technical details of these problems are explained in the IETF draft document draft-ietf-dnsop-misbehavior-against-aaaa-01.txt. In 2004, about 0.5--1% of name servers seem to have to have a problem of this nature. The end result of these issues is that connecting to a site using a problematic name server may be impossible, intermittent or significantly delayed. To prevent introducing more DNS servers with such issues, testing of new DNS equipment should include checking that the response for records is in accordance with the RFCs. As DNS load balancing software has often fallen foul of these problems, particular care should be taken in testing and validating such systems. The fact that problematic nameservers exist is in itself a problem. Where these issues cause direct inconvenience, the maintainers of the server and the maintainers of the DNS data should be notified to allow a normal service to be restored. However, often it is difficult for end users to identify the source of these problems, (for example, where an image embedded in a web page being served from a host with a problem hostname). It is also possible to automatically produce lists of names and nameservers that exhibit these problems. Clearly it is possible to automatically mail hostmaters or to publish "hall of shame" lists based on such data. It is unclear if such actions would achieve any useful effect, as service maintainers are usually primarily concerned about complaints directly from paying users!

3 2