Re: [dns-operations] CloudFlare policy on ANY records changing
On Mon, Mar 9, 2015 at 10:58 PM, Mark Andrews ma...@isc.org wrote: In message cagmqtqjrpx_xg_ojtshsw5yqaefkzwdma16xw7iry9pr0_f...@mail.gmail.com , Yunhong Gu writes: Returning NOTIMP may confuse resolvers as it is not clear what is not implemented. Which is why you only change one thing at a time when trying to determine what is covered by NOTIMP. A NOTIMP response to an ANY query with EDNS0 option could cause a retry-without-EDNS0 query, or mislead the resolver to believe that the nameserver does not support EDNS0. And if you retry w/o a OPT record you will still get NOTIMP, move onto the next nameserver and enventually return SERVFAIL. Retry introduces latency, which matters a lot for resolvers. There are situations a resolver may not want to enumerate all possibilities (e.g. the client may already timeout before the resolver get the final response). Note there really is nothing special w.r.t. ANY here. We have nameservers that return NOTIMP to TXT, MX, NS, SOA, DNSKEY etc. About the only query type that doesn't get NOTIMP is A. ANY is indeed a little special compared to the examples you mentioned. If a nameserver returns response for A, then it should return NODATA instead of NOTIMP for TXT, MX, etc. Returning NODATA for ANY is a little confusing, though it can be argued to be legitimate if only cached records are returned. So the problem is, why NOTIMP? REFUSED sounds like a better choice. Mark -- 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
[dns-operations] Fwd: [nznog] DNSSEC validation at Spark NZ
Forwarded Message Subject: [nznog] DNSSEC validation at Spark NZ Date: Tue, 10 Mar 2015 11:45:27 +1300 From: Sebastian Castro sebast...@nzrs.net.nz Organization: .nz Registry Services To: nz...@list.waikato.ac.nz nz...@list.waikato.ac.nz Hi: We'd like to share a short technical blog post from NZRS about Spark NZ enabling DNSSEC validation for part of their customers. In brief, DNSSEC related traffic coming from Spark NZ resolvers suffered a massive increase back on Dec 16th, Spark NZ also added new DNS backends for their service, and they are using load balancing to share the load. The article https://nzrs.net.nz/content/dnssec-validation-spark-nz Feedback and questions are welcomed! Cheers, -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535 ___ NZNOG mailing list nz...@list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog ___ 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] [DNSOP] dnsop-any-notimp violates the DNS standards
Regarding the statement query type ANY 'matches all RR types CURRENTLY IN THE CACHE'. Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior -- Section 3.7.1 says only that a QTYPE of * matches all RR types, whereas Section 5.3.3 (Algorithm) says to return the answer or the data if it's in the cache, but this is ambiguous with respect to QTYPE=* (other than the highly-improbable case that we have RRsets for every possible RR type, how can we know we have the answer/the data in our cache, given that the QTYPE matches all RR types at the node and there might be other RRsets extant which don't happen to be cached at the time? Is an answer really the answer if we can't be sure that it satisfies the matching rule of the QTYPE definition?). People cite the examples of Section 6.2.2 as definitive evidence that QTYPE=* queries can always be satisfied by whatever happens to be laying around in a cache, but they don't seem to notice that those were *non-recursive* queries in the examples, and it's their *non-recursiveness* that gives rise to the lack of rigor in returning a response (as it is whenever a non-recursive query is sent to a DNS entity that doesn't happen to be authoritative for the relevant zone). The required fetching behavior of a caching resolver in response to a *recursive* QTYPE=* query, is basically undefined by RFC 1034. Common practice is to treat QTYPE=* queries as effectively non-recursive, despite RD being set to 1, if *any* relevant RRset exists in the cache. Possibly, this is because the Section 6.2.2 examples were misunderstood. Or, simply because it was easier to code that way. A more modern concern would be that this rigor could be abused for possible DoS attacks. But, at this point in D! NS history, I doubt we can roll back the clock and force everyone to be rigorous in fetching answers for QTYPE=* queries. So the answers are inherently unreliable, and that situation is not likely to change, unless and until someone invents an ALL QTYPE/RR-type/meta-type. - Kevin -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Wouters Sent: Monday, March 09, 2015 10:48 AM To: D. J. Bernstein Cc: dn...@ietf.org; dns-operati...@dns-oarc.net Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards On Mon, 9 Mar 2015, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. And you've been told for two decades that this was wrong? Specifically, query type ANY matches all RR types for that node on that server. Wrong, query type ANY matches all RR types CURRENTLY IN THE CACHE. So the result of qmail's ANY query is completely meaningless and qmail cannot derive any conclusion from the absence of any record from that query. So if the MX or record has expired from the cache but another RRtype with larger TTL (say NS) is still in there, your ANY query will fail to find records. qmail with this feature is broken. Additionally, Tony Finch did a write up of qmail's ANY problems too: https://fanf.livejournal.com/10.html In new software today I would sacrifice these efficiency benefits for the sake of simplicity, but this doesn't mean that I'm going to frivolously inflict retroactive punishment upon administrators who have installed standards-compliant software and done nothing wrong. You have had 10 years to fix it. Luckilly, I believe most distributions shipping qmail add the patch to fix this already. I understand how a sufficiently large site might acquire the impression that it can safely take radical action at its own whim, violating the existing protocol standards Uhm, we pointd out qmail's _bug_ for a decade. I'm quite sure even you do not need to interop with BIND4 anymore. Apparently Firefox recently deployed ANY queries. I haven't looked at the details but I gather that they're related to the well-known annoyances of handling etc. Firefox was browbeaten into reverting this change on the basis of highly questionable claims regarding amplification: It can return enormous result sets, and some authoritative servers have taken to refusing ANY queries because of the frequency with which such queries show up in amplification attacks - I'm concerned about amplification and the perception thereof by security monitors. No, they were also told that ANY queries only return data from the cache, and using ANY queries means you might miss actual A or records. This has nothing to do with ANY queries and amplification. The common theme of CNAME/MX/A and A/ is that there's widepread interest in being able to easily retrieve multiple record types. What I'm saying is not that
Re: [dns-operations] What would it take...
In message d1250a19.9a81%edward.le...@icann.org, Edward Lewis writes:
Why don't we just implement TSIG signed updates...
In the sense of baby steps first - what I'm driving towards error
detection, ensuring that the zone-to-be is in line with it's environment.
Getting to error correction is the next level, but complicates things.
Why do we need baby steps?
Here are some impediments:
1) The entity responsible for the set up is not likely to be a
programmer.
Doesn't matter. People do username/password pairs all the time.
The point was missed - the solution to this has to rely on updating tools,
not expecting folks to modify code, write a few scripts, set up cron jobs.
As someone familiar with coding, I could write this up for myself, but in
general operations staff aren't going to develop anything very detailed.
key user {
algorithm hmac-sha256;
secret ;
};
zone example.net {
...
dnssec-update-parent { key user [server server ] };
};
or
zone example.net {
...
dnssec-update-parent {
name user;
password ;
[parent zone];
[server server];
[port server];
};
};
The server would then use the credentials to send a signed update
request with the required DS records. It is trivial to work out
the parent zone provided normal delegations are being done. It is
also possible to find where to send the update requests to
automatically.
2) Authoritative servers don't launch queries.
Has NEVER been true. SOA/IXFR queries are done regularly by
authoritative servers. For over the last decade queries for
nameserver addresses have been done for NOTIFY.
Okay, but, the queries are sent to IP addresses held in configurations or
in authoritative data, not relying on what is learned at sea. They
certainly don't iterate.
Yes, they do iterate and have done for over 15 years now. Just
because you havn't noticed that they do this doesn't mean that it
is not been being done.
I could quibble and say that messages sent by AXFR clients (RFC 5936),
which are called queries, aren't exactly the same as queries sent when
resolving a name - they share format and software but the trust model is
different. And that matters here because I've held the belief that
authoritative servers do not want to base their answers (authoritative
answers) on information learned from outside their bailiwick.
3) Authoritative servers don't know anything about the parent zone.
Discoverable.
True, unless (as mentioned later) the master is firewalled off from the
Internet (okay, lame argument). Yet we don't have tools that do this.
Why not?
nsupdate will update the parent zone automatically if the first
record of the update section is a DS record (remove or add).
6ffc3748 (Mark Andrews 2010-05-18 06:18:23 + 3093)
tmprdataset = ISC_LIST_HEAD(firstname-list);
64c43af4 (Mark Andrews 2010-03-09 03:46:12 + 3094)
if (section == DNS_SECTION_UPDATE
64c43af4 (Mark Andrews 2010-03-09 03:46:12 + 3095)
!dns_name_equal(firstname, dns_rootname)
6ffc3748 (Mark Andrews 2010-05-18 06:18:23 + 3096)
tmprdataset-type == dns_rdatatype_ds) {
64c43af4 (Mark Andrews 2010-03-09 03:46:12 + 3097)
unsigned int labels = dns_name_countlabels(name);
64c43af4 (Mark Andrews 2010-03-09 03:46:12 + 3098)
dns_name_getlabelsequence(name, 1, labels - 1, name);
64c43af4 (Mark Andrews 2010-03-09 03:46:12 + 3099)
}
It could be made more robust by looping over all the update section
looking for DS records but it works for the usual case.
For NS it needs to be a explict decision as they exist at both the parent
and the child. I have a feature request to add a at parent directive
to nsupdate to handle this.
The following will send a signed update to the parent zone.
% nsupdate
key name secret
update del zone ds
update add zone ttl ds ...
send
quit
%
4) The owners of the zone and the operator of the DNS are not always the
same entity (person, company).
Doesn't matter.
(I don't know what you mean by doesn't matter other than you are
disagreeing.)
It doesn't matter. All that matters is that credentials to do the
update are with the party that needs to initiate the update.
I raised this impediment to try to point the solution into tools (and
standards) and not relying on processes. The world we live in has managed
to build business relationships that do not align with the needed
communications to make things work smoothly. (This is why I called DNSSEC
clumsy at a Centr meeting in October 2013 - clumsy as in, it can be made
to work but needs more expertise than is evidently available in the labor
market. Evident by the frequency
Re: [dns-operations] Saga of HBONow DNSSEC Failure
On Mar 10, 2015 12:16 PM, Edward Lewis edward.le...@icann.org wrote: ... Perhaps Comcast could install little squirrel feeders in the neighborhood. That they don't, and have let this problem go unabated for years, illustrates their bias. #nutneutrality Apologies, Eli ___ 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] CloudFlare policy on ANY records changing
On Mar 10, 2015, at 8:46 AM, David C Lawrence t...@akamai.com wrote: Paul Hoffman writes: On Mar 10, 2015, at 6:25 AM, Yunhong Gu g...@google.com wrote: So the problem is, why NOTIMP? REFUSED sounds like a better choice. +1. REFUSED exactly describes what is going on. One down side there, however, is that REFUSED as understood by resolvers commonly has the semantic currently that the name is not hosted by the server at all. What used to be root referrals for lame delegations is now REFUSED to minimize response size. If a resolver is sending an ANY before it sends its actual request, that could be a problem. However, they shouldn't be doing that. It is likely that any response we think of (even no response at all) will cause some deployed resolvers to get the wrong idea. Having said that, it is perfectly reasonable for an operator to not want to reply to an ANY, given the unclarity of what it is expected to send back and the opportunity for malicious intelligence gathering. So us saying if you want to do this, use that at least will cause future versions of things that relied on ANY to know what they are getting. Also: this should probably one of the three threads on dn...@ietf.org... --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] CloudFlare policy on ANY records changing
On Tue, 10 Mar 2015, Chris Adams wrote: A problem with ever using ANY to get more information from a cache is the client's/applications's assumption that all requests will go to the same server. Even if a client sends requests to the same IP, anycast can mean they go to a different server. So so true. You can use it in some vague way to fingerprint anycast DNS services. DAMHIK! -- Fred Morris ___ 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 would it take...
On 3/10/15, 16:45, Mark Andrews ma...@isc.org wrote: Why don't we just implement TSIG signed updates... In the sense of baby steps first - what I'm driving towards error detection, ensuring that the zone-to-be is in line with it's environment. Getting to error correction is the next level, but complicates things. Here are some impediments: 1) The entity responsible for the set up is not likely to be a programmer. Doesn't matter. People do username/password pairs all the time. The point was missed - the solution to this has to rely on updating tools, not expecting folks to modify code, write a few scripts, set up cron jobs. As someone familiar with coding, I could write this up for myself, but in general operations staff aren't going to develop anything very detailed. 2) Authoritative servers don't launch queries. Has NEVER been true. SOA/IXFR queries are done regularly by authoritative servers. For over the last decade queries for nameserver addresses have been done for NOTIFY. Okay, but, the queries are sent to IP addresses held in configurations or in authoritative data, not relying on what is learned at sea. They certainly don't iterate. I could quibble and say that messages sent by AXFR clients (RFC 5936), which are called queries, aren't exactly the same as queries sent when resolving a name - they share format and software but the trust model is different. And that matters here because I've held the belief that authoritative servers do not want to base their answers (authoritative answers) on information learned from outside their bailiwick. 3) Authoritative servers don't know anything about the parent zone. Discoverable. True, unless (as mentioned later) the master is firewalled off from the Internet (okay, lame argument). Yet we don't have tools that do this. Why not? 4) The owners of the zone and the operator of the DNS are not always the same entity (person, company). Doesn't matter. (I don't know what you mean by doesn't matter other than you are disagreeing.) I raised this impediment to try to point the solution into tools (and standards) and not relying on processes. The world we live in has managed to build business relationships that do not align with the needed communications to make things work smoothly. (This is why I called DNSSEC clumsy at a Centr meeting in October 2013 - clumsy as in, it can be made to work but needs more expertise than is evidently available in the labor market. Evident by the frequency of defects.) I've already submitted a draft that would make this all possible. Sending signed UPDATE messages is relatively trivial. Which one? Is there an implementation of this? Any operational experience? 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 would it take...
Tsig won't scale for something like this. Please consider sig0. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ 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] Saga of HBONow DNSSEC Failure
Jason- Thank you for sharing the details. Another excellent real world example. Too bad it caused you consternation. -Rick From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf Of Livingood, Jason Sent: Monday, March 09, 2015 8:50 PM To: dns-operations Subject: [dns-operations] Saga of HBONow DNSSEC Failure So earlier today HBO announced a new HBONow streaming service (at an Apple event). The FQDN to order, which should have been DNSSEC-enabled, was order.hbonow.com. This unfortunately suffered from a rather inconveniently timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/). :-( Of course, these being hot Net Neutrality days in the U.S., we at Comcast were quickly blamed for blocking access to ordering this new service (despite failures at Google and other validators). Had this persisted much longer, we might have considered a negative trust anchor of course, assuming we had direct contact with HBO on the matter (established after they fixed the issue we flushed the cache). A good example of the sentiment was the tweet Wow. I have Comcast and can't reach http://hbonow.com unless I use a different network. #NetNeutrality . People tweeted to the FCC to alert them as well. But two other I-Ds I wrote up did come in handy in some of my replies on social media: http://tools.ietf.org/html/draft-livingood-dnsop-auth-dnssec-mistakes-00 and http://tools.ietf.org/html/draft-livingood-dnsop-dont-switch-resolvers-00 Which leads me simply to say that if there's any interest in progressing these I-Ds in any way, let me know. Of course you may not find them useful until people yell at you for other people's DNS errors. ;-) - Jason 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] Saga of HBONow DNSSEC Failure
On Tue, Mar 10, 2015 at 11:09 AM, Matthew Pounsett m...@conundrum.com wrote: On Mar 9, 2015, at 23:50 , Livingood, Jason jason_living...@cable.comcast.com wrote: So earlier today HBO announced a new HBONow streaming service (at an Apple event). The FQDN to order, which should have been DNSSEC-enabled, was order.hbonow.com. This unfortunately suffered from a rather inconveniently timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/). :-( Of course, these being hot Net Neutrality days in the U.S., we at Comcast were quickly blamed for blocking access to ordering this new service (despite failures at Google and other validators). I’d just like to comment how pleased I am that Comcast continues to push DNSSEC validation, despite taking regular hits from end users. +lots. Thank you Comcast, and Jason. W I keep hoping others will follow suit.. the more large validator operators that enable it, the fewer hits anyone will take for doing so. ___ 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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] CloudFlare policy on ANY records changing
On Mar 10, 2015, at 6:25 AM, Yunhong Gu g...@google.com wrote: So the problem is, why NOTIMP? REFUSED sounds like a better choice. +1. REFUSED exactly describes what is going on. --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] Saga of HBONow DNSSEC Failure
On 3/9/15, 23:50, Livingood, Jason jason_living...@cable.comcast.com wrote: So earlier today HBO announced a new HBONow streaming service (at an Apple event). The FQDN to order, which should have been DNSSEC-enabled, was order.hbonow.com. This unfortunately suffered from a rather inconveniently timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/). :-( Of course, these being hot Net Neutrality days in the U.S., we at Comcast were quickly blamed for blocking access to ordering this new service (despite failures at Google and other validators). When this first surface after the infamous NASA.GOV incident, I sent a private apology because I (as well as others) knew this day would come - when an ISP would get the brunt of someone's DNSSEC misfire. (Others include many who worked on the original design and deployment workshops.) This time I'll offer a public apology. Sorry, Comcast. The only way I can make this up to you is to better my efforts at making DNSSEC an easier to run, less clumsy protocol. The protocol is what it is - when something doesn't check out, it goes dark. The mitigation is better tools to explain this and to manage this. The negative trust anchor draft addresses the latter. Oh, and, Jason, a squirrel has managed to chew through my mom's cable, can you fix that for me? Perhaps Comcast could install little squirrel feeders in the neighborhood. 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] Saga of HBONow DNSSEC Failure
On Mar 9, 2015, at 23:50 , Livingood, Jason jason_living...@cable.comcast.com wrote: So earlier today HBO announced a new HBONow streaming service (at an Apple event). The FQDN to order, which should have been DNSSEC-enabled, was order.hbonow.com. This unfortunately suffered from a rather inconveniently timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/). :-( Of course, these being hot Net Neutrality days in the U.S., we at Comcast were quickly blamed for blocking access to ordering this new service (despite failures at Google and other validators). I’d just like to comment how pleased I am that Comcast continues to push DNSSEC validation, despite taking regular hits from end users. I keep hoping others will follow suit.. the more large validator operators that enable it, the fewer hits anyone will take for doing so. ___ 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 would it take...
In message d124b0ce.9a2e%edward.le...@icann.org, Edward Lewis writes: Content-transfer-encoding: 7bit ...to prevent another DS--DNSKEY mishap from happening again? I'm presenting the message to the DNS Operations list of DNS-OARC. (Being subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF participant or talking as a past operator of DNS or as ) In short, think about when a name server loads a zone with a DNSKEY set in it. If, at the parent zone, there is a DS set and none of it's contents refer to a record in the DNSKEY set, all DNSSEC validating queries will declare everything in the zone broken. So, why can't the name server find the DS set, run a check and barf if there's a problem? Barf - either refusing to load the zone or refusing to change the zone that is already running. Why don't we just implement TSIG signed updates to the parent and send a UPDATE message to the parent? What is so hard about a username/password pair which is all that TSIG is. Here are some impediments: 1) The entity responsible for the set up is not likely to be a programmer. Doesn't matter. People do username/password pairs all the time. 2) Authoritative servers don't launch queries. Has NEVER been true. SOA/IXFR queries are done regularly by authoritative servers. For over the last decade queries for nameserver addresses have been done for NOTIFY. 3) Authoritative servers don't know anything about the parent zone. Discoverable. 4) The owners of the zone and the operator of the DNS are not always the same entity (person, company). Doesn't matter. #1 - The implications of this is - tools/components are needed. One option are management/diagnostic tools. Another option is an embedded in the name server component. More tools is great when you are the jockey, more embedded components is great when you are the customer. #2 - Software can do what it wants - but sometimes hidden masters are shielded with the public Internet. (I'll assume the case is that the parent and child zones are on separate sets of machines - when this is't true, we don't have the problem.) I bet though, that it wouldn't be hard to convince the operators of hidden masters to allow them access port 53 outside the firewall. #3 - There's a brute force way to overcome this, come down the root to find the cut point. Or this can be configured somehow (but I hate pinning). Or maybe just doing a straight forward use of a validating recursive server (but that's more tools, see #1). #4 - This is a critical aspect of the problem. Even if the customer tells the DNS hosting company to roll keys, the customer has to be the one who finds the registrar to ensure the DS set is correct in the registry. That's four participants with the most important (customer) the least capable (or they probably wouldn't be a customer). Failing to automate away the customer's problem will kill the effort, certainly stall scaling. The first step is for the operations community to cobble together a solution to this problem. Perhaps a proposal goes to the IETF for the proper review and legal protection. And if there's a need to change other policies, an IETF document might be the greatest asset. This is one way to make DNSSEC less clumsy. Please - if there are more impediments, suggest them. I may have missed something. If you disagree with an impediment, speak out. I've already submitted a draft that would make this all possible. Sending signed UPDATE messages is relatively trivial. Mark -- 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] CloudFlare policy on ANY records changing
Paul Hoffman writes: On Mar 10, 2015, at 8:46 AM, David C Lawrence t...@akamai.com wrote: One down side there, however, is that REFUSED as understood by resolvers commonly has the semantic currently that the name is not hosted by the server at all. If a resolver is sending an ANY before it sends its actual request, that could be a problem. However, they shouldn't be doing that. Yeah, we've well established they shouldn't. Bad guys often don't care about what they shouldn't be doing, though, and (untested assertion follows) using REFUSED responses for ANY queries of random names could be a pretty useful vector for getting all of the servers for a domain declared lame. I'm not saying that ultimately the REFUSED approach is unworkable, just that I'd like to see some practical testing of it in addition to the support of the philosophical purity of it. ___ 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] Saga of HBONow DNSSEC Failure
On 3/10/15, 12:55 PM, Eli Heady eli.he...@gmail.commailto:eli.he...@gmail.com wrote: On Mar 10, 2015 12:16 PM, Edward Lewis edward.le...@icann.orgmailto:edward.le...@icann.org wrote: ... Perhaps Comcast could install little squirrel feeders in the neighborhood. That they don't, and have let this problem go unabated for years, illustrates their bias. #nutneutrality We can only take reasonable, fair, and transparently disclosed steps to prevent squirrels from eating coaxial cable or fiber optic cables. If we put extra layers of protection on cables to block feeding access specifically for squirrels, then of course we’d be blocking the squirrels’ access to the Internet (for nourishment and information). Such chew-blocking may be acceptable if it were on a species-neutral basis, preventing chewing equally by dogs, cats, owls, hawks, squirrels, bears, and others. But I’d probably have to run that past our Legal department. ;-) JL ___ 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] What would it take...
...to prevent another DS--DNSKEY mishap from happening again? I'm presenting the message to the DNS Operations list of DNS-OARC. (Being subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF participant or talking as a past operator of DNS or as ) In short, think about when a name server loads a zone with a DNSKEY set in it. If, at the parent zone, there is a DS set and none of it's contents refer to a record in the DNSKEY set, all DNSSEC validating queries will declare everything in the zone broken. So, why can't the name server find the DS set, run a check and barf if there's a problem? Barf - either refusing to load the zone or refusing to change the zone that is already running. Here are some impediments: 1) The entity responsible for the set up is not likely to be a programmer. 2) Authoritative servers don't launch queries. 3) Authoritative servers don't know anything about the parent zone. 4) The owners of the zone and the operator of the DNS are not always the same entity (person, company). #1 - The implications of this is - tools/components are needed. One option are management/diagnostic tools. Another option is an embedded in the name server component. More tools is great when you are the jockey, more embedded components is great when you are the customer. #2 - Software can do what it wants - but sometimes hidden masters are shielded with the public Internet. (I'll assume the case is that the parent and child zones are on separate sets of machines - when this is't true, we don't have the problem.) I bet though, that it wouldn't be hard to convince the operators of hidden masters to allow them access port 53 outside the firewall. #3 - There's a brute force way to overcome this, come down the root to find the cut point. Or this can be configured somehow (but I hate pinning). Or maybe just doing a straight forward use of a validating recursive server (but that's more tools, see #1). #4 - This is a critical aspect of the problem. Even if the customer tells the DNS hosting company to roll keys, the customer has to be the one who finds the registrar to ensure the DS set is correct in the registry. That's four participants with the most important (customer) the least capable (or they probably wouldn't be a customer). Failing to automate away the customer's problem will kill the effort, certainly stall scaling. The first step is for the operations community to cobble together a solution to this problem. Perhaps a proposal goes to the IETF for the proper review and legal protection. And if there's a need to change other policies, an IETF document might be the greatest asset. This is one way to make DNSSEC less clumsy. Please - if there are more impediments, suggest them. I may have missed something. If you disagree with an impediment, speak out. 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] Saga of HBONow DNSSEC Failure
On 3/10/15, 12:11 PM, Edward Lewis edward.le...@icann.org wrote: I (as well as others) knew this day would come - when an ISP would get the brunt of someone's DNSSEC misfire. (Others include many who worked on the original design and deployment workshops.) It won¹t be the last time! ;-) The only way I can make this up to you is to better my efforts at making DNSSEC an easier to run, less clumsy protocol. Works for me! That¹d be awesome. :-) DNSSEC needs to be super easy to use as an authoritative operator, running on auto-pilot after initial setup. The simpler more automated operations are, the less fragile the signing infrastructure will be (and the whole thing end to end of course). - Jason ___ 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] [Zonemaster] DNS zone/service checking tool features survey
Hi All, Thanks for responding one response per user. Apologies for cross-posting. *Access*: All *Close date*: 03/04/2015 *Survey*: https://fr.surveymonkey.com/r/zonemasterhttps://centr.org/survey-form/dns-checking-tools-ed-2014 *Background*: Afnic and IIS.SE are currently in the maintenance phase of Zonemaster, a new DNS zone/service checking tool developed as a replacement of their respective tools, ZoneCheck (http://www.zonecheck.fr/) and DNSCheck (http://dnscheck.iis.se/). The survey intends to understand the requirements of the community from such a tool. The development of new features to be integrated to the Zonemaster tool will be prioritized based on this survey's feedback. All the documentation and code are public in github. More information about the project can be obtained from here : https://github.com/dotse/zonemaster/blob/master/README.md;. The web interface can be accessed in this link zonemaster.net and from other TLD extensions such as .se, .fr and .re. Sandoche. ___ 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
