Re: [DNSOP] draft-tale-dnsop-edns-clientid

On 28/03/2017 16:02, Dave Lawrence wrote: > Understandable. I honestly have similar reservations. > > One thing that clouds this a little, as far as our draft is concerned, > is that the ISP's CPE already knows this information so in a sense it > isn't that a different party is being

Re: [DNSOP] BULK RR as optional feature

> -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Evan Hunt > > On Tue, Mar 28, 2017 at 10:47:02PM -0500, John R Levine wrote: > > That's exactly the problem -- a server that doesn't handle BULK will > > return the wrong answer. It might return the BULK

Re: [DNSOP] BULK RR as optional feature

> -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of John R Levine > > > But if you have a primary that supports BULK and a secondary > > that doesn't, then you have two authoritative servers for the same > > domain with the same serial number but one of is

Re: [DNSOP] BULK RR as optional feature

On Tue, Mar 28, 2017 at 10:47:02PM -0500, John R Levine wrote: > That's exactly the problem -- a server that doesn't handle BULK will > return the wrong answer. It might return the BULK record itself or > NXDOMAIN for an address that BULK would synthesize. And, if the zone is signed, it'll be

Re: [DNSOP] BULK RR as optional feature

But if you have a primary that supports BULK and a secondary that doesn't, then you have two authoritative servers for the same domain with the same serial number but one of is saying NXDOMAIN when the other one returns a positive answer. This is a significant problem, and the draft ought to

Re: [DNSOP] BULK RR as optional feature

> -Original Message- > From: Evan Hunt [mailto:e...@isc.org] > > On Wed, Mar 29, 2017 at 12:41:26AM +, Woodworth, John R wrote: > > I believe this would ultimately be less efficient than generating > > the records on the fly. > > Unquestionably. This clearly wouldn't be the preferred

[DNSOP] BULK RR Myth[1] - BULK RRs use complicated regex for their syntax

BULK actually does _not_ use regex for its syntax. It does, however, "borrow" from regex in the way it identifies backreferences. The similarities are intentional as to "feel" familiar and be simple to grasp. This familiarity is likely the cause of this misconception. Another is likely the use

Re: [DNSOP] BULK RR as optional feature

On Wed, Mar 29, 2017 at 12:41:26AM +, Woodworth, John R wrote: > I believe this would ultimately be less efficient than generating > the records on the fly. Unquestionably. This clearly wouldn't be the preferred behavior. If the slave does understand BULK records, you'd just transfer those.

Re: [DNSOP] Discussions of NSEC5

On Tue, Mar 28, 2017 at 1:28 PM, Paul Hoffman wrote: [...] > - White Lies can be done with NSEC, not just with NSEC3. RFC 7129 calls > these "minimally covering NSEC records". I would think that doing NSEC > White Lies would require less CPU than doing NSEC3 White Lies

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

On Tue, Mar 28, 2017 at 12:20 PM, Paul Vixie wrote: > > since it allocates no code point and the method requires no interop, > this draft feels a bit like resimprove, which died on the vine for no > reason i can now recall. it's harmless as an FYI, but does not belong on > the

Re: [DNSOP] BULK RR as optional feature

> -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Evan Hunt > > On Tue, Mar 28, 2017 at 06:31:56PM -, John Levine wrote: > > What if such a server receives BULK by AXFR? By IXFR? > > I agree these scenarios in particular need to be specified. > Hi Evan,

Re: [DNSOP] BULK RR as optional feature

generally, we have not worried about versioning or capability negotiation among axfr/ixfr partners. a zone administrator can simply choose primary and secondary servers on the basis of advertised capabilities, and remove any who can't conform. last time we had this discussion, it emerged that

Re: [DNSOP] BULK RR as optional feature

> -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of John Levine > > At yesterday's session, Tale confirmed that since BULK adds so much > new special purpose complexity to DNS servers, the plan is that > support for it will be optional. > > An optional RRTYPE

Re: [DNSOP] BULK RR as optional feature

Wouldn't a BULK RR ignorant DNS server just store the BULK RR as opaque data? Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Mar 28, 2017 at 2:31 PM, John Levine

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

