- dns-wg - mailman.ripe.net

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

Query on Resolver w.r.t DNSSEC
by Natarajan,Ganesh 23 Nov '04

23 Nov '04

Hi , I am Ganesh and I work for wipro. We are currently working on porting DNS BIND 4.8 to DNS BIND 9.2.3. My platform is HP-Nonstop servers. I have a specific query regarding the role of resolver library in DNSSEC. Query: Does DNS BIND 9.2.3 support caching and verification of RRs (resourse records) on the resolver library part by default? We are trying to port 4.8 resolver code to 9.2.3 resolver code. Since Our platfrom doesn't support OPenssl, we are trying to lookout for this option. we wanted to know, whether by default any authentication is enabled at the resolver part in BIND 9.2.3. We understand that RFC2535 states CD and AD bit. If CD bit is set, then resolver doesn't do auth and integrity tests. Is this CD bit disabled or enabled in BIND 9.2.3? To reiterate the whole question again, we wanted to know the role of resolver with respect to DNSSEC in BIND 9.2.3! Since, we are pretty new to DNSSEC, we need your valuable inputs on the above query. regards, Ganesh. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin(a)wipro.com immediately and destroy all copies of this message and any attachments.

3 2

ripe policy about reverse dns?
by Peter Gervai 01 Nov '04

01 Nov '04

Hello, I tend to remember that RIPE had a strict policy about delegated address space reverse DNS: adresses must have a valid reverse and delegated (sub) blocks must be registered in RIPE db. I wanted to refer to the document mentioning these requirements but I was not able to find them. Navigating on www.ripe.net helped nothing: reverse dns part shows the procedure, refers to a page "about ripe policies" which contains only links to RFC and other RIPE documents, which in turn are about the procedure and not any policy. Maybe there are any hidden one mentioning that "you should have reverse on your addresses" but I kindly ask your help where to look for it. If this requirement would have been dropped then I'd be extremely happy to know about it. Thank you, Peter ps: Reason is a(nother) big provider with many /19 and with no reverse or RIPE entry (other than the /19) whatsoever, and occasional spam from these reverseless and nameless blocks.

2 1

Re: [dns-wg] Re: ORSN-SERVERS.NET
by Jim Reid 28 Oct '04

28 Oct '04

>>>>> "Jon" == Jon Lawrence <jon(a)lawrence.org.uk> writes: Jon> Maybe I'm thick, but I still don't get it. What is the Jon> advantage of ORSN over the ICANN root ? I have no idea. However this list is not the place to discuss this topic further. It's essentially a local policy matter and is therefore inappropriate for the DNS WG. If someone wants to set up a mailing list to debate this, please go ahead and do so. Tell us where it is and how to subscribe and unsubscribe. Other than that, I would appreciate it if the discussion of alternate roots stopped in this list. Thanks.

2 1

Jumping the gun on SIDN!
by Pim van Pelt 28 Oct '04

28 Oct '04

Hi, With some relief and pride, I'd like to show you that the dutch registry SIDN has enabled their registrars to offer IPv6 glue. One can send in a request using a freeform ticket. I happen to have been the first, so since todays serial of 200410280, there are new records in the nl. zone. Yaay! ; <<>> DiG 9.3.0 <<>> @ns.domain-registry.nl NS bit.nl. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1989 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6 ;; QUESTION SECTION: ;bit.nl. IN NS ;; AUTHORITY SECTION: bit.nl. 86400 IN NS nsauth1.bit.nl. bit.nl. 86400 IN NS nsauth2.bit.nl. bit.nl. 86400 IN NS nsauth3.bit.nl. ;; ADDITIONAL SECTION: nsauth1.bit.nl. 86400 IN A 213.136.12.51 nsauth2.bit.nl. 86400 IN A 213.136.12.59 nsauth3.bit.nl. 86400 IN A 212.204.192.11 nsauth1.bit.nl. 86400 IN AAAA 2001:7b8:3:2c::53 nsauth2.bit.nl. 86400 IN AAAA 2001:7b8:3:2d::53 nsauth3.bit.nl. 86400 IN AAAA 2001:898:1001:1003::53 ;; Query time: 46 msec ;; SERVER: 193.176.144.2#53(ns.domain-registry.nl) ;; WHEN: Thu Oct 28 13:04:59 2004 ;; MSG SIZE rcvd: 222 The dutch registry will implement and enable IPv6 in their infrastructure also, so I'm told by SIDN. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

2 1