From Niall.oReilly at ucd.ie Mon May 1 01:40:11 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 01 May 2006 00:40:11 +0100 Subject: [dns-operations] [dns-wg] "DNS Vulnerabilities" paper hits the mainstream In-Reply-To: References: <761A99A4-9D9B-476B-BEBC-10B7679184A5@rfc1035.com> <006601c66c83$82ec5600$64c8a8c0@balefirehome> Message-ID: On 30 Apr 2006, at 20:02, Jim Reid wrote: > Niall O'Reilly said he posted something through the > "have your say" feature of the BBC web site. FYI, here's what I posted. Although the observations described at http://news.bbc.co.uk/1/hi/ technology/4954208.stm are interesting and raise important issues, their relation to the conclusions made appears to be at best only tenuous. Internet experts are far from convinced of the rigour of Prof. Sirer's logic. It is disappointing to see BBC so ready to report just one side of a story. /Niall From jim at rfc1035.com Mon May 1 03:00:10 2006 From: jim at rfc1035.com (Jim Reid) Date: Mon, 1 May 2006 02:00:10 +0100 Subject: [dns-operations] [dns-wg] "DNS Vulnerabilities" paper hits the mainstream In-Reply-To: <828b98cbc3b367ce308184359ac09a31@swcp.com> References: <761A99A4-9D9B-476B-BEBC-10B7679184A5@rfc1035.com> <006601c66c83$82ec5600$64c8a8c0@balefirehome> <828b98cbc3b367ce308184359ac09a31@swcp.com> Message-ID: On May 1, 2006, at 01:15, Bill Larson wrote: > How can the "security of the DNS system" be considered as any > better than > the security of the parent servers? Because the parent is not usually authoritative for its children. Sure, the parent could insert bogus delegation info: a fake glue or NS record. But this is little different from a slave server for the child that tells lies about the zone. If anything, a lying slave is probably much worse because the cache poisoning heuristics in a decent implementation will give more credence to what an authoritative child has to say than a non-authoritative parent. > Using an example from the paper. If the FBI has a delegated server > that can be easily hijacked, then this would mean that a significant > number of queries for information in the "fbi.gov" domain could be > subverted with invalid info. This is a security issue and it is > not an > issue under the direct control of the FBI (except for their > decision to > base their operation on a third party service). One would hope that if someone outsources DNS service to a third party, that will be subject to a contract which includes performance levels, problem escalation, response to security incidents as well as criminal or civil penalties for non-compliance. I'd get those safeguards buying a cup of coffee, so why not when buying DNS service? > Isn't this the same type of security issue evaluated with COPS? I don't think so. From olaf at NLnetLabs.nl Mon May 1 10:33:58 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Mon, 1 May 2006 11:33:58 +0300 Subject: [dns-wg] Re: [dns-operations] "DNS Vulnerabilities" paper hits the mainstream In-Reply-To: <761A99A4-9D9B-476B-BEBC-10B7679184A5@rfc1035.com> References: <761A99A4-9D9B-476B-BEBC-10B7679184A5@rfc1035.com> Message-ID: <5D9D5268-8DD1-4311-9E66-2F918C36FB20@NLnetLabs.nl> > > Any thoughts on how to respond to that? http://www.secret-wg.org/Secret-Archive/RIPE52-SWG_files/Slide0003.gif :-) --Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 227 bytes Desc: This is a digitally signed message part URL: From wllarso at swcp.com Mon May 1 02:15:10 2006 From: wllarso at swcp.com (Bill Larson) Date: Sun, 30 Apr 2006 18:15:10 -0600 Subject: [dns-operations] [dns-wg] "DNS Vulnerabilities" paper hits the mainstream In-Reply-To: References: <761A99A4-9D9B-476B-BEBC-10B7679184A5@rfc1035.com> <006601c66c83$82ec5600$64c8a8c0@balefirehome> Message-ID: <828b98cbc3b367ce308184359ac09a31@swcp.com> On Apr 30, 2006, at 5:40 PM, Niall O'Reilly wrote: > On 30 Apr 2006, at 20:02, Jim Reid wrote: >> Niall O'Reilly said he posted something through the >> "have your say" feature of the BBC web site. > > FYI, here's what I posted. > > Although the observations described at http://news.bbc.co.uk/1/hi/ > technology/4954208.stm > are interesting and raise important issues, their relation to the > conclusions made appears > to be at best only tenuous. Internet experts are far from convinced > of the rigour of Prof. > Sirer's logic. It is disappointing to see BBC so ready to report just > one side of a story. I'm not disagreeing with anybody here, I'm not exactly sure what I personally believe at this time and I hope that this discussion helps me make up my mind. But, I keep thinking back on an old security tool that I used to use and the implications of it's design on this issue. Many years ago Dan Farmer wrote a tool to audit the security of a system called COPS. This was built on the idea that the security of a system can be no greater than the security of it's weakest link. How can the "security of the DNS system" be considered as any better than the security of the parent servers? This is the basis for the CoDoNS investigation. Using an example from the paper. If the FBI has a delegated server that can be easily hijacked, then this would mean that a significant number of queries for information in the "fbi.gov" domain could be subverted with invalid info. This is a security issue and it is not an issue under the direct control of the FBI (except for their decision to base their operation on a third party service). Isn't this the same type of security issue evaluated with COPS? Isn't this just an issue of cascading of trust? Why should one situation be considered acceptable while another is unacceptable? Please understand, I am not convinced that CoDoNS is any improvement to the existing DNS system. I am still trying to develop my own informed opinion rather regurgitating than what Cornel or the BBC says. Bill Larson From roy at nominet.org.uk Tue May 2 20:09:34 2006 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 2 May 2006 20:09:34 +0200 Subject: [dns-wg] "DNS Vulnerabilities" paper hits the mainstream In-Reply-To: <761A99A4-9D9B-476B-BEBC-10B7679184A5@rfc1035.com> Message-ID: Jim Reid wrote on 04/30/2006 09:46:25 AM: > Emin Gun Sirer's paper/presentation at RIPE52 has been picked up by > the BBC: > > http://news.bbc.co.uk/1/hi/technology/4954208.stm > > Any thoughts on how to respond to that? I respond to this on different fora, and some of asked me to iterate it here, so here goes: I saw this presentation of the study and results at ripe, and it was more marketing than science. First off, the survey mentioned tracked dependencies on servers which had names not in the delegated zone nor its own (out of bailiwick). Some dependency graphs showed more the 600 nodes. The survey sorted names by node and went on by saying 'the higher the dependency, the more vulnerable a name'. The conclusions in the end were twofold. 1: the old wisdom of having more server dependency is bad. And 2: A new form of DNS is needed. Add 1). The 'old wisdom' was imho: more authoritative servers for a single name, less points of failure, etc,etc. What it does _not_ mean (i.e. grove mistake by the authors) is that resolution graphs should be long and wide (i.e. net resides on ns1.com, com resides on ns1.org, org resides on ns1.edu, etc, etc) Meanwhile, caching was never mentioned. The big message was that somebody who abuses a vulnerability in one of those 600 nodes, would 0wnz (sic) the name, while in my point of view, a hacker would own some part of the resolution graph, depending on where this vulnerable node hangs in the tree, and not automagically the entire name. To add some sugar to this, the presentation went on to show that 17 percent of the tested servers had 'known' vulnerabilities, which then related to 45 % if the names being triviable hijackable, though no accurate methodology was given. The authors made the mistake of confusing protocol with implementation. Dependency is not equal to vulnerability. In the process, some high profile name-servers at berkeley were mentioned, and it was suggested that their operators were not professionals, and that they did not understand the high dependencies. The authors of the paper (that resulted in this presentation) came to the conclusion that server dependencies using out-of-bailiwick servers in DNS is a bad thing, and hence, there was a new kind of DNS needed, discarding the obvious solution of recommending in-bailiwick glue. Add. 2) It turned out that this 'new DNS' was already defined: some form of DNS using distributed hash tables: beehive codons. And ofcourse, at rival Berkeley, there is a similar project: CHORD. Conclusion: This was no less than a marketing talk. They have a solution, and they need to sell it. In order for it to look good, make the old solution and the competition look bad. A marketing study. Not science. Nothing original and nothing new (DJB warned about this: http://cr.yp.to/djbdns/notes.html 'gluelessness' ) . Scare tactics at most. Meanwhile, the codons server set itself has issues. It responds to responses. A few packets would effectively bring the whole codons infrastructure down. Sure, these bugs can be fixed. But if that argument is allowed for codons, it should be allowed for generic dns implementations. Building a new protocol based on the fact that there exist vulnerabilities in current implementations is circular. You'll have more bad implementations that will result in new protocols.... Roy PS, the codons folk have been informed about the vulnerability in their software. From roy at nominet.org.uk Wed May 3 10:36:38 2006 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 3 May 2006 10:36:38 +0200 Subject: [dns-wg] Vulnerability Issues in Implementations of the DNS Protocol Message-ID: With all the lies and statistics going on, this vulnerability advisory from NISCC might have slipped by. Since the url points to a pdf file, I took the liberty to convert this. Roy. -------- http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en NISCC Vulnerability Advisory 144154/NISCC/DNS Vulnerability Issues in Implementations of the DNS Protocol Version Information Advisory Reference 144154/NISCC/DNS Release Date 25 April 2006 Last Revision 02 May 2006 Version Number 1.2 Acknowledgement The DNS Test Tool was created by the Oulu University Secure Programming Group (OUSPG) from the University of Oulu in Finland. What is Affected? The vulnerabilities described in this advisory affect implementations of the Domain Name System (DNS) protocol. Many vendors include support for this protocol in their products and may be impacted to varying degrees, if at all. Impact If exploited, these vulnerabilities could cause a variety of outcomes including, for example, a Denial-of-Service (DoS) condition. In most cases, they can expose memory corruption, stack corruption or other types of fatal error conditions. Some of these conditions may expose the protocol to typical buffer overflow exploits, allowing arbitrary code to execute or the system to be modified. Severity The severity of this vulnerability varies by vendor. Please see the 'Vendor Information' section below for further information. Alternatively, contact your vendor for product specific information. Summary During 2002 the Oulu University Secure Programming Group (OUSPG) discovered a number of implementation specific vulnerabilities in the Simple Network Management Protocol (SNMP). Further work has been done to identify implementation specific vulnerabilities in related protocols that are used in critical infrastructure. The DNS protocol, which is the primary naming system used on the Internet, was studied as part of this program of work. DNS is an Internet service that translates domain names into Internet Protocol (IP) addresses and vice versa. Because domain names are alphabetic, they're easier to remember, however the Internet is really based on IP addresses; therefore every time a domain name is requested, a DNS service must translate the name into the corresponding IP address. OUSPG has developed a PROTOS DNS Test Suite for DNS implementations and employed it to validate their findings against a number of products from different vendors. NISCC has contacted multiple vendors whose products support the DNS protocol and provided them with the test tool to allow them to test their implementations. NISCC believes that most of the relevant vendors who provide support for the DNS protocol have been covered by this advisory. Details DNS is a system that stores information associated with domain names in a distributed database on networks such as the Internet. The domain name system associates many types of information with domain names, but most importantly, it provides the IP address associated with the domain name. It also lists mail exchange servers accepting e-mail for each domain and a wide variety of other records. The OUSPG DNS Test Suite covers a limited set of information security and robustness related implementation errors for the DNS protocol. The factors behind choosing DNS included: DNS is a fundamental infrastructure of the Internet, most Internet applications are dependent on it. DNS implementations are ubiquitous: present in servers, end- user equipment such as personal computers or mobile phones and in routers and firewalls. Therefore DNS may be a potential attack vector in a variety of scenarios against a variety of systems and infrastructure components. There are no free, publicly available robustness test suites to evaluate DNS implementations. The material contained in the test suite covers basic queries, dynamic updates, basic responses and zone transfers. However please be aware that the test material does not cover cache poisoning or address spoofing vulnerabilities. There are three sets of test materials available with the tool; these are specifically designed for the following scenarios: 1. The Query Material -> [queries, dynamic DNS updates] -> DNS server 2. The Response Material -> [query replies] -> DNS server 3. The Response Material -> [query replies] -> DNS stub resolver (client) 4. The Zone Transfer Material -> [zone transfers] -> secondary DNS server The test material simulates hostile input to the DNS implementation by sending invalid and/or abnormal packets. Therefore by applying the OUSPG DNS Test Suite to a variety of products, several vulnerabilities can be revealed that can have varying effects. Mitigation Patch all affected implementations. Solution Please refer to the 'Vendor Information' section of this advisory for platform specific remediation. Vendor Information The following vendors have provided information about how their products are affected by this vulnerability. Please note that JPCERT/CC have released a Japanese language advisory for this vulnerability which contains additional information regarding Japanese vendors. This advisory is available at http://jvn.jp/niscc/NISCC-144154/index.html Cisco Systems, Inc Microsoft Delegate MyDNS Ethereal pdnsd Fujitsu Sun Hitachi Wind River ISC Juniper Networks Cisco Systems, Inc Cisco Systems is currently testing its DNS related products. We will provide updates if warranted at http://www.cisco.com/go/psirt. Delegate Vulnerable: DeleGate/9.0.5 (DEVELOPMENT) and prior versions DeleGate/8.11.5 (STABLE) and prior versions Not Vulnerable: DeleGate/9.0.6 and subsequent versions DeleGate/8.11.6 and subsequent versions DeleGate is an application level gateway (proxy server) which relays multiple application protocols including HTTP, FTP, SMTP, SOCKS, DNS; running on Unix and Windows. There have been bugs in its DNS protocol handling unit where a DNS response message is analyzed. Due to this problem, DeleGate can suffer a denial-of-service attack. For some crafted or broken response messages, it reads the message data area beyond the real size of it, or read it in infinitely recursive function call. Then the DeleGate process will abort causing segmentation fault or so accessing non-existent address or non-available memory. DeleGate as DNS proxy, ICP server and UDP-relay might stop their service receiving such broken DNS response, since the abortion occurs in the main process which is not to be restarted automatically by itself. Other DeleGate proxies for other protocols do not stop servicing but a child process for a session might abort without returning response message of each application protocol. These bugs have been fixed in version 9.0.6 (development version) and 8.11.6 (stable version). The impact for resent versions is not more than DoS, but upgrading to these versions (or subsequent ones) is recommended. The impact can be more serious in ancient versions of DeleGate prior to 8.10.3 which also include many other kind of dangers (http://www.delegate.org/mail- lists/delegate-en/2793), so they must be upgraded anyway. Ethereal The Ethereal development team is investigating the reported vulnerabilities to determine if any versions of Ethereal are affected. We will provide updated status information in the near future. Fujitsu Fujitsu have provided more information on this issue at the following location (in Japanese): http://software.fujitsu.com/jp/security/vulnerabilities/niscc144154.html Hitachi Hitachi believe that the AlaxalA Networks AX series, Hitachi GR2000/GR4000/GS4000/GS3000 and Hitachi HI-UX are NOT vulnerable to this issue. ISC ISC has reviewed a bug that can cause named to terminate abnormally if a broken TSIG is present in the second or later message of a zone transfer. However, this is not considered high-risk as the first message must have a correct TSIG present for the transaction to continue. A fix will be included in a future BIND release. Juniper Networks The OUSPG PROTOS c09-dns-response test tool was run against all Juniper Networks platforms. JUNOS and ScreenOS were unaffected. Tests against JUNOSe, found on the E-series routers, did result in an issue with the DNS client code (ref: KA 23381). The issue was resolved in the following JUNOSe updates: 5-3-5p0-2, 6-0-3p0-6, 6-0-4, 6-1-3p0-1, 7-0-1p0-7, 7-0-2, 7-1-0p0- 1, 7-1-1. Later JUNOSe releases are unaffected. Microsoft Microsoft are still testing their products and will provide an update when more information is available. MyDNS MyDNS 1.1.0 has been released which contains a fix for a query-of-death DoS bug uncovered by the test suite. New versions can be obtained from: http://mydns.bboy.net/ pdnsd The current maintainer of the pdnsd project, Paul A. Rombouts, has run tests on pdnsd with the DNS Test Suite mentioned here and discovered one significant flaw in the pdnsd code, which affects several versions of pdnsd. A DNS query with an unsupported QTYPE or QCLASS can cause pdnsd to leak memory. The amount of memory used by pdnsd may thus grow continually and unbounded and may eventually cause pdnsd to crash or cause the system to become sluggish and unresponsive. All users of pdnsd are advised to upgrade to version 1.2.4 or later of pdnsd, which has a fix for this leak and is available at: http://www.phys.uu.nl/~rombouts/pdnsd.html Sun Sun Microsystems is currently investigating the impact of the OUSPG DNS test suite to Sun's products. If any issues are identified, Sun will publish Sun Alerts which will include details of the impact and suggested resolution for those issues. Wind River Wind River does not believe that any of the products we provide are currently vulnerable to the issues described in this Vulnerability Notice. Acknowledgements The NISCC Vulnerability Management Team would like to thank OUSPG for producing the DNS Test Tool. The NISCC Vulnerability Management Team would also like to thank the vendors for their co-operation in handling this vulnerability and to JPCERT/CC for co-ordinating this issue in Japan. Contact Information The NISCC Vulnerability Management Team can be contacted as follows: Email vulteam at niscc.gov.uk (Please quote the advisory reference in the subject line.) Telephone +44 (0)870 487 0748 Extension 4511 (Monday to Friday 08:30 - 17:00) Fax +44 (0)870 487 0749 Post Vulnerability Management Team NISCC PO Box 832 London SW1P 1BG We encourage those who wish to communicate via email to make use of our PGP key. This is available from http://www.niscc.gov.uk/niscc/publicKey2-en.pop. Please note that UK government protectively marked material should not be sent to the email address above. If you wish to be added to our email distribution list, please email your request to uniras at niscc.gov.uk. What is NISCC? For further information regarding the UK National Infrastructure Security Co-Ordination Centre, please visit the NISCC web site at: http://www.niscc.gov.uk/ Reference to any specific commercial product, process or service by trade name, trademark manufacturer or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NISCC. The views and opinions of authors expressed within this notice shall not be used for advertising or product endorsement purposes. Neither shall NISCC accept responsibility for any errors or omissions contained within this advisory. In particular, they shall not be liable for any loss or damage whatsoever, arising from or in connection with the usage of information contained within this notice. ? 2006 Crown Copyright Revision History 25 April 2006 Initial release (1.0) 26 April 2006 Added Vendor Statement from Cisco (1.1) 02 May 2006 Added Vendor Statement from Fujitsu (1.2) http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en From pim at ipng.nl Mon May 8 14:54:35 2006 From: pim at ipng.nl (Pim van Pelt) Date: Mon, 8 May 2006 14:54:35 +0200 Subject: [dns-wg] ip6.int deprecation Message-ID: <20060508125435.GG7866@bfib.ipng.nl> Dear wg, I have heard from Bill Manning that ARIN has requested removal of their space from the ip6.int tree, and I'm wondering what the current point of view is for the RIPE NCC. I would like to see ip6.int dismanteled 'correctly', ie not in the way described below: I wrote to ipv6-ops at lists.cluenet.de: > I have heard DNS operators are planning on removing ip6.int from their > resolvers (ie by plugging ip6.int into an empty zone on their recursors). > What are your thoughts on this? I am considering removing ip6.int also > in the same way, because I think it can take a long time for the parent > of .int to remove ip6 delegation (if they are even considering this is > unknown to me) and for sure it might take a long time for the ip6.int > folks to remove children from their zone. > Bill replied: | ip6.int is ready to remove zone cuts for ARIN. | they are the only RIR who has requested delegation removal. | when/if the other RIRs request delegation removal, it will | occur. Has this been discussed before? If so, I'm sorry I missed it :) What was the outcome in that case? I think it is a very good idea to have RIPE NCC and APNIC request delegation removal. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From jim at rfc1035.com Tue May 9 12:19:01 2006 From: jim at rfc1035.com (Jim Reid) Date: Tue, 9 May 2006 11:19:01 +0100 Subject: [dns-wg] ip6.int deprecation In-Reply-To: <20060508125435.GG7866@bfib.ipng.nl> References: <20060508125435.GG7866@bfib.ipng.nl> Message-ID: <3428EAEB-4ED4-4D3C-81AB-42FFCB8C910E@rfc1035.com> On May 8, 2006, at 13:54, Pim van Pelt wrote: > I have heard from Bill Manning that ARIN has requested removal of > their > space from the ip6.int tree, and I'm wondering what the current > point of > view is for the RIPE NCC. > > Has this been discussed before? If so, I'm sorry I missed it :) What > was the outcome in that case? I think it is a very good idea to have > RIPE NCC and APNIC request delegation removal. Pim, there has been discussion about the "future" of ip6.int for some time now in the RIPE DNS WG. Mostly this has happened at RIPE meetings rather than on the list. The consensus is that ip6.int should be killed. And at RIPE52, there was some discussion about not just deleting the delegations but removing ip6.int altogether. Co-ordination of this clean-up of the legacy IPv6 reverse address space is being done by the RIRs. They are acting collectively. The plan is to delete the ip6.int delegations by June 1st. The RIRs will do this at the same time. The name servers for ip6.int are getting next to no traffic -- probably nothing but SOA refresh checks -- so removal of this zone should have no operational impact. If you need further info, please check the WG minutes and relevant presentations from the last 3 or 4 RIPE meetings. Andrei Robachevsky from the NCC gave an update on the situation during RIPE52. His presentation is at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns- ip6-int.pdf My guess is Bill's comment has confused you by implying that ARIN was the only RIR to make a request for removal when in fact they presumably were the first RIR to make that request. From training at ripe.net Tue May 9 14:39:47 2006 From: training at ripe.net (RIPE NCC Training Services) Date: Tue, 09 May 2006 14:39:47 +0200 Subject: [dns-wg] Announcement DNS for LIRs Training Course Message-ID: <20060509123947.0B1062F583@herring.ripe.net> Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: And Date: Tuesday 13 June 2006 Time: 0900-1700 Location: Riyadh, Saudi Arabia Hosted by:ZAJIL International Telecommunications Co. W.L.L. And Date: Thursday 13 July 2006 Time: 0900-1700 Location: Munich, Germany And Date: Friday 8 September 2006 Time: 0900-1700 Location: Manchester, United Kingdom And Date: Friday 29 September 2006 Time: 0900-1700 Location: Amsterdam, Netherlands The main objective of the DNS for LIRs Training Course is to provide LIRs with information about the different DNS related services the RIPE NCC has available for them. It covers reverse DNS procedures and checks, as well as giving information about DNS Monitoring (DNSMON), K-Root and anycasting. The course also covers DNSSEC and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zones. Please note that the DNS for LIRs course focuses on DNS services and procedures related to being an LIR. The course does: - NOT teach the basics of DNS - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe fully how to operate a Local Internet Registry (LIR) The course is intended for technical staff of LIRs. It is assumed that all attendees are familiar with common DNS terminology and have a practical knowledge of operating DNS servers. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/dns REGISTRATION: ============ To register for this course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From pim at bit.nl Tue May 9 14:41:31 2006 From: pim at bit.nl (Pim van Pelt) Date: Tue, 9 May 2006 14:41:31 +0200 Subject: [dns-wg] ip6.int deprecation In-Reply-To: <3428EAEB-4ED4-4D3C-81AB-42FFCB8C910E@rfc1035.com> References: <20060508125435.GG7866@bfib.ipng.nl> <3428EAEB-4ED4-4D3C-81AB-42FFCB8C910E@rfc1035.com> Message-ID: <20060509124131.GW22962@localhost.localdomain> Jim, On Tue, May 09, 2006 at 11:19:01AM +0100, Jim Reid wrote: > If you need further info, please check the WG minutes and relevant > presentations from the last 3 or 4 RIPE meetings. Andrei Robachevsky > from the NCC gave an update on the situation during RIPE52. His > presentation is at: > http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-dns-ip6-int.pdf This is a very short and to-the-point presentation, I must admit ;-) > My guess is Bill's comment has confused you by implying that ARIN was > the only RIR to make a request for removal when in fact they > presumably were the first RIR to make that request. It did indeed, thanks so much for clearing this up. I feel much more confident now than I did yesterday with regards to the removal of ip6 from int. groet, Pim -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From randy at psg.com Fri May 12 14:25:47 2006 From: randy at psg.com (Randy Bush) Date: Fri, 12 May 2006 15:25:47 +0300 Subject: [dns-wg] ip6.int deprecation References: <20060508125435.GG7866@bfib.ipng.nl> Message-ID: <17508.32459.471095.252635@roam.psg.com> ip6.int is dead. who cares how a deal rock is removed from the roadside? randy From jelte at NLnetLabs.nl Fri May 12 15:41:45 2006 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Fri, 12 May 2006 15:41:45 +0200 Subject: [dns-wg] Measuring the effects of DNSSEC deployment on query load Message-ID: <44649099.1080807@NLnetLabs.nl> Hi, i have performed a little research on the effects of deploying DNSSEC, which might be interesting to the people of this wg. you can find it at http://www.nlnetlabs.nl/downloads/dnssec-effects.pdf ------------------------------------------------------------------ Abstract Ripe NCC recently started signing the zones on their DNS servers. This document presents a few measurements of the effects (if any) on the behaviour of the resolvers sending queries to the Ripe nameservers. We have looked at the rate of queries with the DO bit (?use DNSSEC?) set to 1, compared to those with the DO bit set to 0. We have also looked at the number of DNS responses that were truncated. ------------------------------------------------------------------- Jelte Jansen NLnet Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From pim at bit.nl Mon May 15 09:10:06 2006 From: pim at bit.nl (Pim van Pelt) Date: Mon, 15 May 2006 09:10:06 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515070249.GA26086@ripe.net> References: <20060515070249.GA26086@ripe.net> Message-ID: <20060515071006.GB6738@localhost.localdomain> Hoi Katie, One thing caught my eye: > [domain_name] is the fully qualified DNS name of the name server without a > trailing "." Considering 'bfib.ipng.nl' and 'bfib.ipng.nl.' end up pointing to the same hostname (the latter doing a somewhat better job), I don't understand why you would want to specify '... without the trailing "."'. I sometimes bump into this in other (related) areas such as looking up "*.in-addr.arpa.". It was discussed some time ago and IIRC the outcome was that the software is easily modified to accept this trailing dot. I'd prefer to see it that way. Thanks for your efforts, -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From katie at ripe.net Mon May 15 09:02:50 2006 From: katie at ripe.net (Katie Petrusha) Date: Mon, 15 May 2006 09:02:50 +0200 Subject: [dns-wg] Proposal to change the syntax of "nserver:" attribute Message-ID: <20060515070249.GA26086@ripe.net> [Apologies for duplicate mails] Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and update the delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server without a trailing "." [ipv4_address] is an IPv4 address of the name server [ipv6_address] is an IPv6 address of the name server If [domain_name] is followed by an IP address, it must be inside the zone that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.test.net 168.0.0.1 nserver: ns1.test.net 0::0 nserver: ns1.example.com nserver: ns1.d1.example.com All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: DNS checks applicable to glue records will be added to the Zone Delegation Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html) -- Katie Petrusha RIPE NCC From pk at DENIC.DE Mon May 15 10:30:20 2006 From: pk at DENIC.DE (Peter Koch) Date: Mon, 15 May 2006 10:30:20 +0200 Subject: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515070249.GA26086@ripe.net> References: <20060515070249.GA26086@ripe.net> Message-ID: <20060515083020.GB11280@unknown.office.denic.de> Mornin' On Mon, May 15, 2006 at 09:02:50AM +0200, Katie Petrusha wrote: > We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). good! > nserver: [domain_name] /or/ > nserver: [domain_name] [ipv4_address] /or/ > nserver: [domain_name] [ipv6_address] What's the reason not to use one line per server and list all v4 an/or v6 addresses within that one line? > If [domain_name] is followed by an IP address, it must be inside the zone > that is being delegated. Any level of a glue name is supported within the > valid domain name syntax. s/inside the zone/inside the domain, since one might have a name server even in a deeper zone. _Unless_ however this was meant as a requirement, but then I can't understand the second sentence. > domain: example.com > nserver: ns1.test.net 168.0.0.1 > nserver: ns1.test.net 0::0 > nserver: ns1.example.com > nserver: ns1.d1.example.com That should probably read 'domain: test.net' (or better s/test/example/). > Consequences for the delegation checks: > > DNS checks applicable to glue records will be added to the Zone Delegation > Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html) Since I've not found the keyword glue on this page, could these checks be circulated to the dns-wg in advance, please? Thanks, Peter From peter at peter-dambier.de Mon May 15 10:57:24 2006 From: peter at peter-dambier.de (Peter Dambier) Date: Mon, 15 May 2006 10:57:24 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515071006.GB6738@localhost.localdomain> References: <20060515070249.GA26086@ripe.net> <20060515071006.GB6738@localhost.localdomain> Message-ID: <44684274.5080907@peter-dambier.de> Pim van Pelt wrote: > Hoi Katie, > > > One thing caught my eye: > > >>[domain_name] is the fully qualified DNS name of the name server without a >>trailing "." > > Considering 'bfib.ipng.nl' and 'bfib.ipng.nl.' end up pointing to the same > hostname (the latter doing a somewhat better job), I don't understand > why you would want to specify '... without the trailing "."'. I > sometimes bump into this in other (related) areas such as looking up > "*.in-addr.arpa.". It was discussed some time ago and IIRC the outcome > was that the software is easily modified to accept this trailing dot. > I'd prefer to see it that way. > > Thanks for your efforts, > > Hi Pim, the trailing '.' has a very spezial meaning. In hostnames it is simply not allowed. So in /etc/hosts you will not find it. If you ask 'name' then /etc/hosts will be the first to answer. If you ask 'name.' then only DNS will answer. Some browsers and all mailer do this. For DNS (the resolver lib) that '.' means this is an FDN. Dont add the search path to it. That is very importan for the Bind DNS server data files. Regards Peter and Karin Dambier -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de mail: peter at echnaton.serveftp.com http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ From pk at DENIC.DE Mon May 15 15:10:15 2006 From: pk at DENIC.DE (Peter Koch) Date: Mon, 15 May 2006 15:10:15 +0200 Subject: [db-wg] Re: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515095947.GA28870@ripe.net> References: <20060515070249.GA26086@ripe.net> <20060515083020.GB11280@unknown.office.denic.de> <20060515095947.GA28870@ripe.net> Message-ID: <20060515131015.GG11280@unknown.office.denic.de> Hello Katie, > and reject > > domain: test.net > nserver: ns2.example.com 168.0.0.1 > > Hope it is clearer now; any suggestions about better and clearer phrasing > are appreciated. That's fine, the owner name of the glue A/AAAA RR may be at any level greater or equal than the zone to be delegated. But ... > The only new glue-related checks will be: > 1) Making sure all glue IPs listed in domain object are also listed > in the zone at every nameserver ... this test might fail in otherwise correct configurations. Unless explicitly excluded, a glue RR may belong to a zone _below_ the delegated one, so the servers of the delegated zone cannot be expected to authoritatively know the A/AAAA RR(s). I'd not believe this is common in e164.arpa, but than I'd also have thought there's no need for glue in that domain in the first place ... > 2) Glue name must be within the same domain (already listed above) Yep. And the check should include the presence of mandatory glue RRs. With a miced v4/v6 environment, would a name server with v6 only glue be accepted (v4 only obviously is)? How many glue RRs would be allowed per name server entry? -Peter From Niall.oReilly at ucd.ie Mon May 15 17:08:11 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 15 May 2006 16:08:11 +0100 Subject: [db-wg] Re: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515131015.GG11280@unknown.office.denic.de> References: <20060515070249.GA26086@ripe.net> <20060515083020.GB11280@unknown.office.denic.de> <20060515095947.GA28870@ripe.net> <20060515131015.GG11280@unknown.office.denic.de> Message-ID: <74694FBB-5541-4C2D-8FF2-E7266C6D9B51@ucd.ie> On 15 May 2006, at 14:10, Peter Koch wrote: > e164.arpa, but than I'd also have thought there's no need for glue > in that > domain in the first place ... I'm not sure why you'ld think that. One way to do it is like you ppl at DENIC do. 9.4.e164.arpa. 14400 IN NS enum1.denic.de. 9.4.e164.arpa. 14400 IN NS enum2.denic.de. 9.4.e164.arpa. 14400 IN NS enum3.denic.de. It's not the only way. 4.4.e164.arpa. 14400 IN NS ns2.4.4.e164.arpa. 4.4.e164.arpa. 14400 IN NS ns3.4.4.e164.arpa. 4.4.e164.arpa. 14400 IN NS ns4.4.4.e164.arpa. 4.4.e164.arpa. 14400 IN NS ns1.4.4.e164.arpa. Here is even a mixture. 3.5.3.e164.arpa. 14400 IN NS enum1.eu.afilias.info. 3.5.3.e164.arpa. 14400 IN NS ns01.3.5.3.e164.arpa. 3.5.3.e164.arpa. 14400 IN NS ns02.3.5.3.e164.arpa. Some people see the second method as "cleaner". This will need glue. /Niall From katie at ripe.net Mon May 15 09:55:30 2006 From: katie at ripe.net (Katie Petrusha) Date: Mon, 15 May 2006 09:55:30 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515071006.GB6738@localhost.localdomain> References: <20060515070249.GA26086@ripe.net> <20060515071006.GB6738@localhost.localdomain> Message-ID: <20060515075520.GA9031@ripe.net> On Mon, May 15, 2006 at 09:10:06AM +0200, Pim van Pelt wrote: Dear Pim, > One thing caught my eye: > > > [domain_name] is the fully qualified DNS name of the name server without a > > trailing "." > Considering 'bfib.ipng.nl' and 'bfib.ipng.nl.' end up pointing to the same > hostname (the latter doing a somewhat better job), I don't understand > why you would want to specify '... without the trailing "."'. I > sometimes bump into this in other (related) areas such as looking up > "*.in-addr.arpa.". It was discussed some time ago and IIRC the outcome > was that the software is easily modified to accept this trailing dot. > I'd prefer to see it that way. You're right. This is rather a typo :( The names are accepted both with and without trailing dot now; it will stay that way. Thanks for noticing this! -- Katie Petrusha RIPE NCC From katie at ripe.net Mon May 15 11:59:47 2006 From: katie at ripe.net (Katie Petrusha) Date: Mon, 15 May 2006 11:59:47 +0200 Subject: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515083020.GB11280@unknown.office.denic.de> References: <20060515070249.GA26086@ripe.net> <20060515083020.GB11280@unknown.office.denic.de> Message-ID: <20060515095947.GA28870@ripe.net> On Mon, May 15, 2006 at 10:30:20AM +0200, Peter Koch wrote: Dear Peter, > > nserver: [domain_name] /or/ > > nserver: [domain_name] [ipv4_address] /or/ > > nserver: [domain_name] [ipv6_address] > > What's the reason not to use one line per server and list all v4 an/or v6 > addresses within that one line? 'One name per line' syntax seemed to be more clear and short... > > If [domain_name] is followed by an IP address, it must be inside the zone > > that is being delegated. Any level of a glue name is supported within the > > valid domain name syntax. > > s/inside the zone/inside the domain, since one might have > a name server even in a deeper zone. _Unless_ however this was meant as a > requirement, but then I can't understand the second sentence. The intention is to accept something like: domain: test.net nserver: ns1.test.net 168.0.0.1 nserver: ns2.d2.test.net ... etc (glue any level under , like a.b.c.x.y.z.test.net) and reject domain: test.net nserver: ns2.example.com 168.0.0.1 Hope it is clearer now; any suggestions about better and clearer phrasing are appreciated. > > domain: example.com > > nserver: ns1.test.net 168.0.0.1 > > nserver: ns1.test.net 0::0 > > nserver: ns1.example.com > > nserver: ns1.d1.example.com > > That should probably read 'domain: test.net' (or better s/test/example/). yes. > > Consequences for the delegation checks: > > > > DNS checks applicable to glue records will be added to the Zone Delegation > > Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html) > > Since I've not found the keyword glue on this page, could these checks be > circulated to the dns-wg in advance, please? All the DNS checks applicable to the 'normal' nameservers currently will be also applied to the glue nameservers. The only new glue-related checks will be: 1) Making sure all glue IPs listed in domain object are also listed in the zone at every nameserver 2) Glue name must be within the same domain (already listed above) Hopefully that makes it clear. After getting all the comments and corrections, I can resend the updated version of the proposal. -- Katie Petrusha RIPE NCC From Woeber at CC.UniVie.ac.at Mon May 15 13:30:03 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 15 May 2006 11:30:03 +0000 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515075520.GA9031@ripe.net> References: <20060515070249.GA26086@ripe.net> <20060515071006.GB6738@localhost.localdomain> <20060515075520.GA9031@ripe.net> Message-ID: <4468663B.60309@CC.UniVie.ac.at> I presume it was copied form the DB Ref Man, which should be update to reflect relality. :-) I really appreciate the fact that the software accepts the trailing "." for an FQDN. Wilfried. Katie Petrusha wrote: > On Mon, May 15, 2006 at 09:10:06AM +0200, Pim van Pelt wrote: > > Dear Pim, > > >>One thing caught my eye: >> >> >>>[domain_name] is the fully qualified DNS name of the name server without a >>>trailing "." >> >>Considering 'bfib.ipng.nl' and 'bfib.ipng.nl.' end up pointing to the same >>hostname (the latter doing a somewhat better job), I don't understand >>why you would want to specify '... without the trailing "."'. I >>sometimes bump into this in other (related) areas such as looking up >>"*.in-addr.arpa.". It was discussed some time ago and IIRC the outcome >>was that the software is easily modified to accept this trailing dot. >>I'd prefer to see it that way. > > > You're right. This is rather a typo :( > The names are accepted both with and without trailing dot now; > it will stay that way. Thanks for noticing this! > From katie at ripe.net Tue May 16 12:13:53 2006 From: katie at ripe.net (Katie Petrusha) Date: Tue, 16 May 2006 12:13:53 +0200 Subject: [db-wg] Re: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515131015.GG11280@unknown.office.denic.de> References: <20060515070249.GA26086@ripe.net> <20060515083020.GB11280@unknown.office.denic.de> <20060515095947.GA28870@ripe.net> <20060515131015.GG11280@unknown.office.denic.de> Message-ID: <20060516101353.GK8239@ripe.net> On Mon, May 15, 2006 at 03:10:15PM +0200, Peter Koch wrote: Dear Peter, > > domain: test.net > > nserver: ns2.example.com 168.0.0.1 > > > > Hope it is clearer now; any suggestions about better and clearer phrasing > > are appreciated. > > That's fine, the owner name of the glue A/AAAA RR may be at any level > greater or equal than the zone to be delegated. But ... > > > The only new glue-related checks will be: > > 1) Making sure all glue IPs listed in domain object are also listed > > in the zone at every nameserver > > ... this test might fail in otherwise correct configurations. Unless > explicitly excluded, a glue RR may belong to a zone _below_ the delegated > one, so the servers of the delegated zone cannot be expected to > authoritatively know the A/AAAA RR(s). Good point. Instead, this check could be implemented to just give a warning if IPs are not listed or differ. So that user can make sure this is intentional. Would that make sense? Alternative way would be just to omit this check alltogether. > I'd not believe this is common in > e164.arpa, but than I'd also have thought there's no need for glue in that > domain in the first place ... There were already comments about this; I only have to mention that initial request to support ipv6 glue came from e164.arpa users. > > 2) Glue name must be within the same domain (already listed above) > > Yep. And the check should include the presence of mandatory glue RRs. Definitely. > With a miced v4/v6 environment, would a name server with v6 only glue > be accepted (v4 only obviously is)? It seems sensible to accept v6 only glue. Since the checks for ipv6-only nameserver will be done over IPv6, it should be accepted as long as it works. Again, this could be also implemented to give a warning to make sure this is indeed the intention. > How many glue RRs would be allowed per name server entry? How many glue RRs per name server entry would you estimate would be needed? Obviously we will take estimation into account when implementing this. Also, from the operational point of view, would this limit be useful, or could it break something? Any feedback on this is also appreciated. Thanks very much for your comments! -- Katie Petrusha RIPE NCC From andrei at ripe.net Mon May 22 17:31:38 2006 From: andrei at ripe.net (Andrei Robachevsky) Date: Mon, 22 May 2006 17:31:38 +0200 Subject: [dns-wg] Re: Deprecation of ip6.int scheduled for 1 June 2006 In-Reply-To: <4416BA2F.8080809@ripe.net> References: <4416BA2F.8080809@ripe.net> Message-ID: <4471D95A.7010300@ripe.net> Dear Colleagues, This is a reminder that from 1 June 2006, reverse delegations in the ip6.int DNS tree corresponding to IPv6 address space allocated by the RIPE NCC will no longer be supported. On 1 June 2006, RIPE NCC delegations will be deleted from the ip6.int zone. Following this we will remove the zones from the authoritative servers and delete the corresponding DOMAIN objects in the RIPE Whois Database. The maintainers of the DOMAIN objects to be deleted will also receive individual notifications 1 week prior to the deletion. This is being coordinated with other RIRs and is based on an IETF Best Current Practice document (RFC 4159). Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC On 14 March 2006 Andrei Robachevsky wrote: > Dear Colleagues > > In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', > as a Best Current Practice document. The RFC noted that maintenance of > "ip6.int" is no longer needed and called on the Regional Internet > Registries (RIRs) to decide when to stop providing support for the > domain. The RIRs have jointly agreed to do this on 1 June 2006. > > There will be a short presentation on this at the RIPE 52 Meeting in > Istanbul. You can find more information about this meeting at: > > http://www.ripe.net/ripe/meetings/ripe-52/index.html > > Regards > > Andrei Robachevsky > Chief Technical Officer > RIPE NCC > > > > > From ripe-wgs.cs at schiefner.de Tue May 23 17:35:03 2006 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 23 May 2006 17:35:03 +0200 Subject: [db-wg] Re: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515083020.GB11280@unknown.office.denic.de> References: <20060515070249.GA26086@ripe.net> <20060515083020.GB11280@unknown.office.denic.de> Message-ID: <44732BA7.4040705@schiefner.de> Peter Koch wrote: >On Mon, May 15, 2006 at 09:02:50AM +0200, Katie Petrusha wrote: >> We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). > > good! A friendly "Us, too!" on behalf of the ENUM WG Co-Chairs as well. Best, -C. From pk at DENIC.DE Tue May 23 18:45:55 2006 From: pk at DENIC.DE (Peter Koch) Date: Tue, 23 May 2006 18:45:55 +0200 Subject: [db-wg] Re: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060516101353.GK8239@ripe.net> References: <20060515070249.GA26086@ripe.net> <20060515083020.GB11280@unknown.office.denic.de> <20060515095947.GA28870@ripe.net> <20060515131015.GG11280@unknown.office.denic.de> <20060516101353.GK8239@ripe.net> Message-ID: <20060523164555.GC1708@unknown.office.denic.de> Hi, {I keep copying the db-wg on this DNS issue not to split the thread. db chairs, pls advise privately} On Tue, May 16, 2006 at 12:13:53PM +0200, Katie Petrusha wrote: > > ... this test might fail in otherwise correct configurations. Unless > > explicitly excluded, a glue RR may belong to a zone _below_ the delegated > > one, so the servers of the delegated zone cannot be expected to > > authoritatively know the A/AAAA RR(s). > > Good point. Instead, this check could be implemented to just give a > warning if IPs are not listed or differ. So that user can make sure this > is intentional. Would that make sense? Well, in this particular constellation I'd assume the names "glued" are not generic anyway, so after some going back and forth my suggestion is to simply require that the name be authoritatively served from that server. E.g. dns1.9.9.e164.arpa and dns2.0.9.9.e164.arpa should be able to answer queries for A/AAAA RRs for their respective names authoritatively. > > I'd not believe this is common in > > e164.arpa, but than I'd also have thought there's no need for glue in that > > domain in the first place ... > > There were already comments about this; I only have to mention that > initial request to support ipv6 glue came from e164.arpa users. Sure, my remark was not meant to challenge these demands, just that things you never believe to happen in practice eventually will happen :-) > How many glue RRs per name server entry would you estimate would be > needed? Obviously we will take estimation into account when implementing > this. Also, from the operational point of view, would this limit be > useful, or could it break something? Any feedback on this is also > appreciated. Me personally does not "believe" in multi-homed name servers, but I'd really like to read other's opinions. -Peter From katie at ripe.net Tue May 23 15:15:00 2006 From: katie at ripe.net (Katie Petrusha) Date: Tue, 23 May 2006 15:15:00 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515070249.GA26086@ripe.net> References: <20060515070249.GA26086@ripe.net> Message-ID: <20060523131500.GA26494@ripe.net> On Mon, May 15, 2006 at 09:02:50AM +0200, Katie Petrusha wrote: Dear colleagues, [Apologies for duplicate mails] As I've got no further feedback, I am sending below the corrected version of the proposal with all the comments taken into account. Please comment on if something is not clear or wrong. ------------- Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and the updated delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server with or without a trailing "." [ipv4_address] is an IPv4 address of the name server [ipv6_address] is an IPv6 address of the name server If [domain_name] is followed by an IP address, it must be inside the domain that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.example.com 168.0.0.1 nserver: ns1.d1.example.com 0::0 All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: The introduction of the new syntax will add the following new DNS checks for glue records: * every glue record has at least one IPv4 or IPv6 address specified in domain object * glue record name is inside the domain to be delegated -- Katie Petrusha RIPE NCC From sanz at denic.de Wed May 24 15:27:59 2006 From: sanz at denic.de (Marcos Sanz/Denic) Date: Wed, 24 May 2006 15:27:59 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060523131500.GA26494@ripe.net> Message-ID: Katie, > [ipv4_address] is an IPv4 address of the name server > > [ipv6_address] is an IPv6 address of the name server It would be helpful to include details about the accepted syntax for these addresses. For instance: [ipv4_address] is an IPv4 address of the name server in dotted quad form [ipv6_address] is an IPv6 address of the name server in the preferred textual canonical form (Sect 2.2.1, RFC 4291) The IPv6 textual compressed form (Section 2.2.2, RFC 4291) is/is not accepted (cross as necessary). The IPv4/IPv6 textual mixed form (Section 2.2.3, RFC 4291) is/is not accepted (cross as necessary). > nserver: ns1.example.com 168.0.0.1 It would be better to use RFC 3330 documentation IP addresses, e.g. nserver: ns1.example.com 192.0.2.0 Best regards, Marcos P.S. Btw, if non-preferred IPv6 textual forms are accepted, will the output of e.g. whois deliver the original or the preferred form? From dougb at dougbarton.us Thu May 25 19:43:10 2006 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 25 May 2006 10:43:10 -0700 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: References: Message-ID: <4475ECAE.80205@dougbarton.us> Marcos Sanz/Denic wrote: > P.S. Btw, if non-preferred IPv6 textual forms are accepted, will the > output of e.g. whois deliver the original or the preferred form? In my experience this is a good place to apply the principle, "Be liberal in what you accept, and conservative in what you send." It would be more convenient to users if you accepted many different forms of IPv6 address, and more convenient for consumers of the data if those addresses were canonicalized into the full form of the address as in section 2.2.1 of RFC 4291. IMHO, Doug -- If you're never wrong, you're not trying hard enough From jeroen at unfix.org Thu May 25 19:58:15 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 25 May 2006 19:58:15 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <4475ECAE.80205@dougbarton.us> References: <4475ECAE.80205@dougbarton.us> Message-ID: <1148579895.22101.6.camel@firenze.zurich.ibm.com> On Thu, 2006-05-25 at 10:43 -0700, Doug Barton wrote: > Marcos Sanz/Denic wrote: > > > P.S. Btw, if non-preferred IPv6 textual forms are accepted, will the > > output of e.g. whois deliver the original or the preferred form? > > In my experience this is a good place to apply the principle, "Be liberal in > what you accept, and conservative in what you send." It would be more > convenient to users if you accepted many different forms of IPv6 address, > and more convenient for consumers of the data if those addresses were > canonicalized into the full form of the address as in section 2.2.1 of RFC > 4291. As RFC4291, 2.2.1 is not really a section, I assume you mean: 8<---------------------------------------------------- 2.2. Text Representation of Addresses There are three conventional forms for representing IPv6 addresses as text strings: 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address. Examples: ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 2001:DB8:0:0:8:800:200C:417A Note that it is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in every field (except for the case described in 2.). ----------------------------------------------------->8 And thus when I submit "whois -h whois.ripe.net 2001:0db8:1234/64" it would return an inet6num with (the /48 exists, the /64 doesn't) : 2001:db8:1234::/48 Is that what you meant? From my point of view, what I do is *always* rewrite the addresses to the compressd form and in lowercase (caps are to screamish ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From dougb at dougbarton.us Thu May 25 20:40:11 2006 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 25 May 2006 11:40:11 -0700 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <1148579895.22101.6.camel@firenze.zurich.ibm.com> References: <4475ECAE.80205@dougbarton.us> <1148579895.22101.6.camel@firenze.zurich.ibm.com> Message-ID: <4475FA0B.5070605@dougbarton.us> Jeroen Massar wrote: > On Thu, 2006-05-25 at 10:43 -0700, Doug Barton wrote: >> Marcos Sanz/Denic wrote: >> >>> P.S. Btw, if non-preferred IPv6 textual forms are accepted, will the >>> output of e.g. whois deliver the original or the preferred form? >> In my experience this is a good place to apply the principle, "Be liberal in >> what you accept, and conservative in what you send." It would be more >> convenient to users if you accepted many different forms of IPv6 address, >> and more convenient for consumers of the data if those addresses were >> canonicalized into the full form of the address as in section 2.2.1 of RFC >> 4291. > > As RFC4291, 2.2.1 is not really a section, I was using the same notation that Marcos had used. And yes, that was what I was referring to. > And thus when I submit "whois -h whois.ripe.net 2001:0db8:1234/64" > it would return an inet6num with (the /48 exists, the /64 doesn't) : > > 2001:db8:1234::/48 > > Is that what you meant? No. I was referring specifically to the case at hand, IPv6 addresses used as glue records. In my opinion, having the addresses always be canonicalized to the full form (not the compressed form) is easier to deal with on a number of levels, including db design, and inclusion in the DNS being the most important. > From my point of view, what I do is *always* rewrite the addresses > to the compressd form and in lowercase (caps are to screamish ;) I definitely agree with lowercasing the addresses. hth, Doug -- If you're never wrong, you're not trying hard enough From jeroen at unfix.org Thu May 25 21:08:59 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 25 May 2006 21:08:59 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <4475FA0B.5070605@dougbarton.us> References: <4475ECAE.80205@dougbarton.us> <1148579895.22101.6.camel@firenze.zurich.ibm.com> <4475FA0B.5070605@dougbarton.us> Message-ID: <1148584139.22101.27.camel@firenze.zurich.ibm.com> On Thu, 2006-05-25 at 11:40 -0700, Doug Barton wrote: > Jeroen Massar wrote: > > On Thu, 2006-05-25 at 10:43 -0700, Doug Barton wrote: > >> Marcos Sanz/Denic wrote: [..] > > And thus when I submit "whois -h whois.ripe.net 2001:0db8:1234/64" > > it would return an inet6num with (the /48 exists, the /64 doesn't) : > > > > 2001:db8:1234::/48 > > > > Is that what you meant? > > No. I was referring specifically to the case at hand, IPv6 addresses used as > glue records. In my opinion, having the addresses always be canonicalized to > the full form (not the compressed form) is easier to deal with on a number > of levels, including db design, and inclusion in the DNS being the most > important. Compressed/uncompressed is a representation method, the parser which reads/exports into/from the database should not give anything about the external representation and can represent it differently internally. If you would argue for uncompressed being easier to parse by a program, then one should maybe better propose to store it completely in binary, hashtrees etc come to mind ;) Programs should use the OS provided, getaddrinfo() and inet_ntop() functions, these afaik on all platforms support any input format and print out usually compressed formats. In case most of the bits of an IPv6 address are used then there is no difference in compressed/uncompressed form, thus there is not much of an argument there for me. In DNS they are represented as 128-bit binary values, thus there is nothing to pick for representation. The tool that reads/writes should do it in a standard way, but there is no way of changing all tools and I've already soon too much that tools do it their own way, not using the OS provided interface or capsing the string etc. In the end for tool writers, as said before, be liberal in what you get -> rewrite the input to what you require. One thing there though, if you query the RIPE database, which I tend to do a lot, inet6num's are always different, even when created by the NCC, the format is sort of the same, but the contents are wildly variating, sometimes in compressed format, otherwise not, sometimes caps, sometimes not. It would be great to have a single format coming out of whois, if that would only help hurt the eyes a bit. Personally though I prefer the compressed form, as that is how I have been representing a lot of IPv6 addresses for a long time now. But as said that is a personal opinion of taste. Thus my 'vote': represent with compressed lowercase. But I could live with uncompressed too, as long as it would be done then also everywhere in a consistent fashion. Most inet6nums are compressed fortunately ;) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: This is a digitally signed message part URL: From pk at DENIC.DE Thu May 25 21:44:37 2006 From: pk at DENIC.DE (Peter Koch) Date: Thu, 25 May 2006 21:44:37 +0200 Subject: [dns-wg] DRAFT meeting minutes DNS WG @RIPE52 Message-ID: <20060525194437.GB17032@denics7.denic.de> Dear DNS WG, here are the draft meeting minutes for Istanbul. Please have a look at the text and send comments or requests for changes to the wg chairs until June, 17th. You'll find the list of five new action items at the end. Please verify the transcript, especially if you're quoted or have (been) volunteered for an action. Thanks to Adrian for providing the minutes (in time); all typos are mine. -Peter ----------------------------------------------------------------------------- DRAFT RIPE DNS WG minutes for RIPE 52, Istanbul ----------------------------------------------------------------------------- WG: DNS Meeting: RIPE 52, Istanbul Date-1: Thursday, 27 April 2006 Time-1: 11:00 - 12:30 (UTC +0300) Chair-1: Peter Koch Minutes-1: Adrian Bedford Jabber: xmpp:dns at conference.ripe.net J-Scribe-1: Susannah Gray J-Script-1: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/dns.txt Audio-1: http://www.ripe.net/ripe/meetings/ripe-52/podcasts/dns-01.mp3 WG URL: http://www.ripe.net/ripe/wg/dns/ Material: http://www.ripe.net/ripe/meetings/ripe-52/presentations/index.html Agenda: http://www.ripe.net/ripe/meetings/ripe-52/agendas/dns.html ----------------------------------------------------------------------------- 0) Administrivia To remove the need for changeover between presenters, Andrei asked that items 4 and 5 be switched. The WG agreed to this. There were no other changes to the agenda. ----------------------------------------------------------------------------- 1) Status Reports o IANA Overview (David Conrad, IANA) Daniel Karrenberg commented on the proposed new IANA website, he was interested to see it was a draft and that feedback was encouraged. Jim Reid asked about the IDN testing and wondered if this would happen within the root zone or if there would be a test bed. David replied that this would be discussed in more depth in the next slot. If it were to happen within the root zone, IANA would be involved; otherwise they would not have a role in this. o IETF - DNSEXT, DNSOP and Others (Olaf Kolkman, NLnetLabs) Ed Lewis asked about experiences people had with split view DNS. Around 15 people said that they had. He also wondered if people who had inherited systems found them confusing. His questions lead him to ask how important the IETF documents were on this topic. Although the particular draft (draft-krishnaswamy-dnsop-dnssec-split-view) was more than a year old, there had been little comment. Olaf replied that there is a need for people to commit to work with the DNSEXT and DNSOP working groups and review papers. If there are not five people willing to do this, then the work is stalled. Carsten Schiefner asked if there was any relationship between the nameserver ID flag (draft-ietf-dnsext-nsid) and Host Identity Protocol (HIP). Olaf explained there was no relationship. Daniel Karrenberg commented that if using split DNS, it is vital to review your work regularly. The deployments out there use different nameservers to make for easier debugging. He added that maybe there is no current solution to the problem. o DNSSEC News/Statistics from the NCC (Brian Riddle, RIPE NCC) Daniel Karrenberg suggested the RIPE NCC prepare a presentation on the causes of the extra network traffic (in excess of the predicted growth) for the next RIPE Meeting. This was accepted as an action item. Jim Reid asked what might be causing the additional 4% of CPU cycles. Brian promised to investigate and report back. Ed Lewis asked about registration activity and requested that the RIPE NCC report on how many signed zones and how many signed delegations exist in the NCC maintained reverse tree. Brian agreed to look into this and report back either through the working group mailing list or at the next meeting. Olaf commented that when writing ripe-352, the authors promised to look at the effects of DNSSEC on the amount of due queries. A paper on this is ready for publication on the NLnetLabs website. (post meeting hint: ----------------------------------------------------------------------------- 2) Action Item Review (Peter Koch) 48.1 This is still to be written up - ongoing 48.2 Mans had made some progress, he will continue the work, including a SIG(0) approach and hopes to complete the work by the next RIPE Meeting - ongoing 49.1 This is on hold as a presentation is being made to the NCC Services Working Group. 49.2 Some work has been done. Jim will circulate a draft to Fernando and the DNS WG co-chairs in the coming weeks. - ongoing 51.1 see plenary presentation on K-root 51.2 see (4) 51.3 Liman has still to write this up. It will possibly be handed over to the NCC Services Working Group. For now it will stay with this group until there is further clarification on the proposal. - ongoing 51.4 - ongoing 51.5 see (6) ----------------------------------------------------------------------------- 3) Anycast on K-Root (Lorenzo Colitti, RIPE NCC) Daniel Karrenberg noted that he hoped everyone was happy with how the RIPE NCC was running K. Andrei later amplified this and outlined a few plans to deploy a further global node on the west coat of the US and then gradually more local nodes. They would look at where successful local nodes existed. He wanted to know that the community supported these plans. Comments were made that local nodes tended to have greater impact when deployed in places where there were no global nodes and in more remote locations. Daniel thanked him for these comments, but wished to point out that global nodes are paid for by the RIPE NCC as the operator, local nodes have a contribution made by local hosts. There was a question about whether the RIPE NCC could look into doing some work to compare experiences and impacts gained by other root operators and look at different set-ups in use. Lorenzo said he would personally find this interesting. Daniel Karrenberg backed this by saying he felt it would be useful work. He asked that anyone with suggestions should contact Lorenzo directly. Randy Bush wished to state that he was happy with how the service had been running so far. He had reported a bug and was encouraged by the response from the RIPE NCC to resolve the issue. ----------------------------------------------------------------------------- 5) Reverse DNS Quality (Brian Riddle, RIPE NCC) George Michealson commented that it was interesting that Brian felt the difference in measure might come down to methodology. He added that it might just be that APNIC have a higher level of lameness than the RIPE NCC. He attributed some of this to stronger admission controls within the domain update process. APNIC have discussed both tightening and weakening their rules. He concluded by saying that the reason that APNIC had 13% lame, compared with 9% in RIPE, came down to better running of the DNS. Olaf asked what definition was used of lames. Brian replied that a record was seen as lame whenever there was no authoritative answer for the SOA. Jim Reid observed that lameness will always be with us. We need to look at ways of dealing with it rather than keep trying to eliminate it completely. He did feel that we needed to do something from a point of view of operational impact and the resultant load that lameness placed on servers. It would be a good step to alleviate problems rather than just keep insisted to everyone that they should keep their DNS in good order. This presentation, he added, was follow-on from an incident that Jim noticed and flagged to the RIPE NCC. There was a lame delegation caused by a master being unathoritative for an extended period of time. There is a need to look at the issues around the progression of a slave secondary service, a part of doing this job responsibly is having some kind of policy and escalation mechanism for flagging lame master servers. This would make sure something is done before a zone expires on the slave servers. Carsten Schiefner said he would like to see some measures in place to check whether the nameserver set of the parent exactly matches the nameserver set announced by the master of the zone. People can change their configuration all the time and there can be nothing on the master server of the child zone. He felt that monitoring this exact match would be an issue, particularly if these changes are also to be applied for ENUM zones. Peter Koch declared this out of scope for this discussion. Ed Lewis asked what would be done when something is lame and gives no response, should it be taken out of DNS and remove the NS record. Brian asked for the community to give guidance on this. Peter Koch suggested that there be an action on the RIPE NCC to post their questions and write up a proposal and question to submit to the working group mailing list. This would be discussed further offline and formulated as action point. ----------------------------------------------------------------------------- 4) IP6.INT Phase Out (Andrei Robachevski, RIPE NCC) There was a short discussion about the best way forward with this. A major concern was that all RIRs should coordinate their work to ensure that all IP6.INT delegations are pulled at the same time. David Conrad commented that as maintainer of the .INT domain he had asked about the impact of simply pulling IP6.INT through various mailing lists. He had seen little in the way of significant negative implications suggested if this happened. He was backed up on this by George Michealson, who commented that he had spent some time trying to find any IP6.INT queries without success. Joao and Daniel noted that if something serves no purpose, then it should go. There was a note of caution sounded by David Conrad. RIRs must work together and agree on a date for this to happen. David Kessens commented that it would be useful to discuss this topic further in the IPv6 Working Group later today. ----------------------------------------------------------------------------- 6) Proposal to Bring ENUM Zone Management in Line with the Reverse DNS (Andrei Robachevski, RIPE NCC) Carsten Schiefner commented that he welcomed this proposal. Jim Reid stated that care was needed when it came to the top delegations under E164.ARPA concern national resources. There are issues of sovereignty and national interests. If we are going to report errors in the delegations, we need to handle it with a degree of sensitivity. It could impact on other things that are not directly connected with the RIPE NCC. Andrei replied that it was equally dangerous to keep errors in the delegation. Appropriate checks will stop the errors from propagating into the system. Daniel Karrenberg stressed that the RIPE NCC was sensitive to the issues, but the priority had to be to keep things working. The IAB would be informed as the party responsible for E164.ARPA. Carsten felt the actions remained unclear and that it was up to the group to define the actions. 51.5 was changed to 52.5 to work together to put forward a semi proposal, or a pre-formal proposal on this and the ENUM WG lists and coordinate between the two groups. Andrei saw two parts of the proposal. One side involved automating and making the existing system less error prone, this is just a call to improve the system. The other side was to look at doing regular lameness checks and looking at how the RIPE NCC should act on these. An action was put on Carsten to come up for a more formal proposal for discussion at working group level, it was felt this should not yet be put forward at the more formal level of the RIPE Policy Development Process. Andrei asked for consensus that this should go through to the Database Working Group to have the RIPE NCC automate checks. There was no objection. ----------------------------------------------------------------------------- Date-2: Thursday, 27 April 2006 Time-2: 16:00 - 17:00 (UTC +0300) Chair-2: Jaap Akkerhuis Minutes-2: Adrian Bedford J-Scribe-2: Caz Merrison J-Script-2: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/dns.txt Audio-2: http://www.ripe.net/ripe/meetings/ripe-52/podcasts/dns-02.mp3 ----------------------------------------------------------------------------- 7) Plenaries Followup Time was given to discussions that followed on from presentations that happened during the plenary. There were several DNS related presentations in the plenary, of which "Security and ENUM" had been discussed in the ENUM Working Group. There was no feedback or questions from the room on any of those presentations. ----------------------------------------------------------------------------- 8) ICANN IDN guidelines & IDN Future (Marcos Sanz, DENIC) During the presentation Patrik F?ltstr?m asked about the issue that arises when, for example, URLs such as deutschebank.de and deutsche-bank.de occurs. He wondered if this was the end of the problem. Marcos replied that he did not feel it was. Rob Blokzijl commented that although the presenter started out by saying it was unwise to look at domain name labels as words, he went on to talk about the confusion that occurs when this happens. Marcos agreed, pointing out that he was talking merely about the ICANN guidelines. There are assumptions made about what is in a domain name and he felt this was not the right direction to follow. Rob noted that language is a very rich thing and trying to constrain it in domain names was unwise. He did not feel that any rules or regulations would help. Olaf encouraged everyone to take a look at the IAB document which touched on the same type of issues raised here. It will be published after 17 May 2006. ----------------------------------------------------------------------------- 9) Dynamic Registry Updates (John Dickinson, Nominet) Jaap Akkerhuis asked if the work mentioned was available for public use. John replied that it was. Jim Reid asked if tools had been used to inspect the contents of journal files. John replied that this area had been left alone. He also wondered what type of sanity checking was in place when managing the updates. John replied that currently, all existing information was removed from zone files and then the updates made within the same transaction to avoid any errors or duplicate entries. Peter Koch asked for clarification on the point made that updates ran in batches of 500. John explained that updates happened every minute. Whatever was there was automatically updated, if there was less than 500, it would run anyway, if there were more than 500, they would be processed in consecutive batches of a maximum of 500 updates. The discussion then moved onto reliance on transfer methods, John stressed that backup methods were in place where there were potentials for communication errors. It was stressed that this was not to be seen as real-time dynamic updating. The TTL and SOA values had not been adjusted and there were no plans to do this. ----------------------------------------------------------------------------- X) I/O with other WGs ENUM related issues were already covered under (6). ----------------------------------------------------------------------------- Y) AOB Peter Koch wished to follow up on a discussion in the Plenary. An Internet Draft will soon be published addressing both reflection and amplification attacks. He encouraged everyone here to read this and comment on it through both the DNS WG Mailing List and also through the IETF DNSOP List. A show of hands suggested a need to cross post the announcement about the draft. ----------------------------------------------------------------------------- Z) Wrap-Up & Close Jaap summarized the action items: 52.1 RIPE NCC: investigate causes for extra DNSSEC network traffic (in excess of the predicted growth) and extra CPU cycles 52.2 RIPE NCC: report number of signed zones and signed delegations in the reverse tree 52.3 RIPE NCC: post questions and proposal to wg mailing list on how to deal with secondary service at ns*.ripe.net in case the master (the relevant *xfr source) is not responsive and the zone is about to expire [this is related to 48.1, but differs in that it should suggest ways forward for ns*.ripe.net] 52.4 RIPE NCC: automate and streamline the process for ENUM delegations, including checks similar to those applied to the reverse tree 52.5 Carsten Schiefner: [continued from 51.5] write a proposal for performing regular lameness checks in E164.ARPA and actions to follow ----------------------------------------------------------------------------- From dougb at dougbarton.us Fri May 26 00:46:48 2006 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 25 May 2006 15:46:48 -0700 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <1148584139.22101.27.camel@firenze.zurich.ibm.com> References: <4475ECAE.80205@dougbarton.us> <1148579895.22101.6.camel@firenze.zurich.ibm.com> <4475FA0B.5070605@dougbarton.us> <1148584139.22101.27.camel@firenze.zurich.ibm.com> Message-ID: <447633D8.3040102@dougbarton.us> Jeroen Massar wrote: > Compressed/uncompressed is a representation method, the parser which > reads/exports into/from the database should not give anything about the > external representation and can represent it differently internally. > If you would argue for uncompressed being easier to parse by a program, > then one should maybe better propose to store it completely in binary, > hashtrees etc come to mind ;) Programs should use the OS provided, > getaddrinfo() and inet_ntop() functions, these afaik on all platforms > support any input format and print out usually compressed formats. Assuming all elements of your argument above are correct, I believe that this supports my suggestion. If you can deal with the addresses programatically regardless of the storage method, this is an argument (in my mind/experience) for storing them in a consistent, lowest common denominator format (read, human-parsable), such as the full, uncompressed form. > One thing there though, if you query the RIPE database, which I tend to > do a lot, inet6num's are always different, even when created by the NCC, > the format is sort of the same, but the contents are wildly variating, > sometimes in compressed format, otherwise not, sometimes caps, sometimes > not. It would be great to have a single format coming out of whois, if > that would only help hurt the eyes a bit. Yes, this is exactly the kind of problem I'd like to see avoided, given that this part of the db must be rewritten anyway. > Thus my 'vote': represent with compressed lowercase. > But I could live with uncompressed too, as long as it would be done then > also everywhere in a consistent fashion. On that we are in complete agreement. Regards, Doug -- If you're never wrong, you're not trying hard enough From sanz at denic.de Fri May 26 09:51:33 2006 From: sanz at denic.de (Marcos Sanz/Denic) Date: Fri, 26 May 2006 09:51:33 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <4475ECAE.80205@dougbarton.us> Message-ID: Doug, > In my experience this is a good place to apply the principle, "Be liberal in > what you accept, and conservative in what you send." It would be more > convenient to users if you accepted many different forms of IPv6 address, > and more convenient for consumers of the data if those addresses were > canonicalized into the full form of the address as in section 2.2.1 of RFC > 4291. I agree. And not only for the consumers, but also for the repository itself (no need to *additionally* store the original textual input, but only a normalized internal representation). Whether the full form address is capitalized or not, I wouldn't mind at this stage. These comments applied originally only to the IPv6 glue of nservers, but as Jeroen pointed out, inet6num objects would benefit from the suggestion, too. Regards, Marcos From jay at nominet.org.uk Fri May 26 10:33:02 2006 From: jay at nominet.org.uk (Jay Daley) Date: Fri, 26 May 2006 09:33:02 +0100 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: Message-ID: If it helps, in .uk we accept in any format, including dotted quad embedded in ipv6 and always output in compressed lower case. If you want an example see the whois entry for ml-associates.co.uk Jay From pk at DENIC.DE Fri May 26 10:51:39 2006 From: pk at DENIC.DE (Peter Koch) Date: Fri, 26 May 2006 10:51:39 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: References: Message-ID: <20060526085139.GA24306@denics7.denic.de> On Fri, May 26, 2006 at 09:33:02AM +0100, Jay Daley wrote: > If it helps, in .uk we accept in any format, including dotted quad > embedded in ipv6 and always output in compressed lower case. If you want > an example see the whois entry for ml-associates.co.uk just for clarification: you're _not_ accepting "IPv4-Compatible IPv6 Addresses" or "IPv4-Mapped IPv6 Addresses", are you? -Peter From jay at nominet.org.uk Fri May 26 11:17:57 2006 From: jay at nominet.org.uk (Jay Daley) Date: Fri, 26 May 2006 10:17:57 +0100 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060526085139.GA24306@denics7.denic.de> Message-ID: Peter > > If it helps, in .uk we accept in any format, including dotted quad > > embedded in ipv6 and always output in compressed lower case. If you want > > an example see the whois entry for ml-associates.co.uk > > just for clarification: you're _not_ accepting "IPv4-Compatible IPv6Addresses" > or "IPv4-Mapped IPv6 Addresses", are you? We are accepting IPv6 addresses where the last four octets are given in dotted quad notation. So of the form 2001::0010:192.168.1.1 We had a very long discussion about this with a registrar quoting RFCs back and forth and in the end agreed to do it. Jay From pk at DENIC.DE Fri May 26 12:31:51 2006 From: pk at DENIC.DE (Peter Koch) Date: Fri, 26 May 2006 12:31:51 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: References: <20060526085139.GA24306@denics7.denic.de> Message-ID: <20060526103151.GA5627@denics7.denic.de> On Fri, May 26, 2006 at 10:17:57AM +0100, Jay Daley wrote: > dotted quad notation. So of the form 2001::0010:192.168.1.1 We had a > very long discussion about this with a registrar quoting RFCs back and > forth and in the end agreed to do it. yes, that won't hurt - whatever it's good for. The examples in section 2.2 of RFC 4291 show this format only for ::192.0.2.1 or ::FFFF:192.0.2.1 type addresses (without limiting it explicitly), and I'd rather not accept those. Whether or not the output format should be canonicalized is a different issue. Once you start it, it could be applied elsewhere (strip the trailing dot in domain names, adjust zip codes), but that's more the db wg's business. -Peter