Paul Vixie writes: > speaking of resimprove, i hope you'll include in this draft the idea of > using delegation-TTL as a delegation-recheck interval, and using an > authoritative NXDOMAIN from the delegator as proof that you need to run > an "rm -rf" in your cache. I definitely like the latter

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Peter van Dijk writes: > On 28 Mar 2017, at 16:35, Dave Lawrence wrote: > > I grant that there is reason for pause because both Nominum and > > OpenDNS have squatted code points which have duplicate functionality. > > Should this squatting perhaps be documented in the style of RFC 8093 to >

Re: [DNSOP] BULK RR as optional feature

That doesn't work -- this is intended to generate rDNS for IPv6 and other places where you can't possibly store the full expansion. It doesn't work for that particular use case, no, but there are other benefits to BULK (the draft specifically mentions "the ability to transfer BULK RR intentions

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Ray Bellis writes: > I'm somewhat philosophically opposed to anything that injects client > related information such that it's shared between different parties. Understandable. I honestly have similar reservations. One thing that clouds this a little, as far as our draft is concerned, is that

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

Earlier today Petr Špaček sent me an off-list comment that he intended to be on-list, and I want to promote it: On Tue, Mar 28, 2017 at 05:20:52PM +0200, Petr Špaček wrote: > Here I have to agree with enforcing "MUST NOT". MD5 is a risk even on > the validating side. It might provide attacker

Re: [DNSOP] BULK RR as optional feature

One possible solution would be an EDNS signal indicating whether or not the secondary server implements BULK. If not, the primary would have to expand the BULK data during transfer, same as BIND expands $GENERATE. That doesn't work -- this is intended to generate rDNS for IPv6 and other places

Re: [DNSOP] Call for Adoption: draft-crocker-dns-attrleaf

On 2/29/2016 5:32 PM, joel jaeggli wrote: On 2/29/16 3:12 PM, Warren Kumari wrote: Per [RFC2434], IANA is requested to establish a DNS Underscore Name Registry, for DNS node names that begin with the underscore character (_) and have been specified in any published RFC, or are documented

Re: [DNSOP] BULK RR as optional feature

On Tue, Mar 28, 2017 at 06:31:56PM -, John Levine wrote: > What if such a server receives BULK by AXFR? By IXFR? I agree these scenarios in particular need to be specified. One possible solution would be an EDNS signal indicating whether or not the secondary server implements BULK. If not,

[DNSOP] Updates from Monday Meeting

All We know we ran out of time, which is a regular problem for us. A combination of being too optimistic in our scheduling and too many people with interesting things to discuss. In the past we've tried to ask for multiple sessions, but with the pressure on slots we've always backed down. We

Re: [DNSOP] attrleaf

On 3/28/2017 2:37 PM, Paul Vixie wrote: if someone wants a new _ name entered into a registry, and if they plan to use it in a way that creates a sub-hierarchy, they should be advised not to follow SRV's example, and in my opinion, the example that ought to be set for them would be what SRV (and

[DNSOP] The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in state "Candidate for WG Adoption"

The DNSOP WG has placed draft-kristoff-dnsop-dns-tcp-requirements in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-kristoff-dnsop-dns-tcp-requirements/ ___ DNSOP mailing

Re: [DNSOP] draft-tale-dnsop-edns-clientid

> On Mar 28, 2017, at 12:31 PM, Peter van Dijk > wrote: > > Please note that neither draft handles the use case of also passing the port > number, which in a world of growing CGN deployment, may soon prove quite > important. Can you elaborate?

Re: [DNSOP] attrleaf

John R Levine wrote: >>> ... It's not offering advice that >>> underscore names are wonderful, it's recognizing the ones that are in >>> use now. >> >> as you wrote above, it's also saying "how to add new names". i'd like >> our advice in this regard to be considered excellent. > > It's only

Re: [DNSOP] attrleaf

Dave Crocker wrote: > On 3/28/2017 12:46 PM, Paul Vixie wrote: >> i don't think it's wise to estimate damage by observed complain level. >> if _ is now in world wide use for all kinds of stuff, you can still say >> that SRV got it wrong, and that the recommended way to do this kind of >> thing

Re: [DNSOP] attrleaf

