January 2003 - dns-wg - mailman.ripe.net

FW: IPv6 reverse DNS meeting at last IETF
by paul.mylotte＠bt.com 21 Jan '03

21 Jan '03

Sorry about coming in late on this thread, but I would like to propose that we: * stop any further IPv6 reverse delegations in ip6.int * move all existing reverse delegations from ip6.int into ip6.arpa * define all future IPv6 reverse delegations in ip6.arpa only. Paul -----Original Message----- From: David Kessens [mailto:david@IPRG.nokia.com] Sent: 07 January 2003 00:50 To: ipv6-wg(a)ripe.net; dns-wg(a)ripe.net Subject: IPv6 reverse DNS meeting at last IETF Hi, I would like to share with you the results of a private discussion that started at a meeting at the last IETF regarding IPv6 reverse delegation issues. The group of people was an ad-hoc group which is worried that the process for moving to ip6.arpa is stagnating. People involved in the discussion were: Kurt Erik Lindqvist David Kessens Johan Ihren Andrei Robachevsky Patrik Faltstrom Jim Reid The topic of the meeting was IPv6 reverse DNS. We agreed on the following: - the move to ip6.arpa is not on track - it's probably best that we start to give attention to this problem in the DNS wg to avoid any duplication in efforts. (BTW this also means that the chairs of the ipv6 wg and DNS wg need a meeting schedule that will allow IPv6 wg participants to attend the DNS wg - we, Jim Reid & David Kessens, have already made this very clear to the RIPE NCC). - Andrei made it clear that the RIPE NCC wants to move forward with a pragmatic approach - we should stop making further delegations in ip6.int (in so far that this is within our powers, at the minimum we can recommend this) - we should make it possible that 3ffe address holders can start getting reverse delegations in ip6.arpa. This is important because it will allow software coders/vendors to do look ups in ip6.arpa only instead of doing kludges by looking in both or in the wrong one (ip6.int) we think this is important to get started as soon as possible since software tends to stay alive longer than desirable Andrei/RIPE NCC was going to ask IAB and/or other powers that be to get this moving. We as a community should help if necessary by a supporting statement. (Andrei already sent his request and is working on a proposal for implementation) - 6to4 reverse delegation We discussed this topic briefly as a lesser priority item. As 6to4 is a transition mechanism for networks that can not get native access to v6, we concluded that reverse delegation might not be that important for the 6to4 addresses. This is clearly a point for more discussion for the DNS wg. Obviously, this is just the opinion of a small group - your comments are welcome! Please follow up to the dns-wg list only (unless you don't agree on moving this topic to the dns-wg in the first place :-)). Thanks, David K. --- ---------------------------------------------------- All subscriber postings should be sent to: ietf-discuss(a)crpo.bt.co.uk Requests to be added to, or removed from, this list should be sent to: graham.travers(a)bt.com CONFIDENTIALITY Note that people from Wholesale, Ignite and Openworld subscribe to this mailing list in addition to BTexact people. Do not post any material you do not want to be seen by other Lines of Business. ----------------------------------------------------

1 0

Re: Experiments on production DNS (was: Re: NS.EU.NET running NSD)
by Jim Reid 20 Jan '03

20 Jan '03

