- dns-wg - mailman.ripe.net

ETSI ENUM Plugtest Announcement
by Jim Reid 08 Apr '05

08 Apr '05

I'm forwarding the announcement below on behalf of the ETSI Plugtest Secretariat. Any questions about the event should be sent to the address below. Apologies to those of you who've already seen this in the ENUM WG or IETF mailing lists. Dear All, We are pleased to invite you to the ENUM interoperability event, 30th May to 3rd June 2005 at ETSI Headquarters, Sophia Antipolis, France. The emerging technology of ENUM is attracting a lot of interest. By mapping telephone numbers to domain names, and from those to URLs, ENUM will be a key driver for the increasing convergence between the internet and telephony worlds. The ETSI ENUM Plugtests event will provide a vendor-neutral setting for equipment manufacturers, operators, ISPs, registries, software companies and system integrators to carry out controlled interoperability and conformance testing. It is a chance to discover ENUM system behaviour with misconfigured clients, servers, and intermediaries, so that they can explore the symptoms of such problems before their customers. For further details and to register, please visit our web site at the following URL: http://www.etsi.org/plugtests/ENUM.htm, the registration deadline is 16th May 2005. Please, show your interest by registering as soon as possible, but payment is not due before 23rd May 2005. Upon registration, you will be provided with ETSI's preferential rates for hotels and car rental. This invitation is open to anyone who may be interested so please feel free to forward it. To promote, boost or expand your image and products a wide range of sponsorship opportunities are available at: http://www.etsi.org/plugtests/sponsorus.htm We are looking forward to welcoming you in the South of France. Best regards, ETSI Plugtests TM Service Email: plugtests(a)etsi.org

1 0

IPv6 access to K-root
by Andrei Robachevsky 28 Feb '05

28 Feb '05

Colleagues, K-root server has now IPv6 transport enabled. k.root-servers.net. AAAA 2001:7fd::1 A 193.0.14.129 This information is also available from www.root-servers.org webiste. Regards, Andrei Robachevsky RIPE NCC

10 17

Re: ORSN-SERVERS.NET
by Markus Grundmann/ORSN 25 Jan '05

25 Jan '05

>In total 76 instances of a root-server of which are 25 in the >EU, 26 in the US, and 50 outside EU/US. >And this network is growing and growing I'm very happy about this posting ;-) 76 copies of an single database source managed by an organization outside from europe and controlled by the U.S. DOC. Great! When it comes the master corrupt all AnyCast servers will use this information. Very great and very stable! ORSN is an DNS system with all the same information provided by ICANN. The difference: We have our own managed and independent database!!! In few days you will found an tool to compare the ORSN database with the ICANN root servers in realtime on our homepage. Some people wrote (not here): "ORSN is not transparently enough!" Sorry! But I must laughing about this words. We do provide all needed information for interested users. Peoples must read our homepage carefully before any can write this. Notice: The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany

10 13

nameserve in root servers
by Wycliffe Bahati 13 Jan '05

13 Jan '05

Dear all I got one of my nameservers registered as an ip address in the root servers. I have since changed provider. The problem is that this IP is still stuck in the root servers. I am not sure how to go about this as most servers are being referenced to my old ip address for dns. Rgds ./bahati

3 4

nameserve in root servers
by Daniel Diaz 12 Jan '05

12 Jan '05

Dear Wycliffe, (sorry for the last incomplete mail). As Janos explains, this has nothing to do with root-servers. In any case could be with the g-tld servers serving your parent zone (i.e. ".com", [a-m].gtld-servers.net.) I´ve just found this (see below) querying for "kla1" IP address, although this shouldn´t be the problem as kla1 is not auth., for "afsat.com."): ; <<>> DiG 8.3 <<>> @62.128.168.70 kla1.afsat.com <....> ;; ANSWER SECTION: kla1.afsat.com. 1d7h50m59s IN A 62.128.174.1 <...> as you see "kla1.afsat.com" replies that "kla1.afsat.com. has IP 62.128.174.1." any of your auth servers replies correctly with IN A 62.128.168.70. Querying any other dns server somehow gets 62.128.174.1. maybe wrong values used on SOA (i.e. too long and out-of-date data is still cached all around). I´ve also seen other little things like not including IN A RR for ns2 in the dar1.afsat.com.´s zone file for afsat.com. Hope this helps. My 2 cents. ; <<>> DiG 8.3 <<>> @62.128.168.70 kla1.afsat.com ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; kla1.afsat.com, type = A, class = IN ;; ANSWER SECTION: kla1.afsat.com. 1d7h50m59s IN A 62.128.174.1 ;; AUTHORITY SECTION: afsat.com. 7h51m7s IN NS dar1.afsat.com. afsat.com. 7h51m7s IN NS ns2.lightband.com. ;; ADDITIONAL SECTION: dar1.afsat.com. 23h52m43s IN A 213.185.122.131 ns2.lightband.com. 1d7h50m59s IN A 199.79.199.2 ;; Total query time: 1354 msec ;; FROM: nh to SERVER: 62.128.168.70 62.128.168.70 ;; WHEN: Wed Jan 12 09:46:08 2005 ;; MSG SIZE sent: 32 rcvd: 127 -- daniel.diaz -- Daniel Díaz SATEC - Valencia http://www.satec.es C/. San Vicente Martir nº90,4ª planta 46007 Valencia Mov.+34 600 990 335 Tel.+34 96 394 0076 Fax.+34 96 353 6730