... It's not offering advice that underscore names are wonderful, it's recognizing the ones that are in use now. as you wrote above, it's also saying "how to add new names". i'd like our advice in this regard to be considered excellent. It's only providing the mechanics to add a name to the

Re: [DNSOP] attrleaf

On 3/28/2017 12:46 PM, Paul Vixie wrote: i don't think it's wise to estimate damage by observed complain level. if _ is now in world wide use for all kinds of stuff, you can still say that SRV got it wrong, and that the recommended way to do this kind of thing is different from what SRV did. you

Re: [DNSOP] attrleaf

John Levine wrote: >> i don't think it's wise to estimate damage by observed complain level. >> if _ is now in world wide use for all kinds of stuff, you can still say >> that SRV got it wrong, and that the recommended way to do this kind of >> thing is different from what SRV did. > > I don't

Re: [DNSOP] attrleaf

>i don't think it's wise to estimate damage by observed complain level. >if _ is now in world wide use for all kinds of stuff, you can still say >that SRV got it wrong, and that the recommended way to do this kind of >thing is different from what SRV did. I don't see how this is relevant to

[DNSOP] BULK RR as optional feature

At yesterday's session, Tale confirmed that since BULK adds so much new special purpose complexity to DNS servers, the plan is that support for it will be optional. An optional RRTYPE with extra semantics introduces some new compatibility problems. What happens if a server that doesn't support

[DNSOP] Discussions of NSEC5

During the mic discussions of NSEC5 yesterday, some speakers conflated a few things. - NSEC3 with a good dictionary allows a fair amount of zone enumeration, but NSEC3 White Lies does not. Sharon did a good job of differentiating this in her slides, but people talking about the need for NSEC5

Re: [DNSOP] Perl related question on BULK RR

In article you write: >NAPTR very cunningly avoids this trap (IIRC) by constraining the rewrites >to be on a strictly monotonically reducing suffix of the input. Also, NAPTR does all of the complex stuff in the client applications. All the

[DNSOP] DS placement

Paul Vixie wrote: > i got underscores wrong in SRV. it may be that we should not follow that > track at all. > > ... this reminds me of the following related topic. had SRV done underscores correctly, then the placement of DS would have been more obvious. right now it's at the delegation

Re: [DNSOP] attrleaf

Dave Crocker wrote: > There is already massive use of underscore names. > > Deep aesthetic pain notwithstanding, there hasn't been a groundswell of > operational complaints that would be needed to reverse this many years > and such widespread use of the convention. i don't think it's wise to

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

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 offer this more broadly. here is *.vix.su, one of my vanity domains.

[DNSOP] My assessment of .homenet as described during the WG session yesterday.

Dear HOMENET and DNSOP WG(s), Wearing the INT AD hat. Firstly, thank you to the DNSOP WG for the deep review, thoughts, and considered responses to my request for review. Secondly, my apologies for not sharing my throughs before the HOMENET session. It would have been impractical to do so as

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Hello, On 28 Mar 2017, at 0:49, Dave Lawrence wrote: Speaking of Ray's draft, our proposal is able to handle his use case but unfortunately our use cases are not achievable in his. I'd welcome joining up. Please note that neither draft handles the use case of also passing the port number,

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Hello, On 28 Mar 2017, at 16:35, Dave Lawrence wrote: I grant that there is reason for pause because both Nominum and OpenDNS have squatted code points which have duplicate functionality. Should this squatting perhaps be documented in the style of RFC 8093 to avoid future surprises? Kind

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

Hi Philip, On 28 Mar 2017, at 12:37, Philip Homburg wrote: So if would be best if a validator that implements MD5 would still return NXDOMAIN is validation fails, but would keep the AD-bit clear even if validation passes for a domain signed using MD5. In the interest of nitpick

Re: [DNSOP] attrleaf

On 3/28/2017 12:03 PM, Paul Vixie wrote: if this is what we should have done, then it may be that the best thing to do at this stage is, that. as in, declare the SRV got it wrong, and note that _tcp and _udp have been camped upon by SRV, wrongly. all of the service protocol names (_telnet, etc)

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

Warren Kumari wrote: > ... I think > that the actual algorithm specified is a secondary consideration -- > first we need to agree on if the concept / idea is good for general > use. that will depend on the algorithm. for example if it's only stretchy for timeouts and servfail, but nxdomain is

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

