- dns-wg - mailman.ripe.net

Re: [dns-wg] IPv6 in .ie
by Jim Reid 09 Sep '04

09 Sep '04

>>>>> "Daniel" == Daniel Karrenberg <daniel.karrenberg(a)ripe.net> writes: Daniel> If I was IANA I would advise .ie strongly to rationalise Daniel> the names in their glue to save space. Yeah. Somebody needs to write up a draft on this as a BCP: using efficient label compression to avoid truncated responses.

5 5

RIPE 48 Action Item.
by Olaf M. Kolkman 09 Sep '04

09 Sep '04

Dear Colleagues, This is a small report on an action item that is upon us. Action 48.X [Olaf Kolkman] Send to the mailinglist [a pointer to] the current list of checks applied to IN-ADDR.ARPA zones before reverse delegation is activated or updated. Initiate review of those checks and propose, if necessary, updates and/or additional tests. The reverse delegation "HOWTO" [1] refers to a web page[2] that can perform the delegation checks that our database update engine performs. That web-based delegation checker comes with an explanation of the most important checks[3]. We think that for the purpose of further discussion of the delegation checks the explanation in [3] is sufficient. However because of a library version mismatch the documentation in [3] may sometimes differ from what is actually verified during WHOIS Database updates. We will be working on updating the web based delegation checker to use the same back-end library and during that process update and audit the documentation. If you have any question regarding details we'll be happy to answer them. Kind regards, Olaf M. Kolkman New Projects, RIPE NCC [1] http://www.ripe.net/reverse/reverse_howto.html The explanation on how to request a reverse delegation [2] http://www.ripe.net/cgi-bin/nph-dc.cgi The web-based zone delegation checker [3] http://www.ripe.net/misc/dc-ext-descr.html

1 0

Document to discuss for RIPE 49
by Fernando Garcia 09 Sep '04

09 Sep '04

Hello all After some years, I restarted an old proposal I made in a RIPE meeting and finally I'm finishing it. Is a document with the title "Planning the migration of a group of servers and associated DNS from an IP range to other" and I have asked for a timeslot in the DNS working group in RIPE 49 to discuss it. The idea is to have it as a operational best practices document to help network administrators to migrate a network without DNS problems (blackouts, lost of control, etc.) I expect to have a draft finished along the weekend and will post it (or a link to it, is a big document, about 90 K size) to the list. In the meantime, here is the table of contents so you can post questions, ideas and flames to the list or to me: 1 Index 2 Abstract 3 Unordered migration 3.1 Resolving without data in the cache 3.2 Resolving with out of date NIC information 3.3 Request with the DNS server in the cache 3.4 Request with the solicited server in the cache 3.4.1 Request to the secondary server 4 Causes 4.1 Change the domain from one ISP to other 4.2 Change the IP addressing of the ISP 5 Priority definition 5.1 Avoid the blackout of the domain 5.2 Avoid the pollution of DNS cache with incorrect information 6 Requirements 6.1 Control over the new DNS server 6.2 Authorized contact in the NIC 6.3 Minimal DNS knowledge 6.4 Plan in advance, two weeks minimum 6.5 Independent and duplicated DNS servers 6.6 If possible, duplicate the other servers 6.7 Coordination between ISP 7 Scenario 7.1 Starting situation 7.2 Ending situation 7.3 Limitations 8 Mechanism 8.1 Change of DNS servers 8.2 Change of other servers 8.3 Insert standard values in the SOA 8.4 Development 9 Detailed procedure 9.1 Create a new DNS server in the new DNS address range 9.1.1 Duplicate the existing information of this domain 9.1.2 Modify the server own address 9.1.3 Reduce the SOA times 9.2Check the new server 9.3 Modify the primary server information in the NIC 9.4 Modify the external secondaries 9.5 Verify the secondaries 9.6 Wait for the changes to propagate 9.7 Modify the address of the other servers 9.7.1 Time and space impact 9.7.2 Duplicate the servers 9.7.3 Move the servers 9.7.4 Duplicate IP addresses 9.7.5 Service implication 9.7.6 Modify “IN A” and “IN PTR” fields 9.8 Wait the propagation 9.9 Deactivate services in the old address range 10 Resumed procedure 11 Special situations 11.1 Traumatical change of provider 11.1.1 Help from a third party 11.1.2 Steps Appendix A.Glosary Appendix B.SOA values Appendix C.ES-NIC form example Appendix D.References Regards, Fernando -- ------------------------------------------------------------------------ ------ Fernando Garcia - fgarcia(a)eurocomercial.es Eurocomercial Informática y Comunicaciones 91 435 96 87 ------------------------------------------------------------------------ ------

1 0

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

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