- dns-wg - mailman.ripe.net

New Document available: RIPE-244
by RIPE NCC Document Announcement Service 05 Jul '02

05 Jul '02

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-244 Title: Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region Author: Joao Luis Silva Damas, Leo Vegoda Date: 4 July 2002 Format: PS=13515 TXT=4723 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the policy for reverse delegation of IPv4 assignments and allocations in the RIPE NCC service region. Accessing the RIPE document store --------------------------------- You can access the "Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region" in HTML format at the following URL: http://www.ripe.net/ripe/docs/rev-del.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-244.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-244.txt plain text version

2 1

ANNOUNCEMENT DNSSEC Course, introduction to the concept and current state
by Henk Uijterwaal (RIPE-NCC) 27 Jun '02

27 Jun '02

* * * Announcement * * * DNSSEC, introduction to the concept and current state Date: Saturday 14 September 2002 Time: 0900 - 1700 Location: Rhodos, Greece AND Date: Tuesday 22 October 2002 Time: 0900 - 1700 Location: Sarajevo, Bosnia AND Date: Thursday 28 November 2002 Time: 0900 - 1700 Location: Paris, France AND Date: Thursday 12 December 2002 Time: 0900 - 1700 Location: Amsterdam, The Netherlands The Domain Name System (DNS) is one of the main parts of the Internet Infrastructure. DNS is trusted by the end-users to is trusted by many end-users to give correct results. At the moment, however, DNS lacks a mechanism to establish the authenticity and integrity of the data it provides. DNSSEC is a set of extensions to provide end-to-end authenticity and integrity. This introduction will cover. - DNS security threads; - DNSSEC security mechanisms; + DNSSEC server protection; + DNSSEC data protection; - Delegation issues; - Key management issues; - Current developments; The DNSSEC introduction is intended for those who are familiar with common DNS terminology and are interested in learning about the concepts and mechanisms that DNSSEC offers. Our goal is to provide participants with sufficient background to be able to deploy DNSSEC in their own organization. Examples are based on the BIND name server. More information about the details of the DNSSEC Introduction can be found at: http://www.ripe.net/disi/ Kind regards, Sandra Gijzen RIPE NCC Training Co-Ordinator REGISTRATION ============ To register for these Courses, please complete the registration form below and reply to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add a value in the `box' area marked between the square brackets (i.e. "[" and "]" ). Alternatively, you can use the Training Course Request Form at: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions about the DNSSEC Introduction, your registration form or the web page, please contact us at <training(a)ripe.net>. --------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The Course you plan to attend (date and location) # COURSE [ ] %END

1 0

DNS WG @ RIPE 42: draft minutes available
by Peter Koch 13 May '02

13 May '02

Folks, the draft minutes of our working group meeting in Amsterdam are now available: http://www/ripe/wg/dns/r42-minutes.html Thanks to Olaf and Daniel for their work. Please send comments and remarks to <dns-wg-chair(a)ripe.net>. Also, some of the presentations can be accessed via http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/index.html#… Anyone else who gave a presentation is invited to send a pointer to the above address. -Peter

1 0

Draft on using SRV records to locate whois servers
by Jim Reid 02 May '02

02 May '02