Hello Shumon, On 28 Mar 2017, at 14:08, Shumon Huque wrote: OpenDNS also has had a similar feature (exact protocol unpublished AFAICT) for a while now (Smartcache, ~ 2009 I think). There is some background at https://www.youtube.com/watch?v=Gt9VUPDoZk0 starting at 14:33. Slides at

[DNSOP] attrleaf

i got underscores wrong in SRV. it may be that we should not follow that track at all. in C at that time, we were renaming our externally reachable library symbols to add _ on the front (#define foo _foo), so that a compilation which did not import that library (#include ) would be able to use

Re: [DNSOP] Kindly review draft-woodworth-bulk-rr-05.txt

> -Original Message- > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] > > On Wed, Feb 15, 2017 at 10:33:50AM +, Woodworth, John R > wrote a message of 121 lines which said: > > > We welcome _any_ feedback on the draft as we are hoping to have >

Re: [DNSOP] draft-tale-dnsop-edns-clientid

On 27/03/2017 17:49, Dave Lawrence wrote: > As Sara commented on Ray's draft that proposes a very similar option, > draft-bellis-dnsop-xpf, this sort of thing clearly needs a close look > at privacy, and I whole-heartedly agree. I've already been directly > poking privacy-concerned individuals

Re: [DNSOP] Perl related question on BULK RR

> -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Tony Finch > > Woodworth, John R wrote: > > > Apologies but I did not hear the full question regarding BULK RR's and > > the perl like back-references. If you could please

Re: [DNSOP] Perl related question on BULK RR

On Tue, Mar 28, 2017 at 11:19:10AM +0100, Tony Finch wrote a message of 33 lines which said: > So my question is, how does the BULK rewriting system interact with DNS > loops? Is there a CPU-eating tarpit in there? Also, I find that the Security Considerations section of

Re: [DNSOP] [Errata Verified] RFC8027 (4877)

I will be happy to take it over Olafur On Tue, Mar 28, 2017 at 12:03 PM, Stephane Bortzmeyer < bortzmeyer+i...@nic.fr> wrote: > On Sun, Mar 26, 2017 at 11:36:08AM -0700, > RFC Errata System wrote > a message of 42 lines which said: > > > The following errata

Re: [DNSOP] Kindly review draft-woodworth-bulk-rr-05.txt

On Wed, Feb 15, 2017 at 10:33:50AM +, Woodworth, John R wrote a message of 121 lines which said: > We welcome _any_ feedback on the draft as we are hoping to have it (or some > incarnation) adopted by the WG soon and look to rally more interest around it.

Re: [DNSOP] [Errata Verified] RFC8027 (4877)

On Sun, Mar 26, 2017 at 11:36:08AM -0700, RFC Errata System wrote a message of 42 lines which said: > The following errata report has been verified for RFC8027, OK, so, now, what do we do with this domain? Does anyone has a project for it or should I let it expire?

Re: [DNSOP] The DNSOP WG has placed draft-crocker-dns-attrleaf in state "Candidate for WG Adoption"

So, now that this draft is re-activated, I'm perusing old postings ... On 12/11/2015 12:46 PM, Bob Harold wrote: _adsp. has trailing dot, none of the others do. The current model is to ignore 'subordinate' underscore names, such as _adsp and treat them as out of scope. pgpkeys missing

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

On 28.3.2017 17:47, Paul Wouters wrote: >> So again, MUST NOT is the right choice. I'm going to write tests for >> Knot Resolver to ensure we never set AD bit for zones signed using MD5. >> Right now. > > If you want to accomplish this, why not actually follow the MUST NOT and > remove MD5

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

> So again, MUST NOT is the right choice. I'm going to write tests for > Knot Resolver to ensure we never set AD bit for zones signed using MD5. > Right now. If you want to accomplish this, why not actually follow the MUST NOT and remove MD5 support so it is treated as unsupported algorithm

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

On 28.3.2017 17:05, Evan Hunt wrote: > On Tue, Mar 28, 2017 at 03:36:40PM +0100, Tony Finch wrote: >> Chris Thompson just mentioned to me another reason for dropping support >> for RSAMD5: it uses a different DNSKEY tag calculation, which implies that >> dropping support should simplify validators

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