1 0

Re: [dns-wg] nameserve in root servers
by Janos Zsako 12 Jan '05

12 Jan '05

> From dns-wg-admin(a)ripe.net Wed Jan 12 09:11:33 2005 Dear Wycliffe, > my probem is with a particular server kla1.afsat.com. If you check the > root server have an ip address 62.128.174.1. It is now 62.128.168.70 > so my problem is changing this there First of all, you are probably talking about _GTLD_ servers, not _root_ servers. There is no trace of kla1.afsat.com in the root servers, as far as I can tell. At the same time, kla1.afsat.com does not appear to be a glue in gtld-servers either. I see as glue: dar1.afsat.com. 172800 IN A 213.185.122.131 ns2.lightband.com. 172800 IN A 199.79.199.2 only. Please find below the full reply to the queries I used. Did I miss something? Best regards, Janos > > wycliffe > On Wed, 2005-01-12 at 11:03, Peter Koch wrote: > > Hello, > > > > > servers. I have since changed provider. The problem is that this IP is > > > still stuck in the root servers. I am not sure how to go about this as > > > most servers are being referenced to my old ip address for dns. > > > > you are talking about addresses in root servers and about 'changing providers', > > which leaves ample room for speculation what the problem really is. > > Could you please tell us the name and address of said name server and one of > > the zones actually served by it? > > > > Thanks, > > Peter $ host -d kla1.afsat.com k.root-servers.net ;; res_mkquery(0, kla1.afsat.com, 1, 1) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20538 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; kla1.afsat.com, type = A, class = IN ;; Querying server (# 1) udp address = 193.0.14.129 ;; got answer, 504 bytes: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20538 ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 13, Addit: 14 ;; QUESTIONS: ;; kla1.afsat.com, type = A, class = IN ;; AUTHORITY RECORDS: com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; ADDITIONAL RECORDS: a.gtld-servers.net. 172800 IN A 192.5.6.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 g.gtld-servers.net. 172800 IN A 192.42.93.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 d.gtld-servers.net. 172800 IN A 192.31.80.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 ;; Query failed, 0 answers, status: no error kla1.afsat.com A record currently not present at k.root-servers.net $ host -d kla1.afsat.com a.gtld-servers.net ;; res_mkquery(0, kla1.afsat.com, 1, 1) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20539 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; kla1.afsat.com, type = A, class = IN ;; Querying server (# 1) udp address = 192.5.6.30 ;; got answer, 127 bytes: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20539 ;; flags: qr rd; Ques: 1, Ans: 1, Auth: 2, Addit: 2 ;; QUESTIONS: ;; kla1.afsat.com, type = A, class = IN ;; ANSWERS: kla1.afsat.com. 172800 IN A 62.128.174.1 ;; AUTHORITY RECORDS: afsat.com. 172800 IN NS dar1.afsat.com. afsat.com. 172800 IN NS ns2.lightband.com. ;; ADDITIONAL RECORDS: dar1.afsat.com. 172800 IN A 213.185.122.131 ns2.lightband.com. 172800 IN A 199.79.199.2 ;; Query done, 1 answer, status: no error kla1.afsat.com A 62.128.174.1 $ host -d -a afsat.com a.gtld-servers.net ;; res_mkquery(0, afsat.com, 1, 255) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20543 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; afsat.com, type = ANY, class = IN ;; Querying server (# 1) udp address = 192.5.6.30 ;; got answer, 134 bytes: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20543 ;; flags: qr rd; Ques: 1, Ans: 2, Auth: 2, Addit: 2 ;; QUESTIONS: ;; afsat.com, type = ANY, class = IN ;; ANSWERS: afsat.com. 172800 IN NS dar1.afsat.com. afsat.com. 172800 IN NS ns2.lightband.com. ;; AUTHORITY RECORDS: afsat.com. 172800 IN NS dar1.afsat.com. afsat.com. 172800 IN NS ns2.lightband.com. ;; ADDITIONAL RECORDS: dar1.afsat.com. 172800 IN A 213.185.122.131 ns2.lightband.com. 172800 IN A 199.79.199.2 ;; Query done, 2 answers, status: no error afsat.com NS dar1.afsat.com ;; res_querydomain(dar1.afsat.com, <Nil>, 1, 1) ;; res_query(dar1.afsat.com, 1, 1) ;; res_mkquery(0, dar1.afsat.com, 1, 1) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20544 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; dar1.afsat.com, type = A, class = IN ;; Querying server (# 1) udp address = 192.5.6.30 ;; got answer, 122 bytes: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20544 ;; flags: qr rd; Ques: 1, Ans: 1, Auth: 2, Addit: 2 ;; QUESTIONS: ;; dar1.afsat.com, type = A, class = IN ;; ANSWERS: dar1.afsat.com. 172800 IN A 213.185.122.131 ;; AUTHORITY RECORDS: afsat.com. 172800 IN NS dar1.afsat.com. afsat.com. 172800 IN NS ns2.lightband.com. ;; ADDITIONAL RECORDS: dar1.afsat.com. 172800 IN A 213.185.122.131 ns2.lightband.com. 172800 IN A 199.79.199.2 afsat.com NS ns2.lightband.com ;; res_querydomain(ns2.lightband.com, <Nil>, 1, 1) ;; res_query(ns2.lightband.com, 1, 1) ;; res_mkquery(0, ns2.lightband.com, 1, 1) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20545 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; ns2.lightband.com, type = A, class = IN ;; Querying server (# 1) udp address = 192.5.6.30 ;; got answer, 131 bytes: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20545 ;; flags: qr rd; Ques: 1, Ans: 1, Auth: 2, Addit: 2 ;; QUESTIONS: ;; ns2.lightband.com, type = A, class = IN ;; ANSWERS: ns2.lightband.com. 172800 IN A 199.79.199.2 ;; AUTHORITY RECORDS: lightband.com. 172800 IN NS deathstar.kersur.net. lightband.com. 172800 IN NS ns2.lightband.com. ;; ADDITIONAL RECORDS: deathstar.kersur.net. 172800 IN A 199.79.199.1 ns2.lightband.com. 172800 IN A 199.79.199.2

3 3

Announcement: Policy Development Process in RIPE
by Rob Blokzijl 21 Dec '04

21 Dec '04

To the RIPE Community, later today I will publish a draft document that describes the policy making process in RIPE. It is draft, so your input is requested in order to come to a generally accepted final document. Logistics: - deadline for comments on the first draft: 1 Februari 2005 - discussion takes place on ripe-list(a)ripe.net - if you are not subscribed to ripe-list(a)ripe.net yet, go to http://www.ripe.net/mailman/listinfo/ripe-list#subscribers - for any questions, don't hesitate to contact chair(a)ripe.net As always, apologies for receiving multiple copies of this announcement. Best regards, Rob Blokzijl RIPE Chairman

2 1

RE: [dns-wg] Matching forward and reverse DNS for DSL pool addresses
by brian.wilkinson＠bt.com 01 Dec '04

01 Dec '04

ok - Thanks to all that replied. We already provide matching forward and reverse - I just wanted to verify that it was definitly required as I am currently reviewing our DNS management processes. Regards Brian -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com] Sent: Wednesday, December 01, 2004 12:48 PM To: Wilkinson,BJ,Brian,XJG11 R Cc: dns-wg(a)ripe.net Subject: Re: [dns-wg] Matching forward and reverse DNS for DSL pool addresses >>>>> "brian" == <brian.wilkinson(a)bt.com> writes: brian> Can anyone confirm whether DSL (and dial) providers are brian> required to provide matching forward and reverse DNS for brian> the address pools or is a wildcard in the reverse zones brian> sufficient? There's no requirement. Though your customers might appreciate it if reverse lookups worked for the IP addresses. Sometimes applications will make life difficult for hosts that don't have working reverse DNS. For instance a client that initiates an SMTP connection may be considered a spam source if there's no sensible answer to a reverse lookup of the client's address. And as Peter has said, wildcards are probably not a good idea for this sort of thing. It could also break when the application does a forwward lookup of the name returned by a reverse lookup. The BSD r- protocols -- which I hope nobody uses any more -- do this to decide if the client is who they claim to be and therefore determin if the client is trusted or not.