Below is a draft of the document Gerhard, Linus and Marcos have been working on. It's been circulated to the list for discussion. Marcos will be giving a presentation on this at the WG meeting next week. Please submit any comments to the authors or, better still, to the mailing list. draft-whois-srv-01.txt Linus Corin Marcos Sanz Gerhard Winkler 24 April 2002 Using DNS SRV records to locate whois servers Status of this Memo This document is a draft on the usage of the DNS SRV RR for the location of whois servers. Abstract There is no common whois database where all domain objects are stored. Several TLDs run their own databases, which can be reached under different network locations and, for the user, there is no easy way to find the right whois server to answer their query by means of a simple whois client. This situation can be improved by using DNS SRV records and SRV-cognizant whois clients. 0. Definitions The key words "MUST", "SHOULD", and "RECOMMENDED" in this document are to be interpreted as described in [RFC 2119]. Other terms used in this document are defined in the DNS specification, [RFC 1034]. 1. Format The general format of DNS SRV records is documented in RFC 2782: _Service._Proto.Name TTL Class SRV Priority Weight Port Target Therefore the simplest format of an SRV record to locate a whois server is: _whois._tcp IN SRV 0 0 43 whois.nic.example. [RFC 1700] foresees the possibility of a whois service over UDP. Common use is TCP but nothing would prevent from analogously setting the _Proto field to the value _udp. The symbolic name of the service is defined as "whois" (case insensitive), which is the most familiar name, though it is also called "nicname" in [RFC 954]. Priority and Weight have a value of 0 in the example above just for readability purposes. It is RECOMMENDED to use the port number 43, as specified in [RFC 1700] or [IANA-NUM]. 2. Usage If there is a whois server running for a specific domain, such an SRV record can be defined. When used for looking up information about a domain, whois clients can do DNS lookups for SRV records, and can use the retrieved target information to point their whois queries accordingly. This kind of client is called "SRV-cognizant" or "SRV-aware" whois client. It is imaginable that this functionality could be extended for other purposes (like inetnum or handle lookup), but this remains open for a future discussion. 3. Restrictions The service record functionality is meant as an extension to the existing whois service and not as a new service. In the absence of a whois protocol whose specification calls for the use of other weighting information, the field Weight in the SRV record keeps the standard meaning specified in [RFC 2782]. As defined in [RFC 2782] the client SHOULD abort if it finds a record defined like: _whois._tcp IN SRV 0 0 0 . The given SRV record is valid for the zone where it appears. This means that it does not provide any information on subdomains or zones below; it is a onelevel information. Search for subdomains MUST behave like conventional DNS search algorithms. 4. Authority There is no authority which defines who should run a whois server, though it is usual that the TLD registry runs a whois service for the zone where it is authoritative. There is no definition of which target should be used as a default for an SRV-cognizant whois client if no whois server could be discovered by means of SRV records. The use of a default whois server is local dependent. 5. Security Considerations The same security considerations as defined in [RFC 2782] should apply. There is no discussion on security, data protection and privacy relating to the contents of the whois server in this paper. This is the responsibility of the whois server operator and has nothing to do with a mechanism that describes how whois servers can be reached. 6. References [RFC 954] NICNAME/WHOIS [RFC 1034] Domain names - concepts and facilities [RFC 1700] Assigned Numbers [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels [RFC 2782] A DNS RR for specifying the location of services (DNS SRV) [IANA-NUM] www.iana.org: Directory of General Assigned Numbers 7. Authors' Addresses Linus Corin Telia International Carrier 4th Floor, 330 High Holborn WC1V 7QY London, United Kingdom linus(a)telia.net Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt/Main, Germany sanz(a)denic.de Gerhard Winkler Vienna University Computer Center / NIC.AT Universitaetsstrasse 7 A-1100 Vienna, Austria gerhard.winkler(a)univie.ac.at

5 7

Re: Re: Draft on using SRV records to locate whois servers
by Marcos Sanz/Denic 01 May '02

01 May '02

James, thanks for your feedback. > Without SRV records, if I wish to use whois to talk to a server named > whois.isp.net I should lookup the A record of whois.isp.net and > contact that host. > > With SRV I should lookup the SRV of _whois._tcp.whois.isp.net and > contact the host specified by the A record owned by the SRV target. Let's say that isp.net (gosh, they really exist) do not know about RFC2219 and run their whois service under the alias foobar.isp.net. How should an SRV-cognizant whois client ever come to the idea of looking up an SRV of the form "_whois._tcp.blafasel.isp.net"? This is precisely the problem that we want to get rid of and with that interpretation of RFC2782 we are reintroducing it again. > Secondly, I feel a reminder that the target of an SRV must have an A RR > is in order. Taking my isp.net example, above, again. If I controlled > customer.com and wanted to use the mechanism in this draft to publish > the fact that customer.com is in isp.net's whois server I cannot use: > > _whois._tcp.customer.com. IN SRV 10 0 43 whois.isp.net. > > as ``whois.isp.net'' does not have an A RR. I must ``undo'' the > name indirection desired by isp.net and instead publish the following > RRs (and keep them up to date): Right, the reminder about the A RR is in order. On the other hand, this way of "undoing the indirection" and trying to keep it up to date is not very practical. Does somebody have any ideas on that? > referred to as ``wacky mode'' - no offence is intended :-) If anybody > wants to play with it, it's at > > http://romana.now.ie/software/srv-whois I really must be wacky, I cannot find it! :-P Regards, Marcos