On Tue, Mar 28, 2017 at 6:20 AM, Pieter Lexis wrote: > On Mon, 27 Mar 2017 18:19:09 -0400 > Jared Mauch wrote: > >> I will note there are other implementations out there as well, such as in >> unbound. serve-expired configuration directive is

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

> On 28 Mar 2017, at 16:05, Evan Hunt wrote: > > My problem is with elevating "pointless" to the force of a "MUST NOT". I > think it should be reduced in force to "OPTIONAL", "NOT RECOMMENDED", or > even "SHOULD NOT". Kill it on the supply side. A "MUST NOT" should kill it on

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

On Tue, Mar 28, 2017 at 03:36:40PM +0100, Tony Finch wrote: > Chris Thompson just mentioned to me another reason for dropping support > for RSAMD5: it uses a different DNSKEY tag calculation, which implies that > dropping support should simplify validators more than dropping other > algorithms.

[DNSOP] I-D Action: draft-ietf-dnsop-dns-wireformat-http-01.txt

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 of the IETF. Title : DNS wire-format over HTTP Authors : Linjian Song Paul Vixie

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

On Thu, Mar 16, 2017 at 12:11 AM, tjw ietf wrote: > During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were > raised by the working group that needed to be addressed. The Authors > addressed the issues, but the changes are enough that there should be a >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-05.txt

On Mon, Mar 13, 2017 at 08:59:32AM -0700, internet-dra...@ietf.org wrote a message of 45 lines which said: > Title : DNS Terminology > Authors : Paul Hoffman > Andrew Sullivan >

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

Pieter Lexis writes: > I feel that the authors should attempt to describe the goal of the > algorithm and suggest possible limits and describe pitfalls rather > than describing the exact algorithm to use. I confess I'm a bit flummoxed by this comment, as I believe the document already does

Re: [DNSOP] draft-tale-dnsop-edns-clientid

Olafur Gudmundsson writes: > Strictly speaking the draft was never formally submitted via IANA. This is part of the problem with documentation. At least one natural entry point for the process, the IANA assignments page, doesn't indicate how to initiate expert review.

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

On 27 Mar 2017, at 21:41, Evan Hunt wrote: On Mon, Mar 27, 2017 at 12:45:04PM -0700, Paul Vixie wrote: also, a validator that outputs "secure" based on MD5 inputs is making a promise it can't keep. MD5 is known to be breakable Please: let's be careful with our wording here. There are

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

On Mon, Mar 27, 2017 at 5:19 PM, Jared Mauch wrote: > IOn Mar 27, 2017, at 5:59 PM, P Vix wrote: > > > > I agree to review and comment. Note that I am provisionally negative to > the idea itself, and my review may reflect that. Vixie > > > I will note

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

On Tue, Mar 28, 2017 at 4:41 AM, Evan Hunt wrote: > We can and should kill MD5 key generation and signing (and I'll add this to > the ticket about updating defaults in BIND) but I'm uncomfortable killing > MD5 validation until I'm sure there aren't any legacy keys floating around. Short history

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

On Mon, 27 Mar 2017 18:19:09 -0400 Jared Mauch wrote: > I will note there are other implementations out there as well, such as in > unbound. serve-expired configuration directive is available there as well. I feel that the authors should attempt to describe the goal of

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

In your letter dated Tue, 28 Mar 2017 11:01:01 +0100 you wrote: >Evan Hunt wrote: >> >> MD5 is known to be breakable, but it's not *as* breakable that hasn't been >> signed, or a resolver that hasn't turned on validation. > >It features Postscript, PDF/JPEG, and GIF MD5 quines

Re: [DNSOP] Perl related question on BULK RR

Woodworth, John R wrote: > Apologies but I did not hear the full question regarding BULK RR's and > the perl like back-references. If you could please repeat the question > we would be happy to comment. I didn't ask the question, but based on a quick look at the

Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)

Evan Hunt wrote: > > MD5 is known to be breakable, but it's not *as* breakable that hasn't been > signed, or a resolver that hasn't turned on validation. If you haven't seen PoC||GTFO 0x14, run over to https://www.alchemistowl.org/pocorgtfo/ and have a read. It features