Re: [DNSOP] Is DNSSEC a Best Current Practice?

On Thu, Mar 10, 2022 at 2:59 PM Grant Taylor wrote: > Aside: Maybe it's just me, but I feel like there is more perceived > value in clarifying existing documentation, in the hopes that others > will be more likely to adopt current best practices, than there is in > updating things. Dare I say it

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

Just a question on this: was the old/classic behavior really random/shuffled? Or was it that bind would "rotate" through iterations where the order was the same each time if you think of the rrset list as a ring, but with a different start and end point within that ring? (That's what's described he

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

ty at least. For that reason, It'd be worth experimenting with an implementation that does shuffle the results each time. On Fri, Jun 15, 2018 at 4:54 PM, Shumon Huque wrote: > On Fri, Jun 15, 2018 at 5:55 PM Colm MacCárthaigh > wrote: > >> >> Just a question on thi

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Mon, Jun 25, 2018 at 7:02 AM, Tony Finch wrote: > > Even that though requires that the authoritative server be capable of > > waiting for an asynchronously retrieved value before it can respond. > > > > For some authoritative servers that might require a substantial redesign. > > That isn't re

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Mon, Jun 25, 2018 at 8:06 AM, Ray Bellis wrote: > On 25/06/2018 16:05, Paul Wouters wrote: > > > Then you might as well use that mechanism to update A/ records and > > skip the intermediate ANAME? > > +1 > > Apex records are a provisioning problem, not a protocol one. > When we implemente

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson wrote: > Doing these big jumps is the wrong thing to do, increasing the key size > increases three things: > time to generate signatures > bits on the wire > verification time. > > I care more about verification time than

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Tue, Apr 1, 2014 at 6:39 AM, Phillip Hallam-Baker wrote: > On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver > wrote: > >> Lets assume a typical day of 1 billion external lookups for a major ISP >> centralized resolver, and that all are verified. Thats less 1 CPU core-day >> to validate every D

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Tue, Apr 1, 2014 at 3:39 PM, Mark Andrews wrote: > > As I have said many times. There is a myth that recursive servers > do not need to validate answers. Recursive servers will always > need to validate answers. Stub resolvers can't recover from recursive > servers that pass through bogus an

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Tue, Apr 1, 2014 at 5:31 PM, Mark Andrews wrote: > > This too is going too far; of course they can, they can ask another > > recursive resolver. > > Which also passes through bogus answers. I will repeat stub resolvers > can't recover from recursive servers that pass through bogus answers. >

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Tuesday, April 1, 2014, Olafur Gudmundsson wrote: > > you are assuming one validation per question ? > what if the resolver needs to to 10? that is 1.8ms, > I'm not :) as I wrote - if the resolver validates after it has recursed, only the final end of the line validation increases the overall

Re: [DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)

On Tue, Apr 1, 2014 at 7:49 PM, Evan Hunt wrote: > On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote: > > DNSSEC is a mitigation against spoofed responses, man-in-the-middle > > interception-and-rewriting and cache compromises. These threats are > > endpoint and path specific, so

Re: [DNSOP] Current DNSOP thread and why 1024 bits

On Wed, Apr 2, 2014 at 6:30 AM, Edward Lewis wrote: > I found that there are two primary reasons why 1024 bits is used in zone > signing keys. > > One - peer pressure. Most other operators start out with 1024 bits. I > know of some cases where operators wanted to choose other sizes but were > t

Re: [DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)

On Wed, Apr 2, 2014 at 2:40 PM, Mark Andrews wrote: > > I don't think this makes much sense for a coherent resolver. If I were > > writing a resolver, the behaviour would instead be; try really hard to > > find a valid response, exhaust every reasonable possibility. If it can't > > get a valid r

Re: [DNSOP] DNS over DTLS (DNSoD)

TLS seems like a poor choice for any new cryptographic transport, it is a very complicated protocol with a considerable amount of implementation complexity, computational and network costs. DTLS seems poorer still, as it is an adaptation of primitives never intended for datagram transmission. But

Re: [DNSOP] call to work on edns-client-subnet

On Tue, May 6, 2014 at 10:18 AM, Joe Abley wrote: > On the authority side, support for this option has a potential impact on > query load. On the recursive side, support for this option has a potential > impact on cache size. > Just to add some limited data; CloudFront (a large CDN) has been usi

Re: [DNSOP] call to work on edns-client-subnet

On Tue, May 6, 2014 at 6:04 PM, Jiankang Yao wrote: > Section > 3.1.1. > Responses Tailored to the Originator in the draft-iab-dns-applications-07 > has some related discussion to this topic. > > From the IAB draft, it see

Re: [DNSOP] call to work on edns-client-subnet

On Thu, May 8, 2014 at 9:15 AM, Ralf Weber wrote: > > There is madness, but the madness is in mixing authoritative and recursive > functions in one server and not in using DNS to direct traffic. That's a pretty big assumption to jump to. It's pretty unlikely that all ANAME implementors do that,

Re: [DNSOP] call to work on edns-client-subnet

On Fri, May 16, 2014 at 6:41 AM, Ted Lemon wrote: > On May 16, 2014, at 8:18 AM, Andrew Sullivan > wrote: > > But it seems to me we ought to > > be more enthusiastic than resigned in this case, even if we have to > > hold our collective nose as well. Either those who understand how the > > DNS

Re: [DNSOP] call to work on edns-client-subnet

On Fri, May 16, 2014 at 7:24 AM, Nicholas Weaver wrote: > No its not. All you have to be willing to do is release the constraint on > "all signatures offline". Doing online signatures allows all the CDN > functionality you want to be DNSSEC validated (not like DNSSEC really does > much good for

Re: [DNSOP] call to work on edns-client-subnet

On Fri, May 16, 2014 at 7:34 AM, Nicholas Weaver wrote: > > On May 16, 2014, at 7:29 AM, Colm MacCárthaigh wrote: > >> And even 4096b RSA signatures only take a handful of milliseconds to > construct on the fly, you can cache signature validity for minutes even in > the v

Re: [DNSOP] call to work on edns-client-subnet

On Fri, May 16, 2014 at 7:50 AM, Paul Vixie wrote: > > what we do have is advice: "if you're going to do this, here is a way > that works." in many cases, and DNSSEC is an example, the advice has an > additional property: "if you want a system like this, here is how > everybody else is doing it."

Re: [DNSOP] call to work on edns-client-subnet

On Fri, May 16, 2014 at 7:54 AM, Nicholas Weaver wrote: > > 16k/second is nothing, and I can generate that from a wristwatch > computer. Caching doesn't help, as the attackers can (and do) bust caches > with nonce-names and so on :/ A 16 core machine can do a million QPS > relatively easily - so

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

On Sun, Sep 21, 2014 at 11:37 AM, Paul Vixie wrote: > i'd be very interested in a standards-track (interoperable; including > DNSSEC support and AXFR/IXFR) version of this feature. my hope is that you > will remove out-of-zone capability here, that is, the target of ALIAS > should have to be auth

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

On Mon, Sep 22, 2014 at 7:06 AM, Tony Finch wrote: > The fun bit is that an auth server implementing some kind of proxying > ANAME is in a position very like Google and OpenDNS. That is, if the > target of the ANAME is a hostname provided by Akamai or CloudFlare or > whoever, and if the auth serve

Re: [DNSOP] New version of the DNS terminology draft

Awesome doc, just some small observations; TTL: It might be worth using the word 'maximum' in relation to the TTL; I think there is consensus that TTLs may be truncated. RRSet: Are the RRs in an RRSet required to have different data? For types such as A//SRV/MX this makes sense, but maybe no

Re: [DNSOP] New version of the DNS terminology draft

On Wed, Jan 21, 2015 at 7:25 AM, Paul Vixie wrote: > > RRSet: Are the RRs in an RRSet required to have different data? For > types such as A//SRV/MX this makes sense, but maybe not for TXT. I > also think views and other implementation specific features confuse > things here. A user might have

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

On Thu, Mar 12, 2015 at 4:09 PM, Mark Andrews wrote: > > In message <3d558422-d5da-4434-bded-e752ba353...@flame.org>, Michael Graff > writes: >> What problem are we specifically trying to solve here again? > > A non-problem for most of us. > >> Michael > > If one really wants to reduce the number