2 1

Re: Re: Draft on using SRV records to locate whois servers
by Marcos Sanz/Denic 30 Apr '02

30 Apr '02

Thanks for your feedback, Peter. Find comments below. On 28.04.2002 15:11 Peter Koch <pk(a)TechFak.Uni-Bielefeld.DE> wrote: > Here's a rough version of a longer problem statement: Nice ellaboration! We will incorporate it (maybe partially) in the next version. > The Regional Internet Registries (RIR) [reference, anyone?] also provide whois We already searched for references on that, but did not found any. > service as part of their coordination task. Again, there is no easy uniform way > to find out which RIR is responsible for a particular address or address range. We explicitly left out such kind of remarks, since we wanted to limit the draft to locating Whois servers for domain lookups. We are already collecting ideas for an extension draft about recommended behaviour of SRV-cognizant whois clients and remarks are very welcome. > > 1. Format [...] > > [RFC 1700] foresees the possibility of a whois service over UDP. Common > > use is TCP but nothing would prevent from analogously setting the _Proto > > field to the value _udp. > > RFC 1700 has been superseded by RFC 3232, so I'd suggest to cite either that Overseen that, thanks. We will fix it for the next version. > The document should clearly say that it deals with the > TCP case only. We thought we should just leave it open. Any other opinions on that? > > The symbolic name of the service is defined as "whois" (case > > insensitive), which is the most familiar name, though it is also called > > "nicname" in [RFC 954]. > > So, did one want to allow both? I'd stick with "whois", unless there is > demand to not only select the service based on the on-the-wire protocol > but also based on the data format (e.g. "ripe-whois" vs. "generic-whois"). > However, I doubt that this granularity would ease deployment. We stick with "whois", as well. One could even think of selecting the service based on the type of data to be queried ("contact-whois", "domain-whois", ?) as Gerhard once observed, but as you say, it is a compromise between hype features and ease of deployment. > > It is RECOMMENDED to use the port number 43, as specified in [RFC 1700] > > or [IANA-NUM]. > > The document mainly talks about client behaviour, so this recommendation > regarding the server's port number seems a bit out of focus to me. > And, it's not needed for interoperability since one purpose of SRV RRs is > giving an administrator the opportunity of using non default ports. If you want client-server interoperability for the "thing" we call "protocol whois" nowadays, you SHOULD set the port to 43. Any other value would be correctly handled by SRV-cognizant clients, but those servers would not be reachable by conventional clients. > > If there is a whois server running for a specific domain, such an SRV > > record can be defined. When used for looking up information about a > > domain, whois clients can do DNS lookups for SRV records, and can use > > the retrieved target information to point their whois queries > > accordingly. This kind of client is called "SRV-cognizant" or > > "SRV-aware" whois client. > > So, does this mean the SRV RR has to be owned by the domain you are interested > in or by its parent? See below for a suggestion of a hierarchical approach. Actually, there might be SRV RRs at several levels, and the loose formulation tries on purpose not to address the issue at that point. > > As defined in [RFC 2782] the client SHOULD abort if it finds a record > > defined like: > > > > _whois._tcp IN SRV 0 0 0 . > > While this copies the definition from RFC 2782, I do not think the client is > expected to abort (i.e. terminate) should this condition be met. Instead, > only the SRV processing is aborted. I would even add: the SRV processing should be aborted _at that level_. Nothing avoids for the client to search for SRV above (or under) that level. But we thought such refinements were out of scope at that moment and were an issue for another draft, as already mentioned. > > The given SRV record is valid for the zone where it appears. This means > > that it does not provide any information on subdomains or zones below; > > This may result in a contradiction: If it's valid for the zone, it is > also valid for subdomains of the zone apex. And, it costs additional > work to find out which zone one actually resides in. And does this mean > _whois._tcp.DE leads to a whois server which has no knwledge about > Uni-Bielefeld.DE (subdomain and delegated zone in this case)? The formulation is indeed missleading. What about: "The SRV record does not provide any information about the existence/absence of a service with the same name on subdomains or zones below". > > it is a onelevel information. Search for subdomains MUST behave like > > conventional DNS search algorithms. > > "conventional" algorithms depend on local search lists, while here you want > searching along the domain name subject to the later whois query. > In addition, conventional DNS search should not extend beyond domain names > within local control (from the queriers point of view) [RFC 1535], while > that is what you explicitly want here. > However, it still could be abused (see security considerations). I think this is a wording problem, as well. I will leave it to Gerhard, since he authored that line. > I'd think the search is the key feature in locating the whois server and > an algorithm should be described, e.g. That is a possible procedure. We take note. > Question remains what to ask the whois server. If a match is found for > _whois._tcp.example, should the server be asked for the full name > www.deep.weird.example or just the smallest suffix needed for differentiation > ("weird.example")? Not asking for the full name could result in delivering an answer for a question that was not asked. > Are all whois servers capable of "closest match"? No > And how to deal with the fact that whois servers have no standardized way to > indicate they do not know a key queried for. Once the server has been reached by means of SRV, contents transmitted are not relevant the process. > This scheme could be extended to cover inetnum lookups (only the IPv4 case is > outlined here): [...] > Opinions? Fine! > > There is no definition of which target should be used as a default for > > an SRV-cognizant whois client if no whois server could be discovered by > > means of SRV records. The use of a default whois server is local > > dependent. > > In the absence of an appropriate SRV entry, the client MAY try > "whois".<domain> (see RFC 2219); Thanks for the reference, we'll take a look at it. > Use of the DNS search algorithm can lead to 2 problems: > 1) By using DNS query logging an organisation could find out who is issuing > whois queries about them even without operating a whois server themselves > 2) An (malicious) organisation could use SRV RRs to misdirect whois requests. > For example, a spamhaus using "spamhaus.example" could direct whois > queries to their own whois server containing no or false information or > even worse, innocent targets. For this reason, whois clients should be > able to start the search above the leaf or particular inner nodes upon > request. Both are real good points. They directly depend upon the behaviour of the SRV client, which is not determined here (top to bottom? bottom to top? stop walking the tree after answer?). Nevertheless, I think 1) finds a place in our draft, as a direct effect of the interaction between Whois and DNS. Regards, Marcos

