Re: [DNSOP] Any suggestion on what I'm doing that is stupid here on NSEC3?

___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Shumon Huque University of Pennsylvania. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: Comments on draft-ietf-dnsop-qname-minimisation

On Mon, Dec 29, 2014 at 5:22 PM, Brian Dickson brian.peter.dick...@gmail.com wrote: - Another thing to possibly call out is the behavior of some name servers when the QNAME is an Empty Non-Terminal, e.g. a non-zone-cut with a child, but no RRs at the owner name. I seem to recall something

Re: [DNSOP] Fwd: Comments on draft-ietf-dnsop-qname-minimisation

to the resolvers. If minimisation is too long, you can write it m12n. I generally dislike these kinds of contractions, but I assume you meant m10n. There are 10 letters between m and n. (contrast i18n and l10n). Shumon Huque ___ DNSOP mailing list

Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)

Paul Vixie's recent suggestion of adding an or A record set in the additional section for a corresponding A or query, I just learned today that Unbound already does this. Not sure if there are any DNS client APIs that can successfully make use of this info yet. Shumon Huque

Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)

On Mon, Mar 9, 2015 at 2:45 PM, Robert Edmonds edmo...@mycre.ws wrote: Shumon Huque wrote: PS. regarding Paul Vixie's recent suggestion of adding an or A record set in the additional section for a corresponding A or query, I just learned today that Unbound already does

Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)

On Mon, Mar 9, 2015 at 2:55 PM, Shumon Huque shu...@gmail.com wrote: On Mon, Mar 9, 2015 at 2:45 PM, Robert Edmonds edmo...@mycre.ws wrote: Shumon Huque wrote: PS. regarding Paul Vixie's recent suggestion of adding an or A record set in the additional section for a corresponding

Re: [DNSOP] comments on dnsop-qname-minimisation-02

On Wed, Mar 11, 2015 at 10:43 AM, Bob Harold rharo...@umich.edu wrote: On Wed, Mar 11, 2015 at 12:35 AM, Shumon Huque shu...@gmail.com wrote: ... One thing this document doesn't make clear is that the algorithm being presented not only minimizes the query name, but also hides the query

Re: [DNSOP] Fwd: New Version Notification for draft-hoffman-dns-terminology-00.txt

, like Absolute, or All or All-Data which might more correctly differentiate it from Incremental. Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] comments on DNS terminology draft

apex. Why is it only the SOA and NS RRsets? I would suggest defining it in terms of the domain name. Isn't this what the original RFCs defined as the 'top node' (and not specific types of data sets that exist at the top node)? Shumon Huque ___ DNSOP

Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt

to do client PTR checks even for v6, but most IPv6 clients don't deliver to mail servers directly (they usually talk to a submission server, where user authentication is the access control mechanism used, rather than PTR checks). Shumon Huque ___ DNSOP

Re: [DNSOP] Some comments on draft-hoffman-dns-terminology

On Thu, Apr 2, 2015 at 2:50 PM, Dave Lawrence t...@dd.org wrote: Paul Hoffman: I added the synonym for slave. How do people feel about primary and master? Personally I'm not fond of the master/slave language and avoid the terms. I recognize their historic computer use and don't feel the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-00.txt

On Tue, Apr 14, 2015 at 8:28 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNS Terminology

Re: [DNSOP] Terminology: primary, secondary, master, slave

Secondary server (synonym: Slave server) Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terminology: forwarding and forwarder

resolver (setting aside chains of forwarders for the moment). It seems to me that the thing that is forwarding queries is the thing that needs a new definitional term. But maybe for some, that is a DNS proxy? Shumon Huque ___ DNSOP mailing list DNSOP

Re: [DNSOP] comments on DNS terminology draft

On Wed, Apr 1, 2015 at 4:37 PM, John Levine jo...@taugh.com wrote: Good point, I was only thinking of recursive answers, and I don't think I see SOAs there all the time. We can add that NODATA responses for authoritative responses include the SOA. A very short survey reveals that unbound and

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

