- dns-wg - mailman.ripe.net

IPv6 in .ie
by Billy Glynn 08 Sep '04

08 Sep '04

Hi, FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new IPv6 compatible name server ns6.iedr.ie. Additionally, we have added AAAA glue for one of our slaves ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Kind regards -- ________________________________ Billy Glynn Network Operations Centre IE Domain Registry Ltd Tel: +353 (0)1 2365404 Mobile: +353 (0)87 9188317 billy.glynn(a)domainregistry.ie ________________________________

6 6

Re: [ipv6-wg@ripe.net] Re: [dns-wg] IPv6 in .ie
by Daniel Karrenberg 07 Sep '04

07 Sep '04

On 07.09 11:46, Iljitsch van Beijnum wrote: > > So then nothing stands in the way of adding AAAA glue records to the > root? Nothing other than the fact that the root is considered special by many and our collective processes are careful with changes to it. Some of this actually has rechnical rationale. I'll just name two examples: 1) The root servers are already the most loaded servers for any zone. 2) There are concerns that buggy resolvers may behave badly and aggrevate 1) above. So some more testing will have to be done and then the collective processes will have to run their course..... . Daniel

1 0

Re: Reverse DNS at the Host Level?
by Jim Reid 23 Aug '04

23 Aug '04

>>>>> "Stephane" == Stephane Bortzmeyer <bortzmeyer(a)nic.fr> writes: >> For instance many mail servers won't accept SMTP sessions from >> hosts with no reverse DNS: it's usually a strong indication of >> a spam source. Stephane> Let me rewrite this properly: Stephane> For instance some mail servers won't accept SMTP Stephane> sessions from hosts with no reverse DNS (they often Stephane> believe it will limit the amount of spam received). Let me rewrite your rewrite properly: :-) For instance some mail servers won't accept SMTP sessions from hosts with no reverse DNS. This is a common anti-spam measure because a significant amount of spam is known to come from hosts that do not have reverse DNS entries.

1 0

Re: [dns-wg] Reverse DNS at the Host Level?
by Jim Reid 23 Aug '04

23 Aug '04

>>>>> "Chris" == Chris Hallam <challam(a)sdl.com> writes: Chris> As an LIR, we have reverse DNS entries in the RIPE database Chris> for all of our ranges at the x.x.x.in-addr.arpa level, but Chris> I was wondering if it was possible to create an entry at Chris> the host level for a specific IP address? Of course. That is the whole point of reverse delegations under in-addr.arpa. You really should populate those zones with PTR records for the active IP addresses. As you seem to have found out the hard way, some things won't work as expected when reverse DNS doesn't work. :-) For instance many mail servers won't accept SMTP sessions from hosts with no reverse DNS: it's usually a strong indication of a spam source. Chris> We have an issue where mail from one of our mail servers Chris> may be being blocked due to host level reverse IP lookups Chris> failing. You didn't give any information that would have helped someone to help you, like the IP address of the mail server or the appropriate LIR assignment for that IP address. Once an LIR has been given an assignment, it should fill in the reverse delegation templates and send them to the RIR. Once they've been checked, the RIR will delegate the corresponding reverse DNS zones to the LIR. They can then be populated by the LIR (or perhaps by its customers) so that reverse lookups of their IP addresses work. That's the broad picture. For more detail, you would need to provide more information. But probably not in this list... Looking at the headers on your posting, it appears to be there's a problem with reverse lookups of 221.249.105.84. Is this the address of the mail server that you're talking about? The reverse name for this IP address is 84.105.249.221.in-addr.arpa. This is a CNAME pointing at 84.80/29.105.249.221.in-addr.arpa. The 105.249.221.in-addr.arpa zone delegates 80/29.105.249.221.in-addr.arpa to ns0-s.dns.pipex.net and ns1-s.dns.pipex.net. Neither of these name servers knows about the 80/29.105.249.221.in-addr.arpa zone. So if it's this address that's causing you trouble, you need to take it up with the administrators of 80/29.105.249.221.in-addr.arpa and 105.249.221.in-addr.arpa. There's a disconnect between them. Either the parent has delegated the child to the wrong name servers or has done that to the child name servers (ns[01]-s.dns.pipex.net) without them being configured to serve 80/29.105.249.221.in-addr.arpa. Once that's sorted out, a PTR record for 84.80/29.105.249.221.in-addr.arpa will be needed. Or I suppose you could just get the CNAME for 84.105.249.221.in-addr.arpa replaced with an appropriate PTR and not bother with this RFC2317-style reverse delegation. Please note that in general this list doesn't discuss specific DNS operational problems or provide tutorials on how to configure name servers and set up zone files. They tend to be handled in somewhere like bind-users(a)isc.org. Followup questions about your mail server's broken reverse DNS entry might be better of going there. This list tends to be used for DNS policy issues -- especially those concerning RIPE and the RIPE NCC membership, the production of BCPs, WG administrivia, etc, etc. The WG charter suggests the sort of discussions that would be appropriate to this list.

3 2

Reverse DNS at the Host Level?
by Chris Hallam 20 Aug '04

20 Aug '04

Hello, As an LIR, we have reverse DNS entries in the RIPE database for all of our ranges at the x.x.x.in-addr.arpa level, but I was wondering if it was possible to create an entry at the host level for a specific IP address? We have an issue where mail from one of our mail servers may be being blocked due to host level reverse IP lookups failing. Any thoughts or advise would be appreciated. Chris Hallam Regional IT Manager - Asia SDL Japan Kabushiki Kaisha Meguro Higashiyama Building 4th Floor 1-4-4 Higashiyama, Meguro Ku Tokyo, 153-0043 エス・ディー・エル・ジャパン株式会社 153-0043 東京都目黒区東山 1-4-4 目黒東山ビル 4階 challam(a)sdl.com <mailto:challam@sdl.com> Telephone 00 81 (0)3 5720 2873 Fax 00 81 (0)3 5720 2592 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. **********************************************************************

1 0

agenda items for RIPE49
by Jim Reid 05 Aug '04

05 Aug '04

It's that time of year again.... The next RIPE meeting is 6 weeks away (more or less). So I'd like to invite contributions and suggestions for agenda items for the WG. Please reply to dns-wg-chair(a)ripe.net by Sept 6th. We usually get the agenda finalised 2 weeks before the WG, so it may not be possible to include items received after that date. Your WG co-chairs will try to accommodate last-minute additions, though it makes our job easier if this doesn't have to be done. Thanks.

1 0

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