1 0

Question: resolution of private IP addresses
by Greg Cipollone 17 Jan '02

17 Jan '02

Dear all, I have a simple question regarding the resolution of hostnames with private IP addresses. One of our corporate customers would like to (mis)use DNS to allow the resolution of intranet hosts. The customer operates its own global VPN but for operational reasons cannot install / manage local DNS it each and every of its locations. Also, the customer does not want to operate a centralised intranet DNS service as the Internet connectivity, which is local in each country, in some of its remote locations would be severely affected (as DNS requests would take inordinate amount of time). I have tried to research this but could not find anything that would be prevent the resolution to private IP addresses. The main concern is that ISP's would filter out their DNS cache to prevent this. Any comments? Best regards, Greg Cipollone Technischer Direktor *************************************************************** Twinwave Intranet und Internet Services GmbH Schmidtstr. 51, 60326 Frankfurt Tel.: +49-69-75 086-0, Fax: +49-69-75 086-555 E-Mail: g.cipollone(a)twinwave.net Web-Seite: http://www.twinwave.net ***************************************************************

3 2

RE: Question: resolution of private IP addresses
by van Eijk, Peter (NL - Diemen) 17 Jan '02

17 Jan '02

I remember researching this too, and remember that we actually put a 10/8 address in the public DNS. AFAIK it is not considered good practice. I also remember a comment by one of my colleagues that the typical VPN software should also be able to handle this issue. Once you have a secure tunnel into your corporate network, you should be able to use the (single) DNS on your intranet. Peter van Eijk, Deloitte & Touche Bakkenist, Network Strategy & Architecture, tel: +31 6 53515927, www.van-eyk.net/pve, pvaneijk(a)deloitte.nl, pve(a)van-eyk.net > -----Original Message----- > From: owner-dns-wg(a)ripe.net [mailto:owner-dns-wg@ripe.net]On Behalf Of > Greg Cipollone > Sent: 16 January 2002 15:23 > To: dns-wg(a)ripe.net > Subject: Question: resolution of private IP addresses > > > Dear all, > > I have a simple question regarding the resolution of > hostnames with private > IP addresses. > > One of our corporate customers would like to (mis)use DNS to allow the > resolution of intranet hosts. The customer operates its own > global VPN but > for operational reasons cannot install / manage local DNS it > each and every > of its locations. Also, the customer does not want to operate > a centralised > intranet DNS service as the Internet connectivity, which is > local in each > country, in some of its remote locations would be severely > affected (as DNS > requests would take inordinate amount of time). > > I have tried to research this but could not find anything > that would be > prevent the resolution to private IP addresses. The main > concern is that > ISP's would filter out their DNS cache to prevent this. > > Any comments? > > Best regards, > > Greg Cipollone > Technischer Direktor > > > *************************************************************** > Twinwave Intranet und Internet Services GmbH > Schmidtstr. 51, 60326 Frankfurt > Tel.: +49-69-75 086-0, Fax: +49-69-75 086-555 > E-Mail: g.cipollone(a)twinwave.net > Web-Seite: http://www.twinwave.net > *************************************************************** > > This e-mail message and its attachments are subject to the disclaimer published at the following website of Deloitte & Touche : http://www.deloitte.nl/disclaimer <http://www.deloitte.nl/index.asp?Pageid=010109135051734>

