Re: [dns-operations] summary of recent vulnerabilities in DNS security.
On 23.10.13 22:17, Haya Shulman wrote: Sorry for the brief description earlier, fyi, a slightly more elaborate design: The idea is to replace a single middle fragment, e.g., given n fragments, for n2, we replace some fragment, s.t., 1 i n. Assume n=3 (and also assume, for simplicity, that fragments arrive in order - adjusting for the general case is straightforward). I want to replace fragment i=2 with a spoofed 2nd fragment. The challenge is to place the spoofed 2nd fragment in IP defragmentation cache, such that it is (1) reassembled with the first fragment, but, (2) not overwritten by the 2nd legitimate fragment. If the attacker plants a spoofed second fragment in a defragmentation cache, it will be reassembled with the 1st authentic, but then will be overwritten by the legitimate 2nd fragment that will subsequently arrive. To ensure that the spoofed second fragment is not overwritten (by the 2nd legitimate fragment), we should set its offset to some lower value (i.e., this results in a gap - that has to be filled - in the resulting reassembled packet). Then when the 3rd (authentic) fragment arrives, it is further reassembled with them (1st and spoofed 2nd). What remains to do, is to fill the missing gap in 2nd fragment. So, to launch this, the attacker has to send two fragments: a spoofed 2nd fragment (which offset is lower than the offset of the authentic second fragment) before (or right after) triggering the DNS request, and after the thre fragments (authentic 1st, 3rd and spoofed 2nd) are reassembled a small fragment is sent to fill the missing bytes (in the spoofed 2nd fragment). Then the packet is ready to leave the IP defragmentation cache. This is not an attack on DNS, but an attack on IP reassembly technology. Which might work or not work depending on how the particular TCP/IP stack functions. This attack affects any IP based protocol and therefore should in no case be labeled DNS vulnerability. This is essentially an IP packet modification vulnerability and in order to do these, you don't even need fragmentation. This might happen even due to malfunctioning network adapter or other network device, not necessarily an attack. One of the reasons for DNSSEC existence is to prevent processing of damaged DNS data, with malicious origin or not. If you are concerned with improperly assembled IP packets, the DNS community is the wrong place to ask for a fix. The DNS community can only make sure their protocol takes care of such issues, and issues like this are totally addressed by technologies such as DNSSEC, TSIG etc. But the fundamental fix for this issue has to happen in the TCP/IP stack. a side by side reading of your earlier draft (http://arxiv.org/pdf/1205.4011.pdf) and your current draft: https://0a94266f-a-62cb3a1a-s-sites.googlegroups.com/site/hayashulman/files/fragmentation-poisoning.pdf?attachauth=ANoY7cpB1yJsBXMWL0_spxDjUMV9m5G_TjI98UgJE6OtoP98H-WrlRJ2AyJVhajdZ5za2vjZ14twuMHuB7NUcRW_EYv36scybuofLgPOwoU2Rvs7zpSnm_Qj3jA3noSc3ibX9b9_7tncZJdGca0FLY8SOrzMTY_O5bd0NPcwBXtDx9vtCjbRisMFf48MiOYFNO-66BY3iyGa584pJ0Sy2vYfI5ZKKCmvJhJsmY96N4XChK5cGgky8eg%3Dattredirects=0 ...shows a remarkably different attitude toward dnssec. what led to your reconsideration? Your observation is correct. Initially it seemed that large responses were a consequence of DNSSEC. But, then we found other techniques to cause fragmentation, not related to DNSSEC, like spoofed ICMP fragmentation needed (reduces the MTU beyond 1.5KB - and removes the requirement of large responses), and malicious domains (created by the attacker), with large responses. This made it clear that the attacks were not an artifact of DNSSEC. On the other hand, DNSSEC prevents these (and other known and future, unforeseen) attacks against DNS. No technology, including DNSSEC claims to protect against future unforeseen attacks. DNSSEC in this case simply ignores packets that have invalid cryptographic signatures, for whatever reason. There might be other attacks on DNS that DNSSEC might not be able to defend against. Daniel ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
It helps to return the NSEC3 record that proves that the wildcard name does not exist. 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: in authvalidated 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: resuming nsecvalidate 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: looking for relevant NSEC3 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: looking for relevant NSEC3 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: NSEC3 proves name does not exist: 'www.xn--80aswg' 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: NSEC3 indicates potential closest encloser: 'xn--80aswg' 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: NSEC3 at super-domain xn--80aswg 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: in checkwildcard: *.xn--80aswg 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: looking for relevant NSEC3 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: NSEC3 at super-domain xn--80aswg 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: in checkwildcard: *.xn--80aswg 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: nonexistence proof(s) not found 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: checking existence of DS at 'xn--80aswg' 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: checking existence of DS at 'www.xn--80aswg' 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: continuing validation would lead to deadlock: aborting validation 25-Oct-2013 00:36:21.420 validating @0x7fc374c8dc00: www.xn--80aswg DS: deadlock found (create_validator) In message ce8e9611.39370%y...@isoc.org, Dan York writes: On 10/24/13 9:12 AM, Chris Thompson c...@cam.ac.uk wrote: At 13:01 23-10-2013, Edward Lewis wrote: My sensors show 4 new gTLDs in the last hour or so...IDN, non-ccTLD...added between 1800 and 1900 UTC. Not mentioned yet is that all four appeared already signed and with DS records in the root zone. Funny you should mention that... I just published a post this morning promoting that fact: http://www.internetsociety.org/deploy360/blog/2013/10/4-newgtlds-launched-y esterday-marks-dawn-of-dnssec-from-the-start-tlds/ From a DNSSEC-advocacy point of view, this is a great step forward as all new domains registered under these newgTLDs will at least have the *option* of being secured by DNSSEC. But... the two Cyrillic gTLDs (xn--80asehdb xn--80aswg) are a bit broken, in that NXDOMAIN responses don't validate properly. Neither dnssec-debugger.verisignlabs.com nor dnsviz.net are able to analyse validations problems for NXDOMAIN responses, so I am not quite sure why yet, but e.g. dig +dnssec www.xn--80asehdb. dig +dnssec www.xn--80aswg. give SERVFAILs which can be avoided by adding the +cd option. Hmmm... interesting. Perhaps some work is still needed on the operational front there... Dan -- Dan York Senior Content Strategist, Internet Society y...@isoc.org mailto:y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.org mailto:y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
On Thu, Oct 24, 2013 at 02:12:10PM +0100, Chris Thompson c...@cam.ac.uk wrote a message of 28 lines which said: Neither dnssec-debugger.verisignlabs.com nor dnsviz.net are able to analyse validations problems for NXDOMAIN responses, DNSviz does not do it by default but you can activate it (DNSSEC options then Denial of existence http://dnsviz.net/d/xn--80asehdb/dnssec/?rr=alla=allds=alldoe=onta=.tk= ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What do you call them?
On 10/24/13 16:08, Edward Lewis wrote: Throwing this out on the table for discussion... In the sense we (the dns operations industry/community) see .com and can say that out loud today Or type it. I mean, searching on http://www.iana.org/domains/root/db hasn't become much easier either. -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What do you call them?
Edward Lewis (ed.lewis) writes: That's you1xi4 in pinyin (I'll omit the characters as they might not render in all email readers) [...] So - what will the dns operations community use to name these TLDs when there are issues with the new gTLDs that are in the xn-- category ? Part of the question is answered by your first remark. If some mail readers (and other applications!) can't render/show 游戏, then we're back at using the ASCII and therefore the ACE name when discussing technical issues / inquiries. This may seem western-centric, but I doubt that Arabic readers (or others not using roman character sets) are in a better position to discuss issues around 游戏, for instance. I may suggest using both the ACE + the real representation. Shouldn't be necessary in 2013, but... .xn--unup4y/.游戏 validates, while .xn--80aswg/.сайт doesn't Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
On Oct 24 2013, Dan York wrote: On 10/24/13 9:12 AM, Chris Thompson c...@cam.ac.uk wrote: At 13:01 23-10-2013, Edward Lewis wrote: My sensors show 4 new gTLDs in the last hour or so...IDN, non-ccTLD...added between 1800 and 1900 UTC. Not mentioned yet is that all four appeared already signed and with DS records in the root zone. Funny you should mention that... I just published a post this morning promoting that fact: http://www.internetsociety.org/deploy360/blog/2013/10/4-newgtlds-launched-y esterday-marks-dawn-of-dnssec-from-the-start-tlds/ There have been a few new TLDs signed from the start before this dawn. I may have missed some, but these certainly were: sx on 2011-12-10 (ccTLD for Sint Maarten) post on 2012-08-08 xn--mgbx4cd0ab on 2012-09-21 (IDN for MY = Malaysia) xn--l1accon 2013-08-18 (IDN for MN = Mongolia) (the dates may suffer from off-by-one-or-even-more errors). The last of those is a sad case, however, as a few days after its initial appearance they performed a KSK rollover, omitting to change the DS records in the root zone, and the zone has failed validation ever since. From a DNSSEC-advocacy point of view, this is a great step forward as all new domains registered under these newgTLDs will at least have the *option* of being secured by DNSSEC. But... the two Cyrillic gTLDs (xn--80asehdb xn--80aswg) are a bit broken, in that NXDOMAIN responses don't validate properly. Neither dnssec-debugger.verisignlabs.com nor dnsviz.net are able to analyse validations problems for NXDOMAIN responses, so I am not quite sure why yet, but e.g. dig +dnssec www.xn--80asehdb. dig +dnssec www.xn--80aswg. give SERVFAILs which can be avoided by adding the +cd option. Hmmm... interesting. Perhaps some work is still needed on the operational front there... Part of the problem is that only one NSEC3 record is returned - the one covering the zone apex, which doesn't necessarily cover the name queried for. But validation seems to fail even in cases when the name is so covered. -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
Hi, On Wed, Oct 23, 2013 at 01:11:43PM -0700, Rick Wesson r...@support-intelligence.com wrote: Does ICANN have a root-zone announce list? https://mm.icann.org/mailman/listinfo/gtldnotification perhaps? Meanwhile practising on my pronunciation: http://translate.google.com/#auto/nl/%E6%B8%B8%E6%88%8F 'Yoshi' or something -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
-Ursprungligt meddelande- Från: dns-operations-boun...@lists.dns-oarc.net [mailto:dns-operations- boun...@lists.dns-oarc.net] För Stephane Bortzmeyer Skickat: den 24 oktober 2013 15:56 Till: Rick Wesson Kopia: DNS Operations; Edward Lewis Ämne: Re: [dns-operations] It's begun... Email lists are so last-century :-) IANA has Twitter https://twitter.com/RootChanges Twitter is so last year. Kind regards, Anne-Marie Eklund Löwinder PGP.sig Description: PGP signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
On Oct 24 2013, I wrote: [...] Part of the problem is that only one NSEC3 record is returned - the one covering the zone apex, which doesn't necessarily cover the name queried for. But validation seems to fail even in cases when the name is so covered. Ah - Mark Andrews' post points out why that is. *.xn--80asehdb (for example) isn't covered by the sole NSEC3 returned, even if the queried name is. -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What do you call them?
Edward Lewis writes: So - what will the dns operations community use to name these TLDs when there are issues with the new gTLDs that are in the xn-- category ? I confess I'm confused by the question. In email I expect writing between people who are not conversant in the language in question to use punycode, and people who conversant to go ahead and use the native script. At bar BoFs and the like among non-speakers there will be likely some ad hoc shorthand description amongst the participants that makes it clear which domain they're talking about. Are you just wondering what sort of resonance to give the punycode in your own mental pronunciation? Like wishing that your own internal voice would read Today a problem with the xn--unup4y domain... as Today a problem with the Chinese game domain...? Good luck with that. Me, I'll probably still lazily just have my mind's ear hear Today a problem with the /you nuppy/ domain ... in much the same way that it makes up half-arsed pronunciations for all sorts of unfamiliar strings. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] All NSs for a TLD being in the TLD itself
The new records for one of the shiny new gTLDs are: xn--ngbc5azd. 172800 IN NS a.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS b.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS c.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS d.nic.xn--ngbc5azd. a.nic.xn--ngbc5azd. 172800 IN A 37.209.192.3 a.nic.xn--ngbc5azd. 172800 IN 2001:dcd:1:0:0:0:0:3 b.nic.xn--ngbc5azd. 172800 IN A 37.209.194.3 b.nic.xn--ngbc5azd. 172800 IN 2001:dcd:2:0:0:0:0:3 c.nic.xn--ngbc5azd. 172800 IN A 37.209.196.3 c.nic.xn--ngbc5azd. 172800 IN 2001:dcd:3:0:0:0:0:3 d.nic.xn--ngbc5azd. 172800 IN A 37.209.198.3 d.nic.xn--ngbc5azd. 172800 IN 2001:dcd:4:0:0:0:0:3 This works, of course, but it feels a bit fragile for me. Is there a history of this being unsafe? Of being more safe than NSs whose names are in other TLDs? --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] All NSs for a TLD being in the TLD itself
On 10/24/13 16:54, Paul Hoffman wrote: The new records for one of the shiny new gTLDs are: This works, of course, but it feels a bit fragile for me. To me it feels pretty lean and mean: http://trans-trust.verisignlabs.com/pix/xn--ngbc5azd.-names.png Is there a history of this being unsafe? Of being more safe than NSs whose names are in other TLDs? That's almost a religious discussion, in my experience. Try: 'dig ns se' (personally I like it) -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] All NSs for a TLD being in the TLD itself
On Thu, Oct 24, 2013 at 04:59:36PM +0200, Marco Davids (SIDN) wrote: On 10/24/13 16:54, Paul Hoffman wrote: The new records for one of the shiny new gTLDs are: This works, of course, but it feels a bit fragile for me. To me it feels pretty lean and mean: http://trans-trust.verisignlabs.com/pix/xn--ngbc5azd.-names.png Is there a history of this being unsafe? Of being more safe than NSs whose names are in other TLDs? That's almost a religious discussion, in my experience. I would not say that, but because of the over inclusiveness of the root glue policy, the use of out of zone names, makes no difference for Paul's question perspective. Fred ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] All NSs for a TLD being in the TLD itself
On Oct 24 2013, Paul Hoffman wrote: The new records for one of the shiny new gTLDs are: xn--ngbc5azd. 172800 IN NS a.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS b.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS c.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS d.nic.xn--ngbc5azd. a.nic.xn--ngbc5azd. 172800 IN A 37.209.192.3 a.nic.xn--ngbc5azd. 172800 IN 2001:dcd:1:0:0:0:0:3 b.nic.xn--ngbc5azd. 172800 IN A 37.209.194.3 b.nic.xn--ngbc5azd. 172800 IN 2001:dcd:2:0:0:0:0:3 c.nic.xn--ngbc5azd. 172800 IN A 37.209.196.3 c.nic.xn--ngbc5azd. 172800 IN 2001:dcd:3:0:0:0:0:3 d.nic.xn--ngbc5azd. 172800 IN A 37.209.198.3 d.nic.xn--ngbc5azd. 172800 IN 2001:dcd:4:0:0:0:0:3 This works, of course, but it feels a bit fragile for me. Is there a history of this being unsafe? Of being more safe than NSs whose names are in other TLDs? Whatever the safety aspects (there are probably arguments both ways) it certainly isn't uncommon. Going by the delegation NS records, 57 out of 323 TLDs have all NS records inside themselves. These include 51 ISO3166 ccTLDs, 5 ASCII gTLDs (biz, mil, net, tel, travel) and [now!] just one IDN gTLD (the above). -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
On Thu, Oct 24, 2013 at 04:33:52PM +0200, Anne-Marie Eklund-Löwinder anne-marie.eklund-lowin...@iis.se wrote a message of 39 lines which said: Twitter is so last year. IANA notifications over 4chan? Or am I so late I don't even know the trend of the day? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
On 24 Oct 2013, at 17:05, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Thu, Oct 24, 2013 at 04:33:52PM +0200, Anne-Marie Eklund-Löwinder anne-marie.eklund-lowin...@iis.se wrote a message of 39 lines which said: Twitter is so last year. IANA notifications over 4chan? Or am I so late I don't even know the trend of the day? Maybe there’s a new medium that we’ve all missed :) Mr Michele Neylon Blacknight Solutions ♞ Hosting Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
Michele Neylon - Blacknight (michele) writes: IANA notifications over 4chan? Or am I so late I don't even know the trend of the day? Maybe there’s a new medium that we’ve all missed :) Tumblr ? Publish diffs in an ARPA zone ? RSS in DNS ? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
On 10/24/2013 06:56 AM, Stephane Bortzmeyer wrote: On Wed, Oct 23, 2013 at 01:11:43PM -0700, Rick Wesson r...@support-intelligence.com wrote a message of 100 lines which said: Does ICANN have a root-zone announce list? Email lists are so last-century :-) Never dismiss the utility of stone knives and bear skins :) rick jones ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
From: Stephane Bortzmeyer bortzme...@nic.fr IANA notifications over 4chan? Or am I so late I don't even know the trend of the day? I keep hearing about this E-male thing, but I can't seem to figure out where to put the stamp. And he doesn't fit through the slot at the Post Office. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What do you call them?
When Kim mentioned we put together an ask of ianacann root updates, if we (the community) were to request a root zone list be started for announcing... one opportunity we have would be to ask for fields from what the applicant furnished from the applicant guidebook in question 14, which would contain the language and English meaning. This would result in what you are describing. This additional information is present in the new idn gtlds but the idn cctlds follow a different process. On Thursday, October 24, 2013, Edward Lewis wrote: Throwing this out on the table for discussion... In the sense we (the dns operations industry/community) see .com and can say that out loud today (whether it's native tongue to you or not). Ane when we see xn--fiqs8s we can call that the IDN for China (simplified) But what will we call xn--unup4y.? That's you1xi4 in pinyin (I'll omit the characters as they might not render in all email readers) which translates into English as game (as in to play a game). The TLD visual is rendered in simplified Chinese script (I hope my terminology is clean). I'm picking the example that I have a shot at parsing, I can't deal at all with Cyrillic or (I believe) Arabic. I doubt there are any or many people on this list that are multilingual *enough to deal with all of the scripts we will see. So - what will the dns operations community use to name these TLDs when there are issues with the new gTLDs that are in the xn-- category ? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. -- Jothan Frakes +1.206-355-0230 tel +1.206-201-6881 fax ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
On 24 Oct 2013, at 14:12, Chris Thompson c...@cam.ac.ukmailto:c...@cam.ac.uk wrote: At 13:01 23-10-2013, Edward Lewis wrote: My sensors show 4 new gTLDs in the last hour or so...IDN, non-ccTLD...added between 1800 and 1900 UTC. Not mentioned yet is that all four appeared already signed and with DS records in the root zone. I *think* this is a condition of delegation. But... the two Cyrillic gTLDs (xn--80asehdb xn--80aswg) are a bit broken, in that NXDOMAIN responses don't validate properly. Neither dnssec-debugger.verisignlabs.com nor dnsviz.net are able to analyse validations problems for NXDOMAIN responses, so I am not quite sure why yet, but e.g. dig +dnssec www.xn--80asehdbhttp://www.xn--80asehdb. dig +dnssec www.xn--80aswghttp://www.xn--80aswg. give SERVFAILs which can be avoided by adding the +cd option. I'm surprised this wasn't picked up as part of pre-delegation testing. Brett ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] All NSs for a TLD being in the TLD itself
The glue records for all TLD NSes are in the root zone. What makes one label fragile, and another label robust? On Thu, Oct 24, 2013 at 10:19 AM, Chris Thompson c...@cam.ac.uk wrote: On Oct 24 2013, Paul Hoffman wrote: The new records for one of the shiny new gTLDs are: xn--ngbc5azd. 172800 IN NS a.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS b.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS c.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS d.nic.xn--ngbc5azd. a.nic.xn--ngbc5azd. 172800 IN A 37.209.192.3 a.nic.xn--ngbc5azd. 172800 IN 2001:dcd:1:0:0:0:0:3 b.nic.xn--ngbc5azd. 172800 IN A 37.209.194.3 b.nic.xn--ngbc5azd. 172800 IN 2001:dcd:2:0:0:0:0:3 c.nic.xn--ngbc5azd. 172800 IN A 37.209.196.3 c.nic.xn--ngbc5azd. 172800 IN 2001:dcd:3:0:0:0:0:3 d.nic.xn--ngbc5azd. 172800 IN A 37.209.198.3 d.nic.xn--ngbc5azd. 172800 IN 2001:dcd:4:0:0:0:0:3 This works, of course, but it feels a bit fragile for me. Is there a history of this being unsafe? Of being more safe than NSs whose names are in other TLDs? Whatever the safety aspects (there are probably arguments both ways) it certainly isn't uncommon. Going by the delegation NS records, 57 out of 323 TLDs have all NS records inside themselves. These include 51 ISO3166 ccTLDs, 5 ASCII gTLDs (biz, mil, net, tel, travel) and [now!] just one IDN gTLD (the above). -- Chris Thompson University of Cambridge Computing Service, Email: c...@ucs.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. __**_ dns-operations mailing list dns-operati...@lists.dns-oarc.**net dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/**mailman/listinfo/dns-**operationshttps://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/**mailman/listinfo/dns-jobshttps://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Jonathan ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
In message db6dae86e038ff4d86ec85b0c70a986e2e519...@wds-exc1.okna.nominet.org.uk, Brett Carr writes: On 24 Oct 2013, at 14:12, Chris Thompson c...@cam.ac.ukmailto:c...@cam.ac.uk wrote: At 13:01 23-10-2013, Edward Lewis wrote: My sensors show 4 new gTLDs in the last hour or so...IDN, non-ccTLD...added between 1800 and 1900 UTC. Not mentioned yet is that all four appeared already signed and with DS records in the root zone. I *think* this is a condition of delegation. But... the two Cyrillic gTLDs (xn--80asehdb xn--80aswg) are a bit broken, in that NXDOMAIN responses don't validate properly. Neither dnssec-debugger.verisignlabs.com nor dnsviz.net are able to analyse validations problems for NXDOMAIN responses, so I am not quite sure why yet, but e.g. dig +dnssec www.xn--80asehdbhttp://www.xn--80asehdb. dig +dnssec www.xn--80aswghttp://www.xn--80aswg. give SERVFAILs which can be avoided by adding the +cd option. I'm surprised this wasn't picked up as part of pre-delegation testing. Heaps of DNS problems exist because people do not do testing of negative responses. Note this one will only start to manifest itself once you populate the zone and even then your test query may work if the wild card and the qname fall into the same NSEC3 range. Mark Brett -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] All NSs for a TLD being in the TLD itself
Hi Paul, Why would this be unsafe and/or fragile? As was already mentioned the root zone has to include glue for whichever name you choose anyway, due to the position in the hierarchy - so it's just a matter of reducing unnecessary dependencies for us. Happy to hear thoughts besides the religious believes. :) Cheers, -- Wolfgang Nagele IT Manager ARI Registry Services Level 8, 10 Queens Road Melbourne, Victoria, Australia, 3004 Phone +61 3 9866 3710 Email: wolfgang.nag...@ariservices.com Web: www.ariservices.com The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. On 10/25/13 1:54 AM, Paul Hoffman paul.hoff...@vpnc.orgmailto:paul.hoff...@vpnc.org wrote: The new records for one of the shiny new gTLDs are: xn--ngbc5azd. 172800 IN NS a.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS b.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS c.nic.xn--ngbc5azd. xn--ngbc5azd. 172800 IN NS d.nic.xn--ngbc5azd. a.nic.xn--ngbc5azd. 172800 IN A 37.209.192.3 a.nic.xn--ngbc5azd. 172800 IN 2001:dcd:1:0:0:0:0:3 b.nic.xn--ngbc5azd. 172800 IN A 37.209.194.3 b.nic.xn--ngbc5azd. 172800 IN 2001:dcd:2:0:0:0:0:3 c.nic.xn--ngbc5azd. 172800 IN A 37.209.196.3 c.nic.xn--ngbc5azd. 172800 IN 2001:dcd:3:0:0:0:0:3 d.nic.xn--ngbc5azd. 172800 IN A 37.209.198.3 d.nic.xn--ngbc5azd. 172800 IN 2001:dcd:4:0:0:0:0:3 This works, of course, but it feels a bit fragile for me. Is there a history of this being unsafe? Of being more safe than NSs whose names are in other TLDs? --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.netmailto:dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] All NSs for a TLD being in the TLD itself
On Thu, Oct 24, 2013 at 10:53:03PM +, Wolfgang Nagele wrote: Why would this be unsafe and/or fragile? As was already mentioned the root zone has to include glue for whichever name you choose anyway, due to the position in the hierarchy This isn't strictly true. The only thing the root zone actually has to contain is glue for the NS records on the parent side of any delegation from the root. It just so happens that the root zone includes the other glue too. As for whether this arrangement is fragile, I could (like others) construct the argument either way. Best, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