1 0

Re: [dns-wg] Matching forward and reverse DNS for DSL pool addresses
by Jim Reid 01 Dec '04

01 Dec '04

>>>>> "brian" == <brian.wilkinson(a)bt.com> writes: brian> Can anyone confirm whether DSL (and dial) providers are brian> required to provide matching forward and reverse DNS for brian> the address pools or is a wildcard in the reverse zones brian> sufficient? There's no requirement. Though your customers might appreciate it if reverse lookups worked for the IP addresses. Sometimes applications will make life difficult for hosts that don't have working reverse DNS. For instance a client that initiates an SMTP connection may be considered a spam source if there's no sensible answer to a reverse lookup of the client's address. And as Peter has said, wildcards are probably not a good idea for this sort of thing. It could also break when the application does a forwward lookup of the name returned by a reverse lookup. The BSD r- protocols -- which I hope nobody uses any more -- do this to decide if the client is who they claim to be and therefore determin if the client is trusted or not.

1 0

Matching forward and reverse DNS for DSL pool addresses
by brian.wilkinson＠bt.com 01 Dec '04

01 Dec '04

Can anyone confirm whether DSL (and dial) providers are required to provide matching forward and reverse DNS for the address pools or is a wildcard in the reverse zones sufficient? Regards Brian Wilkinson

3 2