Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-rfc2845bis

On Wed, Jul 10, 2019 at 10:56:26PM +0200, Benno Overeinder wrote: > >From the feedback on the mailing list, the chairs believe that all > feedback and comments have been addressed by the authors, either in the > draft or on the mailing list. With tremendous apologies for not spending a second on

Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

On Sun, Mar 24, 2019 at 04:36:50AM -0700, Paul Vixie wrote: > i object to serve-stale as proposed. my objection is fundamental and goes to > the semantics. no editorial change would resolve the problem. I too object. This is partially due to the apparently unresolved IPR issue from Akamai, who

Re: [DNSOP] New draft for consideration:

On Sun, Mar 24, 2019 at 06:42:53AM +, Paul Hoffman wrote: > to the terminology problems, I am proposing a few abbreviations that > people can use in these discussions. The draft below, if adopted by the > DNSOP WG, would update RFC 8499 with a small set of abbreviations. Hi Paul, Thank you

[DNSOP] Brief update on DNS Camel & Hello-DNS

Hi everyone, After the most excellent DNS-OARC in Amsterdam, I got some new zeal to work on DNS projects. In this message I request feedback & hope that some of you may want to help. DNS Camel Viewer First, the "DNS Camel viewer" on https://powerdns.org/dns-camel/ has been

Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?