>>>>> "Wilfried" == Wilfried Woeber, UniVie/ACOnet <woeber(a)cc.univie.ac.at> writes: Wilfried> Could someone explain *what the real problem* is, if Wilfried> it exists/ed? In the DNS world, there are many "real problems". :-) For this particular example, it turns out that ns.eu.net *was* misconfigured for a while. [I'm not sure when or for how long.] This meant it gave incorrect answers. Once this was noticed, the problem was promptly fixed. It wasn't an implementation error in NSD or a difference of interpretation in the DNS protocol by the authors of BIND or NSD. Quite simply it appears to have been an example of administrative error causing garbage-in, garbage-out. In this case the garbage was the DNS data fed to NSD. The OP compounded matters by referring to connectivity problems which don't seem to exist. And not showing when and where the NXDOMAIN responses came from didn't help. We now return this discussion to yet another bout of ICANN-bashing...

1 0

Experiments on production DNS (was: Re: NS.EU.NET running NSD)
by Berislav Todorovic 20 Jan '03

20 Jan '03

As far as I remember, on 1 October 2002 people using ns.EU.net as secondary for their zones received the following announcement from RIPE NCC (just stating the significant part): >> We, the RIPE NCC, host the nameserver ns.eu.net since the beginning of >> June 2002 as a service to the Internet community, to give the >> administrators of the large number of domains that ns.eu.net is still >> running secondary nameservice for, ample time to stop referencing to it. >> >> We cannot provide this service indefinitely and are planning to stop >> running ns.eu.net in 1 month time, in the beginning of November 2002. Despite of the warning, ns.EU.net continued to operate normally after November 2002. Well, many people probably appreciate this. However, since few days ago a lot of ccTLD administrators started to complain about reachability of ns.EU.net. Today we got the explanation about it: >> Since January 13, the RIPE NCC is running the NS.EU.NET nameserver >> with a new software, NSD ( http://www.nlnetlabs.nl/nsd ). Well, experimenting is just fine, but don't you think people should have been warned in advance? I don't need ns.EU.net anymore, since I moved all domains we need to another server. However, some ccTLD's are still using it and blaming our company for the problems, since EU.net domain is still owned and operated by us. Your argument might be that "they had enough time to migrate". True. You are free to remove them completely from ns.EU.net, but as long as ns.EU.net is a live box and serves as a DNS - it is a part of production environment. Would you, please, take a look into 4 ccTLD's that return NXDOMAIN and take care they continue to have normal service: al ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4 bg ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4 tp ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4 zw ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4 Their primaries are: al 146.48.65.46 bg 192.92.129.1 tp 194.106.128.50 zw 194.133.122.47 Regards, Beri --------- Berislav Todorovic, Senior IP Specialist -------- ----- KPN Eurorings B.V. - IP Engineering/NOC/Support ----- ---- Telecomplein 5, 2516 CK Den Haag, NL ---- ----- Email: beri(a)eurorings.net <=> beri(a)EU.net ----

5 6

Re: Experiments on production DNS (was: Re: NS.EU.NET running NSD)
by Wilfried Woeber, UniVie/ACOnet 20 Jan '03

20 Jan '03

>> Your argument might be that "they had enough time to migrate". True. > >Yes, they had, but ICANN/DoC bureaucrats hold them hostages. That's an issue not directly (technically :-) related to this discussion. >IMHO, it is better to shut it down completely. The DNS behaves fine >when a server is down, not when it is running and giving possibly >wrong information (as ns.eu.net hosted by RIPE already did for former >domains of EUnet-France). Could someone explain *what the real problem* is, if it exists/ed? I am definitely NOT a DNS expert, but I couldn't verify a "wrong" answer returned by ns.eu.net yet. >Otherwise, nsd is a very fine software :-) and I'm glad to see it used >in production. Why not trying it on NS.RIPE.NET? But _if_ there is a problem (and not simply a _different_ behaviour than bind would respond, due to an inconsistent configuration somewhere), then everybody would be better off to get it documented and fixed, I suppose? Wilfried. PS: I am very interested to get this sorted out, because we already have that creature doing business here, and I'm considering to use it for another service soon. Thanks....

1 0

NS.EU.NET running NSD.
by Daniel Diaz 15 Jan '03

15 Jan '03

(apologies for duplicates) Dear all, Since January 13, the RIPE NCC is running the NS.EU.NET nameserver with a new software, NSD ( http://www.nlnetlabs.nl/nsd ). In case of any observed oddity with NS.EU.NET and/or service, please let us know by sending an e-mail to <ops(a)ripe.net>. -- Daniel.Diaz Operations Manager RIPE NCC #---------------------------------------------------------------------- # To unsubscribe, send a message to <dnsop-request(a)cafax.se>.

1 0

Draft on using SRV records to locate whois servers
by Marcos Sanz/Denic 09 Jan '03

09 Jan '03

Folks, Below is the updated draft we have been working on. Comments have been incorporated and new sections have been added. We would like to light up the discussion here before the WG meeting. The most up-to-date version of the document can always be found at http://mailbox.univie.ac.at/~gw/draft-whois-srv.txt Regards, Marcos Sanz DENIC eG (See attached file: draft-whois-srv.txt)

1 0

Re: [ipv6-wg@ripe.net] arpa zone for 2002::/16 ?
by Andrei Robachevsky 08 Jan '03

08 Jan '03

Gert Doering wrote: > Hi, > > On Fri, Jan 03, 2003 at 11:27:32AM +0100, Gert Doering wrote: > >>> Here you are talking about 3ffe & arpa. I would like to know if there is >>>something going to make reverse available for 2002::/16 addr space? Maybe >>>there could be used automatic zone delegation by current ipv4 ns delegation? >> >>Huh? 2002:: reverse delegation is available since 1999 or so, and since >>mid 2000 (if I remember correctly) both in ip6.int and ip6.arpa. That's >>not our problem here :-) > > > Sorry. I didn't have enough coffee yet. What I wrote relates to > 2001:: delegation, not 2002:: > > The situation on 2002:: 6to4 space is still a bit unclear, at least in > the RIPE land - there is an action item on the RIPE NCC to propose > a solution for 6to4 RR, but as far as I know, nothing has been implemented > yet. > This issue has been discussed at the private meeting during last IETF (please see David Kessen's report on this): > - 6to4 reverse delegation > > We discussed this topic briefly as a lesser priority item. > > As 6to4 is a transition mechanism for networks that can not get > native access to v6, we concluded that reverse delegation might not > be that important for the 6to4 addresses. > > This is clearly a point for more discussion for the DNS wg. > We would like to get more input from the community with regards to importance of this issue and preferable solutions. Explicit delegation of NS records for 6to4 addressed may require quite a lot of coordination efforts and may not be the best solution as it comes from some IETF documents (for example draft-ietf-dnsop-ipv6-dns-issues-00.txt and draft-moore-6to4-dns-03.txt). > Gert Doering > -- NetMaster Regards, Andrei Robachevsky CTO, RIPE NCC

1 0

IPv6 reverse DNS meeting at last IETF
by David Kessens 08 Jan '03

08 Jan '03

Hi, I would like to share with you the results of a private discussion that started at a meeting at the last IETF regarding IPv6 reverse delegation issues. The group of people was an ad-hoc group which is worried that the process for moving to ip6.arpa is stagnating. People involved in the discussion were: Kurt Erik Lindqvist David Kessens Johan Ihren Andrei Robachevsky Patrik Faltstrom Jim Reid The topic of the meeting was IPv6 reverse DNS. We agreed on the following: - the move to ip6.arpa is not on track - it's probably best that we start to give attention to this problem in the DNS wg to avoid any duplication in efforts. (BTW this also means that the chairs of the ipv6 wg and DNS wg need a meeting schedule that will allow IPv6 wg participants to attend the DNS wg - we, Jim Reid & David Kessens, have already made this very clear to the RIPE NCC). - Andrei made it clear that the RIPE NCC wants to move forward with a pragmatic approach - we should stop making further delegations in ip6.int (in so far that this is within our powers, at the minimum we can recommend this) - we should make it possible that 3ffe address holders can start getting reverse delegations in ip6.arpa. This is important because it will allow software coders/vendors to do look ups in ip6.arpa only instead of doing kludges by looking in both or in the wrong one (ip6.int) we think this is important to get started as soon as possible since software tends to stay alive longer than desirable Andrei/RIPE NCC was going to ask IAB and/or other powers that be to get this moving. We as a community should help if necessary by a supporting statement. (Andrei already sent his request and is working on a proposal for implementation) - 6to4 reverse delegation We discussed this topic briefly as a lesser priority item. As 6to4 is a transition mechanism for networks that can not get native access to v6, we concluded that reverse delegation might not be that important for the 6to4 addresses. This is clearly a point for more discussion for the DNS wg. Obviously, this is just the opinion of a small group - your comments are welcome! Please follow up to the dns-wg list only (unless you don't agree on moving this topic to the dns-wg in the first place :-)). Thanks, David K. ---

6 7