On Tue, Jul 14, 2015 at 1:00 PM, 神明達哉 jin...@wide.ad.jp wrote: At Mon, 13 Jul 2015 22:01:29 -0400, Shumon Huque shu...@gmail.com wrote: Regarding Section 5 (possible side effect on root servers), I wonder about the implication of qname-minimization (which I expect will be deployed much

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

On Fri, Jul 10, 2015 at 2:53 PM, 神明達哉 jin...@wide.ad.jp wrote: On Tue, Jul 7, 2015 at 2:20 AM, fujiw...@jprs.co.jp wrote: [...] In Introduction it states: While negative (non-existence) information of DNS caching mechanism has been known as DNS negative cache [RFC2308], it requires

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

On Mon, Oct 26, 2015 at 10:03 PM, Paul Vixie wrote: > On Monday, October 26, 2015 10:15:37 AM Ray Bellis wrote: > > On 26/10/2015 09:52, I wrote: > > > That's clear - what isn't perhaps, is what the RCODE should be, given > > > that this text is in a section with "Name Error"

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

On Mon, Oct 26, 2015 at 11:59 AM, Ray Bellis wrote: > > > On 26/10/2015 15:32, Evan Hunt wrote: > > > But RFC 5155 is clear on the subject; empty non-terminal nodes are > > mentioned under "no data" rather than "name error". > > Ah, thanks, that's useful to know, and further

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

edgesuite.net. A IN at zone net. >>[Got Referral to zone: edgesuite.net.] >> Query: edu-dscg.edgesuite.net. A IN at zone edgesuite.net. ERROR: NXDOMAIN: edu-dscg.edgesuite.net. not found www.upenn.edu. 300 IN CNAME www.upenn.edu-dscg.edgesuite.net. Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

he queried name? I understand the stated rationale for including NS RRsets. On the other hand this makes it less likely that the TLS chain extension would use this message format (because of size considerations) rather than its current format of a sequence of RRsets (a discussion that is happening around that draft). -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-ordered-answers-00.txt

Deccio, has uncovered a case where a certain resolver implementation fails to authenticate negative responses when NSEC/NSEC3 signatures appear before the data records in the authority section of responses from an upstream forwarder. I hope he'll elaborate on more specific details. (Not implying

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

On Wed, Dec 16, 2015 at 10:50 PM, Paul Vixie wrote: > On Wednesday, December 16, 2015 09:08:03 PM Robert Edmonds wrote: > > > Shane Kerr wrote: > > > > I have updated the DNS over HTTP review document that I sent some days > > > > ago. Thanks to Jinmei for reading it. > > > > > >

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dnsop-nxdomain-cut

On Sun, Dec 13, 2015 at 11:12 PM, Shumon Huque <shu...@gmail.com> wrote: > On Sun, Dec 13, 2015 at 4:55 PM, Stephane Bortzmeyer <bortzme...@nic.fr> > wrote: > >> On Sat, Dec 05, 2015 at 05:07:13PM -0500, >> Tim Wicinski <tjw.i...@gmail.com> wro

Re: [DNSOP] Refusing NS queries, was Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

solvers normally obtain NS records not by explicit queries, but indirectly as part of data included in referral responses. Even with DNSSEC, I think a validating resolver could function properly without ever needing to issue explicit NS queries (with the exception of priming queries which are directed a

Re: [DNSOP] comments on draft-bortzmeyer-dnsop-nxdomain-cut-00

an just note this once and keep using QNAME in other places. > > > One additional comment on 01: > > - Section 7 > >The technique described here may help against a denial-of-service >attack named "random qnames" and described in Section 3. > > I suggest "a denial-of-service attack on authoritative servers" for > the same reason as my comment on the "benefits" section of the > previous version. > Yes, this sounds appropriate. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

ort registry (with the prepended underscore) would be a > legal label to the left of that. > > That would completely get away from the need to maintain the likes of > _sip, etc in the underscore registry. Is Dave's registry proposal documented in written form anywhere? Some plan

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

ded the transport label. I am far less convinced this is needed. Client identities are not expected to be transport specific for the same application, so this introduces an unnecessary complication, and we should I think be conservative in how much application semantics we encode into domain names. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

roles for application protocol Foo" is a bit more challenging, since the client TLSA record uses a symbolic name for the application whereas the server TLSA record uses a port number. Assumptions could be made about applications using well known ports I guess, but that doesn't offer a comple

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

t, and why should authoritative servers receive those queries? But I understand the concern that there might be implementation challenges for some. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

NXDOMAIN eliciting queries from one of their large resolvers to the F.ROOT server resulting in them being response rate limited. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

remove text that 'sounds' like implementation advice. I also favor "SHOULD", but let's see where WG deliberations lead us. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

set, an NXDOMAIN from the root-servers will serve as a blanket NXDOMAIN for the entire TLD the query belonged to. The effect of this is far fewer queries to the root-servers.". Whether or not to limit this to secure responses is one of the open questions. A few people have expressed fears that

Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

I've read the draft and support its adoption. Will review, etc. On Sun, Apr 10, 2016 at 10:18 AM, Tim Wicinski wrote: > This was discussed in Buenos Aires Friday morning, but the sense we > received from the room is that the group should move forward with this > draft.

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

A and A go out back to back, put typically is put out on the wire first. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] NXDOMAIN synthesis for NSEC3 (was call for adoption for draft-fujiwara-dnsop-nsec-aggressiveuse)

tain someone has this data. Ed Lewis, would this be something > that would be possible to pull out of your survey of signed zones? > For just the TLDs, "most" is true; I have some data at: https://www.huque.com/app/dnsstat/category/tld/dnssec/ In short, 895 or 79.1% of the signed T

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

On Mon, May 16, 2016 at 5:45 PM, bert hubert wrote: > 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 >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-02.txt

> > > Title : NXDOMAIN really means there is nothing > underneath > > > > Authors : Stephane Bortzmeyer > > > > Shumon Huque > > > > Filename: draft-ietf-dnsop-nxdomain-cut-02.txt

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)