On Wed, Oct 24, 2018 at 05:01:53AM -0400, Viktor Dukhovni wrote: > And yet, here and there I see mention of having to take care to avoid "loops", > but loops are impossible in a monotone strictly decreasing sequence. Yes. This is one of the best ways of preventing such loops. Some libraries

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Sat, Aug 18, 2018 at 07:12:57PM -0400, Ted Lemon wrote: > How will you block it? So just to make this a bit more colorful, DoH allows servers to push unsollicited DNS responses, which the browser is then free to put in its DNS cache. This allows the DoH endpoint to hop around at will, or even

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On Sat, Aug 18, 2018 at 05:22:53PM -0400, Ted Lemon wrote: > 1. Why is DoH being used? > 2. What is the thread model that DoH is addressing? That not yet enough of the internet has been centralized on big cloud providers in foreign jurisdictions, I think. (this post does get DNS operational

[DNSOP] DoH interaction, sortlist Re: BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

On Fri, Jun 15, 2018 at 01:12:31PM -0400, Andrew Sullivan wrote: > I believe that RRsets are unordered sets by definition. So I supect > that if people are relying on the order in which they come off the > wire, they're making a mistake. A data point here may be useful. PowerDNS has in many

[DNSOP] tdns teachable from scratch authoritative server 'official launch'

Hi everyone, I'm happy to announce that RIPE Labs allowed me some prime space on their site to announce 'tdns'. I posted about this before, but your help is really welcome right now. https://labs.ripe.net/Members/bert_hubert/introducing-tdns-the-teachable-authoritative-dns-server has the

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

On Mon, Apr 16, 2018 at 03:30:36PM +0100, Tony Finch wrote: > I'm slightly surprised that Evan and Mukund haven't mentioned this, but > BIND 9.1 to 9.11 had additional-from-cache and additional-from-auth > options which controlled this behaviour. (I turned them off on my servers > years ago.) In

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

On Fri, Apr 13, 2018 at 07:59:19AM -0700, Paul Hoffman wrote: > >Specifically, I thought it was a good a idea to make a "minimal but > >correct and best practices" authoritative nameserver. > Thank you, thank you. I can also tell you it is fun to start one from scratch and not make the same

[DNSOP] tdns, 'hello-dns' progress, feedback requested

Hi everyone, [tl;dr - is it ok not to chase CNAMEs out of zones and only to do in-zone glue? how many CNAMEs should one follow? Plus some fun things] Under the watchful eye of the lovely camel Farsight sent us [1], I've been working on enhancing the 'hello-dns' pages on

Re: [DNSOP] Verifying errata 5316 against RFC1034.

On Sun, Apr 01, 2018 at 11:58:07PM +0530, Mukund Sivaraman wrote: > Caching takes place not just by BIND, but Unbound as well and does not > cause problems, so the stronger requirement is unnecessary and ought to > be re-worded. PowerDNS recursor will also happily cache a *.record but not do

Re: [DNSOP] Current DNS standards, drafts & charter

On Sun, Apr 01, 2018 at 02:39:06AM +0530, Mukund Sivaraman wrote: > Just a "guide to the RFCs" won't be sufficient. Language has to be > corrected; large parts of RFC 1034 and 1035 have to be rewritten and > restructured, incorporating clarifications from newer RFCs. It would be > a big work, but

[DNSOP] Hello, and welcome to DNS

Hi everyone, [tl;dr: check out https://powerdns.org/hello-dns/ and https://powerdns.org/hello-dns/meta.md.html ] As part of looking into the complexity of the current DNS specification, I have been pointed at earlier efforts to improve the situation, both for DNS and for other protocols.

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman wrote: > I'd raise the bar even higher, to see complete implementation in a major > open source DNS implementation when it applies. Sometimes implementation > problems are very revealing (client-subnet should have gone through > this).

[DNSOP] Current DNS standards, drafts & charter

Hi everyone, I've been looking at the amount of DNS out there, and I think we can do several things with them. I've also concluded that the mediocrity of DNS implementations outside of the well-known ones can not be fully blamed on "stupid programmers". The fact that we've offered the world

[DNSOP] help needed adding sections Re: DNS Camel Viewer

On Sat, Mar 24, 2018 at 02:04:02PM -0400, Matthew Pounsett wrote: > I went to go dig into this and in the process of producing a list I found > that the list was longer than I imagined, and that there are more > categories of documents that don't contribute to the camel than I thought. Hi

[DNSOP] DNS Camel Viewer

Hi everyone, [tl;dr, check out https://powerdns.org/dns-camel/ ] As a first step in attempting to not only whine about a glut of DNS standards, I've made an easy to update viewer of all DNS relevant standards. The good news is, if we filter out obsoleted, historical, informational and BCP

[DNSOP] The DNS Camel writeup

Hi everyone, I did a small writeup of the "DNS Camel" presentation from this Tuesday in London. It can be found here: https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/ (includes link to video, https://www.youtube.com/watch?v=8N_PO3s_Z24=youtu.be=1h20m4s ) One

Re: [DNSOP] CLIENT-SUBNET bis appetite?

On Thu, Dec 14, 2017 at 11:09:13PM +0530, Mukund Sivaraman wrote: > Any appetite for it? Don't throw things at me.. I ask because the > current thing is slowly getting more widely deployed and there are > design issues that can do with a ECS2 that breaks from ECS1 protocol. I > ask because I'm

Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling

On Wed, Dec 13, 2017 at 05:36:32PM +0800, zuop...@cnnic.cn wrote: > so far as i know, many CDNs already use similar methods as you mentioned in > PowerDNS 4.1.1 > but i think only the Authoritative Server change is not enough, support > on the recursive server is also very important . >

Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling

On Wed, Dec 13, 2017 at 09:18:23AM +0100, Stephane Bortzmeyer wrote: > > For example, a CDN provider can’t schedule 70% of traffic to node A > > and 30% of traffic to node B [...] adding a “weight” attribute > > First, the obvious question: why reinventing RFC 2782? Implementing this

Re: [DNSOP] IVIPTR: New RR for DNS

On Sat, Nov 25, 2017 at 10:41:13PM +0500, Tariq Saraj wrote: > Please provide your valuable feedback on the newly uploaded draft. > draft-tariq-dnsop-iviptr-00 > > *IVIPTR: Resource Record for DNS* Hello Tariq, I have read through this

Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname

On Thu, May 11, 2017 at 06:55:55AM -0400, tjw ietf wrote: > I'm caught up with my day job, and the discussion on this has died down, > but it looks like the work is moving along smoothly, it's time to kick off > a Call for Adoption on this document. (well, maybe late). > > This starts a Call for

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

On Fri, Apr 07, 2017 at 10:20:00AM +0200, Bjørn Mork wrote: > Just to avoid any confusion: Although I demonstrated the issue by > running BIND on my laptop only, the real usage scenario is resolver > service for a few million distinct administrative domains (aka > "customers"). Changing the trust

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Tue, Dec 20, 2016 at 01:12:06PM -0500, Paul Wouters wrote: > One would hope it interops, as this document only describes an IXFR/AXFR > of a zone with existing RRTYPEs with some semantics associated to CNAME > records for other applications (such as DNS servers) The "some semantics" parts are

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Tue, Dec 20, 2016 at 10:46:40AM -0800, Paul Hoffman wrote: > >Unbound is also slated to have support for RPZ. > Unbound can document it or point to the ISC documentation. We might as well stop doing standards all together then. We have something that works. It interoperates. There is an

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Tue, Dec 20, 2016 at 09:43:25AM -0800, Paul Hoffman wrote: > On 20 Dec 2016, at 8:35, Ray Bellis wrote: > > >The document primarily covers BIND's behaviour. > > Noted. That seems like a good reason for ISC to document it. No it doesn't. It also documents the exact PowerDNS behaviour. RPZ is

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

On Mon, Dec 19, 2016 at 11:50:02AM +0200, ac wrote: > > So please realise this is something that people need. Best that they > > do it in a standardized fashion. > > > > people also need tools to send out bulk emails. maybe bots. should we > start RFC's for that? We did in fact. All those things

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

On Mon, Dec 19, 2016 at 11:24:33AM +0200, ac wrote: > when there is an RFC that describers how to lie and then adds > deception, this is no longer something to negotiate or to discuss much. By this token any firewall is censorship and lies. Yet we still use them. We have also documented ways to

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

On Mon, Dec 19, 2016 at 09:09:42AM +, Evan Hunt wrote: > On Mon, Dec 19, 2016 at 10:42:35AM +0200, ac wrote: > > it still is never okay to lie and to deceive. > > [...] > > This is simply about ethics. > > I hereby, with full knowledge and prior consent, give my resolver (which > I own)

Re: [DNSOP] software patents Re: draft-fujiwara-dnsop-resolver-update-00

On Tue, Nov 15, 2016 at 04:58:43AM +0900, Ted Lemon wrote: > On Fri, Nov 11, 2016 at 10:13 PM, bert hubert <bert.hub...@netherlabs.nl> > wrote: > Bert Huber wrote: > > Also, should we work with companies attempting to hinder progress by > > clinging to patents whic

[DNSOP] software patents Re: draft-fujiwara-dnsop-resolver-update-00

On Fri, Nov 11, 2016 at 01:49:31AM +0900, fujiw...@jprs.co.jp wrote: > Jinmei-san, thanks very much for your detailed comments. > > I also received IPR claim from Nominum. > > https://datatracker.ietf.org/ipr/2907/ > https://patents.google.com/patent/US7769826B2/ As a matter of policy,

Re: [DNSOP] Root server tar pitting? Is there a better way?

On Mon, May 16, 2016 at 06:35:10PM -0400, Shumon Huque wrote: > PowerDNS's root-nx-trust is I believe an implementation of what is described > in nxdomain-cut: > > https://tools.ietf.org/html/draft-ietf-dnsop-nxdomain-cut-03 > > rather than the nsec-aggressive-use or cheese-shop drafts -

Re: [DNSOP] Root server tar pitting? Is there a better way?

On Mon, May 16, 2016 at 09:34:17PM +, Wessels, Duane wrote: > I think what you're suggesting has already been proposed. See > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ and > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/ It is in fact

Re: [DNSOP] Root server tar pitting? Is there a better way?

On Mon, May 16, 2016 at 09:34:17PM +, Wessels, Duane wrote: > Hi Brian, > > I think what you're suggesting has already been proposed. See > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ and > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-cheese-shop/ It

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote: > Or just having the TCP implementation in BIND get improved as it’s clear there > are some more people pushing in this direction. I’m looking at just putting > something like DNSDIST on my hosts to process TCP and balance it across >

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote: > Or just having the TCP implementation in BIND get improved as it’s clear there > are some more people pushing in this direction. I’m looking at just putting > something like DNSDIST on my hosts to process TCP and balance it across >

Re: [DNSOP] Order of DNS records...

On Tue, Jan 12, 2016 at 03:47:16PM +0100, Stephane Bortzmeyer wrote: > > returned RRSIG first for 44% of my statistically dubious sample. > > It is said that PowerDNS does it at random, on purpose, to break > erroneous programs. Let me clarify that. PowerDNS Authoritative has always randomized

[DNSOP] available, a test domain for EDNS client subnet

Hi everybody, With help from PowerDNS ueber value community member Aki Tuomi, the GeoIP backend in PowerDNS has been extended to use the netmask information contained in the Maxmind geolocation database. We needed this because we couldn't find a lot of domains out there that actually respond

Re: [DNSOP] Character encoding of URI Target RDATA?

On Wed, Jun 17, 2015 at 12:38:22PM +0900, Masataka Ohta wrote: What I'm asking is how the octet sequences provided by the URI RR RFC The RFC does not provide the octet sequences. Zone files do. This is indeed correct. We can ignore what characters are in the URI and just stuff them in the

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On Mon, Mar 16, 2015 at 11:53:17PM +0900, Paul Vixie wrote: that is not the use case for this. the updated document makes clear that the iteration complexity in split-authority systems having a lightweight front end, is the situation where ANY is painful. Sorry? We solve implementation

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On Mon, Mar 16, 2015 at 03:16:08PM +, Ray Bellis wrote: Hypothetically, if you're using one of those funky NoSQL-style backends where RRs are looked up in a key-value store directly from a (QNAME, QTYPE) tuple I can see how supporting QTYPE == ANY would be tricky. At DNS query rates, you

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

On Mon, Mar 09, 2015 at 11:08:03AM -, 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. Hi Dan, The way I read RFC

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

except for that operated by the people with the problem - authoritative servers. Bert On Sun, Sep 21, 2014 at 01:52:22PM +0200, bert hubert wrote: Hi everybody, Your input on the initial implementation described below would be most appreciated. I see this as a dns operations issue since

[DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

incompatible with existing implementations? Is there standardization work we could align against? Thanks! Bert - Forwarded message from bert hubert bert.hub...@netherlabs.nl - Date: Sun, 21 Sep 2014 12:54:07 +0200 From: bert hubert bert.hub...@netherlabs.nl To: pdns-us

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote: - What happens / should happen if the @ IN MX 25 outpost.ds9a.nl. record is not in the zone file and the server gets an MX query for example.com? It proxies that on as an MX query for www.powerdns.com and puts back the answer. So

Re: [DNSOP] some implementation notes: binding to all IP addresses

On Tue, Oct 09, 2012 at 08:57:59AM +1100, Mark Andrews wrote: I did not know about __APPLE_USE_RFC_3542, which I've just added to my tree. It tells the compiler which version of the advanced API to use as of Lion from memory. You also have similar magic on Linux as the advanced socket API

[DNSOP] some implementation notes: binding to all IP addresses

Hi, This message is slightly offtopic, but this is the best list for reaching all DNS implementors I think. And I need your help! After ten years of nagging, PowerDNS Authoritative Server implemented 'automatic binding to ALL IPv4 and IPv6 addresses'. We do so using the

Re: [DNSOP] draft-dickinson-dnsop-nameserver-control-00

On Thu, Nov 27, 2008 at 11:01:13AM -0800, TS Glassey wrote: Yeah and like the other DNSSEC I-D's I dfound numerous things in it that would violate the controls put in place by US Patent 6,370,629 of which I am one of the two owners and controlling parties to that IP. Please start litigating.

Re: [DNSOP] I think we may have a solution - DNSCurve

On Mon, Sep 01, 2008 at 04:49:12PM -0400, Paul Wouters wrote: On Sun, 31 Aug 2008, David Conrad wrote: 5. I suspect having encryption will make getting export licenses more complicated. 6. Ellipctic Curve is patent encumbered Perhaps http://cr.yp.to/ecdh/patents.html can shed some

Re: [DNSOP] I think we may have a solution - DNSCurve

On Sun, Aug 31, 2008 at 01:21:31PM -0700, David Conrad wrote: are easier now then they were when I had a couple of lawyers look at it for DNSSEC (which doesn't have encryption)) and it may or may not Technically, this may be true - but I got into trouble over an AES-based random generator,

Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

On Tue, Aug 19, 2008 at 08:55:31AM -0400, Andrew Sullivan wrote: Now, maybe that doesn't matter for many of these cases. It is entirely possible that DNSSEC deployment for most zones is just not worth it. If that's true, however, why are we so worried about poison attacks? Because quite a

Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

On Tue, Aug 19, 2008 at 12:07:04PM -0400, Paul Wouters wrote: Because this is only true for the authorative part of DNSSEC. Since Dan showed you can cache poison any non-DNSSEC resolver for ANY domain, not just the domains you are not protecting, you basically have no choice but to mitigate

Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

On Tue, Aug 19, 2008 at 01:13:44PM -0400, Paul Wouters wrote: On Tue, 19 Aug 2008, bert hubert wrote: In fact, I'm so far not having luck getting around even my 3-year old primitive anti-spoofing behaviour. Funny, that's not what Dan's talk said. PowerDNS specifically was trivial to spoof

[DNSOP] DNS over TCP *currently* does not scale

On Sun, Aug 17, 2008 at 11:42:39PM -0400, Dean Anderson wrote: TCP isn't susceptible to this kind of attack at all. TCP spoofing is While this is true, it turns out the current crop of authoritative nameservers, including mine, is not up to serving thousands of requests/second over TCP. Or at

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

On Mon, Aug 18, 2008 at 05:27:24PM +, Paul Vixie wrote: TCP/53 a redheaded stepchild and its uses are all dangerous or unscalable. (that initiators do the close, and that responders have a minimum 2-minute timeout, says that any conformant implementation can be slapped down hard with a

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

On Mon, Aug 18, 2008 at 07:20:16PM +, Paul Vixie wrote: We've just had it easy over the past years, and it shows. it *can't* scale. laws of physics. 'When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

On Mon, Aug 18, 2008 at 01:45:43PM -0400, Brian Dickson wrote: The problem, I think, is TCP itself, not TCP support within implementations. E.g. resource limits per IP address (16 bits of port number) don't scale to current-size Internet scale. It is possible to host 10 connections on 1

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

On Mon, Aug 18, 2008 at 07:49:20PM +, Paul Vixie wrote: so what does microsoft exchange do when it tries to talk to a tinydns service like everydns.net who doesn't implement TCP/53 at all? It doesn't need to - it speaks to resolvers. what would it do if it had a TCP-forbidding

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

On Mon, Aug 18, 2008 at 06:11:14PM -0400, Paul Wouters wrote: It is possible to host 10 connections on 1 IP address and 1 port, and this happens in practice. Think, again, of webservers, which all have to listen on port 80, yet support lots of clients simultaneously. Bad example. One of

Re: [DNSOP] Public Suffix List

On Mon, Jun 09, 2008 at 02:24:30PM +0200, Antoin Verschuren wrote: You can't hijack something that does not exist though, which is what I think is the problem here. Agree, but when this global list of local DNS policy would exist and used, which would be authoritative, the list or the

Re: [DNSOP] New Draft Charter

On Tue, Mar 25, 2008 at 05:33:20PM -0400, Dean Anderson wrote: Are you using TCP DNS? Most people don't use TCP DNS. That is changing, though. I guess I don't recall who your work for, or what kind of Fwiw, I tried running TCP only some weeks ago, but you don't get far that way if you actually

Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]

On Wed, Nov 28, 2007 at 10:55:44AM +0100, Peter Koch wrote: On Tue, Nov 27, 2007 at 02:35:29PM -0800, John Crain wrote: Currently about 60% New IP to 40% old IP... and rising slowly So clearly a lot of folks still need to up date their hints files :( part of that traffic will be due

Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]

On Wed, Nov 28, 2007 at 04:22:41PM +, [EMAIL PROTECTED] wrote: The increase in traffic might easily be due to more favourable connectivity to 'B', which would lead many resolver implementations to shift more queries to it. Bert old B topolgy didnt change... :)

Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?

On Mon, Jun 11, 2007 at 07:03:13PM -0400, Dean Anderson wrote: I have asked the IESG and the ISOC Attorney to intervene in this matter, informally. Let me personally add that I find this a very sad moment in the already sorry history of DNS standardisation... Bert --

Re: [DNSOP] Best Practice document on local copy of the root zone?

On Sat, Feb 10, 2007 at 09:50:43PM +0100, Paul Wouters wrote: On Sat, 10 Feb 2007, Pekka Savola wrote: As Bert mentioned in the next message, the risk of outdated (and therefor out-of-sync) roots is real. I just compared the root zone as RedHat shipped it on Fri 07 Sep 2001, with the