- dns-wg - mailman.ripe.net

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 01 May '02

01 May '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

DNSSEC Course, Prague October 8, 2001
by Olaf Kolkman 15 Aug '01

15 Aug '01

DNSSEC Course Final Announcement This mail was already sent to both the lir and the techsec-wg mailing list. We forgot to include the most obvious target group: dns-wg. Excuse us for possible receipt of multiple copies. The RIPE NCC will be organising a DNSSEC course The course will be held in Prague on the Monday after the RIPE Meeting, October 8: 9 am to 5 pm. The goal of the course is familiarise the participants with DNSSEC so they can maintain their own secured zone and to identify current difficulties in deployment and possible future directions. To be able to run the program in a day we expect the participants + being able to administer DNS zone files with bind; + to bring their own dummy zone to experiment with; + to bring a laptop running the latest version of bind; + being able to patch bind software if needed; About a week before the course, you will receive a homework assignment. This will take about an hour to complete and has to be done in advance, so that during the course little time will be wasted on configuration issues. The course will consists of two parts: an introduction to DNSSEC and a hands-on part. The hands-on part will cover: + securing zone transfers using TSIG + generating zone keys and signing zones + securing 'corporate' sites with DNSSEC + establishing a chain of trust + key-exchange and rollover The RIPE NCC does not charge for this course but the amount of participants will be limited to 25 persons. If the interest in the course exceeds the number of available places a selection will be made based on first come first serve basis and by limiting the amount of participants from one affiliation. To register please fill in the form below and mail it to disi-ws(a)ripe.net, use subject header: "[DNSSEC RIPE40] Registration". Please, do not reply to the mailinglists. Finally, the RIPE NCC plans to repeat this course on a regular basis in 2002, so if your application for this event is rejected, there will be ample opportunities to take the course at a later time. --Olaf Kolkman RIPE NCC, DISI project http://www.ripe.net/disi - - - - - - - - - - - - ---cut here--- - - - - - - - - - - - - - - --------------------DNSSEC Course Registration Form.--------------- I hereby register for the DNSSEC course in Prague on October 8, 9am-5pm. Name : E-mail : Affiliation : Job title : Street Address : City : Could you shortly describe why you are interested in participating in this course and what you hope to learn? Your registration will be confirmed within 2 work days after it was received. Since the amount of participants is limited you might be put on a waiting list. ----------------------------------------------------------------------

1 0

WG: Update, NGtrans - DNSext joint meeting, call for participation
by Thomas Trede 24 Jul '01

24 Jul '01

FYI: I think this might also be important for the DNS-WG of RIPE. Regards, Thomas Trede -----Ursprungliche Nachricht----- Von: owner-ipng(a)sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Alain Durand Gesendet: Freitag, 20. Juli 2001 22:24 An: ngtrans(a)sunroof.eng.sun.com; namedroppers(a)ops.ietf.org; ipng(a)sunroof.eng.sun.com; dnsop(a)cafax.se Cc: randy(a)psg.com; tony(a)tndh.net; fink(a)es.net; Olafur Gudmundsson Betreff: Update, NGtrans - DNSext joint meeting, call for participation Correction on the previous announcement: The NGtrans/DNSext chairs would like to make a call for participation in the upcoming joint meeting. The goal of the meeting is to facilitate consensus on how IPv6 addresses are represented in DNS and related issues. This meeting requires extensive homework by participants and the chairs would like to request submission of documents for a reading list for this meeting. The output from the meeting will be draft consensus proposal. Here is non exclusive a list of relevant topics: 1 - Design tradeoffs in DNS and IPv6 (AAAA, A6, DNAME, bit string) - DNS operational considerations including DNSSEC costs in regard of address record format - DNS implementation complications due to address record format - IPv6 Remembering requirements and impact on address record format - Case for A6 - Case for AAAA - transition from ip6.int to ip6.arpa - transition from AAAA to A6 2 - tools/protocols/strategies to bridge IPv6 and IPv4 DNS resolution Anybody wishing to make a presentation should send a draft to the chairs of this meeting before July 26th 2001, 21:00 UTC (that is, 2pm PDT, 5pm EDT, 11pm MEST) - Randy Bush <randy(a)psg.com> - Alain Durand <alain.durand(a)sun.com> - Bob Fink <fink(a)es.net> - Olafur Gudmundsson <ogud(a)ogud.com> - Tony Hain <tony(a)tndh.net> Drafts not yet published by the ID editor are acceptable contributions (please include an URL). The chairs will review the list of submission, derived the actual agenda of the meeting from it and send all reading materials to the DNSext and NGtrans mailing list no later than July 27th, 21:00 UTC. The format of the meeting is going to be: - Short summary of the discussion points from the documents - Technical discussion on the relevance of the points - Technical discussion on the points from documents as measured by Rob Austein's document draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt - Brainstorming on the best way to go forward - Straw polls leading to consensus building on a plan of action - the chairs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo(a)sunroof.eng.sun.com --------------------------------------------------------------------

1 0

Fwd: IN-ADDR.ARPA Progress Report
by Joao Luis Silva Damas 02 Jul '01

02 Jul '01

Dear all, here I forward an announcement from ARIN regarding current progress in the maintainance of the in-addr.arpa zone. Best regards, Joao Damas RIPE NCC >From: ARIN IN-ADDR Role <inaddr(a)arin.net> >Subject: IN-ADDR.ARPA Progress Report >Message-ID: <Pine.SOL.4.05.10106291525050.10191-100000(a)ops.arin.net> > >Goal: > >Reduce the size of the IN-ADDR.ARPA zone file. This file will be reduced >in size by only containing name servers for /8 networks. > > >Completed Steps: > >Apr 2001 - Established relationships with 2 companies to provide >independent server networks for all ARIN IN-ADDR zone files. > >Jun 2001 - Released a new IN-ADDR.ARPA zone file generator to correct >existing erroneous data. > > >Next Step: > >July 9, 2001 - ARIN will begin revising the IN-ADDR.ARPA zone for those >direct /8 delegations to ARIN. These /8 zone files will be serviced by >the two ARIN nameserver networks. These changes will not affect the >performance of reverse lookup in any of the IPv4 Address space. > >Please direct any questions to inaddr(a)arin.net. > > >Ginny Listman >Director of Engineering >American Registry for Internet Numbers --

1 0

Permission to use/adapt RIPE document 192?
by Brad Knowles 21 Jun '01

21 Jun '01

Folks, I've recently found out about the document at <ftp://ftp.ripe.net/ripe/docs/ripe-192.txt>. I also happen to be in the process of writing a chapter on the DNS for an upcoming book. Can anyone tell me what the RIPE approval process is that I need to go through in order to be able to make use of some of the configuration file and zone file information contained within this page (making some modifications of my own)? Thanks! -- Brad Knowles, <brad.knowles(a)skynet.be> /* efdtt.c Author: Charles M. Hannum <root(a)ihack.net> */ /* Represented as 1045 digit prime number by Phil Carmody */ /* Prime as DNS cname chain by Roy Arends and Walter Belgers */ /* */ /* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */ /* where title-key = "153 2 8 105 225" or other similar 5-byte key */ dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'

1 0