make that clearer. I would personally be okay with removing this section also. I can't recall what discussion happened that caused this scenario to be included - maybe Stephane remembers. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)

On Wed, Sep 14, 2016 at 6:05 PM, Spencer Dawkins at IETF < spencerdawkins.i...@gmail.com> wrote: > Hi, Shumon, > > On Wed, Sep 14, 2016 at 4:33 PM, Shumon Huque <shu...@gmail.com> wrote: > >> >>> ---

Re: [DNSOP] Where in a CNAME chain is the QNAME?

an owner name, i.e., the name of the node to which this > resource record pertains. > Yes, Owner name is defined in terms of a resource record, i.e. the domain name that owns a resource record. But the question section has no resource record. It has 3 components of a potential resource record. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

non-existent", but "MAY continue to answer existing positive cached entries". I think this managed to cover or at least placate all positions expressed by working group participants leading up to the last call. I'm not sure we'll get new agreement on your proposed revision. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

On Wed, Sep 28, 2016 at 12:44 PM, Ralf Weber <d...@fl1ger.de> wrote: > Moin! > > On 28 Sep 2016, at 17:21, Shumon Huque wrote: > > To be precise, I would say we are not necessarily always pruning out > entire > > zones. For a leaf zone, we are pruning al

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

y invalidate cached entries below the cut and also return NXDOMAIN for them. Your rewrite appears to remove (or at least not mention) that possibility. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

0 message thread on this very topic from earlier this year! :-) -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Where in a CNAME chain is the QNAME?

ion. > > The QNAME is a domain name, but is it an owner name? There is no owned > record data in the question section (and the entries in the question > section are not RRs). > Yes, I agree. I suggest "the QNAME is the domain name that appears in the Question section of a DNS message". -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

On Wed, Sep 28, 2016 at 2:37 PM, Matthew Pounsett <m...@conundrum.com> wrote: > > > On 28 September 2016 at 10:29, Shumon Huque <shu...@gmail.com> wrote: > >> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett <m...@conundrum.com> >> wrote: >> &

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

out entire zones. For a leaf zone, we are pruning all names within that zone below the nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes, for non-leaf zones, all zones below too are pruned. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-tale-dnsop-serve-stale

