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 t

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] 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 worthwhile

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 . > b

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 once

[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&feature=youtu.be&t=1h20m4s

[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 docume

[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 Matthew,

[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 1000-2

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). Wel

[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. (https:

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 I

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 anyth

[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 http://powerdns.org/hello-

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 mistak

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 9.

[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 content

[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 case

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 after

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] 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 accide

[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 update

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

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 ar

[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 with

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 re

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 > mu

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 > mu

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 i

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 somet

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 - thos

[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, softw

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 > wrote: > Bert Huber wrote: > > Also, should we work with companies attempting to hinder progress by > > clinging to patents which are no longer enforceable? >

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) *perm

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 d

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] 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 a

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 ecosyst

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 w

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] 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 A

Re: [DNSOP] I-D ACTION:draft-regnauld-ns-communication-00.txt

On Wed, Dec 20, 2006 at 10:05:50AM +0100, Stephane Bortzmeyer wrote: > I would like to know if people here believe that this work is on-topic > for the WG. It does not change the protocol (so it does not seem > adapted to DNS Extensions) but it is not really "DNS operations". I'm very interested i

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

On Fri, Feb 09, 2007 at 03:20:59PM +0100, Stephane Bortzmeyer wrote: > I was surprised that there is apparently no formal document, either > RFC or else, on this subject "Local copy of the root zone considered > harmful | good". Did I miss something? Depending on the ratio of bandwidth available

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, > wit

Re: [DNSOP] what's the right thing to do upon receiving something like this?

On Fri, Feb 16, 2007 at 07:18:35PM +, Paul Vixie wrote: > there is an rfc1918 address for this nameserver. there's no way for me to > be sure that it's the same 10.20.2.102 that i would reach if i tried, yet > there's no way to be sure that it's not the same, either. granted that the > best t

Re: [DNSOP] DNS resolver loop for a ccTLD .bg

On Fri, Feb 23, 2007 at 12:35:40PM +0200, Zvezdelin Vladov wrote: > When a resolve for a ccTLD .bg, there is > a loop going on, maybe somewhere at auth01.ns.uu.net. auth01.ns.uu.net appears to be lame for .bg, and it also appears the .bg zone does not list auth01.ns.uu.net as one of its nameserv

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 -- http://www.Pow

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

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

On Wed, Nov 28, 2007 at 04:07:59PM +, [EMAIL PROTECTED] wrote: > and perhaps more interesting, the old address for "B" > showed a tapering off of traffic and then an INCREASE > last year. Old L and J got their numbers less than a > decade ago. ... so i would not go b

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 chan

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 actuall

Re: [DNSOP] Public Suffix List

On Mon, Jun 09, 2008 at 02:02:05PM +0200, Antoin Verschuren wrote: (...) > I'm very afraid that Mozilla is trying to hijack the authority model here. You can't hijack something that does not exist though, which is what I think is the problem here. Bert -- http://www.PowerDNS.com O

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

Re: [DNSOP] Public Suffix List

On Mon, Jun 09, 2008 at 08:33:30AM -0400, Edward Lewis wrote: > If the browsers do implement a check based on TLD name, I bet they > are also gullible enough to implement RFC 3514. Browsers already implement a lot of 'supra-dns' knowledge. Try visiting a known malware or phishing site these days

[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 l

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

On Mon, Aug 18, 2008 at 04:34:30PM +, Paul Vixie wrote: > and let's also make explicit that TCP is not to be used unless UDP returns > TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA. This means disabling one of the more widely used MTAs. TCP is a first class DNS citizen

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 someth

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

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-fo

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.

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

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

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

On Tue, Aug 19, 2008 at 10:09:16AM -0700, David Conrad wrote: > On Aug 19, 2008, at 10:00 AM, bert hubert wrote: > >In fact, I'm so far not having luck getting around even my 3-year old > >primitive anti-spoofing behaviour. > > Have you tried dsniff anywhere on the path

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] 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 s

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 litigatin

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

On Thu, Nov 27, 2008 at 12:26:39PM -0800, TS Glassey wrote: > >Please start litigating. I've looked at this patent and the other one you > >mentioned in the context of DNSSEC, and based on earlier discussions with > >a > >patent attorney, your claims don't look like they would stand up at least >

Re: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for IPv6...

On Tue, Sep 1, 2009 at 10:35 PM, Edward Lewis wrote: > At 4:05 +0900 9/2/09, fujiw...@jprs.co.jp wrote: > >> Performance problem will be solved by better code and new hardware. >> >> In my opinion, "Dynamically Generate PTR When Queried" works well. > > I have to ask based on the experience I had w

Re: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for IPv6...

On Wed, Sep 2, 2009 at 3:03 PM, Edward Lewis wrote: >> It works very well. One large country's incumbent telco has all of its >> subscribers behind a scripted powerdns server synthesising PTRs, and >> with exception of the large hardware cost savings (these were gigabyte >> size zones), nobody noti

[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 setsockopt/sendmsg/recvms

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

[DNSOP] port 0 requests leading to errors

Hi everybody, This is mostly a note to implementors, but it may also be helpful to operators. Periodically, PowerDNS users would tell us about odd errors in their logs about 'Invalid arguments' from sendmsg or sendto. We spent a lot of time investigating these messages, as they usually point to s

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

essly incompatible with existing implementations? Is there standardization work we could align against?" Thanks! Bert - Forwarded message from bert hubert - Date: Sun, 21 Sep 2014 12:54:07 +0200 From: bert hubert To: pdns-us...@mailman.powerdns.com Subject: [Pdns-users] P

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. S

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

On Mon, Sep 22, 2014 at 01:37:03PM -0400, Olafur Gudmundsson wrote: > I’m getting confused about what the exact semantics of the proposed > mechanisms are. We're here to figure those out. Thanks for your input Olafur, appreciated! > > Q1: The intent is that ALIAS/ANAME/etc are a fallback rewr

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

astructure 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

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 RF

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

On Mon, Mar 09, 2015 at 04:18:12PM +0100, bert hubert wrote: > 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 que

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 hards

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, yo

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