Re: [dns-operations] All NSs for a TLD being in the TLD itself
On 29/10/2013 11:45, Jim Reid wrote: On 29 Oct 2013, at 09:24, Calvin Browne cal...@orange-tree.alt.za wrote: I'm going to point out that .se went down because of a problem right at this point relativly recently. IIRC, that problem had nothing to do with whether the TLD's NS RRset was in the zone or not. Something went wrong with zone file generation and that RRset got corrupted somehow. [When the authoritative NS RRset gets mangled, it doesn't matter if the targets of those NS records are inside or outside the zone.] Things still worked (sort of). The delegation info at the root was unchanged and valid. Resolvers got referrals to the authoritative .se name servers even though those servers might not have had NS records in the .se zone itself. From memory - a script bungled the generation of the ns.se zone. Having NS's outside of this zone would have meant a less catastrophic failure. the .ng case was similar, the administrator passed away, and the zone all the .ng NSes were in wasn't renewed, so it was suspended and .ng dissappeared. This incident went unreported AFAIK, even though .ng was down for two or so days. *my personal analysis* is that both these incidents would have been prevented by having NS's in zones outside the registry's direct control. So *I* understand when people say this naming scheme appears brittle, and *I* get the same feeling. [of course - there are other factors that come into play - reply sizes, managing external relationships, and even IANA gluing policies which make updates to tld's more cumberson when a NS set is in different zones] --Calvin PS - the .se stuff was in 2009 - so I used 'relatively recently' incorrectly - apologies. ___ 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 29, 2013, at 10:24 AM, Calvin Browne wrote: On 25/10/2013 19:34, dns-operations-requ...@lists.dns-oarc.net wrote: SNIP From: Einar L?nn einar.l...@iis.se snip what do you think is fragile? the in-baliwick glue? why? the ip address clumping would worry me if i thought they were not anycast. randy Someone did a comparison between all the ccTLD's a few years back (was it CENTR? or RIPE? I cant find it...) where they checked stuff like this. I think I remember 100% in-bailiwick glue was considered best as this gives most control to the TLD itself and has the least risk of hijacking due to inzone or out of zone dependancies. I actually agree with this assessment, at least as long as (in the example above) the zone nic.xn--ngb5azd is *very* well guarded (locked utterly) and preferrably also never delegated. Which it might actually be, then it's suddenly much riskier as you must have full control of the delegated zone also (which I kind of consider an inzone dependancy)... (Compare: In .SE the zone NS.SE that contains all names of all NS-records for .SE is in-bailiwick and *not* a delegated zone). BigMac:~ einar.lonn$ dig se ns +short a.ns.se. b.ns.se. c.ns.se. d.ns.se. e.ns.se. f.ns.se. g.ns.se. i.ns.se. j.ns.se. B I'm going to point out that .se went down because of a problem right at this point relativly recently. And .ng and I think there were more.. --Calvin No system is perfect until all human steps have been removed, so I'm curious how out-of-zone name servers can protect against *human* error? ;) Although you do have a point, in the case of our incident where a rogue $ORIGIN destroyed our zone, out-of-zone name servers actually would have helped. But it's a very specific case this would protect against and now I doubt this will ever happen again (we have quite a bit more checks today than we had when this happened). Furthermore this relatively tiny risk could be compared to the risk of a hijack of a name server residing out-of-zone which silently captures X percent of all your traffic. As you say you could consider this as having all your eggs in one basket; however I kind of like the idea of having 100% control, especially with DNSSEC-signed NS' and glue, and this is tricky to achieve in any other way. Had to speak with some people internally before composing this, thus the delay. Saw more emails concerning this later in the thread; they are actually (somewhat) incorrect, out-of-zone NS' would have helped us. Still not worth it though imho, considering control and security mentioned above. /Regards, Einar 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 Oct 29, 2013, at 12:21 PM, Calvin Browne wrote: On 29/10/2013 11:45, Jim Reid wrote: On 29 Oct 2013, at 09:24, Calvin Browne cal...@orange-tree.alt.za wrote: I'm going to point out that .se went down because of a problem right at this point relativly recently. IIRC, that problem had nothing to do with whether the TLD's NS RRset was in the zone or not. Something went wrong with zone file generation and that RRset got corrupted somehow. [When the authoritative NS RRset gets mangled, it doesn't matter if the targets of those NS records are inside or outside the zone.] Things still worked (sort of). The delegation info at the root was unchanged and valid. Resolvers got referrals to the authoritative .se name servers even though those servers might not have had NS records in the .se zone itself. From memory - a script bungled the generation of the ns.se zone. Having NS's outside of this zone would have meant a less catastrophic failure. Incorrect. ns.se is not a zone and cannot be delegated, it's locked for delegation and is *only* used for the in-bailiwick names of NS-records for .SE. This it what I earlier referred to as in-zone dependancy, for .SE there are *no* dependancies whatsoever so ns.se cannot break - because it's not a zone. the .ng case was similar, the administrator passed away, and the zone all the .ng NSes were in wasn't renewed, so it was suspended and .ng dissappeared. This incident went unreported AFAIK, even though .ng was down for two or so days. This is what worried me about having *any* real zones where names of TLD-level name servers reside; if the names themselves are delegated you're suddenly opening up a whole bunch of potential dangers IMHO. And, of course, especially outside your own name space for reason mentioned earlier. *my personal analysis* is that both these incidents would have been prevented by having NS's in zones outside the registry's direct control. As I said, for the *exact* problem we faced this would have helped. We're however much more paranoid about features such as ORIGIN now so I strongly doubt it will happen again. ;) So *I* understand when people say this naming scheme appears brittle, and *I* get the same feeling. [of course - there are other factors that come into play - reply sizes, managing external relationships, and even IANA gluing policies which make updates to tld's more cumberson when a NS set is in different zones] --Calvin PS - the .se stuff was in 2009 - so I used 'relatively recently' incorrectly - apologies. I understand why different organizations have different solutions; as you've all found out our method of naming is quite sensitive to features such as $ORIGIN. However; our solution is very nice with DNSSEC as every single record is signed and it's also very robust to outside tampering. If there was a silver bullet for naming I think everyone would have that specfic schema, afaik there is none - and to be honest, perhaps this is good for the Internet, diversity never killed anyone, right? ;) /Regards, Einar 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 Oct 29, 2013, at 12:51 PM, Daniel Kalchev wrote: snip Furthermore this relatively tiny risk could be compared to the risk of a hijack of a name server residing out-of-zone which silently captures X percent of all your traffic. As you say you could consider this as having all your eggs in one basket; however I kind of like the idea of having 100% control, especially with DNSSEC-signed NS' and glue, and this is tricky to achieve in any other way. DNSSEC is here to help you. No matter what happens with any of your secondaries, as long as they do not have the secret part of your DNSKEY(s), this does not matter. This kills the incentive to hijack/attack DNSSEC signed zones secondaries, because it is not an attack vector that works. Those X percent of responses, will simply be ignored by all validating resolvers. Oh really? How will I sign the glue of out-of-zone nameservers? In theory they could be in a signed-zone themselves, and thus signed etcetera, but it's still not even close to having them in a non-delegated zone controlled in one single place if you want full control (all these steps add complexity and security implications regardless of how you perform them to be honest, however; you do win stability). Currently every single A is signed for .SE, and signed with our own key inside our own zone. There are no dependancies outside of root. DNSSEC will of course not protect you from human errors, like the one discussed here. No, since it was a human error we did sign the zone we broke. ;p Had to speak with some people internally before composing this, thus the delay. Saw more emails concerning this later in the thread; they are actually (somewhat) incorrect, out-of-zone NS' would have helped us. Still not worth it though imho, considering control and security mentioned above. I believe you need to open that discussion again, in consideration of the DNSSEC properties mentioned above. Daniel Honestly I think it's a matter of policy; how much is security and control worth if you pitch it against stability? Our current delegation of .SE I think is pretty much focused on security and control, it's only natural that we lose some stability due to this but basically… it's a cost we're willing to take (and you could perhaps argue that we've paid the price for it with this incident). ...I wish I could find that survey, it was quite good and talked about exactly this for a lot of different TLDs. ;p No one remembers it? Annoying that I cant refer/point to it... ;( /Regards, Einar 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 2013-10-29, at 06:18, Jaap Akkerhuis j...@nlnetlabs.nl wrote: If I remember correctly, the whole mess was augmented by all these resolvers which thought that SE had a delegation only policy. When the name servers became in balliwick ... The threat of delegation-only configuration in BIND9 was one of the things that caused me to propose the naming scheme you see for Afilias's hosted TLDs, back in the day. Aside from the general ugliness and confusion that all those similar NS names cause (sorry about that) the general approach was to delegate the TLD to names in separate zones, but to host those zones alongside the TLD on the same nameserver. So, for example, we see [walrus:~]% dig org. ns +short a0.org.afilias-nst.info. d0.org.afilias-nst.org. b0.org.afilias-nst.org. c0.org.afilias-nst.info. a2.org.afilias-nst.info. b2.org.afilias-nst.org. [walrus:~]% dig org.afilias-nst.info. ns +short b0.org.afilias-nst.org. d0.org.afilias-nst.org. a0.org.afilias-nst.info. c0.org.afilias-nst.info. a2.org.afilias-nst.info. b2.org.afilias-nst.org. [walrus:~]% dig org.afilias-nst.org ns +short c0.org.afilias-nst.info. b0.org.afilias-nst.org. b2.org.afilias-nst.org. a0.org.afilias-nst.info. d0.org.afilias-nst.org. a2.org.afilias-nst.info. [walrus:~]% This allows any of those nameservers to answer authoritatively for any of those three zones, but provides defence against people asserting delegation-only semantics in ORG. The use of separate superordinate TLDs for the nameservers themselves (ORG and INFO) was to avoid the question of whether there was a risk in naming them all under one TLD, since that question is difficult to answer convincingly; the risk profile when you consider all possible failure modes gets complicated to describe, quickly. I haven't worked for Afilias for many years and certainly don't speak for them (or PIR) now, so consider this a historical nugget rather than anything authoritative about present-day operations or strategy :-) Joe signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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 29, 2013, at 2:10 PM, Daniel Kalchev wrote: On 29.10.13 14:33, Einar Lönn wrote: On Oct 29, 2013, at 12:51 PM, Daniel Kalchev wrote: snip Furthermore this relatively tiny risk could be compared to the risk of a hijack of a name server residing out-of-zone which silently captures X percent of all your traffic. As you say you could consider this as having all your eggs in one basket; however I kind of like the idea of having 100% control, especially with DNSSEC-signed NS' and glue, and this is tricky to achieve in any other way. DNSSEC is here to help you. No matter what happens with any of your secondaries, as long as they do not have the secret part of your DNSKEY(s), this does not matter. This kills the incentive to hijack/attack DNSSEC signed zones secondaries, because it is not an attack vector that works. Those X percent of responses, will simply be ignored by all validating resolvers. Oh really? How will I sign the glue of out-of-zone nameservers? In theory they could be in a signed-zone themselves, and thus signed etcetera, but it's still not even close to having them in a non-delegated zone controlled in one single place if you want full control (all these steps add complexity and security implications regardless of how you perform them to be honest, however; you do win stability). Currently every single A is signed for .SE, and signed with our own key inside our own zone. There are no dependancies outside of root. This is not what I said. Perhaps my command of English is not good enough to communicate it properly, so I will try again. Suppose, .se had an out of zone secondary, say ns.iana.org. Obviously, outside of .SE control. Your worry is that somehow things might go wrong with this name server, because something went wrong with .iana.org or with .org. Of course this is possible. Your next concern is that control of ns.iana.org might go in the wrong hands. This is also possible. Without DNSSEC, whoever controls that name server can respond on behalf of your zone, and you resolvers see X percent answers, that you did not authorize. With DNSSEC, none of this is possible. You should know why. This is irrespective of whether the zone holding that name server is signed or not, and by whom. At worst, you will be operating with one name server less, which is logical, because that name server is compromised and you should not be using it anyway. DNSSEC simply makes that ignore the broken name server process automatic. I'm not a DNSSEC-expert, but I really think you're wrong in what DNSSEC can and cannot do. Afaik: If a record is not signed in-zone it *can* be faked and the cache *can* be poisoned. With your example above I can indeed sign the NS RRSET containing ns.iana.org but I cannot protect it's glue and this, if all the other zone(s) are not properly protected with DNSSEC, gives opportunity for anyone to poison at any level; I could either attack the glue itself for NS.IANA.ORG or I could attack the zone IANA.ORG or I could attack ORG (if these are not signed). If DNSSEC would automatically secure the entire Internet if a single zone was signed, I suppose that'd be great, this is however not so. There is a chain of trust similar to the delegation chain and you cannot secure or control anything outside your own zone(s). I cannot poison the cache when using signed in-zone names, but I can sure poison the cache for glue of unsigned out-of-zone name servers (or even redelegate the zones themselves if they are not signed). That is the definition of cache poisoning and DNSSEC doesnt help you except for protecting the *name*, which no computer cares about in the slightest. Had to speak with some people internally before composing this, thus the delay. Saw more emails concerning this later in the thread; they are actually (somewhat) incorrect, out-of-zone NS' would have helped us. Still not worth it though imho, considering control and security mentioned above. I believe you need to open that discussion again, in consideration of the DNSSEC properties mentioned above. Daniel Honestly I think it's a matter of policy; how much is security and control worth if you pitch it against stability? With DNSSEC, there is no downside. Are there no stability concerns with DNSSEC you say? Let me just politely disagree with you, strongly. ;) The security benefits outweigh the stability concerns, yes, but this does NOT mean there are no stability concerns to address. If DNSSEC had no downsides everyone would use it from day 1, without hesitation, and the world would be a happier place. Our current delegation of .SE I think is pretty much focused on security and control, it's only natural that we lose some stability due to this but basically… it's a cost we're willing to take (and you could perhaps argue that we've paid the price for it with this incident). Policy has it's costs.
Re: [dns-operations] All NSs for a TLD being in the TLD itself
On Oct 25 2013, Andrew Sullivan wrote: 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. That depends on whether you think including sibling glue [*] is mandatory, or at least advisable. All NS records for TLD delegations involve either required glue if the name is inside the TLD, or sibling glue if it is inside another TLD. (In theory, it could be a name actually in the root zone itself, but of course there aren't any such cases.) [*] sibling glue is what the BIND documentation (e.g. the man page for named-checkzone) calls it. It may not be standard terminology. -- 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] All NSs for a TLD being in the TLD itself
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? what do you think is fragile? the in-baliwick glue? why? the ip address clumping would worry me if i thought they were not anycast. randy ___ 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 25, 2013, at 3:45 PM, Randy Bush wrote: 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? what do you think is fragile? the in-baliwick glue? why? the ip address clumping would worry me if i thought they were not anycast. randy Someone did a comparison between all the ccTLD's a few years back (was it CENTR? or RIPE? I cant find it...) where they checked stuff like this. I think I remember 100% in-bailiwick glue was considered best as this gives most control to the TLD itself and has the least risk of hijacking due to inzone or out of zone dependancies. I actually agree with this assessment, at least as long as (in the example above) the zone nic.xn--ngb5azd is *very* well guarded (locked utterly) and preferrably also never delegated. Which it might actually be, then it's suddenly much riskier as you must have full control of the delegated zone also (which I kind of consider an inzone dependancy)... (Compare: In .SE the zone NS.SE that contains all names of all NS-records for .SE is in-bailiwick and *not* a delegated zone). BigMac:~ einar.lonn$ dig se ns +short a.ns.se. b.ns.se. c.ns.se. d.ns.se. e.ns.se. f.ns.se. g.ns.se. i.ns.se. j.ns.se. BigMac:~ einar.lonn$ dig ns.se ns @a.ns.se ; DiG 9.8.5-P1 ns.se @a.ns.se ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6494 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns.se. IN A ;; AUTHORITY SECTION: se. 7200IN SOA catcher-in-the-rye.nic.se. registry-default.nic.se. 2013102506 1800 1800 864000 7200 ;; Query time: 45 msec ;; SERVER: 192.36.144.107#53(192.36.144.107) ;; WHEN: Fri Oct 25 16:54:07 CEST 2013 ;; MSG SIZE rcvd: 99 Wish I could find that survey with the comparison, anyone remember it? It was a good one and gave out gold stars and such for nice DNS setups, which was kind of fun… ;) /Regards, Einar 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
Randy, On Oct 25, 2013, at 9:45, Randy Bush wrote: the ip address clumping would worry me if i thought they were not anycast. Anycast or not, I wouldn't think this is a problem. Meaning, I don't see why this would be a problem with unicast. Assuming that (for v4) the /24's are independently routed, it wouldn't matter if the numbers are numerically close or not. I ask because I might be missing something. And assuming it's a given that to an external endpoint, anycast is indistinguishable to unicast. I can't tell if that's two routes to a multi-homed LAN or two routes that diverge geographically. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ 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 25, 2013, at 1:33 PM, Edward Lewis ed.le...@neustar.biz wrote: Randy, On Oct 25, 2013, at 9:45, Randy Bush wrote: the ip address clumping would worry me if i thought they were not anycast. Anycast or not, I wouldn't think this is a problem. Meaning, I don't see why this would be a problem with unicast. Assuming that (for v4) the /24's are independently routed, it wouldn't matter if the numbers are numerically close or not. Well, it *might* -- having a wider separation of addresses (and multiple AS#) reduce the risk of someone accidentally misconfiguring an ACL and blocking access…. Lets say your space is 192.0.2.0/24 and 192.0.3.0/24 -- it's possible that someone intending to ACL 192.0.0.0/24 and 192.0.1.0/24 makes a booboo and ACLs off 192.0.0.0/22 instead of 192.0.0.0/23. While this sound alike a theoretical / unlikely issue, it *does* happen -- ask me how I know… W I ask because I might be missing something. And assuming it's a given that to an external endpoint, anycast is indistinguishable to unicast. I can't tell if that's two routes to a multi-homed LAN or two routes that diverge geographically. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ 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 -- She'd even given herself a middle initial - X - which stood for someone who has a cool and exciting middle name. -- (Terry Pratchett, Maskerade) ___ 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] 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] 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