that. Vixie > > > I will note there are other implementations out there as well, such as in > unbound. serve-expired configuration directive is available there as well. > OpenDNS also has had a similar feature (exact protocol unpublished AFAICT) for a while now (S

Re: [DNSOP] draft-tale-dnsop-serve-stale

On Wed, Mar 29, 2017 at 2:10 PM, Paul Vixie <p...@redbarn.org> wrote: > > > Shumon Huque wrote: > > On Tue, Mar 28, 2017 at 12:20 PM, Paul Vixie <p...@redbarn.org > > ... > > > > speaking of resimprove, i hope you'll include in this draft

Re: [DNSOP] on zone enumeration and the futility of secrecy on authenticated denial

2017-03-28 12:41 GMT-05:00 Paul Vixie : > at DNSOP yesterday i asked that anyone who thought zone enumeration was > a risk and that any crypto change (such as NSEC5) could manage that risk > should please accept a free demonstration of passive dns. > > i realized that i could

Re: [DNSOP] Discussions of NSEC5

only white lies implementation in a production quality open-source nameserver available/known to us at the time of the measurement work. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-tale-dnsop-serve-stale

so hardening it. > Hi Paul, Perhaps you've forgotten (since you participated in the discussions), but the portion of resimprove that dealt with expunging cached data below the NXDOMAIN boundary was rescued, expanded on, and published as RFC 8020 ("NXDOMAIN: T

Re: [DNSOP] Updated NSEC5 protocol spec and paper

o think so, otherwise NSEC3 would not have been developed. I personally don't care for any zones that I run. But if we are providing a solution for folks that do care, we should have the most secure (yet practical) solution we know how to design. -- Shumon Huque __

[DNSOP] Updated NSEC5 protocol spec and paper

Hi folks, We've requested an agenda slot at the DNSOP working group meeting at IETF98 to talk about the NSEC5 protocol. Our chairs have requested that we send out a note to the group ahead of time, so here it is. This protocol has not to our knowledge been presented at dnsop before, but has been

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Mon, Jul 10, 2017 at 1:50 PM, Bob Harold <rharo...@umich.edu> wrote: > > On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <shu...@gmail.com> wrote: > >> Hi folks, >> >> We've posted a new draft on algorithm negotiation which we're hoping to >> di

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

ready has a DDoS reputation - this isn't going to make things that much worse. Also DNSSEC has already been way surpassed in this area by NTP/SNMP etc. What we should be working on is deployment of proper protocol level mitigations, like Cookies, etc. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

describing my personal plans, so don't rush to implement Ed448 on my account! :-) -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Mon, Jul 10, 2017 at 2:53 PM, Shumon Huque <shu...@gmail.com> wrote: > On Mon, Jul 10, 2017 at 1:50 PM, Bob Harold <rharo...@umich.edu> wrote: > >> >> On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <shu...@gmail.com> wrote: >> >>> Hi f

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Mon, Jul 10, 2017 at 5:00 PM, Paul Wouters <p...@nohats.ca> wrote: > On Mon, 10 Jul 2017, Shumon Huque wrote: > > We've posted a new draft on algorithm negotiation which we're hoping >> to discuss at IETF99 (and on list of course). I've discussed this >> topic wit

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Thu, Jul 20, 2017 at 9:51 AM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > On Wed, Jul 19, 2017 at 02:28:37PM +0200, > Shumon Huque <shu...@gmail.com> wrote > a message of 153 lines which said: > > > > Suppose I send the list ECDSA;RSA, and I receive

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

easier to deal with operationally. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Thu, Jul 20, 2017 at 11:48 AM, Willem Toorop <wil...@nlnetlabs.nl> wrote: > Op 20-07-17 om 10:45 schreef Shumon Huque: > > On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson > > <ola...@cloudflare.com <mailto:ola...@cloudflare.com>> wrote: > > >

Re: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

On Wed, Jul 19, 2017 at 10:49 AM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > On Tue, Jul 04, 2017 at 11:42:56AM -0400, > Shumon Huque <shu...@gmail.com> wrote > a message of 108 lines which said: > > > We've posted a new draft on algorithm negotiation whi

[DNSOP] New draft: Algorithm Negotiation in DNSSEC

the on-line Internet-Drafts directories. Title : Algorithm Negotiation in DNSSEC Authors : Shumon Huque Haya Shulman Filename: draft-huque-dnssec-alg-nego-00.txt Pages : 9 Date: 2017-07-03 Abstract

Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

in a CNAME chain as > defined in [RFC2308]. > > I'm certainly not wedded to these two names. > These two terms sound reasonable to me. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

On Thu, Aug 24, 2017 at 8:00 PM, Darcy Kevin (FCA) wrote: > Honestly, I think the part of RFC 1034 (Section 4.3.2) that says "change > QNAME to the canonical name in the CNAME RR, and go back to step 1" is just > treating the string "QNAME" as a variable in a loop. One

Re: [DNSOP] 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 5:55 PM Colm MacCárthaigh wrote: > > 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

Re: [DNSOP] 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 6:40 PM Mark Andrews wrote: > What we should be asking is why a service that needs multiple machines > isn’t using SRV. It has randomisation between servers explicitly defined > along with proportional load balancing. > That would be nice, but sadly major applications

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

esults 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 this: was the old/classic behavior really >>> random/shuffled? Or was it

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

On Mon, Jun 18, 2018 at 5:14 PM Florian Weimer wrote: > * Paul Vixie: > > > in other words we should re-order rrsets by default, so that very few > > people or agents are ever prone to think their order is stable. the spec > > says they are unordered, but human nature says, expect more of what >

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

On Mon, Jun 18, 2018 at 7:05 PM Darcy Kevin (FCA) wrote: > RFC 6724 specifically says: "Rules 9 and 10 MAY be superseded if the > implementation has other > means of sorting destination addresses. For example, if the > implementation somehow knows which destination addresses will result > in the

Re: [DNSOP] 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 1:13 PM Andrew Sullivan wrote: > On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote: > > A number of folks have been bitten by a bug in bind 9..12 where it > silently > > changes the default sorting of rrsets to always be sorted (even if the > > authoritative

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Tue, Jun 19, 2018 at 2:56 PM Wessels, Duane wrote: > > > On Jun 19, 2018, at 11:11 AM, Shumon Huque wrote: > > > > > > On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček wrote: > > > > I think we need to first answer question why existing

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček wrote: > > I think we need to first answer question why existing technologies do > not fit the purpose. > This is a reasonable question. I noticed that the draft doesn't mention SIG(0) at all. One of the main motivators of the draft is stated to be

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

On Tue, Jun 19, 2018 at 2:51 PM 神明達哉 wrote: > At Mon, 18 Jun 2018 17:51:26 -0400, > Shumon Huque wrote: > > > Client applications delegate address sorting to name resolution functions > > like getaddrinfo() - correct? > > > > Doing some quick tests of getadd

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Tue, Jun 19, 2018 at 2:56 PM Wessels, Duane wrote: > > > > * If the goal is to support secure acquisition of the zone outside the > DNS protocol, then it can't do that. But neither is ZONEMD needed for that > - we can use an out of band signature using a variety of methods. > > Yes, this is

Re: [DNSOP] NXDOMAINs as in RFC 1034

at no descendant of X exists either (they all fall in the same NSEC[3] span. To add another finer detail, an NSEC3 authenticated denial statement, proves that the "next closer name" does not exist, which in the general case, is some ancestor of the qname. That is enough to prove that th

Re: [DNSOP] NXDOMAINs as in RFC 1034

On Tue, May 29, 2018 at 1:45 AM Mukund Sivaraman wrote: > > RFC 1034 states in 3.1 "The domain system makes no distinctions between > the uses of the interior nodes and leaves, and this memo uses the term > "node" to refer to both." > Right. > Then, it states in 3.6 "A domain name identifies

[DNSOP] HTTP dns-alt-svc draft

In other threads, Erik Nygren suggested that we review the proposed DNS record for HTTP Alternative Services draft: https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02 (You might also want to read RFC7838 for background). This is an effort from people in the HTTP community.

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

On Fri, Jun 22, 2018 at 3:27 PM Warren Kumari wrote: > On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman wrote: > >> >> With additional-from-cache (default on), BIND will return address of >> target of SRV if it is already in cache. The second RTT will get >> amortized. It won't take a lot to

Re: [DNSOP] SIG(0) useful (and used?)

On Fri, Jun 22, 2018 at 12:05 PM Tom Pusateri wrote: > What’s the point of using DNS to look up a KEY RR to verify a signature if > you can’t trust the KEY? The KEY resides in the senders zone so no > relationship with a resolver will help you here. > Yeah, this is a limitation in the SIG(0)

Re: [DNSOP] HTTP dns-alt-svc draft

On Sat, Jun 23, 2018 at 12:00 AM Shumon Huque wrote: > In other threads, Erik Nygren suggested that we review the proposed > DNS record for HTTP Alternative Services draft: > > https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02 > (You might also want

Re: [DNSOP] HTTP dns-alt-svc draft

On Sat, Jun 23, 2018 at 1:12 PM Ben Schwartz wrote: > On Sat, Jun 23, 2018 at 12:01 AM Shumon Huque wrote: > >> >> It actually has similarities to SRV. But offers more capabilities >> to web applications, such as http protocol version selection, and >> has an ex

Re: [DNSOP] HTTP dns-alt-svc draft

On Sat, Jun 23, 2018 at 1:23 PM Ben Schwartz wrote: > On Sat, Jun 23, 2018 at 6:51 AM Shumon Huque wrote: > >> On Sat, Jun 23, 2018 at 12:00 AM Shumon Huque wrote: >> >>> In other threads, Erik Nygren suggested that we review the proposed >>> DNS record

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

On Sat, Jun 23, 2018 at 10:45 PM Paul Vixie wrote: > > Joe Abley wrote: > > I think a pragmatic solution needs to work in unsigned zones. > > > > ... > > can someone ask the IAB to rule on whether any new internet technology > standard should address unsigned DNS zones, or for that matter, IPv4

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Tue, Jun 19, 2018 at 7:15 PM Mukund Sivaraman wrote: > > There also seems to be a scalability problem with SIG(0) in that > generating the signature involves a public-key operation per DNS > message. > > For a zone transfer of the root zone from F, the AXFR contains 79 > messages in the TCP

Re: [DNSOP] SIG(0) useful (and used?)

On Wed, Jun 20, 2018 at 7:30 PM Joe Abley wrote: > On Jun 20, 2018, at 19:07, Warren Kumari wrote: > > ​... what I'd alway wanted[0] was to be able to setup my own recursive > name server somewhere on the Internet, and then only allow myself (and a > few of my closest friends) to be able to

Re: [DNSOP] SIG(0) useful (and used?)

On Thu, Jun 21, 2018 at 9:55 AM Warren Kumari wrote: > > I think that 95% of the issue is on the stub side. > > Paul's https://github.com/BII-Lab/DNSoverHTTP and Stubby both come fairly > close to solving this. The more I think about it, DPRIVE and DoH are > driving towards what I want. > >

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Thu, Jun 21, 2018 at 11:56 AM Wessels, Duane wrote: > > The problem I'm seeking to solve is somewhat different, and its probably > not clearly stated in the draft so I will add some text to rectify that. > > I'm not trying to solve the problem that SIG(0), SIG(AXFR), or TLS > addresses > --

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Thu, Jun 21, 2018 at 2:19 AM Petr Špaček wrote: > > HTTPS over TLS is what we did for root zone import into Knot Resolver's > cache (from version 2.3 onwards but beware, there are little bugs which > were fixed in 2.4 - to be released soon). > Out of curiosity, which HTTPS source are you

Re: [DNSOP] SIG(0) useful (and used?)

On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri wrote: > On Jun 21, 2018, at 12:19 AM, Vladimír Čunát > wrote: > > On 06/20/2018 04:59 PM, Tom Pusateri wrote: > > DNSSEC will tell you the answer you get is correct but it could be a > to > a different question or be incomplete. > > Can you

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Thu, Jul 26, 2018 at 10:53 PM Steve Crocker wrote: > Let me play Candide and stumble into this naively. If we’re imagining > very wide spread distribution of the root zone, say 100,000 or 1,000,000 > local copies distributed twice a day, I would expect the evolution of a set > of trusted

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Fri, Jul 27, 2018 at 7:28 AM Jim Reid wrote: > > > On 27 Jul 2018, at 12:17, Tony Finch wrote: > > > > Ah, the obvious solution is to deprecate zone files and just ship update > > journals instead! > > Why not go for distributed hash tables? :-) > > Says he running away to watch the

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis

On Fri, Jul 27, 2018 at 12:08 AM manu tman wrote: > On Tue, Jul 24, 2018 at 9:32 AM Tim Wicinski wrote: > >> >> We discussed this and there appears to be support to adopt this, with >> the caveat of adding more content to the section on Operational >> Considerations. >> >> >> This starts a Call

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Thu, Jul 26, 2018 at 8:38 PM Paul Hoffman wrote: > On 26 Jul 2018, at 10:25, Ondřej Surý wrote: > > >> If the ZONEMD record is signed, the only person who can mount a > >> collision attack is the zone owner themselves. If the ZONEMD record > >> is unsigned, an attacker can just remove it. > >

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Thu, Jul 26, 2018 at 11:24 PM Davey Song wrote: > The draft says zone digest is not for protecting zone transmition. IMHO, > the treat model is MITM attack by malicious editing on on-disk data (NS > and glue especially) and server the new zone to end user. DNS digest > intends to enable end

Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

On Fri, Aug 24, 2018 at 10:26 AM Paul Hoffman wrote: > On Aug 24, 2018, at 6:43 AM, Vladimír Čunát > wrote: > > > > On 08/24/2018 02:01 AM, Paul Hoffman wrote: > >> Thoughts? > > > > Well, if the OS resolver is validating, it will SERVFAIL with such a > > query. > > The protocol requires

Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02

ecords for signed zones may live in unsigned zones and thus may not be validatable at all. See glue for .COM, .NET, .ORG etc for prominent examples. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec

be solved. Lastly, I attended a meeting of several DNS companies on Thursday, and the discussion on this topic that occured clearly indicated to me that there is interest. -- Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

  1   2   3   >