1 0

host tool used for RIPE hostcounts
by Olafur Osvaldsson 27 Nov '01

27 Nov '01

Hi, As I understand, you made the host tool I'm referring to. We've been using the host tool from ftp.ripe.net for the hostcounts since I don't remember when but noticed some strange behaviour this month. We got a bunch of these errors: *** incomplete resource record for ppp129-110.islandssimi.is, offset 8186 ;; response truncated to 8192 bytes ;; got answer, 23618 bytes: ;; ns_initparse: Message too long *** expand error in resource record for islandssimi.is, offset 8186 After some diging it looks like this only happens when transfering from nameservers with version 9 of bind, wich seems to be sending the whole transfer at once instead of sending one RR at a time like bind 8 does. I've fixed this by patching host.h and set the MAXPACKET size to what I think is the maximum in bind 9. There is probably a better solution to this but this atleast makes things work correctly for now. I've Cc'd this to the dns-wg(a)ripe.net as there are probably alot of people there geting into the same trouble. Oli -- Olafur Osvaldsson Systems Administrator Internet Iceland inc. Tel: +354 525-5291 Email: oli(a)isnic.is

3 2

DNSSEC course material
by Olaf Kolkman 30 Oct '01

30 Oct '01

Dear colleagues, Excuse me for duplicate mails. The material used for the RIPE 40 DNSSEC course is now on-line. It can be found at http://www.ripe.net/disi/ . --Olaf Kolkman --------------------------------------------------------------------- Olaf M. Kolkman | RIPE NCC DISI Project ----------- | --------------- ---------------- RIPE NCC | Phone: +31 20 535 4444 | Singel 258 | Fax: +31 20 535 4445 | 1016 AB Amsterdam | http://www.ripe.net/disi | The Netherlands | OKolkman(a)ripe.net |

1 0