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] summary of recent vulnerabilities in DNS security.
On Thu, Oct 24, 2013 at 09:11:41AM +0300, Daniel Kalchev dan...@digsys.bg wrote a message of 247 lines which said: This is not an attack on DNS, but an attack on IP reassembly technology. Frankly, I do not share this way of seeing things. Since the DNS is, by far, the biggest user of UDP and since TCP is already protected by PMTUD, I do not think we can say it's not our problem. This might happen even due to malfunctioning network adapter or other network device, not necessarily an attack. A random modification by a malfunctioning device or an errant cosmic ray has a very small probability of being accepted (UDP checksum, DNS checks, etc). We are talking here about a deliberate attack, by a blind attacker. ___ 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] summary of recent vulnerabilities in DNS security.
On Tue, Oct 22, 2013 at 11:59:04PM +, Vernon Schryver v...@rhyolite.com wrote a message of 50 lines which said: Why would there be extra support calls? Wrong keys are no worse than wrong delegations Of course, they are worse. In the vast majority of cases, lame delegations (or other mistakes) do not prevent resolution (as long as one name server works). A wrong key can completely prevent resolution, leading to a loss of service. The DNS is extremely robust, you have to try very hard to break it. With DNSSEC, it's the opposite, you have to be very careful for it to work. Why would registrars get support calls about validation problems? Do they get calls now (that they answer) from DNS resolver operators (other than big resolvers like Comcast) for lame delegations? See above. I cannot visit http://www.онлайн/ while it works from $OTHERISP so it's your fault. ___ 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] summary of recent vulnerabilities in DNS security.
On Tue, Oct 22, 2013 at 01:28:15PM -0700, Paul Vixie p...@redbarn.org wrote a message of 24 lines which said: BIND9 V9.9 may surprise you. it has inline signing and automatic key management. I don't think it is a fair description of BIND 9.9 abilities. It does not manage keys (which, IMHO, mean creating them as necessary, remove them when outdated, change them intelligently depending on the TTL, etc). ___ 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] summary of recent vulnerabilities in DNS security.
From: Stephane Bortzmeyer bortzme...@nic.fr Why would there be extra support calls? Wrong keys are no worse than wrong delegations Of course, they are worse. In the vast majority of cases, lame delegations (or other mistakes) do not prevent resolution (as long as one name server works). A wrong key can completely prevent resolution, leading to a loss of service. The DNS is extremely robust, you have to try very hard to break it. With DNSSEC, it's the opposite, you have to be very careful for it to work. Let's agree to somewhat disagree about that. I've found giving one's registrar the wrong IP address or glue a lot worse than a stupid delegation in my own zone files. DNSSEC needs a more effort than plain DNS, but that almost none of extra effort has anything to with registrars. Registrars/registries must sign your DNSSEC RRs, but they must now also sign your other RRs, so that's no extra work for them. Why would registrars get support calls about validation problems? Do they get calls now (that they answer) from DNS resolver operators (other than big resolvers like Comcast) for lame delegations? See above. I cannot visit http://www.онлайн/ while it works from $OTHERISP so it's your fault. I don't understand that. Of course DNSSEC causes more support calls, but the calls are to ISPs and IT groups and not to the registrars trying to sabotage or delay DNSSEC for as long as possible supposedly because of DNSSEC support calls. And again, whether they do suffer more support calls *not*, let them charge extra for adding DNSSEC records! If they can profit from simple DNS for US$10/year, then they could profit with DNSSEC for US$30/year. A rational reason for the registrar DNSSEC sabotage is that the margins on the PKI certs they flog to the punters are at lot more than US$30/year (proof: free certs), and DNSSEC+DANE will eventually kill that cash cow. Yes, no doubt some registrars are too dumb to see that. ... } From: Stephane Bortzmeyer bortzme...@nic.fr } This is not an attack on DNS, but an attack on IP reassembly } technology. } } Frankly, I do not share this way of seeing things. Since the DNS is, } by far, the biggest user of UDP and since TCP is already protected by } PMTUD, I do not think we can say it's not our problem. How dos PMTUD protect TCP? When since perhaps 1995 has PMTUD been seen as protection instead of vulnerability, thanks to goobers with firewalls? Why can't similar attacks using TCP segment assembly be mounted against DNS/TCP? I've heard of more segment assembly attacks than IP fragment assembly attacks, albeit against TCP applications other than DNS. } This might happen even due to malfunctioning network adapter or } other network device, not necessarily an attack. } } A random modification by a malfunctioning device or an errant cosmic } ray has a very small probability of being accepted (UDP checksum, DNS } checks, etc). We are talking here about a deliberate attack, by a } blind attacker. (I thought these latest attacks are not blind, but never mind that.) I've seen more vastly more bit rot undetected by UDP and TCP checksums (esp. due to my own software and firmware bugs and bugs in green hardware) than human attacks. And the number of bad TCP and UDP checksums reported by `netstat -s` on any even slightly busy host should be worrisome. Why does it matter whether the bad bits are natural or man made? Why not turn on DNSSEC, declare victory, and go home? Why continually rehash the falling DNS sky? Aren't there enough other security issues? Some that I've heard about are incomparably worse in consequenes as well as ease of attack (e.g. no hours of 100 Mbit/sec flooding or per-target packet tuning to forge one measly DNS response). Vernon Schryverv...@rhyolite.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
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] key management in bind9 (was Re: summary of recent vulnerabilities)
Hi Stephane, BIND9 V9.9 may surprise you. it has inline signing and automatic key management. I don't think it is a fair description of BIND 9.9 abilities. It does not manage keys (which, IMHO, mean creating them as necessary, remove them when outdated, change them intelligently depending on the TTL, etc). True that it doesn't create keys. We do have plans for an external tool to do this -- probably to be written in python and run from cron, rather than a built-in feature of named -- but we haven't had the necessary combination of staff and time to write it yet. If you, or anyone else reading, have specific requests for how such a tool should work, I'd appreciate the input. I know we'll be wanting a policy file to specify things like algorithm, key size, roll period, etc, but I'm not sure I've thought of all the configuration knobs that would be useful. I'd like to hear about any other areas where we could be doing a better job, too. In the meantime, though, you can create as many keys in advance as you like. It's easy to make a new key that's a direct successor to a previous one using the -S option to dnssec-keygen; named will then move the keys in and out of the zone on schedule. # create initial ZSK firstkey=`dnssec-keygen example.com` # set it to go inactive in 60 days and to be removed in 90 dnssec-settime -I now+60d -D now+90d $firstkey # create a successor ZSK; # it will prepublish in 30 days and activate in 60 secondkey=`dnssec-keygen -S $firstkey` There's also a tool (dnssec-coverage) to check whether the scheduled activation and inactivation dates for the keys you've created contain any inadvertent lapses in coverage. For example, supposing the maximum TTL for example.com is a week and the DNSKEY TTL is a day: $ dnssec-coverage -m 7d -d 1d example.com PHASE 1--Loading keys to check for internal timing problems PHASE 2--Scanning future key events for coverage failures Checking scheduled ZSK events for zone example.com, algorithm RSASHA1... Fri Oct 25 17:45:36 UTC 2013: Publish: example.com/005/53481 (ZSK) Activate: example.com/005/53481 (ZSK) Sun Nov 24 17:46:46 UTC 2013: Publish: example.com/005/60972 (ZSK) Tue Dec 24 17:46:46 UTC 2013: Inactive: example.com/005/53481 (ZSK) Activate: example.com/005/60972 (ZSK) Thu Jan 23 17:46:46 UTC 2014: Delete: example.com/005/53481 (ZSK) No errors found -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
