Re: [dns-operations] dnstap tool
Hi! We have the dnstap binary running under daemontools' 'supervise', and pipe its output either to 'logger' for syslogging, or an 'aws logs push' process to ingest directly to Cloudwatch Logs. Since the example golang binary simply writes to standard out, it was easy to wire up. matt > On Nov 9, 2020, at 5:47 AM, Hoan Vu wrote: > > > Dear! > > We are learning to get query log by dnstap tool. For DNSTAP Tool we cannot > get log query continuosly and directly to the current syslog server, since > raw log need to capture and then read after stop capture. > I wanna to know how to get the query log continously when using DNSTAP TOOL > of your DNS and other DNS of organizations have already applied. Can you > share with us and help us to deploy DNSTAP TOOL to our DNS Authoritative > Secondary. > Thanks! > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] knot-dns
Hi drc! On Dec 14, 2014, at 6:51 PM, David Conrad d...@virtualized.org wrote: If you built out your customer resolver cloud with a set of Nominum servers and Unbound servers behind load balancers, would the resolver bug being discussed have taken out your infrastructure? Do you believe managing the configuration of a set of Nominum servers and Unbound servers (regardless of how many) is in any way challenging? I think we are agreeing on this point. In your example, where is the value I would have derived from taking on the overhead of adding Unbound servers to my architecture? Matt ___ 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] knot-dns
How many different responses did we see to the recent recursion cve? How does code diversity fix protocol vulns? Matt On Dec 13, 2014, at 1:44 PM, Roland Dobbins rdobb...@arbor.net wrote: On 14 Dec 2014, at 4:36, Rubens Kuhl wrote: What I'm curios about is how we measure code diversity among those 3 platforms; would using any 2 of the 3 be diverse enough for long-term survivability, or are they too similar in architecture ? While it sounds good on phosphor, the concept of code diversity is so abstract, compared to the significant operational challenges and associated security challenges of operating separate systems performing the same functions (sort of), but differently, that any potential benefit is generally outweighed by the negative impact to security posture of said challenges. --- Roland Dobbins rdobb...@arbor.net ___ 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] knot-dns
Hi DRC! Sorry, I didn’t mean to advocate a monoculture in a vacuum. My point was delivered much more eloquently by Roland: Given the set of practical issues we’re worried about today, delivering a service via multiple codebases certainly isn’t a magic bullet. Upon closer inspection heterogeneity might reduce exposure to catastrophe much less than you’d expect. Or more likely, have a multiplicative effect instead. For a simple example, if my business depended on PKI, would I have gained security and reliability over the last few years by using both OpenSSL and GnuTLS? Would adding in native OSX and Windows frameworks have reduced my exposure or multiplied my risks? Cheers, matto On Dec 14, 2014, at 2:52 PM, David Conrad d...@virtualized.org wrote: On Dec 14, 2014, at 12:28 PM, Matthew Ghali mgh...@snark.net wrote: How does code diversity fix protocol vulns? Because different people implement the protocol differently (as evidenced by the above)? Of course, one might argue that the fact that there were different behaviors might suggest a bug in the protocol specification, but that doesn't argue against code diversity. Code diversity is to help mitigate implementation bugs. Regards, -drc 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] dig 9.8.5-P1 not seeing 'aa' flag set from authoritative nameservers?
...and anyone selling those products, they are sleeping quite well also. :( On Jul 25, 2014, at 6:28 AM, Casey Deccio ca...@deccio.net wrote: On Fri, Jul 25, 2014 at 8:22 AM, Mark E. Jeftovic mar...@easydns.com wrote: As I was drifting off to sleep I realized that had to be it. I'm on vaction at the moment and I noticed this as I was connected on the hotel's WIFI. I suppose no one can sleep well with DNS interceptors on the loose... (except those running validating resolvers and resolving signed zones, of course :) ). Casey ___ 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 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] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 9:29 AM, Robert Willmann robert.willm...@gordito.de wrote: The argument, that you won't get a certificate for these names from someone who is regognized by your browser isn't valid: As you only would use such a internal domain for your internal network, you would have to create a internal CA anyway (and put it in your browsers). You may be much smarter than me, but I have found that establishing and maintaining a full internal PKI is a bit more complicated than purchasing a certificate. Unless you're talking about half-assing it, in which case I'd wonder what the value of the eventual leaf certificates actually are, besides security theater. Is there a use case I am missing where certificates of unknown provenance would be beneficial to operational security? Matt 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] Current thinking on internal corporate/campus domain names
Hi PHB- I'm curious when this scheme would be simpler to implement or less expensive to operate as opposed to using a delegated internal subdomain of an existing parent domain registration (see corp.verio.net modulo the psychopathic NS rrset). I'm certainly no authority but everyone seems to have a much more complicated solution to what I've always found to be a simple problem. Is it the old never expose 1918 addresses in public DNS fetish, or the related must not expose secret internal names via DNS paranoia? Matt On Jun 24, 2014, at 12:05 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: Well you could use ADQ2EW-H5BLYG-JSUJEZX-S6QT3I-ZSA.corp But no public CA could issue you any certificates which would mean you can't do IMAP over TLS and many other things you would likely want to do. But there could be a .crypt or .ppe top level domain in which there was no registration fee. People would simply generate a master public key pair, generated the phingerprint (Base64s of the SHA-512-128 hash of the DER KeyInfo encoding of the public key), this would be their second level domain. ADQ2EW-H5BLYG-JSUJEZX-S6QT3I-ZSA.crypt Entries in the zone would naturally be DNSSEC signed and TRANS logged. The DNSSEC KSK would be signed by the master public key corresponding to the zone. You would probably not want to present a zone of that type to end users but you might well use it as the target of a CNAME. Or the binding might be made through a certificate. If you ever lost your Master Key or it was disclosed you would be utterly and totally screwed. On Tue, Jun 24, 2014 at 1:11 PM, Colm MacCárthaigh c...@stdlib.net wrote: On Mon, Jun 23, 2014 at 5:41 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: As a practical matter .corp is already used for this purpose and ICANN has been forced to accept the practice. So that would be a good choice. One of the problems with .corp is what happens when companies, universities or other organisations (and their networks) merge. There is definitely a case for uniqueness. It would be interesting to have a registry for a TLD that can manage uniqueness, but also guarantee that the TLD will never have active public nameservers (talk about cheap to run!). -- Colm ___ 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 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] alidns
Were I Facebook and and permitted to operate in China, the first thing I’d expect to need is a special cluster to serve the region. Most likely with slightly different “content policies”. Just playing devils advocate; matt On Jun 20, 2014, at 12:02 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Tue, Jun 17, 2014 at 10:43:04AM -0700, Matthew Ghali mgh...@snark.net wrote a message of 133 lines which said: Your methodology may have been sufficient 20 years ago, but just about any CDN complicates the issue. How do you propose distinguishing between deliberate traffic engineering and lies, Heuristics: you query facebook.com from many places in the world (for instance by using RIPE Atlas probes) and you see that all the answers are in the same prefix, except in China. This is a good indication. 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] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root
On Apr 4, 2014, at 2:20 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: [Warning: sloppy terminology, for instance, root is not used in the usual DNS meaning.] http://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root Funny idea but it works only if your DNS is hosted at CloudFlare. Funny... First, to claim invention for DNS record synthesis is far past disingenuous. At the least Akamai and Route 53 have been doing this for years. Cloudflare has a reputation and didn’t care what damage it took with their colleagues, who obviously don't overlap at all with their market. Second, to call this record synthesis a “CNAME” is a disservice to the industry. Everyone else selling this sort of service has gotten along fine describing it honestly - AWS’s alias, for example. Overloading the name of a clearly defined DNS rrtype just causes confusion and misunderstanding. Old Matt would drop the (f-)bomb here and say something snarky. We’ve established that Cloudflare was dishonest in naming the service and its original providence. New Matt will just be sure clients are aware of the many other vendor choices. Hopefully, this was just a late April 1 prank, and I’ve been trolled. matto ___ 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 requests are logged by BIND?
I'm pretty sure you are comparing qps to pps and being surprised that there is not a 1:1 relationship. matto On Jan 25, 2013, at 11:11 AM, Liu Mingxing lmxha...@gmail.com wrote: By a rrdtool, I found that DNS traffic of router before an authoritative nameserver is larger than those seen from querylog. For example, cacti tells us qps is 2k while querylog shows a smaller qps. ___ 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's a suffix?
Well, I went back to check, but none of the RFCs seem to explain what a suffix is, in the context of DNS. Clearly I haven't been keeping up with new developments in the technology. Where can I read about this new object? The last time I checked, people using terms like suffix in relation to DNS were usually MS AD administrators* who were clearly confused by simple concepts like domain names. Apparently times have changed, with this term now being used legitimately between subject matter experts on a mailing list for dns operators. I'm obviously behind again so please advise on how I can recognize a suffix in the wild, and distinguish it from a garden-variety old-fashioned domain name. Thanks in advance for the help! Matt Ghali (* Or, surprisingly enough, technology executives at huge telcos who were running RFQs for multi-million-dollar ENUM projects.) On Jan 20, 2013, at 6:34 PM, Jothan Frakes jot...@gmail.com wrote: I strongly suggest you submit .cw to the public suffix list at mozilla. http://publicsuffix.org/submit/ Jothan Frakes ___ 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] responding to spoofed ANY queries
So if I understand correctly, the solution you are advocating is to only answer non-spoofed queries? On Jan 10, 2013, at 7:23 AM, Jim Reid j...@rfc1035.com wrote: I agree: provided we're talking about responding to queries from valid recursors. However we're not. The context is spoofed queries. [See above.] Responding to these is bad because (a) it chews your bandwidth and CPU; (b) the replies don't go to the actual source that generated the queries; (c) the destination of those responses doesn't want or need that inbound traffic. This is why we agree RRL helps to reduce the damage from spoofed ANY flood attacks. ___ 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
