Re: [DNSOP] [Ext] Re: New draft for consideration:

[Joel Jaeggli]

> On Mar 24, 2019, at 08:59, Matthew Pounsett  wrote:
> 
> 
> 
>> On Sun, 24 Mar 2019 at 11:46, Paul Hoffman  wrote:
>> 
>> > I'm also not too hot for conflating "user consciously changes
>> > /etc/resolv.conf or equivalent" with "application makes the choice for the
>> > user". 
>> 
>> The split here is more "someone changes from traditional without the user 
>> knowing, when the user cares". If you have a better way to express that, 
>> that would be great.
>> 
>> > Perhaps we should talk about 'Per-application stubs'? Because this is the
>> > nub. 
>> 
>> Maybe, but I'm hesitant to make the break that way because some 
>> applications' stubs use the traditional resolver, others don't. I would be 
>> hesitant to conflate those two.
> 
> I don't think the current wording for DaO expresses the same point that 
> you've made here.  In particular, mentioning that DaO might refer to a user 
> modifying /etc/resolv.conf is inconsistent with the intent that DaO is 
> sending queries somewhere other than where the traditional configuration 
> says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the 
> traditional place to configure that.  Whatever that file says, I think any 
> resolver that is consulting that file to find its upstreams is doing DaT.

I think we’re at the point where using acronyms is is obscuring the detail of 
what is being described. If and acronym describes a protocol or an 
architectural feature that is unambiguous, great. 
> 
> How about:
>DaO: DNS resolution between a stub resolver and a recursive resolver that
>differs from the recursive resolver configured in the traditional
>location(s) for a system. 

This describes a multitude of systems of varying implementation. It would seem 
for example to include bonjour, a tor client, some vpns and many operating 
system container environments.

> DaO can be configured by a user changing where a
>stub resolver gets its list of recursive servers, or an application running
>RDoT or DoH to a resolver that is not the same as the resolver configured
>in the traditional location for the operating system.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Any website publishers who use CDNs on the list?

[Joel Jaeggli]

> On Nov 2, 2018, at 17:57, Dan York  wrote:
> 
> Are there any other publishers of websites on this list who use CDNs in front 
> of their sites - and who are interested in the whole “CNAME at apex” issue?
> 
> Given the ANAME discussions and other continuing “CNAME at apex” discussions, 
> I started putting together a short draft clearly stating the problem 
> statement of why we who publish websites want something like CNAME at apex 
> (and why we aren’t happy being locked into proprietary solutions).  
> 
> The issue has been stated multiple times in different email threads 
> (including by Paul Vixie just yesterday) … but I thought it would be useful / 
> helpful to formally write it down in a draft during these discussions.

$employer hosts apex domains on an anycast service. Like all of the 
work-arounds it is a bodge, albeit one that is not explicitly incompatible with 
existing DNS practice. ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[joel jaeggli]

On 2/6/18 8:13 AM, Paul Hoffman wrote:
> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
>
>> On 6.2.2018 13:22, Tony Finch wrote:
>>> A. Schulze  wrote:

 Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
 I also prefer that longer variant.
>>>
>>> Yes, more friendly for web searches if someone is wondering about weird
>>> queries.
>>
>> Bonus points if we can get a number reserved by RFC editor, it would
>> allow us to use name like
>> test-rfc-is-ta-
>> test-rfc-not-ta-
>>
>> That would be super awesome.
>
> ...and super-unlikely, given the history of the RFC Series.
>
>> Is something like RFC number pre-allocation possible?
Not really, nor is specifying them. Allocation is the domain of the RFC
editor and occurs once they enter the editor queue. until then they're
just internet drafts.
 
Naming something properly can with specific instructions be done at the
time of editing. as for example is done with IANA instructions,
references and so on... That's pretty much the opposite of early allocation.
> Sometimes (rarely), after Working Group Last Call. That's why I
> suggested "kskroll-sentinel" since those words are in the WG draft
> name, and will probably appear in the IETF Datatracker forever.
>
> --Paul Hoffman
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] adoption mechanics and disclaimers wrt dns-rpz

[joel jaeggli]

On 3/20/17 8:15 AM, Warren Kumari wrote:
> On Mon, Mar 20, 2017 at 12:55 AM, Paul Vixie  wrote:
>> on sunday march 12, chinese.apri...@gmail.com wrote as follows:
>>
>>> I'd be happy to see the document proceed under two conditions:  1) it
>>> becomes a WG document, subject to IETF change control, and 2) that the
>>> disclaimer requested back on 20170103 be added to the document. To refresh
>>> the collective mind, here is the missing text:
>>>
>>> applicability statement.
>>>
>>> This draft is documents a process and method for intercepting DNS queries
>>> and fabricating responses to redirect the querier into a walled garden or
>>> enclave that is NOT part of the open Internet. Adoption and acceptance of
>>> this draft is an acknowledgement that the IETF, the IAB and ISOC reject the
>>> principles espoused at https://open-stand.org/about-us/principles/, in
>>> particular article 3.  Collective Empowerment insofar as the evolution of
>>> the DNS is concerned.
>> i was not subscribed at the time, so i'm working from the archives. the above
>> quoted text is wrongheaded and its proposals unacceptable in several ways.
>>
>> first, the document has been adopted, but is not subject to ietf change
>> control.
>
> Authors (and DNSOP),
>
> It appears that this may have been a process violation here - RFC5378
> Section 3.3. Right to Produce Derivative Works seems to say that the
> IETF needs change control before a WG can formally adopt a document. I
> believe that we missed the fact that this included "non-standard"
> copyright boilerplate.
>
> I / we are still investigating, and would appreciate it if the WG
> gives us some time to figure this out.
Hi,

It appears to be the case that the author's statement above necessarily
precludes adoption as a working group document. It is not uncommon for
documents to have terms applied to them  that are incompatible with
working group adoption. Those are sometimes altered on adoption,
processed as individual submissions, or through another stream (external
standards require special handling for example, rfc 5830). Applying the
tlp 5  section 6c limitations is obviously at the discretion of the
contributors and may be changed at any time.

thanks
joel
> W
>
>
>> rather, the authors will attempt to modify the text to suit the
>> consensus position of the WG, and at publication time, rights to create
>> derivative works will be released to the IETF. so, the WG has domain over the
>> meaning of the final document and the content of future documents, but not
>> over the content of the final document. the authors want to work with the
>> community to ensure that a consensus document is published, but we do not 
>> want
>> to open the door to wrongheaded and unacceptable wordings typified by the
>> above.
>>
>> second, your disclaimer won't be added, and if the consensus of the WG is 
>> that
>> it must be added, then the standardization activity of dns-rpz will fail. you
>> are free to pitch your ideas, and the authors are free to try to accommodate
>> those ideas, but the final arbiter of whether accommodation is necessary or
>> has been accomplished is WG consensus, not the authors, and not any WG 
>> member.
>>
>> third, ignoring completely the words and the wording of your proposed
>> applicability statement, and focusing purely on the ideas it contains, let's
>> dispense with the nonsequiturs and canards as follows:
>>
>> * queries are not intercepted; they are processed differently and 
>> deliberately
>> by an RDNS server which has voluntarily subscribed to explicit policy 
>> sources.
>>
>> * response fabrication is in this case a service desired by the end-user and
>> by the RDNS operator, thus, "fabrication" has improper connotation.
>>
>> * redirection is by no means the only capability offered.
>>
>> * walled gardens or enclaves may, or may not, be part of the open internet.
>>
>> * adoption and acceptance does not acknowledge anything like what's shown.
>> rather, it's an acknowledgement that the internet now does work this way, at
>> the deliberate and voluntary behest of its RDNS operators and users, and that
>> a specification document has two boons: in the short term, giving 
>> implementors
>> and publishers a single authoritative reference for how dns-rpz works now;
>> and, giving change control of the dns-rpz protocol itself over to the IETF
>> upon this document's publication, so that the community can drive changes in
>> the protocol henceforth.
>>
>> i did not note any second or other voice in favour of this amendment, and due
>> to the vacuous pseudo-mumbo alt-jumbo of the proposal, i predict there will 
>> be
>> no other voice in favour of it.
>>
>> so, the authors propose a replacement for the current abstract:
>>
>>> This document describes a method for expressing DNS response policy
>>> inside a specially constructed DNS zone, and for recursive name
>>> servers to use such policy to return modified results to DNS clients.
>>> Such modi

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

[joel jaeggli]

On 3/10/17 5:07 AM, Warren Kumari wrote:
> Once a document becomes a WG document the authors are required to
> incorporate WG consensus.
> 
> If this does not / is not happening, the chairs have the option /
> responsibility to replace the authors with ones that do...

If there's no consensus for advancing an altered or unaltered document
then that's a problem; but not one that hasn't happened before. Consent
is pert of concensus.

> W
> 
> On Thu, Mar 9, 2017 at 3:27 PM, Paul Wouters  wrote:
>>
>>
>>> On Mar 9, 2017, at 18:54, tjw ietf  wrote:
>>
>>> We’re going to go ahead and adopt it for DNSOP, with the intention of
>>> resolving the concerns people expressed by keeping the status as
>>> informational (not standards track) and making sure the cautions and
>>> limitations the WG discussed on the use of RPZ are clear in the document.
>>
>> I don't understand how this works.
>>
>> The authors clearly stated the document will describe only what is currently 
>> implemented and they were
>> not willing to make changes. How can this ever turn into a real WG document?
>>
>> Paul
>>
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

[joel jaeggli]

On 1/6/17 9:25 AM, Mukund Sivaraman wrote:
> On Fri, Jan 06, 2017 at 01:48:59AM +, Warren Kumari wrote:
>>> (2) In a feature implemented for Unbound:
>>>
>>> - Unbound first checks cache
>>>
>>> - If a stale answer is found, its TTL is set to 0, and the cache entry
>>>   is served
>>>
>>> - If a stale answer is found, Unbound starts something similar to
>>>   prefetch/HAMMER.
>>>
 NOTE: I believe that there may be (non-Google) IP associated with
 this. A lawyer will be filing the IPR disclosure later today (time
 zone differences, etc).
>>> The two approaches are somewhat different, and so at least one of them
>>> may not be covered by this patent.
>>>
>> Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole was
>> acquired by Akamai in March 2015. I believe that David will discuss the IPR
>> with his employer.
> Please explore if this patent can be circumvented without affecting the
> goal of the draft, so that it does not apply. It would be better than
> licensing it under some legal terms.
IMHO this can be better expressed as a preference for unencumbered
technology.

the working group should not as far as I am concerned get buried in how
precisely to achieve that.
> Consequently, if the patented method is strictly adopted, please include
> an explanation of why it could not be circumvented.
>
>   Mukund
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop





signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[joel jaeggli]

On 12/29/16 1:51 PM, william manning wrote:
> "lets standardize this 'cause everyone does it"  sounds like the medical
> community should have standardized on whiskey & leaches & coat hangers
> because thats what everyone did.  if this work does proceed, i'd like to
> insist that it carry a disclaimer that it is designed specifically for
> closed networks and is not to be used in the Internet.

this sounds like an aplicability statement to be included in the
introduction.

> Indeed, thedraft is very clear this is for enclaves and not for open
> Internet use.
> 
> 
> /Wm
> 
> On Thu, Dec 29, 2016 at 10:15 AM, Vernon Schryver  > wrote:
> 
> > From: Richard Clayton  >
> 
> > Everyone involved understands that there isn't at present a turnkey
> > application that the other 5% (and indeed all the in-house corporate
> > systems) could deploy
> 
> I do not understand that.
> If the command `nslookup -q=txt -class=CHAOS version.bind` to a UNIX
> shell or Windows command prompt on your desktop says anything about
> BIND, then chances are good that you are already using one of the
> turnkey applications that in-house corporate systems and others have
> already deployed and could configure.  Even if there is no sign of
> BIND9 from that `nslookup` command, the odds are good that the recursive
> server you use has an RPZ taint or will have within months.
> 
> 
> > So although deploying RPZ does a reasonable job of papering over the
> > cracks in our response to cybercrime I think that on balance it's too
> > dangerous a tool for the IETF to wish to bless in any way -- it's poor
> > social hygiene to standardise these types of tools.
> 
> While I understand how a reasonable person can hold that position,
> I think the papered cracks are not only less bad, but the best that
> can be hoped for in the real world.
> 
> 
> > I also note from reading the draft that this blessing will freeze in
> > some rather ugly design (with the authors arguing that the installed
> > base cannot adjust to something cleaner).
> 
> That is not the intended meaning of the draft.  Instead it tried to
> acknowledge the extreme difficulty of changing an installed base.
> Words that convey that intended meaning would be appreciated.
> 
> 
> Vernon Schryverv...@rhyolite.com 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Joel Jaeggli's Yes on draft-ietf-dnsop-maintain-ds-04: (with COMMENT)

[Joel Jaeggli]

Joel Jaeggli has entered the following ballot position for
draft-ietf-dnsop-maintain-ds-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/



--
COMMENT:
--

Separate standards action was carried for the RFC 7344 Standards action.

Draft 04 moved the status change to the front-matter.

Was Discuss:

Place holder for the discussion of a standards action for 7344
discussion

I'm taking this off agendas until I get an update and the standards
action.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC operational issues long term

[joel jaeggli]

On 11/16/16 10:44 PM, Wessels, Duane wrote:
> 
>> On Nov 16, 2016, at 10:18 PM, Mikael Abrahamsson  wrote:
>>
>> As a whole, nobody seems to be interested in actually coming up with a 
>> viable solution that actually fixes peoples problems. Everybody's just 
>> punting the problem elsewhere or waving their hands and says "not our 
>> problem".
> 
> I don't think its possible to have a solution that works for devices on the 
> shelf for an arbitrarily long time.  You posed the problem as 10 years, which 
> I think is an unrealistically long time.

A decade is well within the service range of all sorts embedded systems.

> You could probably have a useful discussion about what is an appropriate 
> amount of time for something to be on the shelf and still expect it to work.  
> If there is some consensus on that then the operators of the key material can 
> design around it.  
> 
> DW
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-wallstrom-dnsop-dns-delegation-requirements-03

[joel jaeggli]

On 11/13/16 6:16 AM, Edward Lewis wrote:
> I read through the document and had a lot of comments, so maybe I need to 
> "back up a bit."
> 
> I'm conflicted over documents that define good operational practices over top 
> of a standard protocol.  There's much evidence we need this, for example, 
> just to pick one, the number of TLD zones with very large DNSKEY sets.  On 
> the other hand, confusing operations and protocol can impair efforts to 
> improve the protocol, such as how round-robin made DNSSEC more difficult in 
> needing to define a canonical order of the resource records within an RR set.
> 
> I'd support this document but it has to state up front that it has a limited 
> scope, which needs to be properly defined.

traditionally we would call that an applicability statement. I think
that's quite useful particularly if there are cases where it should not
be be employed.

> The origin of my comment is section 2.1 which says that a delegations' name 
> must be a hostname (a'la RFC 1123) and further that registered names are 
> generally good for this.  I know that there's no need for a delegation's name 
> to be "printable" in general, the only delegation I can't make work (with 
> DNSSEC) is '*'.
> 
> E.g., there's no reason I can't have "\007.mylab.mydept.myorg.example" in my 
> zone.  Of course, that would not be very easy to access via a web browser 
> location bar.
> 
> Contrary to that, I had few "problems" with section 3 because it states up 
> front "the public Internet DNS hierarchy" as the application domain.  Section 
> 2 and earlier didn't scope the work.
> 
> What I can't find is a definition for, what is called in section 8, a "fully 
> functional" delegation.  Again, that is tied to the lack of scope.
> 
> And, (as this dives deeper than I intended to mention), in section 8.2 there 
> is this:
> 
> "Any DNSKEY algorithm number used for in a zone MUST be assigned by IANA."
> 
> Does that include PRIVATEDNS (253)?  (To pick nits, it's not DNSKEY algorithm 
> number, it's the registry of DNS Security Algorithm Numbers.)  If someone 
> uses that "IANA assigned" number they won't be "fully functional" for some 
> interpretation of "fully functional."  And ... I think IANA "assigned" is the 
> wrong verbage, perhaps IANA registered.  By now I've gone far into the weeds.
> 
> I'd like to see the document state or define what kind of delegations it is 
> covering.  I think it is fine to define a kind of something more generic and 
> apply rules to that.  Much in the same way that IDNA defines rules for 
> IDNA-aware applications while not altering the basic protocol definition.
> 
> Bottom line - there ought to be a way to provide operational guidance to 
> participants on the global public Internet while allowing for continued 
> permission-less innovation.  Guidance is needed but don't give it in a way 
> that can be used to stop anyone from trying other things in their sandboxes.

sure

> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Special Use Names Summary

[joel jaeggli]

On 10/7/16 1:56 PM, Tim Wicinski wrote:
> 
> Special Use Names Summary
> 
> 
> First, thanks to all for a pretty useful discussion.  There were a few
> things uncovered which are not in either draft.  It does appear that the
> draft-tldr-sutld-ps is the very rough consensus choice as a starting
> point. Both drafts say useful things, and the chairs would very much
> like to see people keep working to get all relevant points into one. The
> scoping question of choosing between “What do we think of RFC 6761” and
> “What underlying problem do we actually have” came up quite clearly, and
> seemed like a key factor to us.

Thank you  for doing this, sieving the discussion  on the adoption was
no small effort.

> The chairs felt that a limited scope draft was possible, and what we
> were looking for. Even with a limited scope draft, we've found we can't
> ignore questions about the underlying assumptions behind 6761, both
> because they're not fully articulated and because they may not include
> several cases we care about. For example:
> - what problem do we have because we value uniqueness in domain
> names as an architectural principle, regardless of specific strings chosen?
> - what problem exists for the IETF even if we say we don’t care what
> other groups (ICANN, the Tor Project, open source creators) do?
> - what happens if we abandon this work, or deprecate RFC 6761?
> 
> There are also several items which need clarifying, which the WG
> discussion may also include and the chairs will work on with the IESG
> and the IAB as appropriate.
> 
> - Describing, as much as possible, how this work interlocks with
> ICANN’s policy authority over the DNS root zone
> - Providing guidelines for IETF WGs
> - Providing guidelines for domain name use outside of the IETF
> disposing of some distractions that keep coming up
> - Clarifying, to the degree possible, who has process authority over
> what (IESG, IAB, this WG, other IETF WGS)

We have previously sent liason statements to ICANN to make them aware of
this work. Personally I would expect that a future liaison statement on
outcomes would need to be supported by an ietf consensus call so I look
to us being able to offer guidance for such a statement.

> Thanks
> 
> Tim/Suzanne
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] drop udp to stop DDOS?

[joel jaeggli]

On 10/1/16 8:36 AM, A. Schulze wrote:
> Hello,
>
> a nsd user posted an interesting question:
> https://open.nlnetlabs.nl/pipermail/nsd-users/2016-September/002364.html
>
>> Could we eliminate the DDoS threat by just turning off UDP?
>>
>> Recursive servers I understand probably have to keep accepting them,
>> but authoritative servers are only intended for recursive servers to
>> query, so would it be safe to just drop port 53 UDP requests?
>
> are there any experiences/opinions on that?
> Andreas
Recursing resolvers expect to be able to contact an authoritative
nameserver on udp 53, so if you just drop that in a hole that is going
to be kinda of a problem because they're going to time out.

There is a bit of an art to protecting servers from packets that they
shouldn't be recieving. just because it has to listen on udp 53 does no
mean it has to be able to recieve udp traffic for all other dports.it's
own queries for example could be done with a different source ip.

Once you get beyond (dns / ntp) reflection though theres no particular
reasion why a volumetric dos attack needs to use the UDP header. For
that matter the traffic doesn't even need to splash on the target host
to be effective if the goal is bandwidth consumption.

>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Joel Jaeggli's Discuss on draft-ietf-dnsop-maintain-ds-03: (with DISCUSS)

[Joel Jaeggli]

Joel Jaeggli has entered the following ballot position for
draft-ietf-dnsop-maintain-ds-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/



--
DISCUSS:
--

Place holder for the discussion of a standards action for 7344 discussion




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Gen-art LC review: draft-ietf-dnsop-maintain-ds-03

[joel jaeggli]

Hi,

yeah I reached back out to robert on 8/17, I don't think there has been
closure yet so the scheduled iesg discussion may be premature.

joel

On 8/30/16 5:24 AM, Jari Arkko wrote:
> Robert — thanks for the review (again)! And thanks everyone for a document 
> that to me seems quite useful and necessary.
>
> I do have a similar concern as Robert did, however, in making sure that the 
> change to 7344 is properly highlighted. Joel, did you have a plan on how to 
> make that happen? I haven’t seen any IETF list traffic on the last call since 
> June…
>
> For what it is worth, I have today reviewed both draft-ietf-dnsop-maintain-ds 
> and RFC 7344, and personally find the recommendations and actions reasonable.
>
> Jari
>




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Gen-art LC review: draft-ietf-dnsop-maintain-ds-03

[joel jaeggli]

appolgies for setting this aside for a month. IETF intervened, I don't
plan to advance this until the question is addressed in any event.
On 7/8/16 1:32 PM, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-dnsop-maintain-ds-03
> Reviewer: Robert Sparks
> Review Date: 8 Jul 2016
> IETF LC End Date: 11 Jul 2016
> IESG Telechat date: Not yet scheduled for a telechat
>
> Summary: Ready, but with nits and perhaps a process problem
>
> Potential process problem:
>
> This document intends to move RFC7344 from Informational to PS in place
> (without republishing RFC7344. The intent to do so is buried at the end
> of the document (the abstract doesn't mention it). The Last Call for the
> document does not make it clear that _this_ document is elevating
> RFC7344.
> (It at least mentions it, which is good, but the writeup about the
> elevation
> can be read to say "we're considering this elevation somewhere else,
> keep it
> in mind while evaluating this document").
I don't recall the shift in status be controversial within the working
group, so perhaps I view it a logical step having developed experience
with the work as being worthwhile. That said I think there is a point to
be made here between advancing a standards track document and having a
standards track document address previously unspecified uses in an
informational document, Perhaps a third state is that the standards
track document is introducing an entirely new facility (trust anchor
setup) and dragging 7334 along with it.

I'm not sure the location of section 6.1 particularly matters wrt the
question of what to do, it's readily apparent in the front matter as a
section heading.

possibly the thing to do is hold separate last call for the standards
action I don't see this document as proposing any edits to 7334 that
would make revising it a necessity.
>
> There is no hint from the subject line that this is a call to bring
> RFC7344
> onto the standards track. Unless there is some other communication effort
> that I've missed on a quick search, I think it is very likely that most
> of the IETF community outside the dnsop working group missed this intent.
> I strongly encourge a last call focusing _specifically_ on moving RFC7344
> to the standards track without republication.
that seems like the right think to do.
>
> My personal feedback on elevating RFC7344 without republishing is that
> it's
> not the right thing to do. At the very least "Category: Informational"
> appears in the document itself, and that will not change. If the IESG
> decides to proceed with this as currently formulated, count me in the
> deep rough.
>
> Nits:
>
> In 1.2, "that decision SHOULD be fully under the child domain's
> control"...
> Why is that a 2119 SHOULD? I think this is commentary on that it would be
> a bad idea for someone else to unilaterally decide to turn of DNSSEC for
> a child domain? Why not just say that (it would be even better to expand
> on _why_ it's a bad idea. If you really think this is the right way to
> say
> what you mean, and you keep 2119, please talk about when it would be
> ok to
> not follow that SHOULD.
>
> In 1.3, consider pointing to Appendix A of RFC7344 to better define RRR.
>
> In the Security Considerations, you have "Users SHOULD" and "all options
> SHOULD be considered". These are not meaningul uses of 2119 - please use
> prose to say what you really mean. If you want to keep them, please talk
> about when it would be ok to not follow the SHOULD. I think you're trying
> to say "Completing the rollover via an unsigned state is dangerous and
> should
> only be used as a last resort" or something similarly strong.
>
> Consider pointing back to the 5 scenarios you spell out in section 1.2
> in the
> security considerations section. The asserted existance of operational
> and
> aoftware limitations that necessitate turning off DNSSEC to facilitate
> a change
> of operator is certainly a major security consideration.
>
> Consider doing more to the DNS Security Algorithms Number registry than
> the current instructions indicate. Simply adding a reference to this
> document
> to the row for number 0 does not convey that this "reserved" number is
> actually
> being _used_ in a protocol, and that when it is it's an algorithm
> number that
> is not a number for an algorithm. I don't know how to say that
> cleanly, but
> the registry should say more than simply "reserved" if this document
> is approved.
>
> Typo-nit: s/digiest/digest/
>
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC7706 (4755)

[joel jaeggli]

sure,

thanks for the review.

joel
On 7/31/16 6:15 PM, Paul Hoffman wrote:
> This is a good (if minor) errata. Please approve.
> 
> --Paul Hoffman
> 
>> On Jul 31, 2016, at 5:58 PM, RFC Errata System  
>> wrote:
>>
>> The following errata report has been submitted for RFC7706,
>> "Decreasing Access Time to Root Servers by Running One on Loopback".
>>
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=7706&eid=4755
>>
>> --
>> Type: Editorial
>> Reported by: John W. O'Brien 
>>
>> Section: 2
>>
>> Original Text
>> -
>> The system MUST be able to run an authoritative server on one of
>> the IPv4 loopback addresses (that is, an address in the range
>> 127/8 for IPv4 or ::1 in IPv6).
>>
>> Corrected Text
>> --
>> The system MUST be able to run an authoritative server on one of
>> the IP loopback addresses (that is, an address in the range
>> 127/8 for IPv4 or ::1 in IPv6).
>>
>> Notes
>> -
>>
>>
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary. 
>>
>> --
>> RFC7706 (draft-ietf-dnsop-root-loopback-05)
>> --
>> Title   : Decreasing Access Time to Root Servers by Running One 
>> on Loopback
>> Publication Date: November 2015
>> Author(s)   : W. Kumari, P. Hoffman
>> Category: INFORMATIONAL
>> Source  : Domain Name System Operations
>> Area: Operations and Management
>> Stream  : IETF
>> Verifying Party : IESG
>>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: Last Call:

[joel jaeggli]

since this is a 4 week last call I'm more than happy for it proceed
during this meeting and out the other side.

thanks
joel


 Forwarded Message 
Subject: Last Call: 
Date: Fri, 15 Jul 2016 02:50:08 -0700
From: DraftTracker Mail System 
To: iesg-secret...@ietf.org
CC: tjw.i...@gmail.com, joe...@gmail.com, Tim Wicinski 


Last Call Request has been submitted for


https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-03.txt

[joel jaeggli]

On 6/10/16 8:44 AM, Ólafur Guðmundsson wrote:
> Dear colleagues 
> 
> This version addresses all comments received during the WGLC, 
> The main changes are clarifications requested by reviewers.
> In addition some reordering was done to fit better with the model that
> operations are "Introduction Maintainance Deletion" 
> In the IANA section there is a new paragraph (section 6.1) that elevates
> RFC7344 to standards track to avoid down reference. 

lgtm, when the chairs send it to me I'll IETF LC it.

thanks
joel

> 
> Olafur 
> 
> On Fri, Jun 10, 2016 at 11:40 AM,  > 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 of
> the IETF.
> 
> Title   : Managing DS records from parent via
> CDS/CDNSKEY
> Authors : Olafur Gudmundsson
>   Paul Wouters
> Filename: draft-ietf-dnsop-maintain-ds-03.txt
> Pages   : 9
> Date: 2016-06-10
> 
> Abstract:
>RFC7344 specifies how DNS trust can be partially maintained in-band
>between parent and child.  There are two features missing in that
>specification: initial trust setup and removal of trust anchor.  This
>document addresses both these omissions.
> 
>Changing a domain's DNSSEC status can be a complicated matter
>involving multiple unrelated parties.  Some of these parties, such as
>the DNS operator, might not even be known by all the organizations
>involved.  The inability to disable DNSSEC via in-band signalling is
>seen as a problem or liability that prevents some DNSSEC adoption at
>large scale.  This document adds a method for in-band signalling of
>these DNSSEC status changes.
> 
>Initial trust is considered in general to be a hard technical
>problem, this document sets forth reasonable policies that clarify
>and simplify the initial acceptance policy.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-03
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org
> .
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: Re: *[AD] Fwd: AUTH48 [LB]: RFC 7873 NOW AVAILABLE

[joel jaeggli]

FYI

draft-ietf-dnsop-cookies

now normatively includes RFC 7120

Thanks
joel


 Forwarded Message 
Subject: Re: *[AD] Fwd: AUTH48 [LB]: RFC 7873
 NOW AVAILABLE
Date: Tue, 17 May 2016 08:25:46 -0700
From: joel jaeggli 
To: Lynne Bartholomew 
CC: RFC Editor 

On 5/16/16 5:00 PM, Lynne Bartholomew wrote:
> Dear Joel,
> 
> Forwarding this email directly to you.
> 
> Thank you.
> 
> RFC Editor/lb
> 
> Begin forwarded message:
> 
>> *From: *rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>
>> *Subject: **[AD] Re: AUTH48 [LB]: RFC 7873
>>  NOW AVAILABLE*
>> *Date: *May 16, 2016 at 3:27:43 PM PDT
>> *To: *d3e...@gmail.com <mailto:d3e...@gmail.com>, ma...@isc.org
>> <mailto:ma...@isc.org>
>> *Cc: *rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>,
>> dnsop-...@ietf.org <mailto:dnsop-...@ietf.org>, dnsop-cha...@ietf.org
>> <mailto:dnsop-cha...@ietf.org>, tjw.i...@gmail.com
>> <mailto:tjw.i...@gmail.com>
>>
>> Authors, AD*,
>>
>> *Joel, please reply regarding #1.
>>
>> 1) [AD] Per author feedback earlier in the process, RFC 7120 is now
>> cited in Section 8 and listed it as a Normative Reference.  Please let
>> us know if you approve.
>>
>> Original:
>> IANA has assigned the following DNS error code as an early
>> allocation:
>>
>> Changed to:
>> IANA has assigned the following DNS error code as an early allocation
>> per [RFC7120]:
>> ...
>> [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
>>Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120,
>>January 2014,
>><http://www.rfc-editor.org/info/rfc7120>.

this is fine I approve, I am informing the working group.

>>
>> 2) We changed instances of "HMAC-SHA256" to "HMAC-SHA-256" (and
>> "HMAC-SHA1" to "HMAC-SHA-1") to match [RFC6234], which is cited.
>> However, the document also uses "HMAC-SHA256-64", which matches the
>> IANA-registered description from RFC 6696. Please review whether the
>> current text -- with this apparent inconsistency (hyphen vs. no hyphen
>> after "SHA") -- is correct.

So I'm hardly and informed reference on these things however; SHA-1 is a
proper name whereas SHA256/SHA-256 is a concatentation of (SHA + (the
number of key bits)) .

rfc 4291 seperates them with dashes.

https://tools.ietf.org/html/rfc4231

6696s convention is

 This field indicates the integrity algorithm used
 for ERP.  Key lengths and output lengths are either indicated
 or are obvious from the cryptosuite name.

e.g.

HMAC-SHA256-64

that's fine since it's now written in stone but it's not necessary to
indicate the output length  most of the time...

If you're using the iana description then by all means proceed.



>>
>> 3) Please let us know if any changes are needed for the following
>> items, which are about terminology across the Cluster 284 of
>> documents, which includes these documents in addition to RFC-to-be 7873.
>>
>>  RFC 7828 (draft-ietf-dnsop-edns-tcp-keepalive)
>>  draft-ietf-dprive-dns-over-tls (RFC-to-be 7858) in AUTH48-DONE
>>  draft-ietf-dnsop-edns-chain-query in EDIT*R
>>  draft-ietf-dane-openpgpkey in EDIT*R
>>
>> a) The following terms were used inconsistently in this cluster of
>> documents. We have updated the document to use the forms on the right.  
>> Please let us know any objections.
>>
>> Resolver / resolver*
>> Recursive Resolver / recursive resolver*

no objection

>> * Per more common usage in recently published RFCs
>>
>> b) The following terms are used inconsistently in this cluster of
>> documents.  Please let us know which form is preferred.
>>
>> answer section / Answer Section**
>> querying / QUERYing

5.4 QUERYing for a Server Cookie

gives me pain. yes QUERY is the opcode; Querying is what is being done.

Answer Section is probably fine

I assume that probably comes from rfc 1035 (upper case answer) though
that uses it exclusively lower case (10 times)

4.1. Format

All communications inside of the domain protocol are carried in a single
format called a message.  The top level format of message is divided
into 5 sections (some of which are empty in certain cases) shown below:

+-+
|Header |
+-+
|   Question| the question for the name 
server
+-+
|Answer | RRs answering the question
+--

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

[joel jaeggli]

On 5/4/16 8:43 AM, Ted Lemon wrote:
> Jinmei-san, with all due respect, I think that you are missing the mark
> here.  The point of this document is not to make normative requirements.
>   That's why it's informational.   It's simply to enumerate the set of
> options that ISPs have.   The reason that the author, who works for an
> operator, decided to write the document was that no such document
> existed, and such a document would be useful for informational purposes.
>   It is not the purpose of the document to either recommend or deprecate
> the practice described in RFC 1912; indeed, the consensus of the working
> group seems to be that the practices in RFC 1912 regarding PTR records
> are no longer best practices.
> 
> Nevertheless, operators have to deal with support calls when there is no
> PTR mapping, and end users have to deal with the inaccessibility of
> services operated by people who still believe in and rely upon the RFC
> 1912 recommendations.   I personally think it's a terrible idea to use
> PTR records for host validation, yet I still want PTR records set up
> according to RFC 1912 because I care more about being able to access
> services that do PTR lookups than I do about purity.
> 
> Additionally, if you look at section 11 of RFC 6763, there is actually a
> strong motivation for at least having the PTR tree delegated, because it
> allows the home network to publish rendezvous records for DNS service
> discovery on the home network.   Without this capability, unicast DNSSD
> may be quite difficult to successfully deploy in the home, which would
> be a shame.   This is actually something that ought to be mentioned in
> the document.
> 
> The point is that the mere fact that you do not think this is useful
> isn't a reason not to publish it.   The working group already got
> consensus that this work was useful when we adopted it; the question now
> is, are there _mistakes_ in the document that need to be corrected prior
> to publication, or that would mean that despite the working group
> consensus to adopt the document, it is no longer a good idea to publish
> it.   I do not think the concerns you have raised are the sort of
> concerns that would motivate such a reconsideration.

process observation

It's also of course possible that the community outside the working
group partcipants will see the issue differently then does the working
group (that not what wglc is for). It is certainly possible to disagree
with the document without asserting that the contents are a mistake.

thanks
joel

> 
> On Tue, May 3, 2016 at 1:56 PM, 神明達哉  > wrote:
> 
> At Mon, 25 Apr 2016 16:50:42 -0400,
> Tim Wicinski mailto:tjw.i...@gmail.com>> wrote:
> 
> > This starts a Working Group Last Call  for draft-ietf-dnsop-isp-ip6rdns
> >
> > Current versions of the draft is available here:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/
> >
> > Please review the draft and offer relevant comments. Also, if someone
> > feels the document is *not* ready for publication, please speak out with
> > your reasons.
> 
> I've read the latest version (01) of the draft.  I don't think this
> document is ready for publication.
> 
> I think a good summary of why not is this comment by Stephane
> Bortzmeyer: "It seems this document did not take into account the
> lessons from the failure of
> draft-ietf-dnsop-reverse-mapping-considerations".
> 
> The draft as currently written looks quite awkward, especially if
> considering the role of reverse mapping that many of this wg
> participants seemingly have in their mind.  In my understanding
> everyone agrees a revers mapping can be useful for purposes like
> debugging or pure logging, but many of us doubt the use of reverse
> mapping for purposes like access controls.  And, because of the second
> point, the attempt of making a reverse-forward match is pretty
> dubious, especially if it involves technical difficulties such as
> scalability issues, since this matching is quite tightly coupled to
> the practices like PTR-(and matching with forward)-based access
> control; for the purpose of logging helpful information only
> human-readable PTR should suffice.
> 
> Yet the focus of this document is about how to ensure the
> forward-reverse match.  It may be true that this draft does not
> encourage that practice.  But if the wg is generally suspicious about
> the practice in the first place, it would look quite awkward that the
> same wg is going to publish something that describes how to do that
> practice.  One common "excuse" to resolve such conflict is to say that
> we are just describing what operators want or might do without either
> encouraging or discouraging the practice.  But, again, if the wg
> generally thinks such a practice doesn't make sense, this logic
> doesn't make

Re: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

[joel jaeggli]

On 5/6/16 12:53 PM, Adrien de Croy wrote:
> 
> Maybe you can explain why, if https is needed everywhere, that after
> significant and extended arguing, the httpwg decided to make it optional
> in http/2
> 
> I really don't see the point in making all those arguments again over
> here in dnsop, when they were done to death many times in httpwg.  Go
> take a look there.
> 
> As for Stephen Farrell's view on it, yes we know his point of view on
> the topic. I and many others disagree with his view on this.
> 
> There's also RFC 2804 which is much more sensible and less likely to pit
> engineers against governments.

rfc 2804 says nothing about extending the security envelope of
protocols. it does state that we do not consider requirements for
wiretapping as part of protocol development.


> 
> 
> -- Original Message --
> From: "Stephane Bortzmeyer" 
> To: "Adrien de Croy" 
> Cc: "Shane Kerr" ; "dnsop@ietf.org"
> 
> Sent: 7/05/2016 7:40:17 a.m.
> Subject: Re: [DNSOP] Fwd: New Version Notification for
> draft-song-dns-wireformat-http-03.txt
> 
>> On Fri, May 06, 2016 at 07:14:29PM +,
>>  Adrien de Croy  wrote
>>  a message of 72 lines which said:
>>
>>>  Putting https where it's not needed (and it's not needed everywhere)
>>
>> It is. If you don't know why, read RFC 7258 (6973 is useful, too).
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

[joel jaeggli]

On 4/24/16 3:20 PM, Suzanne Woolf wrote:
> Hi,
> 
> (no hats)
> 
> I had honestly expected the work on the homenet naming architecture to
> include a discussion of constraints on the syntax and other
> characteristics of the names to be used.

Personally I see that as part of the design anti-pattern with the dns
that got us to this point in the first place. because their aren't
suitable alternatives to name resultion there is in fact no other way
around it until we do something less shambolic, or theres an emergent
alternative that actually makes sense to the market. I don't see 7788 as
providing any normative guidance on naming, which falls short of what I
would call specification certainly were a looking for a rational for the
selection of .home it's not in that document.


> The default set for the homenet namespace in RFC 7788 strikes me as a
> risky recommendation from a purely operational perspective.  It's been
> surmised now for years that ".home" is widely used in local DNS
> configurations, based on the so-called "name collision" work
> commissioned by ICANN, and it's hard to see how collisions between
> overlapping local uses of the same names is preferable in any way to
> collisions between the global default namespace and local uses.
> 
> There's no reason to assume that homenet use of ".home" is compatible
> with pre-existing uses. Name collisions within one local scope, or
> multiple overlapping local scopes, seem to me to be dangerous in exactly
> the same ways as ambiguity between the "public namespace" and a local
> one would be.
> 
> Even a special use registry entry can't reasonably be expected to have a
> big impact on the other uses of ".home" that the name collision work
> surmised to be already occurring in the operational internet-- or the
> collisions that could occur if the homenet recommendation is widely used. 
> 
> Using ".home" for homenets is a bad idea, and would have been a bad idea
> even if there was a special use registry entry for it. 


> 
> Suzanne
> 
> 
> On Apr 23, 2016, at 10:58 PM, Ted Lemon  > wrote:
> 
>> The Special-Use Top-Level Internet Names Problem Statement draft
>> (https://tools.ietf.org/html/draft-tldr-sutld-ps-00) references the
>> ICANN document that talks about .home (I don't know the URL off the
>> top of my head).   Like Suzanne, I'm pretty embarrassed that I didn't
>> catch this.   The RFC only references ".home" once, and says nothing
>> about how it is handled, as would be needed for the RFC 6761 process,
>> and of course there's nothing about .home in the IANA considerations.
>>   I will be adding this RFC to the list of documents in the tldr
>> draft, because what happened here is definitely "a problem."
>>
>> FWIW, I presented a homenet naming architecture document in the
>> homenet working group that talks about how this actually ought to be
>> done
>> (https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00).
>>   I am fairly sure that the appearance of ".home" as a default setting
>> in the HNCP draft was an oversight on the part of the authors--the
>> working group had been using ".home" as a shorthand for "the
>> special-use top-level internet name that we'll use for name resolution
>> in home networks that don't have global names delegated to them,"
>> which as you can see is a bit of a mouthful.
>>
>> Bottom line: this is not actually the intended way things should work
>> for naming in homenets, and a lot of people missed it.   Sigh.
>>
>>
>> On Sat, Apr 23, 2016 at 9:14 PM, John Levine > > wrote:
>>
>> >sounds like there could be trouble with that
>> >
>> >https://icannwiki.com/.home
>> >
>> >based on the applicants currently investing in acquiring that TLD.
>>
>> There's a bunch of applicants for .HOME, .CORP. and .MAIL.  I gather
>> that ICANN has decided not to delegate any of them due to collisions
>> with existing use in the wild.  (For .home, there's a lot of random
>> little routers using it, unrelated to new RFC 7788 uses.)
>>
>> There was some discussion in the IETF of adding those three names to
>> the RFC 6761 registry, but it didn't go anywhere, largely (in my
>> opinion) due to lobbying by one of the .home applicants.
>>
>> R's,
>> John
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[joel jaeggli]

On 4/7/16 4:19 PM, George Michaelson wrote:
> I wouldn't normally invoke 'the nuclear option'  but the parallels
> with good science/bad politics are stark here. Norbert Weiner left the
> field and moved into biology and cybernetics because he realized his
> personal ethics were totally adrift in the sea of consequence of work
> on nuclear physics. I think Condon or somebody said after the trinity
> test, he lived on sleeping pills forever. I don't want to be in that
> space. (its in richard rhodes' book. i forget where)
> 
> Ignoring the social consequences of entirely logical technologically
> driven decisions is not just silly, its actually dangerous. This is
> what RFC6761 does. It ignores consequence in the world of names as
> social constructs.
> 
> We're not the gods of the internet. The social consequences of build
> outs has to be understood to exist. ICANN is the forum where social
> constructs meet, and discuss names. technically motivated internet
> names have a social context. It has to be discussed properly by the
> people who understand it.

Oddly enough I agree. to quote the liason statement:

...
Discussion of these requests under the process established in RFC 6761
has revealed difficulties in applying its guidelines in practice.
Under its current charter, the DNSOP working group in the IETF is
responsible to review and clarify the overlap between (among other
things) the special names registry from RFC 6761 and the public DNS
root. This could include consideration of the problem of existing name
collisions, provision of additional guidelines, or further
modification to the process in RFC 6761 to reduce the potential for
collisions in the future. Any changes are to be kept within the
constraints of RFC 2860 (or any future modification to RFC 2860).

All such discussion and any modification will be open and transparent
to participation by interested parties, in accordance with established
IETF processes. We invite participation of interested parties,
including members of the ICANN community, in this work.
...

> I know John Perry Barlow's statement of independence is very popular,
> but I live in the real world. Aspirations are not concurrent with
> reality, and I prefer desire and reality to align. I believe Barlow
> has more recently said he understands aspiration to be different to
> reality, so maybe we're all of one mind here.
> 
> The best possible alignment right now of desire and reality, is for
> ICANN to be the forum which adjudicates what labels exist or are
> special in the top levels of worldwide socially visible naming. The
> IETF should be seen to ask them, based on sound technical reasons, to
> consider names. Not telling, asking.
> 
> This is what I believe. This is what motivates me to discuss this
> problem: Lets not pretend we can drive this on technology alone. We
> can't.
> 
> -G
> 
> On Thu, Apr 7, 2016 at 4:08 PM, joel jaeggli  wrote:
>> On 4/7/16 3:25 PM, David Conrad wrote:
>>> Suzanne,
>>>
>>> On Apr 7, 2016, at 2:39 PM, Suzanne Woolf  wrote:
>>>>> On Apr 7, 2016, at 11:17 AM, Stephane Bortzmeyer  
>>>>> wrote:
>>>>>
>>>>> Since we have this liaison, does anyone know if it was used to inform
>>>>> ICANN of this discussion (it seems the right thing to do) and to ask
>>>>> them if they wanted to comment?
>>>>
>>>> https://datatracker.ietf.org/liaison/1351/
>>>>
>>>> (DNSOP co-chairs, AD, and IAB collaborated on this, as the IAB has 
>>>> oversight of liaisons for the IETF.)
>>>
>>> Out of curiosity, since that liaison statement was made about 18 months 
>>> after RFC 6761 was published and about a 10 months after 
>>> draft-grothoff-iesg-special-use-p2p-names was submitted, was there any 
>>> previous liaison communication to ICANN prior to that statement related to 
>>> RFC 6761?
>>
>> Afaik there's only one liason statement to icann since the inception of
>> liason statement tracking; the basis of inter-organiation collaboration
>> is imho largely the RFC series.
>>
>>> Thanks,
>>> -drc
>>> (speaking only for myself)
>>>
>>>
>>>
>>> ___
>>> DNSOP mailing lis
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[joel jaeggli]

On 4/7/16 3:25 PM, David Conrad wrote:
> Suzanne,
> 
> On Apr 7, 2016, at 2:39 PM, Suzanne Woolf  wrote:
>>> On Apr 7, 2016, at 11:17 AM, Stephane Bortzmeyer  wrote:
>>>
>>> Since we have this liaison, does anyone know if it was used to inform
>>> ICANN of this discussion (it seems the right thing to do) and to ask
>>> them if they wanted to comment?
>>
>> https://datatracker.ietf.org/liaison/1351/
>>
>> (DNSOP co-chairs, AD, and IAB collaborated on this, as the IAB has oversight 
>> of liaisons for the IETF.)
> 
> Out of curiosity, since that liaison statement was made about 18 months after 
> RFC 6761 was published and about a 10 months after 
> draft-grothoff-iesg-special-use-p2p-names was submitted, was there any 
> previous liaison communication to ICANN prior to that statement related to 
> RFC 6761?

Afaik there's only one liason statement to icann since the inception of
liason statement tracking; the basis of inter-organiation collaboration
is imho largely the RFC series.

> Thanks,
> -drc
> (speaking only for myself)
> 
> 
> 
> ___
> DNSOP mailing lis
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[joel jaeggli]

On 4/7/16 2:31 PM, Paul Hoffman wrote:
> On 7 Apr 2016, at 12:17, Stephane Bortzmeyer wrote:
> 
>> draft-adpkja-dnsop-special-names-problem is full of FUD about how
>> ICANN could be pissed off by a decision of the IETF to add .something
>> to the Special-Use registry, but did we actually *asked* ICANN about
>> it?

https://gnso.icann.org/mailing-lists/archives/council/msg16659.html

> This statement seems like FUD to me. Can you point to which paragraphs
> in the document that gives you that feeling? I ask this because, as much
> as I dislike some of the words and organization of the draft, I cannot
> map what you say to anything in the draft (so that I could suggest an
> edit).
> 
> --Paul Hoffman
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[joel jaeggli]

On 4/1/16 4:53 PM, George Michaelson wrote:
> Whats your reaction going to be, to a closed 6761 because if you come
> to the microphone with a "but we built to the userbase, we have
> millions" and make bambi eyes, I feel a bit like saying "you were
> warned"
> 
> ie, squatting a domain, is squatting a domain, no  matter how much you
> believe in your own process. If you populate code to the label, a
> specific label, you're in moral hazard.
> 
> You cannot predict what label (if any) you will get. You need to code
> agile, to a label being in another space (eg .alt) which is also
> unknown. it has to be in a .conf or other runtime option, not hard
> coded.

which would be super useful implementation advice to the community so
not to create moral hazard in the future.

> forever.
> 
> -G
> 
> On Fri, Apr 1, 2016 at 7:40 AM, str4d  wrote:
>> On 29/03/16 07:53, John Levine wrote:
>>> Finally, no matter what we do, at some point someone will come by with
>>> .GARLIC which is like .ONION but stronger and they will say (with some
>>> justification) that it's used by a zillion people around the world.
>>> "You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't,
>>> sorry."  Then we'll have to deal with it one way or the other.  I hope
>>> that .alt will push that day off farther into the future but it's
>>> unlikely to push it to infinity.
>>
>> Injecting a little levity: I2P does in fact use a variant of onion
>> routing called garlic routing! But we are already in the 6761 process
>> for .I2P, and have absolutely no desire to take garlic any further than
>> a technical metaphor :)
>>
>> str4d
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-liu-dnsop-dns-cache

[joel jaeggli]

On 3/31/16 6:18 AM, abby pan wrote:
> 
> 
> Stephane Bortzmeyer mailto:bortzme...@nic.fr>>于2016
> 年3月29日周二 下午9:48写道：
> 
> On Mon, Mar 28, 2016 at 05:38:01AM +,
>  abby pan mailto:abby...@gmail.com>> wrote
>  a message of 246 lines which said:
> 
> > 1) baofeng recursive ddos attack(2009):
> > http://www.pcworld.com/article/165319/article.html
> 
> A more technical reference for this attack is the OARC talk
> 
> 
> yes, in ziqian_liu's talk , they "Increase the TTL of baofeng.com
>  related RRs"  on the cache  to rescue
>  
> 
> > 2) baidu dns hijack(2010):
> >
> 
> http://www.zdnet.com/article/baidu-dns-records-hijacked-by-iranian-cyber-army/
> 
> This paper says it was purely social engineering on the registrar. No
> change in the DNS would help.
> 
>  
> if cache can temporary prolong the ttl of baidu ns, that will help.

It actually can't really unless you're proposing that a recursive
resolver refuse to honor the ns/soa after ttl expiration. that makes it
rather hard to change providers, transfer zones or replace nameservers.
which are of course reasons why you would have a lower ttl on such
records anyway.

if you're suggesting that large content providers zones are sufficiently
ossified that they never change or are re/delegated well, that isn't true.

> 
> > The selection is automatic, commonly TOP-N domain names.
> 
> OK, so if I want my own personal vanity domain name to be well cached,
> I just have to hire a botnet to send many requests for
> bortzmeyer.org .
> 
> Also, it seems you mix "important" with "often
> queried". impots.gouv.fr  (the tax service)
> is important in France, if
> you cannot reach it, you'll not be able to pay and you wil be
> fined. But it does not see a lot of requests, typical people use it
> once a year.
> 
>  
> yes,  simply online TOP-N is easy to around. 
> 
> But the "hot" domain we can pre-set, as your example, like "*.gov.cn
> "， “qq.com ",  "baidu.com
> ",  "taobao.com " in china.
> 
> We manage the "most important" domain list, not just from dns query
> count, but also the service data flow associated with the domain, also
> from some company alliance.
> 
> 
> > How long will the SERVFAIL cache last usually depend on ISP network
> > bgp status, especially when recursive send dns query when the ns
> > server is in other ISP.
> 
> You mean the name server has to know BGP?
> 
> 
> I mean if cache server can check the NS BGP status with some addtional
> module,  the rtt of dns query will be benefits.
> 
> But as Evan Hunt says, that's not "should" , but can be a choice.
>  
> 
> 
> > The pre-fetching is something like link-fetching(
> > https://en.wikipedia.org/wiki/Link_prefetching ), shortten the
> response
> > time.
> > Again, pre-fetching is part of "backup cache" for ddos attack
> resuce or
> > baidu hijack rescue, etc.
> 
> I did not say pre-fetching is bad, I said it does not require any
> change in the DNS server (it can be done from the outside).
> 
> 
> I did not say that need change in the DNS server's normal task.
> 
> but it can be some additonal module to active when encounter ddos or
> hijack ( outside the normal case ) .
>  
> 
> 
> > In "baofeng recursive ddos attack": short domain TTL + ns shutdown +
> > huge amount client fail and retry prolonging the TTL can partly
> > defense the attack.
> 
> I did not say increasing the TTL is bad, I said it is a change in the
> protocol and therefore your draft has to declare it updates RFC 1034
> (and 1035).
> 
> 
> same as above,  it can be some additonal module to active when encounter
> ddos or hijack ( outside the normal case ) .
> 
> so that's not change in the protocol, not change the normal dns
> query/response.
> 
> it's actived to  auto defense when huge count to 1s TTL suddenly rise.
>  
> 
> 
> > Sometimes recursive receive hijack data (cache-poisoning attack).
> > if there is an security analysis module, users will more benefits.
> 
> If it is just asserting the validity of data before returning it to
> the user, what do you need besides the already existing RFC 2181
> (section 5.4.1) and RFC 5452 (specially sections 6 and 9)?
> 
> 
> again, it is not change the protocol, but some additional module to
> validate the data in cache dns operation.
> 
> comodo, opendns has give the protect service : 
> http://www.computerworld.com/article/2872700/6-dns-services-protect-against-malware-and-other-unwanted-content.html
> 
> for example, detect hijack phishing ip of xxx.qq.com 
> , help to correct or block it.
> -- 
> 
> Best Regards
> 
> Pan Lanlan
> Tel: +86 186 9834 2356
> 
> 
> 

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[joel jaeggli]

On 3/28/16 9:08 PM, George Michaelson wrote:
> On Tue, Mar 29, 2016 at 1:36 PM, Andrew Sullivan  
> wrote:
>> That's in effect an argument that the special-names registrations are not 
>> special.  I
>> do not agree with that claim.
> 
>>From an extreme point of view (which clearly, contextually, I hold)
> thats exactly what I think I fundamentally agree with, in what Alain
> is saying: The special-names are claiming technological override on
> process which ignores the central unity of all name-strings:

It doesn't ignore it, it assumes the unity of namespace. otherwise what
would be the point? you'd just go off and do your own thing...

>  for
> ICANN, for the namespace, these are labels like all the others.

indeed.

> They're asking for a joker-card permit, which I have major issues
> with. That aside, they're just like all the others. The qualities they
> have in the zone, the records which do or do not exist are in another
> plane, orthoginal.
> 
> -G
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[joel jaeggli]

On 3/28/16 8:49 PM, David Conrad wrote:
> Andrew,
> 
> On Mar 28, 2016, at 8:36 PM, Andrew Sullivan 
> wrote:
>> But I think you're smuggling into your argument a claim that 
>> they're potentially subject to the IPR and socio-economic issues
>> that have been a problem in the DNS root and TLD zones.  That's in
>> effect an argument that the special-names registrations are not
>> special.  I do not agree with that claim.
> 
> Just to be clear, you believe that the IESG putting a name onto the
> special names registry means that it will then be immune from IPR and
> socio-economic issues?

What IETF activity is immune to IPR or sociology-econmic issues?

> Thanks, -drc
> 
> 
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-edns-client-subnet-06: (with DISCUSS and COMMENT)

[joel jaeggli]

07 would be greatly appreciated.

joel

On 2/24/16 10:27 PM, Stephen Farrell wrote:
> 
> Hi David,
> 
> All of those changes look good to me. Happy to clear the discuss
> when you post -07.
> 
> Cheers,
> S.
> 
> On 25/02/16 01:12, Dave Lawrence wrote:
>> Stephen Farrell writes:
>>> Section 11.3, I like that we're recommending that ECS be
>>> disabled by default, but want to check one thing. This says: 
>>> "Due to the high cache pressure introduced by ECS, the feature
>>> SHOULD be disabled in all default configurations."  Does that
>>> mean that all servers SHOULD disable this by default or does
>>> this only apply to some servers? If the former, it should
>>> probably be (re-)stated somewhere early on and more prominently
>>> and not only stated far down in the document like this. If the
>>> latter, then I think you need to be more precise and I'd like to
>>> know why we're not preferring the more privacy friendly option
>>> as our default. So I hope your answer is "yeah, all servers and
>>> sure we can state that earlier as well" :-)
>>
>> In the draft that is pending its (presumably) final edits to make
>> version -07 to head to the RFC Editor, the last paragraph of the
>> Privacy Note (which is section 2), now says:
>>
>>We recommend that the feature be turned off by default in all
>>nameserver software, and that operators only enable it explicitly
>>in those circumstances where it provides a clear benefit for their
>>clients.  We also encourage the deployment of means to allow users
>>to make use of the opt-out provided.  Finally, we recommend that
>>others avoid techniques that may introduce additional metadata in
>>future work, as it may damage user trust.
>>
>> Does that adequately address your concern?
>>
>>> - abstract: I think it'd be good if the abstract noted that this
>>> was documenting a deployed option and not necessarily
>>> recommending this as the best thing ever. There's text in the
>>> write-up and intro that does that nicely that could work if
>>> reduced to one sentence, e.g. maybe something like: "This
>>> documents an EDNS0 option that is in active use on the Internet
>>> today that is intended to be revised in the near future to
>>> improve it's security and privacy features."  
>>
>> How is this for the new abstract?
>>
>> This document describes an EDNS0 extension that is in active use
>> to carry information about the network that originated a DNS
>> query, and the network for which the subsequent response can be
>> cached. Since it has some known operational and privacy
>> shortcomings, a revision will be worked through the IETF for
>> improvement.
>>
>>> - 7.2.2 says "Because a client that did not use an ECS option
>>> might not be able to understand it, the server MUST NOT provide
>>> one in its response." That seems like a bit of a pity - one
>>> comment I was going to make was that it might be good to include
>>> this (or something) in a response so that a client that didn't
>>> ask for ECS could be informed that some DNS server is doing ECS.
>>> Would that actually break things? 
>>
>> I don't think anyone has real experimental evidence on this.  We do
>> see a lot of variation in the way that various DNS servers handle EDNS
>> in general, but I believe pretty much all of it has been with regard
>> to how servers handle EDNS anomalies in requests, and not with its
>> unexpected presence in responses.
>>
>> Given the lack of experience in this area I'd be reluctant to include
>> anything about it in this document, but will certainly consider
>> looking into it more for the revision.
>>
>>> - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g.
>>> RFC6598 at all.  RFC6890 has a MAY associated with it, but does
>>> refer to 6598. And what about stuff like RFC7534, which isn't
>>> mentioned? Is that all correct and up to date? 
>>
>> I believe it is good as-is; we actually have known operational use
>> cases of allowing things like CGNAT through because a co-operating
>> resolver and authority have shared information about what the network
>> looks like.  This is covered a little in the section on NAT
>> Considerations.  If there's still something problematic I'd be happy
>> to address it.
>>
>>> - 11.1, 4th para: "Users" isn't really right. People don't know
>>> about any of this stuff really. "Clients" would be more accurate
>>
>> Rephrased from:
>>
>>Users who wish their full IP address to be hidden can include an
>>ECS option specifying the wildcard address (i.e.  SOURCE
>>PREFIX-LENGTH of 0).
>>
>> to:
>>
>>Users who wish their full IP address to be hidden need to configure
>>their client software, if possible, to include an ECS option
>>specifying the wildcard address (i.e.  SOURCE PREFIX-LENGTH of 0).
>>
>> Good? 
>>
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Desc

Re: [DNSOP] why classes are useless, was New Version Notification for draft-sullivan-dns-class-useless-01.txt

[joel jaeggli]

On 3/19/16 4:53 PM, Andrew Sullivan wrote:
> On Fri, Mar 18, 2016 at 06:44:44PM -0400, Michael StJohns wrote:
>> responses within the UDP sizes.The class field might have been a useful
>> way to do that, especially for things related to keys and signatures.
> 
> There are lots of things the class field _might_ have been useful for.
> What I've been trying to suss out in this conversation is whether
> there is any way to make that potential utility actual.  Do you think
> the repurposing you're mentioning is a realistic hope, or just a road
> not taken?

IMHO any effort that expects end users (humans) to differentiate by
class seems like a fools errand; machines perhaps. If by road not taken
we mean user interface disaster avoided then yes, we avoided that.

> Best regards,
> 
> A
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[joel jaeggli]

On 2/29/16 3:12 PM, Warren Kumari wrote:
> On Mon, Feb 29, 2016 at 10:40 AM Tim Wicinski  > wrote:
> 
> There was some good discussion around this draft when it first appeared,
> and the initial idea by the author was to run this through the Apps area
> working group.  The chairs feel it make more sense to run this through
> DNSOP and we urged the author to allow us the chance to give the working
> group a try before giving up.
> 
> *Note: This draft will create an IANA registry for "underscored names".
> Now 10 years ago, even I would of blanched at such a thought.  But there
> seems to have come a time where it makes sense to document the
> morass of these labels and offers some guidance.  The discussion seemed
> to bear this out.
> 

  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
   by a specification published by another standards organization.  The
   contents of each entry are defined in Section 4

So the registry policy I read as specification required given the
inclusion of 3rd party documents rather than RFC required.  Is that how
you read it? Should those be subject to expert review?

anyway 5226 obsoleted 2434 so I'd probably cite that.

thanks
joel

> 
> Yeah. Support. 
> 
> I hold it true, whate'er befall;
> I feel it when I sorrow most;
> 'Tis better to have documented this
> Than never to know at all.
>  (apologies to L. AT)
> 
>  
> 
> 
> This starts a Call for Adoption for "DNS Scoped Data Through
> '_Underscore' Attribute Leaves"
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-crocker-dns-attrleaf/
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> 
> Contribute, review.
> 
> W 
> 
> 
> This call for adoption ends 14 March 2016.
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-06.txt

[joel jaeggli]

We're good,

We hold the token at his point so we can push it over to the rfc editor.

Thanks for the effort
joel


On 2/22/16 4:21 AM, Sara Dickinson wrote:
> All, 
> 
> This update addresses all of the outstanding comments from the IESG review of 
> this document, apart from a decision on the question about DNS-over-DTLS.
> 
> Joel/Tim - is there an update on that decision?
> 
> Regards
> 
> Sara. 
> 
>> On 22 Feb 2016, at 12:08, 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 of the IETF.
>>
>>Title   : The edns-tcp-keepalive EDNS0 Option
>>Authors : Paul Wouters
>>  Joe Abley
>>  Sara Dickinson
>>  Ray Bellis
>>  Filename: draft-ietf-dnsop-edns-tcp-keepalive-06.txt
>>  Pages   : 14
>>  Date: 2016-02-22
>>
>> Abstract:
>>   DNS messages between clients and servers may be received over either
>>   UDP or TCP.  UDP transport involves keeping less state on a busy
>>   server, but can cause truncation and retries over TCP.  Additionally,
>>   UDP can be exploited for reflection attacks.  Using TCP would reduce
>>   retransmits and amplification.  However, clients commonly use TCP
>>   only for retries and servers typically use idle timeouts on the order
>>   of seconds.
>>
>>   This document defines an EDNS0 option ("edns-tcp-keepalive") that
>>   allows DNS servers to signal a variable idle timeout.  This
>>   signalling encourages the use of long-lived TCP connections by
>>   allowing the state associated with TCP transport to be managed
>>   effectively with minimal impact on the DNS transaction time.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-06
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-tcp-keepalive-06
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-michaelson-dnsop-rfc6761-is-closed-00.txt

[joel jaeggli]

On 2/22/16 4:17 PM, George Michaelson wrote:
> I know it had that clause Brian. I kept the document short. I think the
> clause was a sanity clause whose invokation was basically insane. We
> should not have formalized a process on it, it should have been
> something done on very mature consideration. Instead, we've had a very
> immature conversation and now have .onion, the mDNS outcome in .local
> and the queue of me-too at the door.

Before were get off on a tangent how we sealed off our authority to
maintain the technical function of the dns; the delegation of zone cuts
for specialized purposes specifically  in 2860, I'm convinced we did not.

If we had there would be little purpose to the rechartering effort that
led to us discussing 6761 revision today.

> I've discussed this with other people. We don't agree, but there is a
> sense that if there is a bar it was set ludicrously low. 
> 
> So I wrote this document to tease the conversation out.
> 
> Without wanting to get pejorative, and understanding there are
> sensitivities here, can I ask a very basic question, which you may be
> able to answer, but its about *US* not about *YOU* so please don't feel
> objectified.
> 
> Why is it, in the IETF, we find it so hard collectively to say "we made
> a mistake" ?

Experimentation and mistake is inevitable. If we thought it was hunk
dory, we wouldn't be chartered to review it.  Do I have misgivings about
what has transpired that caused us to arrive at this point? absolutely.


> -George
> 
> On Tue, Feb 23, 2016 at 12:49 PM, Brian E Carpenter
> mailto:brian.e.carpen...@gmail.com>> wrote:
> 
> Hi George,
> 
> >RFC 6761 [RFC6761] specified mechanisms for reserving a top level
> >name in the DNS.
> >
> >This reversed a prior decision documented by RFC 2860 [RFC2860] to
> >close off mechanisms for name assignment in the IETF, the function
> >being recognized as vesting with ICANN.
> 
> That is 100% incorrect. RFC 2860 clause 4.3 states explicitly and for
> the exact purpose of *not* closing off assignments in all cases:
> 
>Note that (a) assignments of domain names for technical uses (such as
>domain names for inverse DNS lookup), (b) assignments of specialised
>address blocks (such as multicast or anycast blocks), and (c)
>experimental assignments are not considered to be policy issues, and
>shall remain subject to the provisions of this Section 4.
> 
> So whatever the technical merits of your proposal, such names and
> address
> blocks remain under the IETF's authority. That doesn't mean the IETF
> should blunder around with its eyes closed, but if we want .heffelump.
> to be reserved for a technical purpose, we can so decide.
> 
> (I am not on the dnsop list so please keep me in cc.)
> 
> Regards
> Brian
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Can I have a slot in the DNSOP WG to discuss draft-michaelson-dnsop-rfc6761-is-closed

[joel jaeggli]

On 2/22/16 6:21 PM, George Michaelson wrote:
> 
> 
> On Tue, Feb 23, 2016 at 3:05 PM, Paul Wouters  > wrote:
> 
> Face to face time is rare. It also does not include everyone that's on
> the list. So where possible, discussion on the lists is always
> preferred.
> 
> 
> A good bar. A high bar. A high bar, which I don't think the "design
> team" output can meet because I've checked the archives, to match my
> memory, and substantive discussion on the qualities of the idea of
> having a registry are few: there are nits on the words of the revision,
> but we've yet to actually broach "do we want to do this" in any real form.
> 
> So consider the door open on that discussion:
> 
> Folks: Do we *really* want to do this? Do we really *want* to revise
> RFC6761? Can we talk about this a bit?
> 
> Me? I don't want to do this. I want a process that is so rarely invoked,
> you have to be a lot taller to get on the ride, than at present. I want
> a substantive IETF-wide technically understood reason that is breaking
> architecture, avoiding URI methods, requiring code, that we all understand. 

The part I like about your proposed position is that it's unequivical.

> And certainly not "because a lot of users now depend on it, because we
> squatted"

Oddly I'm not enthused by this as a reason for existing or future 6761
registration reuest, technical merit or necessity on the other hand is
not carte blanche to employ 6761 or at least is doesn't seem to be and
matters of taste are hard to fence in with objective criteria.

> -G
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-chain-query-06: (with COMMENT)

[joel jaeggli]

That works for me.

note, the IESG review is now completed. so we hold token on when to ship it.

thanks
joel


On 2/18/16 6:43 AM, Paul Wouters wrote:
> On Mon, 15 Feb 2016, Stephen Farrell wrote:
> 
>> --
>> COMMENT:
>> --
>>
>>
>>
>> - In section 3 you promised me privacy considerations in section
>> 8 but I didn't find any there. That was almost a DISCUSS, but
>> since fixing it is easy and I assume won't be controversial I
>> can stick with a YES ballot:-)
>>
>> - I would suggest that you do note in section 8, that the fqdn
>> in the CHAIN option could allow an attacker to (re-)identify a
>> client. E.g. if the attacker sees that you have validated
>> tetbed.ie before that could single you out, even if you have
>> changed your n/w, cilent IP address etc. Presumably that would
>> be a relatively long lasting concern as well, as RRSIG expiry
>> tends to be weeks ahead. I think just noting that and maybe
>> saying that DPRIVE is a likely mitigation would be a good thing
>> to do.
> 
> I have added the following two sections to the security considerations.
> Let me know if that addresses your concerns:
> 
> 8.1.  Additional work and bandwidth
> 
>Producing CHAIN answers incurs additional load and bandwidth on the
>Recursive Resolver.  At any time, a Recursive Resolver may decide to
>no longer answer with CHAIN answers and fall back to traditional DNS
>answers.
> 
> [8.2 was the original section regarding Amplification]
> 
> 8.3.  Privacy Considerations
> 
>A client producing CHAIN queries reveals a little more information
>about its cache contents than regular DNS clients.  This could be
>used the fingerprint a client across network reconnections.  If DNS
>privacy is a concern, a CHAIN query client MAY try to use a DNS
>transport that provides privacy, such as [DNS-over-TLS] or a trusted
>DNS server that is contacted through a VPN connection such as IPsec.
> 
> I believe that resolves the "promises" in Section 3.
> 
> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [regext] Any interest in draft-latour-dnsoperator-to-rrr-protocol ?

[joel jaeggli]

On 2/16/16 1:05 PM, Barry Leiba wrote:
>>> I think it would fall under REGEXT once it's up? The REGEXT charter
>>> has a section about DNS Operator.
>>>
 The working group will also identify the requirements for a
 registration protocol where a third-party DNS provider is involved.
 These requirements will be documented in an Informational RFC.
>>
>> based on on current progress I would expect regext to exist prior to or
>> by IETF 92.
> 
> And by "IETF 92", Joel means IETF 95.

yeah that, sorry

> Barry
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Any interest in draft-latour-dnsoperator-to-rrr-protocol ?

[joel jaeggli]

On 2/16/16 7:09 AM, Jacques Latour wrote:
> Hi,
> 
> I think it would fall under REGEXT once it's up? The REGEXT charter has a 
> section about DNS Operator.
> 
>> The working group will also identify the requirements for a
>> registration protocol where a third-party DNS provider is involved.
>> These requirements will be documented in an Informational RFC.

based on on current progress I would expect regext to exist prior to or
by IETF 92.

> Jack
> 
> 
>> -Original Message-
>> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of John Levine
>> Sent: February-13-16 4:45 PM
>> To: dnsop@ietf.org
>> Subject: [DNSOP] Any interest in draft-latour-dnsoperator-to-rrr-protocol ?
>>
>> I noticed the -02 of this draft go by yesterday.
>>
>> It's a very rough version of a DNSSEC key record bootstrap design in which 
>> the
>> operator of the delegated zone pokes the operator of the upper level zone
>> using http, which tells the upper level zone to import keys from the 
>> delegated
>> zone's CDS and CDNSKEY records.
>>
>> Is there much interest in this?
>>
>> On my tiny DNS server I have over 100 signed zones where I can't install the
>> upper level DS records because I'm not the registrant, I'm just running their
>> DNS.  It would be nice to have a way to do that that scales better than
>> walking each of the registrants through their registrars' DNSSEC update
>> processes.
>>
>> R's,
>> John
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-edns-tcp-keepalive-05

[joel jaeggli]

On 1/25/16 2:38 PM, 🔓Dan Wing wrote:
> 
> On 21-Jan-2016 07:39 am, Tim Wicinski  wrote:
>> 
>> DNSOP,
>> 
>> Joel our AD sent this note out two weeks ago to get some working
>> group consensus on this discussion which came up during the IESG
>> telechat on tcp-keepalive
>> 
>> I am in agreement with Joel on this (tcp-keepalive is not the
>> mechanism for DTLS), but it should be thought of.
>> 
>> any opinions? I'd like to get some resolution so we can move this
>> along
> 
> The TCP mechanism (edns-tcp-keepalive) negotiates the ability of the
> client and the server to send multiple DNS queries on the same TCP
> connection.  As such, it seems ill-named (that is, a title adjustment
> seems important).  This does not actually "keep the connection
> alive", which is the traditional meaning of "keepalive" in IETF
> protocols.  This EDNS0 option is useful for both DNS-over-TCP, as
> well as DNS-over-TLS-over-TCP.
> 
> For DNS-over-DTLS-over-UDP, we should not need to negotiate the
> client or server capability to send multiple DNS queries over the
> same DTLS connection; the mere act of negotiating DTLS indicates the
> ability to handle subsequent DNS queries using that same DTLS
> connection.  The same might also be true of DNS-over-TLS-over-TCP, in
> fact?  I mean, is there a client or a server that wants to use
> DNS-over-TLS-over-TCP and _not_ also have the ability to keep their
> TCP connection alive for later DNS queries over that same TLS
> connection?  Perhaps for both DNS-over-TLS, and DNS-over-DTLS, the
> semantics of edns-tcp-keepalive are implied?

that is an interesting reading. though I'd want to hear an implementor
or two say they interpreted it that way.

> -d
> 
> 
> 
> 
> 
> 
> 
>> 
>> thanks tim
>> 
>> 
>> 
>> On 1/7/16 10:30 AM, joel jaeggli wrote:
>>> From Stephens discuss, this is a question we should probably
>>> answer for ourselves. (it's no longer a consideration as a
>>> discuss.
>>> 
>>> The question: how does this option play with DNS over DTLS? [1]
>>> 
>>> The reason I ask is that there may be a need in that case for
>>> some similar option (or a TLS extension maybe) though for the
>>> DTLS session lifetime and not a TCP session lifetime. At present
>>> you are saying that this option is not it. And that's a fine
>>> answer but you could also have said that this could also be used
>>> for DTLS session lifetime handling. And that last might make
>>> sense for operational reasons (not sure really, but could be).
>>> 
>>> [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03
>>> 
>>> My take personally is tcp keepalive option is not the mechanism
>>> for dtls, but then we get multiple options specifying essentially
>>> the same sort of value at some point in the future.
>>> 
>>> I just want to make sure we have a good reading on this.
>>> 
>> 
>> ___ DNSOP mailing list 
>> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 





signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alvaro Retana's Discuss on draft-ietf-dnsop-5966bis-05: (with DISCUSS)

[joel jaeggli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/7/16 11:35 AM, Alvaro Retana (aretana) wrote:
> 
> On 1/7/16, 2:30 PM, "Brian Haberman" 
> wrote:
> 
>>> What happens now?   A two week PS Last Call?  (a question for
>>> JoelŠ)
>> 
>> As an AD (at least for the next 3 months), I don't think we need
>> a new LC. Rather, we can fix the meta data, announce the fix to
>> the community, and continue processing the document.
> 
> I agree.

wfm

> Alvaro.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlaOyaUACgkQ8AA1q7Z/VrL6iACfftg51N0Kf6MlwY+rf/zFdzGO
pT4AniGoN/7mNtLZL7r4irEEDK6ZjL9I
=AMx6
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alvaro Retana's Discuss on draft-ietf-dnsop-5966bis-05: (with DISCUSS)

[joel jaeggli]

It is intended as ps, given the changes I think advancement to IS is
not warrented notwithstanding wide deployment.

The duration of the last call looks to be my bad and I will have to
correct that.

joel

On 1/6/16 8:55 AM, Mankin, Allison wrote:
> Alvaro,
> 
> The draft aims for PS, not IS. I think you've found an XML editing bug on our 
> part. We wouldn't expect to go IS, given this bis includes new material. So 
> this was a great catch.
> 
> Thanks,
> Allison
> 
> Sent from my iPhone
> 
>> On Jan 6, 2016, at 11:43, Alvaro Retana  wrote:
>>
>> Alvaro Retana has entered the following ballot position for
>> draft-ietf-dnsop-5966bis-05: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> I don’t have concerns over the technical content of this document, but I
>> do have want to raise a process-related DISCUSS.
>>
>> The Intended RFC Status of this document is “Internet Standard”, which
>> seems like a logical progression from RFC5966 (Proposed Standard). 
>> However, I am concerned that the proper process was not followed:
>>
>> 1. RFC6410 calls for “an IETF-wide Last Call of at least four weeks”, but
>> the LS started on Nov/23 and ended on Dec/7, 2 weeks.
>>
>> 2. In looking at the archives I couldn’t find any discussion about
>> changing the maturity level.
>>
>> 3. It also concerns me that the changes go beyond a simple revision of
>> the old text.  For example, there are recommendations that are completely
>> new and for topics that were not even mentioned in the original (e.g.
>> pipelining).
>>
>>
>> I may have missed the discussions in the archive.  Not being a DNS expert
>> I may also be overestimating the changes to this document. But knowing
>> that the “document was actively discussed and reviewed” and that it “had
>> a broad discussion as the wording of several points were more accurately
>> described” (from the Shepherd’s write up), I think that this document may
>> not be ready to be an Internet Standard.
>>
>> The obvious solution to this DISCUSS is to change the intended status to
>> Proposed Standard.
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-edns-tcp-keepalive-05: (with DISCUSS and COMMENT)

[joel jaeggli]

On 1/7/16 6:52 AM, Stephen Farrell wrote:
> 
> Hi Sara,
> 
> On 07/01/16 10:54, sara wrote:
>>
>>> On 6 Jan 2016, at 21:58, Stephen Farrell
>>>  wrote:
>>>
>>>
>>> Hiya,

 Speaking for myself I don’t see this as the solution to managing
 DTLS sessions, I think that would be better handled with a TLS
 extension.
>>>
>>> Yes, that's the obvious answer, and a not bad answer. Did the dnsop
>>> WG (or dprive) consider the issue already?
>>
>> It is a good question, but it wan't explicitly discussed AFAIK.
> 
> Okey-dokey, I'll ask Joel how he prefers to handle this on the
> call today and go with whatever he recommends.

oh goodie, happy to discussion, definitely not the arbiter of taste.

>>
> - 3.3.2:
>>>
>>> Oops:-) Typo there sorry, the one that puzzled me is at the end of
>>> 3.2.2 where it says " This holds true even if a previous 
>>> edns-keepalive-option exchange occurred on the existing TCP 
>>> connection."
>>
>> Ah, this is to do with the semantics of EDNS0 exchanges. It just
>> clarifies that if the server chooses not to send the option in this
>> scenario it is effectively equivalent to the server sending a 0
>> timeout (indicating it does not want to continue with keepalive) even
>> it if previously indicated it supported it.
> 
> Ah grand, I get it now. I think the way you've explained it above
> is clearer for me anyway, so maybe consider saying it that way if
> you do any more changes.
> 
> Cheers,
> S.
> 
>>
>> Sara.
>>
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] "anything goes" (was Re: Should we try to work on DNS over HTTP in dnsop?)

[joel jaeggli]

On 12/18/15 10:07 AM, Andrew Sullivan wrote:
> On Wed, Dec 16, 2015 at 08:36:00PM -0800, Paul Vixie wrote:
>>
>> this is the new era of "anything goes" for DNS protocol development. as with 
>> client subnet, no 
>> matter how bad an idea is, if someone is already doing it, then the ietf 
>> documents that use.
>>
> 
> I am getting a little tired of this description.  If it's "anything
> goes" then we can just give up and go home.
> 
> Some people don't like client subnet.  I'm not too convinced that the
> architectural arguments against it are so good, but that's a different
> debate.
> 
> I'm much more concerned about snide remarks dismissing the serious
> efforts of people as "anything goes".  I think it's unfair, I think it
> pretends access to a trancendental goodness that (I am prepared to say
> _a priori_) no participant here has, and I think it needlessly
> disparages the good faith efforts of many people to make the Internet
> better in an environment where we don't all agree about what "better"
> is.  I think many of us stand improvement (I here include myself) at
> making our arguments less charged.

I think we dramatically better off, if we are willing to critically
consider the implications of proposals someplace and expose the record
of that, and I don't have a better location on offer then here.

> Best regards,
> 
> A (speaking, as usual, for myself only)
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fuel on fire: more TLD to come :-)

[joel jaeggli]

On 11/11/15 7:58 AM, Stephane Bortzmeyer wrote:
> I write a draft requesting registration of each of these in the RFC
> 6761 registry :-D

While I might consign this to the realm of nutjobs, it seems to be the
case that what they intend to describe is an entirely seperate namespace.

> https://forum.ethereum.org/discussion/1383/the-ethereum-domain-naming-system
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] agenda bashing

[joel jaeggli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

paul,

I would like to apologize for asking you to sit down.

My interpretation of the statement was that:

We do not have scope to address a charter item because it belongs at
icann.

We need to either address it or inform the iesg that we are not going
to fulfill our current charter.

It could reasonably have been interpreted as a question about how we
aportion our time. I am clearly abusing my position in either case
for which I am sorry.

Thank you for your forebearance
joel
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlY6sbMACgkQ8AA1q7Z/VrI6rgCfQTWOgtY/BGJ8CiD4kTSijEab
BlUAn1BOcccrbkFhaJXF+jVYM1oO694+
=KZfG
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft -domain-names-01

[joel jaeggli]

I think the dicussion of names is useful and insightful.

we can find a home for it I'm pretty sure but I'm happy to see
discussion of it.

joel

On 11/3/15 4:39 PM, Tim WIcinski wrote:
> 
> I spoke to Ed this morning during breakfast, and we discussed his
> draft.  I do like this as a well written read through the history of
> namespace and domains, but I feel (and I think Ed even would agree) this
> is not so much a DNSOP document, but something that should be in an area
> where they need a better understanding of DNS (*cough* appsawg *cough*).
> 
> How does the working group think of this?
> 
> thanks
> tim
> 
> On 10/30/15 8:23 PM, Edward Lewis wrote:
>> A while back I floated a draft across this mail list and got (what I
>> think) is sufficient (perhaps not the right word) feedback from the WG.  I
>> updated the document and resubmitted.  FWIW, this is the document link:
>> https://tools.ietf.org/html/draft-lewis-domain-names-01
>>
>> I'm not even asking for comment on the list (but you can if you want).
>> When I rev'd the document, I didn't mention it on this list (until now).
>>
>> What I'm asking for is - when in Yokohama, if you have an interest in this
>> I'm willing to discuss.
>>
>> The issue in the document is both internal to DNS and external to DNS, I'm
>> looking for broader input (such as applications area topics).
>>
>> Ed
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Meeting agenda

[joel jaeggli]

Hello, AD here.

On 10/28/15 5:24 AM, yaojk wrote:
> 
> 
> 
> 
>> 在 2015年10月28日，19:45，Tim Wicinski  写道：
>>
>>
>>
>>
>>> On 10/28/15 7:37 AM, yaojk wrote:
>>> Hello
>>>
>>> http://tools.ietf.org/wg/dnsop/agenda?item=agenda-94-dnsop.html
>>>
>>> From the agenda above, I see that it doesn't include my draft
>>> discussion. Could you kindly assignee 5 minutes to introduce the draft-
>>> yao-dnsop-root-cache？
>>>
>>> Thanks
>>>
>>> Jiankang Yao
>>
>> Hi
>>
>> Thanks for asking, but we're not going to give time to this draft.  
> 
> 
> 
> It might be your power as chairman. But I think that your arguments to block 
> the draft discussion is not reasonable.

We invest chairs with editorial discretion among other things. that is
of course backstopped with an appeals process but for now somebody has
to manage the facility.

https://tools.ietf.org/html/rfc2418#section-6.1

>> The consensus of comments about the draft is that it has many issues that 
>> need to be addressed.  
> 
> 
> Unfortunately, I haven't such senses of your called consensus.

I'm not going to challenge that assertion... For myself; Joe Abley's
message on 9/30 is the last cogent message related to the discussion of
this draft that's on record. to date (until now) I don't see further
activity on it.

> On 9/30/15 6:17 AM, Joe Abley wrote:
...
> I think I would need to see a convincing problem statement and
> understand how this proposal provided effective solutions before I
> could support it.

There doesn't really seem to be much point (imho) in taking the
discussion off the mailing list in order to utilize expensive high
bandwith discussion time since it just trailed off a month ago, that
said, that's not up to me.

thanks
joel




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

[joel jaeggli]

On 9/30/15 6:46 PM, Paul Vixie wrote:
> 
> 
> John Levine wrote:
>>> It should be easy enough to create a local alias address for the purpose
>>> though.  "ifconfig lo inet6 add ::2 alias", salt to taste.
>>
>> Uh, no.  The *only* loopback address is ::1.  The rest of ::/8 is 
>> reserved.
> 
> right. just like 127.0.0.0/8 is reserved. yet i use 127.0.0.2, .3, and
> so on, all the time. i think it's probably safe to intrude on this
> "reservation" for this use case.

127.0.0.0/8 is in fact entirely reserved for loopbacks rfc 990 (class a
was great even if I don't remember it that well)

::1/128 is the rfc 4291 loopback

that doesn't mean we can't address that but:

1.  ::2 isn't infact reserved for that purpose

2. 4291 deprecated ip4 compatible v6 addresses and declared that space
unusuable which makes anything in ::/96  a bad example.

The "IPv4-Compatible IPv6 address" is deprecated by this document.
   The IANA should continue to list the address block containing these
   addresses at http://www.iana.org/assignments/ipv6-address-space as
   "Reserved by IETF" and not reassign it for any other purpose.  For
   example:

  ::/8Reserved by IETF[RFC3513]  [1]

   The IANA has added the following note and link to this address block.

  [5]  ::/96 was previously defined as the "IPv4-Compatible IPv6
   address" prefix.  This definition has been deprecated by RFC
   4291.

   The IANA has updated the references for the IPv6 Address Architecture
   in the IANA registries accordingly.


>> If you have a loopback software interface, you could set up a link
>> local address like fe80::1, but now your DNS software has to
>> understand link scoped addresses like fe80::1%lo.
>>
>> Having set up a DNS cache on my LAN using link local IPv6 addresses, I
>> can report that it doesn't work very well.
> 
> agreed.
> 
>> All in all, I think the advice to stick with IPv4 loopback addresses
>> is reasonable.  We can revisit this in 2050 when IPv4 is starting to
>> be phased out.
> 
> disagreed. ipv4 should die a-s-a-p. don't bring up any new ipv4 services
> unless you are sure they have to talk to the legacy internet. which is
> demonstrably not the case for localhost dns service.
> 
> now you don't see it:
> 
> root@family:/home/vixie # ifconfig lo0
> lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> inet 127.0.0.1 netmask 0xff00
> nd6 options=21
> 
> now you do:
> 
> root@family:/home/vixie # ifconfig lo0 inet6 ::2/128 alias
> root@family:/home/vixie # ifconfig lo0
> lo0: flags=8049 metric 0 mtu 16384
> options=63
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> inet 127.0.0.1 netmask 0xff00
> inet6 ::2 prefixlen 128
> nd6 options=21
> 
> ntpd is a grabby little thing:
> 
> root@family:/home/vixie # netstat -an | grep ::
> tcp6   0  0 ::1.465*.*LISTEN
> tcp6   0  0 ::1.587*.*LISTEN
> tcp6   0  0 ::1.25 *.*LISTEN
> tcp6   0  0 ::1.993*.*LISTEN
> tcp6   0  0 ::1.143*.*LISTEN
> tcp6   0  0 ::1.995*.*LISTEN
> tcp6   0  0 ::1.110*.*LISTEN
> udp6   0  0 ::2.123*.*
> udp6   0  0 fe80::1%lo0.123*.*
> udp6   0  0 ::1.123*.*
> udp6   0  0 fe80::2a0:98ff:f.123   *.*
> 
> i had to alter these lines of my ipfw configuration:
> 
> add passall from any to any via lo0
> add denyall from any to { ::1 or 127.0.0.0/8 }
> add denyip  from { ::1 or 127.0.0.0/8 } to any
> 
> they now read:
> 
> add passall from any to any via lo0
> add denyall from any to { ::1 or ::2 or 127.0.0.0/8 }
> add denyip  from { ::1 or ::2 or 127.0.0.0/8 } to any
> 
> i had to add a line to ntp.conf:
> 
> restrict -6 ::1
> restrict -6 ::2
> 
> noting, the other lines in that vicinity tell us things about
> 127.0.0.0/8 that the IETF might not know:
> 
> restrict 127.127.1.0
> 
> but anyway, it works:
> 
> root@family:/home/vixie # ntpq -p ::2
>  remote   refid  st t when poll reach   delay   offset 
> jitter
> ==
>  mm1.redbarn.org 108.61.194.853 u1   6410.2873.617  
> 0.075
>  ks.redbarn.org  208.75.88.4  3 u2   6411.171   -0.744  
> 0.000
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Ben Campbell's Discuss on draft-ietf-dnsop-root-loopback-04: (with DISCUSS and COMMENT)

[joel jaeggli]

On 9/30/15 4:08 PM, Paul Hoffman wrote:
> On 30 Sep 2015, at 15:32, Ben Campbell wrote:
> 
>> --
>> DISCUSS:
>> --
>>
>> This is just a process discuss:
>>
>> The IPR disclosure at http://datatracker.ietf.org/ipr/2539/ says that due
>> to the early state of the draft, license terms will be provided later.
>> Obviously the draft is beyond early stages now. Does it make sense to ask
>> for an update before progressing this draft?
> 
> That's a question for the IESG, not the DNSOP WG, correct?

The question for the  w.g. is are they aware of it?  the answer to that
is yes.

WRT to do they care care enough to withhold this document, I think we
have very little evidence for that.

> Having said that, it's not clear why the IESG would want to allow
> Verisign, or anyone else who says that they have a patent that they say
> they believe applies, to block progression of a document in the IETF.
> For an informational document such as this, maybe the damage of waiting
> months for a response is not a big deal, but doing so kinda sets a bad
> precedent for more timely standards track documents.
> 
>>
>>
>> --
>> COMMENT:
>> --
>>
>> -- section 1, paragraph 7: "Thus, recursive resolver software such as
>> BIND will not need to add
>>  much new functionality, but recursive resolver software such as
>>  Unbound will need to be able to talk to an authoritative server"
>>
>> It might be useful to mention the properties of BIND and Unbound that
>> make the difference.
> 
> We did that in the sentence preceding the one quoted. That is, the
> property is that BIND also contains an authoritative resolver, but
> Unbound does not.
> 
>>
>> -- 1, paragraph 8: "Because of the significant operational risks
>> described in this
>>  document, distributions of recursive DNS servers MUST NOT include
>>  configuration for the design described here."
>>
>> This made my day!
> 
> Glad to hear it! Others seemed to have chuckled over our disclaimer of
> originality in Section 7. If we can elicit as much laughter here as for
> an April 1 RFC, Warren and I have done our jobs.
> 
> --Paul Hoffman and Warren Kumari
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alissa Cooper's Yes on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[joel jaeggli]

On 8/31/15 1:04 PM, Alissa Cooper wrote:

> I agree with Alvaro and Stephen's comments. In particular, to my eye
> [tor-rendezvous] should be a normative reference given item #3 in Section
> 2. However, it seems more important to publish this document than to
> re-issue the last call to call out a new downref.

I'm not sure that I  agree that  this would require a downref were it
cited normatively. the citation is to a document maintained by the third
party not to a informational draft describing the specification that is
maintained by the third party. the tor project protocol specific meets
some reasonable definitions of an open standard.

That said this document is not a protocol specification, it is a
resource reservation which was my rational for allowing this to be
treated this as informational references. The requirement to specify dns
protocol behavior with respect to a resource is a requirement of the
6761 resource reservation and it might well be a reason to cite that
(which is cited already) but the current reference is essentially to the
expectations of the protocol (tor) whereas the requirement is imposed on
non(tor protocol) actors by the 6761 reservation.


> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[joel jaeggli]

On 8/21/15 7:28 PM, Barry Leiba wrote:
>> valid point, however with respect to 6761 the onion namespace
>> substantially predates the existence of 6761 or the consensus documented
>> there so I don't think the what if scenario is particularly helpful
> 
> Indeed, and Stephen pointed that out to me privately as well.  That
> was a mistake in my response to Stephen -- I blew that part.
> 
> Remember, here, that I'm abstaining *not* because I don't want this
> request to be honored, but because requesting these special TLDs in
> this manner doesn't scale.  The .onion request was originally bundled
> with half a dozen others, and was split from it for a reason.  As we
> start to process the other requests, there has to be a line in the
> sand.  Having everyone who has deployed some non-IETF thing that turns
> out to need a TLD reservation ask us to please intervene and reserve
> it for them isn't, I think, what 6761 was meant for, and doesn't
> scale.  That's really the issue for me.
> 
> In any case, my abstaining doesn't have any direct effect on this
> document.

yup, I agree. I am fine with that stance, i just want to make sure we
have a common view of events, I think that's very important as we
address the ongoing problem.

thanks
joel

>  I accept that there's IETF consensus for doing this.  By
> abstaining, I'm simply saying that I can't ballot "no objection", but
> that I won't stand in the way of rough consensus.  I do think it's
> best that we not belabor this further.  As the other ballots come in,
> we'll almost certainly approve this document, and, given the
> importance of Tor, that will be for the best.
> 
> Barry
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

[joel jaeggli]

On 8/21/15 2:40 PM, Barry Leiba wrote:
>> I'm pretty sure I'll be a yes ballot on this (after I re-read the
>> draft which I've not read for quite a while). And I don't expect
>> either of us to change our ballot, but that said, I hope you don't
>> mind explaining your ballot a little more since I'm not getting part
>> of your argument and that part could be relevant if/when other special
>> use name drafts are processed. (Or if/when someone tries to win the
>> race and first improve IETF handling of special-use names.)
> 
> And I see you are a "yes", and I certainly have no interest in trying
> to convince you or anyone to change or ballot a certain way.  I'm only
> expressing my own opinion here.
> 
> My point here is that there were always other ways of doing this
> besides using a made-up TLD, and it was always possible to use 6761 to
> reserve a name early on.

That's an argument that this is moral hazard territory, I think that's a
valid point, however with respect to 6761 the onion namespace
substantially predates the existence of 6761 or the consensus documented
there so I don't think the what if scenario is particularly helpful in
looking at the problem of this draft. The thinking of the IETF community
has evolved over time with the creation of  the registry and the
assignment of .local being a significant (and recent) milestone.

>  Neither of those paths were taken, which is
> where my characterisation of "squatting" came in.  It used to be
> thought of as safe, if not entirely legitimate, to do that, because
> only a relatively few things were valid TLDs.
>  
> Now that ICANN has opened up the TLD space, it has become a clear
> issue, and we're being asked -- and not because of work in the IETF --
> to retroactively protect this TLD from assignment to someone else by
> reserving it for a particular software project.  In general, I simply
> don't think we should be doing that.  In *this* case, I think doing it
> serves the public good sufficiently that I'll accept that we've been
> backed into it.  In the general case, I think we should send
> applicants to ICANN to make their case there.  That fits under this
> stipulation, from RFC 6761 Section 3:
> 
>Reservation of a Special-Use Domain Name is not a mechanism
>for circumventing normal domain name registration processes.
> 
> I know there are a number of other TLDs waiting for this same
> treatment, and, as I said, while I understand the need to proceed in
> this case, I think it would be a mistake to continue doing this for
> case after case of other such TLDs.  If we to do more of this, we
> should reserve one specific TLD for it (or use one we already have),
> and have the uses migrate to that TLD.

FWIW I think we have to address the problem of how to allow for
experimentation in a way the does not result in future problems like
this  (that could have been avoided); or result in inadvertent pressure
on the domain name system. But that's outside the scope (I hope) of this
draft.

> Barry
> 
>> On 21/08/15 19:37, Barry Leiba wrote:
>>> --
>>> COMMENT:
>>> --
>>>
>>> I believe the IETF shouldn't be involved with registering special-use
>>> TLDs for things that have been squatted on, and thus helping to
>>> circumvent ICANN's normal process.
>>
>> The above confuses me.
>>
>> Do ICANN have any process for allocating special-use names that will
>> not be used in the DNS? I am not aware of such but it may exist. I
>> am also not at all clear that I'd accept that ICANN ought be in that
>> particular business.
>>
>> Note: I am not saying what I think of, not asking what you think of,
>> ICANNs new gTLD programme, but for the sake of this discussion, let's
>> assume that programme is "normal";-) But that process is surely not
>> one that could be used for special-use names that are required by
>> protocols that require not using those names in DNS queries.
>>
>> Secondly, I don't get what you are saying you think about current IETF
>> consensus (i.e. RFC 6761). Are you saying that:
>>
>> a) you don't agree with 6761? or
>> b) that 6761 is fine but only for not-yet-deployed special-use names?
>>
>> If (a) I'm not sure that's our (IESG) role, and (b) seems highly
>> unlikely to be workable (if one assumes an I-D has to wend its way
>> through the process the special-use name will be deployed before IESG
>> evaluation). So maybe you mean something else?
>>
>>> I know there are a bunch of other
>>> such TLDs that people/organizations would have us snag for them, and I
>>> very much want to avoid that nasty iceberg, of which this is the tip.
>>
>> That's why I'm asking my questions above - I do think there's more work
>> to be done here amounting to some combination of improving 6761 and
>> figuring out how to properly handle the other queued-up strings.
>>
>> In passing I have to say that I don't agree there's 

Re: [DNSOP] what's in .alt, was Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[joel jaeggli]

I think this is a useful and interesting discussion. but it's anchored
in the .alt proposal which we should separate from the onion tld last
call I hope.

Thanks
joel

On 7/19/15 6:55 AM, John R Levine wrote:
>> so: offering someone a chance to register that a conflict exists does
>> not serve the purpose of advancing interoperability. that is, the
>> information "ONION.ALT exists, see http://whatever"; is useful, whereas
>> the information "ONION.ALT exists, see http://someplace and/or
>> http://someplace_else"; is not useful. this, to me, is what FCFS means.
> 
> Really, I get that.  But here's the two options:
> 
> A) registry says "ONION.ALT exists, see http://someplace and/or
> http://someplace_else";, you say hm, two different packages, I better
> look at both of them to see which one is installed on my computer.
> 
> B) registry says "ONION.ALT exists, see http://someplace";, you look at
> it and scratch your head when you realize it's not what's on your
> computer so you go do a Google search and eventually find
> http://someplace_else.
> 
> There is no C), since we don't control what software people write.  I
> don't understand why B) would be better for anyone.
> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[joel jaeggli]

On 7/18/15 12:16 AM, Ted Lemon wrote:
> On 07/17/2015 01:35 AM, David Conrad wrote:
>> To be honest, I doubt this. It assumes folks who are developing 
>> these non-DNS protocols know/care about what the IETF thinks.
> I suspect that more do than you think.   However, what they think 
> about the IETF is that we have a very heavyweight process, and it's 
> hard to get anything done here in a timely fashion.

Innovation is not something we should have any interest in gating. Not
only is that futile, but it's also wildly presumptive of our role in
the process.

We can however work to make it eaiser, both to bring work to the IETF and
so support it to responsible stewardship.

 If we want to avoid future instances of squatting, it behooves 
 us to
>>> avoid applying too much process friction onto documents of this 
>>> type.   Granted, it's hard to tell how much is too much, but this
>>> particular discussion was kicked off in November of 2013, and
>>> here it is July of 2015, and we are still talking about it. 
>>> That's a pretty heavy process.
>> I agree on the need for less friction, hence my interest in trying 
>> to find objective criteria. Lack of objective criteria pretty much
>>  guarantees the same sort of discussion and 'heavy process' you're
>>  complaining about.
> With all due respect, this is a classic mistake that geeks make: 
> thinking that there can be some objective criterion or set of 
> criteria that would make decisions simple.   The reality is that to 
> make criteria of this sort objective would require a solution to the 
> halting problem.   At which point the cold minds that sleep in the 
> space between the stars would awaken.   So really, for the sake of 
> humanity, I think it would be best to avoid going down this path.
> Er, that is, if resolving this discussion depends on finding some
> such objective criteria, we are never going to resolve it.
> 
> It's pretty clear that .onion in particular does satisfy the 
> non-objective criteria we currently have.
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Stability of identifiers (Was: Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[joel jaeggli]

On 7/17/15 7:13 AM, Stephane Bortzmeyer wrote:
> On Wed, Jul 15, 2015 at 06:17:54PM +,
>  Edward Lewis  wrote 
>  a message of 148 lines which said:
> 
>> URLs are nice for giving a reference, but there's still a need to curate
>> the data.  In particular, what if the torproject.org name registration
>> expires and is bought by someone else?
> 
> Nothing human is forever. What if the private organisation issuing
> DOIs collapse? What will happen of all the DOIs bought on the
> marketing-created assumption that it was stable?

good references are nice, but by their nature are largely outside of our
control. the best we can do in general is curate them.

if you read rfc 20, good luck trying to find a copy of USAS X3, 4-1968

> Or we should use only identifiers issued by organisations older than
> three centuries, on the assumption that they have demonstrated
> stability. A good example is ARKs (draft-kunze-ark) issued by the
> French National Library (prefix 12148), which was established in 1537
> AD meaning it is probably here to stay.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[joel jaeggli]

On 7/16/15 9:04 AM, Richard Barnes wrote:
> On Thu, Jul 16, 2015 at 12:44 AM, Joe Hildebrand  wrote:
>> On 15 Jul 2015, at 5:37, David Conrad wrote:
>>
>>> I try to be pragmatic. Given I do not believe that refusing to put ONION
>>> in the special names registry will stop the use of .ONION, the size of the
>>> installed base of TOR implementations, and the implications of the use of
>>> that string in certificates, I supporting moving ONION to the special names
>>> registry.  I really (really) wish there was more concrete, objective metrics
>>> (e.g., size of installed base or some such), but my gut feeling is that TOR
>>> is pretty well deployed and given the CAB Forum stuff, I see no particular
>>> reason to delay (after all, it's not like the deployed base of TOR is likely
>>> to get smaller).
>>
>>
>> I don't see any mention of the CAB Forum stuff in the draft.  Has anyone
>> done the analysis to see if CAB Forum members really will issue certs to
>> .onion addresses if we do this?  Do they issue certs for .example or .local
>> today?
> 
> There are at least a few CAs issuing for .onion right now, under the
> exceptions that are going to expire in a few months.  So I assume that
> these CAs will be interested in issuing if policy allows.
> 
> My understanding is that the basic requirement that CABF has is that a
> name either be clearly a valid DNS name or clearly *not* a valid DNS
> name.  (And in either case, that the applicant be able to demonstrate
> control.)  Right now, that's ambiguous.  Adding .onion to the RFC 6761
> registry would remove the ambiguity, since it would officially mark
> names under .onion as not DNS names.

I won't presume that we can tell the CAB Forum folks what they can do.

They've stated what they intend to do and it seems likely that the will
carry through with that.

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/

> --Ricahrd
> 
> 
> 
>> If certificate issuance is one of the key drivers for this work, there needs
>> to be information in the draft that shows that this approach will work.

I think there's a certain amount of moral hazard associated with being
extremely concerned about the conisderations arising from that. it may
be the case that they have a deadline, whether it gets added to the
registry or not should come down to the merit of the request and it's
congruence with how we run that registry.

>> --
>> Joe Hildebrand
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[joel jaeggli]

On 7/15/15 10:16 AM, Ted Lemon wrote:
>> I'm agreeing with Ted in that this application is insufficient.
> 
> Whoa there, cowboy!   I didn't say it was insufficient.   I proposed
> changes to the text that I think would result in it better expressing
> what I think was intended.

I can see some explanatory text getting added, I think this coming week
will likely be useful for feedback.

> And also, please don't call it an application.   It is an internet
> draft, which has passed working group last call, and is in IETF last
> call.   An application would be something that would be handled by the
> IESG, through the instrumentality of the IANA.

yup, wg document, proposed standard, 4 week ietf LC and all that.

dnsop would absolutely not be undertaking any work on the tor protocol.
It was clearly the appropriate place to handle  the problem posed by
this draft however.

> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[joel jaeggli]

On 7/16/15 6:44 AM, Warren Kumari wrote:
> On Thu, Jul 16, 2015 at 2:23 PM, Andrew Sullivan  
> wrote:
>> On Thu, Jul 16, 2015 at 01:30:03PM +0200, Warren Kumari wrote:
>>> We shouldn't be figuring out how useful a WG is by the number of
>>> documents published, but I don't think DNSOP is still where documents
>>> go to die...
>>
>> Agreed, but I also don't want to return to that bleak past where we
>> could never get anything published because it wasn't perfect, and then
>> the number of recycles got high enough that nobody would review, so
>> the draft wasn't perfect, and so on.

good enough is a substantiallly different  bar then good.

If there are things that folks really cannot live with I think that's
really what I want to know about.

> +very many much lots.
> 
> I just wanted to acknowledge the fact that our chairs are now getting
> documents pushed through
>
> W
> 
>> The editors will put their heads
>> together once more on the basis of the most recent comments.
>>
>> A
>>
>> --
>> Andrew Sullivan
>> a...@anvilwalrusden.com
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[joel jaeggli]

On 7/16/15 8:20 AM, Ted Lemon wrote:
> On 07/15/2015 02:45 PM, Francisco Obispo wrote:
>> It doesn’t feel right to me rewarding bad behavior. 
> I don't think it's fair to characterize this as "bad behavior."   It is
> completely unsurprising behaviour, as I explained in some detail in a
> previous message:
> http://www.ietf.org/mail-archive/web/dnsop/current/msg14924.html

If we find some of the situations we find ourselves in the present less
then desirable, we should produce incentives that make them less likely
to occur and which support experimental deployment.

We have proposals along those lines and I think we'll get better
outcomes if we continue to pursue that.

> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 2181 - a pathway forward.

[joel jaeggli]

On 7/10/15 9:06 AM, Suzanne Woolf wrote:
> Bill,
> 
> On Jul 10, 2015, at 9:38 AM, Olafur Gudmundsson 
> wrote:
> 
>> Question: What sections of 2181 do you see the need to update?
> 
> This seems to be the critical question to your chairs and our AD as
> well.
> 
> If I understand it correctly, your proposed document roadmap has us
> putting eight documents through the process as standards-track RFCs
> with no change in substance from RFC 2181, so we can then put three
> more documents through the process with new content. This seems like
> a very process-heavy way to update 2181.

It does,

Also there are  4035, 2535, 4343, 4033, 4034, 5452   which update
respective portions of 2181 so breaking apart 2181 into individual
pieces from the outset means incorporating those updates (fine I guess)
but then you're operating on those drafts; or walking back those changes
which I doubt is your intent.

This is a foggy recollection but I'll recount it here, by way of
communicating my own thoughts.

When Bill asked me at nanog what I though of multiple 2181 changes. I
proffered the opinion that. given that 2181 is several topics (7 I
think) it would be best if each proposed update to a topic taken on in
2181 were to be a seperate draft so that could be discussed on their
invidual merits rather than as a package of changes to 2181. 4343 and
5452 I would treat as precident  for that.

that is not a call imho for splitting appart 2181 first and then
proposing changes. if I was interpreted at any time as proposing that
I'm sorry.

> It's also hard to commit to obsoleting 2181 in eight separate steps
> without seeing the proposed updated content will be, or knowing
> whether it will get to consensus.
> 
> Could you describe the substance of what you think needs to be
> changed? If the WG wants to do the work, we can manage the process
> machinery accordingly.
> 
> 
> thanks, Suzanne
> 
> 
> 
> 
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Problem with CLASS

[joel jaeggli]

On 7/6/15 7:25 AM, manning wrote:
> I still need to catch up on the full weekends activity, but I’d like to 
> suggest that, like the
> v4/v6 transition, it may be time to consider revisiting the DNS protocols.  
> Not that there would
> ever be a DNS EMP, wiping our all legacy code, but perhaps a phased migration 
> to DNSv2 and a 
> shim to ensure backwards compatibility.   In such a case, it might be 
> reasonable to “fix” ordering
> (among many other things).

I would hope that offers to tear the temple down would come with a
proposal for the erection of a new edifice, albiet maybe not here.

> Or we can continue to put bandaids over the DNS festering wounds.

This is dnsop, addressing the condition of current patient, rather than
euthanizing it, is the remit. We do the later somewhere else.

> manning
> bmann...@karoshi.com
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
> 
> 
> 
> On 6July2015Monday, at 6:59, Edward Lewis  wrote:
> 
>> (Having quickly scanned through the thread to catch up.)
>>
>> CLASS has been problematic since the start.  The first "mistake" made was
>> encoding the CLASS field after the OWNER NAME field in a resource record.
>> This meant that all domain names have to be encoded and treated the same
>> regardless of class, removing an important functionality that would have
>> encouraged better development of CLASS concepts.
>>
>> Had the CLASS field come before OWNER NAME, I believe that its history
>> would be different.  I.e., it would have been used and not ignored.  Much
>> as message compression, there was a time when it was proposed and used,
>> then it went through an era where it was assumed/forgotten before once
>> again becoming an issue during the latter phases of DNSSEC development.
>> The result of that historical path was two sets of intertwined RFC
>> revisions differing on the topic before finally being discovered, if I
>> recall correctly, when the unknown types RFC (3597, see section 4) was
>> developed.  What I mean to say here is that over the decades, the
>> collection of volunteers that made up DNS WG, DNSSEC WG, DNSIND WG, DNSEXT
>> WG, and this one haven't consistently applied the same frame of reference
>> to the protocol.
>>
>> Unless we wiped all DNS code from existence, I don't see how we could ever
>> engineer a path to a "Clarifications of the CLASS" in the DNS protocol.
>> Unlike other loosely defined items in STD 13, CLASS was so poorly formed I
>> can't see saving it past current use.
>>
>> I wasn't aware of the mentioned (in the thread) effort to use a different
>> CLASS for IDN, but the idea had come to me (as in 'across my desk' from
>> someone else) a long time ago too.  It wasn't apparent that it could even
>> work given the ordering of the fields in the resource record.
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Some distinctions and a request - Have some class?

[joel jaeggli]

On 7/3/15 7:01 AM, Warren Kumari wrote:
> On Fri, Jul 3, 2015 at 9:43 AM, manning  wrote:
>> Actually, there IS an escape method already defined.  We just don’t use it 
>> much these days.
>> It’s called  “class”
>>
>> There is no reason these alternate namespaces should sit in the IN class.  
>> they could/should be in their
>> own class, like the old CHAOS protocols.   So  a class  “ONION” or “P2P” 
>> would work out very nicely.
> 
> Yup, but the problem is that people want to be able to enter the
> alternate namespace names into existing applications (like browsers,
> ssh, etc), just like a "normal" DNS name. They want to be able to
> email links around (like https://facebookcorewwwi.onion/ ) and have
> others click on them, etc.
> 
> There is no way that I know of to tell e.g Safari to look this up in a
> different class... and, even if there were, they would *still* leak,
> because people are lazy...

well before we just started  typing stuff in and let heuristics and
search engines divine what we meant, we had urns. I will  not suggest
that we're going back there UI wise but the heuristics can get  more
expressive. this can be largely a UI issue today in chrome, if I want to
send my query to a particular application e.g. wolfram alpha I do "= "
and proceed.

UI grooming in no way prevents leakage. nor does it preclude you from
having to divine the intentions of the user.

> W
> 
>>
>> After all it’s the Domain Name System.  (can comprehend names in multiple 
>> domains, not just the Internet)
>>
>> manning
>> bmann...@karoshi.com
>> PO Box 12317
>> Marina del Rey, CA 90295
>> 310.322.8102
>>
>>
>>
>> On 2July2015Thursday, at 20:56, manning  wrote:
>>
>>>
>>> On 2July2015Thursday, at 18:21, Robert Edmonds  wrote:
>>>
 manning wrote:
> There in lies the problem.  These systems have no way to disambiguate 
> a local v. global scope.
>It seems like the obvious solution is to ensure that these nodes 
> do NOT have global scope, i.e. No connection to the Internets
>and no way to attempt DNS resolution.   Or they need to ensure 
> that DNS resolution occurs after every other “name lookup technology”
>which is not global in scope.

 I don't understand this point.  Since Onion hidden service names are
 based on hashes derived from public keys surely they're globally scoped
 (barring hash collisions)?

 --
 Robert Edmonds
>>>
>>> If they _are_ globally scoped,  what part of the local system decides which 
>>> namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the 
>>> DECnetV, the IXP, or the DNS…
>>> where is search order determined?  Does first match in any namespace win?  
>>> What is the tiebreaker when there are label collisions between namespaces?
>>>
>>>
>>> /bill
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-edns-client-subnet-01.txt

[joel jaeggli]

I would think at this point that this draft would be ready to go
someplace. Feview of the February discussion that led to the
changes/reversion here was instructive.

Thanks
joel

On 5/26/15 2:07 PM, Warren Kumari wrote:
> This version incorporates a *large* number of comments received, and
> also reverts the changes made to SCOPE / SOURCE NETMASK, making this
> document describe how this has actually been implemented in practice.
> 
> It also clarifies that you cannot hand NXDOMAIN to some clients and
> not others, some new text describing the birthday attack mitigations,
> whitelisting some clients.
> 
> W
> 
> 
> -00 to -01 (IETF)
> o  Made the document describe how things are actually
> implmented now. This makes the document be more of a "this is how
> we are doing things, this provides information on that". There
> may be a future document that describes additional funcationality.
> o NETMASK was not a good desription, changed to PREFIX-LENGTH
> (Jinmei, others). Stole most of the definition for prefix length
> from RFC4291.
> o Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include
> IPv6 (Tatuya Jinmei)
> o Comment that ECS cannot be used to hand NXDOMAIN to some clients
> and not others, primarily because of interoperability issues.
> (Tatuya Jinmei)
> o Added text explaining that implmentations need to document thier
> behavior with overlapping networks.
> o Soften "optimized reply" language. (Andrew Sullivan).
> o Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0)
> o Some more grammar / working cleanups.
> o Replaced a whole heap of occurances of "edns-client-subnet" with
> "ECS" for readability. (John Dickinson)
> o More clearly describe the process from the point of view of each
> type of nameserver. (John Dickinson)
> o Birthday attack still possible if attacker floods with ECS-less
> responses. (Yuri Schaeffer)
> o Added some open issues directly to the text.
> 
> On Tue, May 26, 2015 at 4:49 PM,   wrote:
>>
>> A new version of I-D, draft-ietf-dnsop-edns-client-subnet-01.txt
>> has been successfully submitted by Warren Kumari and posted to the
>> IETF repository.
>>
>> Name:   draft-ietf-dnsop-edns-client-subnet
>> Revision:   01
>> Title:  Client Subnet in DNS Querys
>> Document date:  2015-05-26
>> Group:  dnsop
>> Pages:  26
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-edns-client-subnet-01.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/
>> Htmlized:   
>> https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-01
>> Diff:   
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-client-subnet-01
>>
>> Abstract:
>>This draft defines an EDNS0 extension to carry information about the
>>network that originated a DNS query, and the network for which the
>>subsequent response can be cached.
>>
>> IESG Note
>>
>>[RFC Editor: Please remove this note prior to publication ]
>>
>>This informational document describes an existing, implemented and
>>deployed system.  A subset of the operators using this is at
>>http://www.afasterinternet.com/participants.htm . The authors believe
>>that it is better to document this system (even if not everyone
>>agrees with the concept) than leave it undocumented and proprietary.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Rejecting Practice for Theory (was Re: relax the requirement for PTR records?)

[joel jaeggli]

On 5/14/15 6:48 PM, Ted Lemon wrote:
> On May 14, 2015, at 2:52 PM, joel jaeggli  wrote:
>> It would be super-annoying for delegations to nameservers that do
>> not exist to occur for these, because not only will there be
>> trillions of them but I get to wait for them to time out, so
>> delegation to cpe for example seems like a non-starter.
> 
> It would help if you would consider the existing body of work that's
> been discussed on this very topic before drawing unwarranted
> conclusions.  

managing on behalf of a customer and automatically delegating are rather
different I agree.

I am aware of

https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-02

which is where homenet seems to be.

I look somewhat unfavorably on the act of automatically populating zones
 on a customers behalf upstream of their cpe for the same reason I not
so interested in autmatically injecting host-id signaling, or in fact
from dynmic dns updates using host-id. if the data has meaning it has
privacy implications and that involves consent and if it doesn't then
I'm not sure what utility it has over wildcard records.

>  I alluded to it in an earlier message when I said that
> the delegation should be automatically negotiated.   There's work on
> this going on in homenet, and I also wrote a draft for the dhc
> working group before I became an AD and all work stopped.   I'm sure
> you can still find it in the archive.   I suspect that particular
> proposal has become moot as a result of work that occurred in the
> intervening years, but it could be revived if necessary.
> 
> That was a long way of saying that I agree with you that delegations
> shouldn't dangle, but disagree with you that this means delegations
> are a bad idea.   Dangling delegations are a bad idea!   :) 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Post-Interim considering the 4 proposals

[joel jaeggli]

On 5/15/15 8:48 AM, str4d wrote:
> Hugo Maxwell Connery wrote:
>> Hi,
> 



>> I believe that the grothoff and appelbaum drafts are the first 
>> cases of testing the mechanism for the use of the special names 
>> registry.  I also assume that the registry was created to be used 
>> for more than its initial propulation with things like .local and 
>> .invalid.

.local  is really the first (poster child) case. these proposals are
really the second.


>> Additionally, I agree with some members of the DNSOP community
>> that names matter.  "my-product.invalid" is not a good way to start
>> a venture.  Should .alt be available "my-product.alt" is far 
>> preferrable as confirmed by a member of the I2P community both at 
>> the Interim meeting and in later mailing list communication 
>> (str4d).

we shouldn't be in the business of setting up incentives for a behavior
we want to encourage by making them look like penalties.

> You are right in saying that .TLD.alt is preferable to .TLD.invalid
> from a user's perspective. But that does not automatically imply that
> .TLD.alt is preferable to .TLD.

agree.

I would expect that an future allocations of the form .tld would account
for the availability of alternative methods.

> What I said was, if I were writing a new I2P-like application
> requiring a non-DNS .TLD _after_ .alt had been accepted and publicized
> as the accepted way of establishing non-DNS domain structures, then I
> would use .TLD.alt instead of .TLD, because it would be far less
> hassle (to get it reserved, as I expect having .alt would enable IETF
> to more easily evaluate and accept reservations under it) for not much
> additional work educating users. I would of course _prefer_ to use
> .TLD on its own, but as an app developer I would take the path of
> least resistance. Right now, that is to register .TLD under RFC 6761.
> If .alt is accepted, it would be that.
> 
>> Indeed, that person claims that .alt would have been used if it
>> was both available and understood.
> 
> I said that I2P would _probably_ have used it, had .alt existed at the
> time as the accepted way of establishing non-DNS domain structures.
> However, I want to ensure that these two points are abundantly clear:
> 
> * I am not one of the original developers of I2P. I was not involved
> with I2P until years after .i2p had already been chosen and
> established, so I cannot speak for what they would actually have done.
> 
> * Even if .alt does become available, I2P will not be transitioning to
> it. (This has already been thoroughly discussed previously on this ML
> around the P2PNames draft in general, and the .onion and .i2p TLDs in
> particular.)

The question of what to do about the existing practice seems orthogional
to the question of what to do about future ones.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Rejecting Practice for Theory (was Re: relax the requirement for PTR records?)

[joel jaeggli]

On 5/14/15 11:25 AM, Paul Vixie wrote:
> 
> 
> Ted Lemon wrote:
>> On May 14, 2015, at 4:15 AM, Shane Kerr  wrote:
>>> The main argument seems to be that because e-mail uses reverse DNS as
>>> input into spam detection, it is important. The argument proceeds to
>>> then say that we want every computer on the Internet to run an SMTP
>>> server, so every computer needs a PTR record.

...

> so, my hope is that we could recommend against machine-generated PTR's,
> and recommend in favour of PTR delegation when a customer requests it,
> all while understanding that ISP's will do whatever they want after they
> see whatever recommendations we make.
> 

I would vastly prefer to get a signed nxdomain from an isp then some BS
machine generated record...

It would be super-annoying for delegations to nameservers that do not
exist to occur for these, because not only will there be trillions of
them but I get to wait for them to time out, so delegation to cpe for
example seems like a non-starter.



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Interim Meeting on Special Names and RFC 6761

[joel jaeggli]

On 4/14/15 6:52 PM, Ted Lemon wrote:
> On Apr 14, 2015, at 4:02 PM, Warren Kumari  wrote:
>> Seeing as Interims are supposed to be announced >=30 days in the
>> future I'm guessing not the 14th of May...
> 
> If this is a virtual interim two weeks is sufficient.   I thought this _was_ 
> a virtual interim.   Not so?

It is.

> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Interim Meeting on Special Names and RFC 6761

[joel jaeggli]

On 4/8/15 7:48 PM, str4d wrote:
> Tim Wicinski wrote:
>> All,
> 
>> As we announced in Dallas, we’ve decided to have a separate
>> meeting on Special Names and RFC 6761 topics.   We're planning on 
>> scheduling this the week of April 13th; with Thursday, April 16th 
>> as an initial choice.
> 
> Thanks for planning this :)

Dates are actively being looked at, the development of the topic is
taking longer than was anticipated prior to the meeting.

I'm not the chair, but I think we can be assured that there will be an
update soonish and proposed dates will be outside the notification window.

> As someone who has an interest in this particular meeting but has
> never watched or participated in IETF or DNSOP meetings before, how
> will this meeting be conducted? How do people choose to watch or
> participate? The only information I can find that might be related is
> about IEFT interim meetings [0], but there is no scheduled interim
> meeting for this topic [1]. Is there another mailing list or website I
> should be following for more information?
> 
> [0] https://www.ietf.org/meeting/interim-meetings.html
> [1] https://www.ietf.org/meeting/interim.html
> 
> 
>> If folks have any preference for a date, or conflicts with this 
>> one, please let us know. We plan on having the meeting at 2pm UTC, 
>> which would translate to 4pm CEST, 10am EST, 7am PST, and 11pm
>> JST. Other suggestions are also welcome-- no time is perfect for 
>> everyone but we’re trying to accommodate the widest range of 
>> participants that we can.
> 
> I haven't seen any further communication (on this ML) about the
> meeting, so I assume the specified date and time is still the case?
> Friday would work better for me than Thursday (which I can't do at 2pm
> UTC), but I'm just one person.
> 
> 
>> We’re working on a detailed agenda but the initial plan is to 
>> attempt to address both specific drafts and some of the 
>> larger-scale issues we’re seeing around the administration of the 
>> special-use domain names registry.
> 
> Sounds good. I look forward to seeing these issues nailed down.
> 
> str4d
> 
> 
>> thanks Tim/Suzanne
> 
>> ___ DNSOP mailing list
>>  DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[joel jaeggli]

On 3/17/15 8:11 PM, Andrew Sullivan wrote:
> On Tue, Mar 17, 2015 at 12:59:25PM -0400, Richard Barnes wrote:

 If an application does not implement tor, and is not tor aware, it
 _will_ do a DNS lookup. You can't really go ask the world to stop
 doing that. You need to deal with that fact.
>>>
>>
>> The entire point of the special use domains registry is to tell general
>> clients how to behave with regard to special-use names.  It exists
>> precisely to tell the world the DNS names for which they should not do
>> lookups, because they require different handling.
> 
> Actually, my understanding is that the point of the special use
> domains registry is to create a repository for applications so that,
> _if_ they are looking at names in domain name slots and trying to do
> something sensible, they know where to look to learn about those
> sensible things.
> 
> There is no way for a document to specify, "Don't look stuff up in the
> DNS."  If we had a reliable way to make that rule, AS112 wouldn't have
> been necessary.  I think there's nothing wrong with the document
> saying that you _shouldn't_ look them up, because they're promised not
> to give you a response anyway so it's just pollution traffic.  But do
> not delude yourself into thinking that adding stuff to the special
> names registry will do anything to prevent leaking.  It will not.

it certainly cannot prevent leakage from resolvers unaware of the new
reservation.

something like  the .alt probably might once iplemented, do so for
future spaces assuming it were used.

> A
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] revisiting outstanding dicusses for 6304bis

[joel jaeggli]

On 2/24/15 12:28 PM, Andrew Sullivan wrote:
> On Tue, Feb 24, 2015 at 12:06:06PM -0800, Joel Jaeggli wrote:
>> Should we consider recommendations with respect to treatment of logging or 
>> storage of queries or the extent to which such queries should be protected? 
>>
> 
> IMO, No.  The text as it stands says, "This could result in logs."
> There are lots of operational reasons to log, and the fact that your
> leaking queries could result in information about your system being
> made public is a reason _not to leak_ in the first place.  That has
> nothing to do with operating AS112, which is infrastructure to sink
> traffic that never should have made it to the Net in the first place.

Ok thanks, this echos my assumptions , but I don't consider myself an
arbiter to taste, at least absence of validation.

> Best regards,
> 
> A
> 
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] revisiting outstanding dicusses for 6304bis

[Joel Jaeggli]

Working group, 

I would direct your attention to the current discuss, here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc6304bis/ballot/

Should we consider recommendations with respect to treatment of logging or 
storage of queries or the extent to which such queries should be protected? 

Thanks
Joel

Sent from my iPhone

> On Feb 23, 2015, at 08:25, Kathleen Moriarty 
>  wrote:
> 
> 
> 
>> On Mon, Feb 23, 2015 at 10:21 AM, Paul Hoffman  wrote:
>> On Feb 23, 2015, at 7:13 AM, Kathleen Moriarty 
>>  wrote:
>> > Thanks for bringing this to my attention.  The updated text points out the 
>> > risk, but it would have been nice seeing it phrased in a way to encourage 
>> > mitigation of that risk (recommend not to log).  It'd easier to attack a 
>> > system and gain access to logs than to observe session traffic.
>> 
>> AS112 operators do so for the public benefit. There are very good 
>> operational reasons why they *should* log, in order to help find bugs and to 
>> provide better service. You are asking that the very tiny chance of a 
>> privacy breach should trump that operational benefit.
> 
> As an FYI - I wouldn't put this in the privacy bucket, but rather security as 
> it reveals information about a network that could be used in future attacks 
> against the organization leaking their data. 
>> 
>> The mention of the privacy issue with logging is sufficient, and going 
>> further would have negative consequences to the operations of this service.
> 
> Mitigating the risks could be helpful and might mean protecting access to 
> logs in cases where logs must be generated. 
> 
> Thanks,
> Kathleen
>> 
>> --Paul Hoffman
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

[joel jaeggli]

On 11/5/14 12:50 PM, Paul Vixie wrote:
> 
> 
>> Andrew Sullivan 
>> Wednesday, November 05, 2014 10:50 AM
>> On Wed, Nov 05, 2014 at 10:19:59AM -0800, 神明達哉 wrote:
>>> https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06
>> ...
>> ... I believed I had watered down the draft so thoroughly that it
>> would be impossible for anyone to disagree with it. I was evidently
>> wrong. If we're going to bring that thing back up (in any sense you
>> like), then I think it needs to get a spine. Perhaps also my
>> willingness to try to find consensus has declined in the intervening
>> years: I just don't think there _is_ a consensus on this.
> the lack of consensus means it can't be a proposed standard, not that it
> can't be an FYI, BCP or similar, right?

BCP requires consensus after a fashion very similar to a standards track
document.

something with no-consensus basis would probably go to the ISE. Some
that people do not oppose publication of even if they disagree with it
might be informational.

but this is all jail-house lawyering, if the w.g. can't build a
consensus then it doesn't advance as a w.g. document.

> 
> the fact of the network is, without a PTR you will have a hard time
> originating TCP/25. we should say that.
> 
> another fact is, not everyone who should be able to (non-maliciously)
> access your web service will have a PTR. we should say that, too.
> 
> those aren't opinions and they shouldn't be controversial.
> 
> -- 
> Paul Vixie
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Anycast and DNS questions

[joel jaeggli]

On 9/3/14 10:01 AM, David Conrad wrote:
> Hi,
> 
> On Sep 3, 2014, at 8:42 AM, Guangqing Deng 
> wrote:
>> From RFC1034 section 4.1, it seems that the way used for improving
>> the redundancy and resilience of DNS system is to increase DNS
>> servers. I agree that for the performance of the DNS system, the
>> redundancy and resilience are the first goal and low latency is the
>> second goal. Usually, the first goal mainly depends on the DNS
>> server deployment policy (such as the total number and geographical
>> distribution of DNS severs) and the second goal relates to not only
>> the DNS server deployment policy but also the method used for DNS
>> clients selecting the best DNS server like any cast.

anycast is not a selection mechanism employed by a client. it is the
network that determines the catchment area served by a given anycast
instance.

> Careful here.
> 
> Anycast improves redundancy/resiliency for the system as a whole.  As
> typically deployed, it may not improve redundancy/resiliency for a
> single client.  For example, if a DNS server instance in an anycast
> cloud is no longer responding to DNS queries due to a DoS but the
> routing announcement of that instance is not pulled down, the clients
> topologically nearest that instance will not see improved
> redundancy/resiliency — they’ll not see any responses.
> 
> Anycast may or may not improve latency — it depends on the routing
> system. If the “nearest” instance network topologically to a set of
> clients happens to be on the other planet, latency will not be
> improved for those clients.
> 
> Anycast is a very blunt tool. It can help improve
> redundancy/resiliency and latency if properly deployed, constantly
> monitored, and maintained, but it is very important to understand its
> limitations and implications.
> 
> Regards, -drc
> 
> 
> 
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (Child To Parent Synchronization in DNS) to Proposed Standard

[joel jaeggli]

On 8/8/14 8:16 AM, The IESG wrote:
> 
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document:
> - 'Child To Parent Synchronization in DNS'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2014-08-22. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

FYI,

I requested that this last call be rerun due to US incorrectly assigning
the status of informational and therefore a 2 week duration on the original.

The importance of feedback is underscored by it's intended standards
track status.

Thank you
Joel

> Abstract
> 
> 
>This document specifies how a child zone in the DNS can publish a
>record to indicate to a parental agent that it may copy and process
>certain records from the child zone.  The existence of and value
>change of the record may be monitored by a parental agent and acted
>on as appropriate.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] another AS112 document question

[joel jaeggli]

On 5/22/14, 10:05 AM, Joe Abley wrote:
> William and I have heard the suggestion that we should add 112 to
> this registry. A convenient mechanism for doing so would be to add
> some IANA considerations to rfc6304bis.

start from first principles.  the resource holder is the DNS-OARC which
has a street address you and  I recognize. if the OARC wan't to assign
the resource to IANA they can inidicate that, we can then direct iana to
manage it as part of the registry via a standards action.


> 7249 is not particularly clear on what "special" means. AS 112 is not
> special from a protocol perspective; it's just another origination
> point for prefixes on the Internet, and in that sense is the same as
> AS 701, etc.

Special I interpret as process by which the registry is managed
directing iana to add the resource to the registry, e.g. the process
defines them as special, as opposed to ordinary resource holders in the
registry system.

> On the other hand, AS 112 *is* special in the sense that it
> corresponds to a specific architecture service that has been
> described in the IETF, and one which is not controlled operationally
> by any single entity, and AS 112 really shouldn't be used for
> anything else.

though in this particular case there is a resource holder even if that
resource holder is an informalry constructed entity.

> So, same basic question as before: given that rfc6304bis is already
> in wglc, do we think it's worthwhile adding a sentence to the text to
> request the IANA to add 112 to the "Special-Purpose AS Numbers"
> registry?
> 
> 
> Joe ___ DNSOP mailing
> list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)

[joel jaeggli]

On 5/19/14, 1:09 PM, John Heidemann wrote:
> 
> Folks,
> 
> I believe consensus was that dnsop needs a problem statement about DNS
> privacy before we explore possible solutions.

If I were to speculate on the basis of the dicussion here and in the
DNSE bof the solution space involves signficant if maybe not dramatic
architecture changes.

I would be happy to support exploration of the problem here and
documents of an according nature, but I imagine us chartering it as a
standalone activity.

> Stephane's draft-bortzmeyer-dnsop-dns-privacy seems like a very good start
> to this problem statement.  Are there plans to discuss this draft at
> IETF90 in Toronto?
> 
> I sent him some detailed comments out-of-band, but one question for the
> list:  what do we call the parts of the DNS resolver hierarchy?
> 
> draft-bortzmeyer-dnsop-dns-privacy-02 defines and uses the terms
> (1) "stub resolver",
> (2) "resolver" and
> (3) "name server"
> 
> and also 
> (2.5) a forwarding DNS resolver/server that is beyond the first-hop
> recursive resolver/server but not authoritative.
> 
> 
> for the things that
> (1) initiates queries, 
> (2) handle recursive resolution,
> (3) reply with authoritative responses.
> 
> 
> The short version is:
> 
> I recommend against use of resolver without an adjective for (2). 
> 
> Prior RFCs do not have consensus about what to use (both recursive resolver 
> and
> recursive name server appear).  Personally I'd go with "recursive
> resolver".  Does the list have other recommendations?
> 
> 
> 
> The tl;dr version is below:
> 
> I looked over many (but certainly not all) existing RFCs, and there is
> some variation in terminology:
> 
> RFC-1035 (the original DNS spec):
> (1) stub resolver
> (2) recursive server
> (3) no specific term (!)... it does talk about "foreign name servers"
> and "masters" and "authoritative data", but not authoritative servers
> 
> RFC-1996 (DNS notify):
> (1) (not used)
> (2) (not used)
> (3) authoritative server
> 
> RFC-1999 (EDNS):
> none
> 
> RFC-3833 (DNS threats) uses
> (1) stub resolver
> (2) recursive name server
> (3) authoritative name servers
> 
> RFC-4033 and 4035 (DNSsec) use:
> (1) stub resolver
> (2) recursive name server
> (3) authoritative name servers
> 
> RFC-4871 (DKIM):
> uses only 
> (2) recursive name server
> 
> RFC-5966 (DNS over TCP):
> (1) stub resolver
> (2) recursive server (or forwarder)
> (3) authoritative server
> 
> RFC-6891 (ENDS(0)):
> (1) stub resolver
> (2) recursive resolver AND caching resolver
> (3) authoritative server
> 
> 
> 
> 
> Back to 
> 
> draft-bortzmeyer-dnsop-dns-privacy
> 
> My recommendation for terms is:
> 
> (1) stub resolver
> (2) recursive resolver
> (2.5) forwarding resolver OR maybe caching intermediate resolver
> (3) authoritative nameserver (or authoritative name-server)
> 
> Based on these observations:
> 
> - "resolver" without an adjective for (2) risks ambiguity
> 
> - recursive resolver vs. recursive server for (2) seem to depend on if
>   you're approaching the problem from the end-user or the providers
>   point of view.  The challenge is that (2) is both a client AND server,
>   leading to inconsistency.
> 
> Just a suggestion,
>-John Heidemann
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft new charter

[joel jaeggli]

On 4/7/14, 9:40 AM, Edward Lewis wrote:
> This charter seems to fly in the fase of the traditional IETF charter
> style, wherein a WG was deemed to have a set end point.

that's not entirely uncommon in ops charters. for better or worse
operations (of dns, ipv6, multicast, global routing etc)  doesn't just
end when a working group as cleared it current milestones.




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft new charter

[joel jaeggli]

On 4/6/14, 4:25 PM, Tim Wicinski wrote:
> (catching up, and I'll jump into the middle of things)
> 
> On 4/4/14, 4:59 AM, Stephane Bortzmeyer wrote:
>> On Thu, Apr 03, 2014 at 05:39:58PM -0400,
>>   Suzanne Woolf  wrote
>>   a message of 69 lines which said:
>>
>>> 4. Publish documents on extensions or protocol maintenance to the DNS
>>> Protocol, with a focus on the operational impacts of
>>> such changes. Act as clearinghouse for discussion or provide
>>> advice to ADs
>>> and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record
>>> synthesis, or other mechanics of extending DNS to support other
>>> applications.
>> Do we all agree that it may cover, in the future, the work which is
>> currently discussed on the dns-privacy mailing list?
> 
> Short Answer: yes. Long Answer: if what comes out is a new protocol or a
> major spin of the protocol, the idea is to delegate that to a new
> working group.

As with the rapid spinup of dnssd I think we can be confident that the
internet area remains the right place and has the will to do new DNS
work, and we can and should address the undertaking of new protocol work
through that channel.

> The idea is to keep this specifically vague that allows new things that
> come up to be addressed, rather than being constrained by the charter.
>>> 6. Publish documents that attempt to better define the overlapping
>>> area among the public DNS root, DNS-like names as used in local
>>> or restricted
>>> naming scopes, and the 'special names' registry that IETF
>>> manages, and how they will interact moving forward.  Work in a
>>> liaison capacity to ICANN to assist in this.
>> I strongly dislike "the public DNS root" as if there were only one
>> (technically, any root is a root and, for dnsop, it does not matter if
>> it is the USG root or any other, the DNS operational issues are the
>> same) and I dislike even more "DNS-like names", which seems to imply
>> there are inferior names. www.foobar.local is a domain name, even if
>> it is not resolved through the DNS.
>>
>> I suggest: Publish documents that attempt to better define the
>> overlapping area among the DNS and other resolution protocols which
>> use domain names (and may have gateways to the DNS), especially in the
>> context of the 'special names' registry that IETF manages (RFC 6761).
>>
>>
> This isn't a bad option, but this whole line item is a giant ball of
> pain but something we've been asked to help facilitate.   We have some
> ways to go it seems.

from my vantage point documenting the attracive nuisance that exists
today is one problem.  what to do about the existing problems is
another. how to allow for future inovation without tha same consequences
as before is the third.

> tim
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Changes to Charter

[joel jaeggli]

On 3/25/14, 8:39 AM, Tim Wicinski wrote:
> 
> 
> On 3/24/14, 1:48 PM, joel jaeggli wrote:
>> On 3/19/14, 12:42 PM, Tim Wicinski wrote:
>>>
>>> 5. Address possible minor changes or extensions to the DNS Protocol,
>>> initially with a focus on the operational impacts of these changes. Act
>>> as clearinghouse or providing advice to ADs and other WGs on EDNS0
>>> options, new RRTYPEs, record synthesis, or other mechanics of  extending
>>> DNS to support other applications.
>>
>> I fell like this is intended to allow work on issues related to the
>> root/tld registration but without being explicit. I'm a little on the
>> fence with respect to how explicit we want to but I think we should
>> actually call it out.
>>
> 
> We were trying to be explicitly vague, or vaguely explicit.  I was
> thinking we could say something like "such as root/tld conflicts or
> namespace or application space conflicts".
> 

if I had to channel my other colleagues on the IESG it's probably
important enough to warrant it's own bullet. I will ultimately get my
own chance to whittle at the text so it's just a suggestion.






signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Changes to Charter

[joel jaeggli]

On 3/19/14, 12:42 PM, Tim Wicinski wrote:
> 
> Hello
> 
> This is a conversation I've scheduled a few times and I did poor time
> mangement.  After some discussion we're proposing adding two items to
> the DNSOP charter:
> 
> ---
> 
> 5. Address possible minor changes or extensions to the DNS Protocol,
> initially with a focus on the operational impacts of these changes. Act
> as clearinghouse or providing advice to ADs and other WGs on EDNS0
> options, new RRTYPEs, record synthesis, or other mechanics of  extending
> DNS to support other applications.

I fell like this is intended to allow work on issues related to the
root/tld registration but without being explicit. I'm a little on the
fence with respect to how explicit we want to but I think we should
actually call it out.

> 6.  Publish documents which address DNS-related issues, by identifying
> and documenting the problem space around the issue. The group will then
> discuss these issues and decide if which group should address the
> solution space.
> 
> --
> 
> We welcome your feedback either on the items, the wording, or anything
> you wish to comment on.
> 
> thanks
> 
> tim
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] on the subject of dnse

[joel jaeggli]

https://twitter.com/enginonder/status/446819815106576384/photo/1



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] dnse related docs.

[joel jaeggli]

On 3/5/14, 9:16 AM, Carsten Strotmann wrote:
> Hi,
> 
> Joel Jaeggli writes:
> 
>> DNSop folks,
>>
>> If we created a new session in the thursday evening 18:40-20:40 slot
>> to accommodate expanded discussion of the Drafts discussed during DNSE
>> and deconflicted that discussion with UTA on friday morning would that
>> be a significant imposition? it seems unlikely that more than a 1/3 of
>> the slot would be required.
> 
> would remote participation be possible during this session? I would like
> to join (at least listen in).

yes, this is a scheduled meeting block, (scim is also meeting during
this window)

> Carsten
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] dnse related docs.

[Joel Jaeggli]

DNSop folks,

If we created a new session in the thursday evening 18:40-20:40 slot to 
accommodate expanded discussion of the Drafts discussed during DNSE and 
deconflicted that discussion with UTA on friday morning would that be a 
significant imposition? it seems unlikely that more than a 1/3 of the slot 
would be required.

Thanks
joel

Joel's widget number 2 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

[joel jaeggli]

On 3/3/14, 9:25 AM, Norbert Bollow wrote:
> Warren makes a strong argument in favor of .alt I think.

yeah... anything that has the potential to result in additional leakage
seems like a recipe for additional pain.

> Another related aspect is that if something like onion.notreallydns.org
> is used, with notreallydns.org registered for the specific purpose of
> providing a home for one or more non-resolving dns-like names, it
> is very non-trivial to guarantee that whoever has registered the
> notreallydns.org name will continue paying the yearly fees forever. If
> the registration lapses, an attacker could become the new holder of the
> notreallydns.org domain and use it to snoop and/or serve malware...
> 
> Greetings,
> Norbert
>  
> 
> Am Sun, 2 Mar 2014 22:20:48 +
> schrieb Warren Kumari :
> 
>> On Wed, Feb 26, 2014 at 2:34 PM, Joe Abley  wrote:
>>>
>>> On 26 Feb 2014, at 5:03, Mark Andrews  wrote:
>>>
 In message ,
 David Conrad writes:

> On Feb 25, 2014, at 9:51 AM, Stuart Cheshire 
> wrote:
>> If we have *some* pseudo-TLDs reserved for local-use names,
>
> I would think =
> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_element=
> s would be appropriate for this purpose.
>
> Regards,
> -drc

 Whatever is used needs to be insecurely delegated so that in app
 validation will work.
>>>
>>> I still don't see why we need a TLD, or a delegation/reservation
>>> under ARPA.
>>>
>>> There are many, many TLDs under which an application/protocol
>>> implementer can reserve some namespace for their exclusive use at
>>> low cost ($10/year, say). Why is this approach not preferred for a
>>> new application/protocol? It seems far simpler.
>>
>> Yes, and it is -- but it means that leakages hit more folk.
>>
>>>
>>> Perhaps all that is missing is some guidance that says "you
>>> shouldn't hijack namespaces that you don't control, even for
>>> non-DNS applications; register a domain instead".
>>
>> Because for some things, people specifically do *not* want it to hit /
>> go through the DNS -- this is why they have done this, and *not* just
>> registered e.g onion.com...
>>
>> For example, I'm a  *huge* Justin Beiber fan. I, and a bunch of my
>> fellow closet Bieberites hang out on the-bieb-is-cool.onion. (you
>> don't really think we want everyone to know that we obsess over every
>> little antic, do you?)
>>
>> Last week I emailed my friend a link to
>> http://www.the-bieb-is-cool.onion/Justins_New_Shoes.html.
>> Unfortunately, he was just *so* excited to see that the Bieb has new
>> sneakers that he clicked on the link from his phone (which doesn't
>> have the ToR interceptor software installed). This, of course, means
>> that the "DNS like" name, which should not really be used in a DNS
>> context suddenly hit the DNS.  Only his recursive and the root saw
>> this, and that's embarrassing enough, thank you.
>>
>> This is bad enough, but if people built stuff like this under
>> .onion.eff.org (or foo.onion.arpa), there would now be many more
>> people in the list who knew our shameful little secret.
>>
>> Obviously this is a somewhat contrived example (after all, who
>> wouldn't want to make it widely known that they *love* Justin
>> Bieber!), but lets instead pretend I'm using an overlay network as a
>> political dissident, or to discuss my sexual orientation, or...
>>
>> This is some of the justification behind the .ALT TLD proposal
>> (http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00) -- create
>> a special label to be used to denote that this is not actually a name
>> in the DNS context. By reserving it as a special use name:
>> A: It creates a "safe" namespace, secure from collision for people to
>> root namespaces that have no meaning in a DNS context.
>> B: when one of these names *does* leak (as they will), iterative
>> resolvers will be authoritative, with an empty zone, so
>> the-bieb-is-cool.onion.alt only gets seen by the iterative and goes no
>> further.
>> C: When one does go further (as they will), the root can delegate to
>> AS112, while can squash it.
>> D: 4 years from now, when someone comes along and says "I created a
>> shiny new directory system. I used something that looks like DNS
>> names, and I placed it under .pony. Please reserve that for me" the
>> IESG can at least say "But we told you not to do that..." They can
>> also a: reserve it, b: not, or c: we can have another thread about
>> this all again, but now at least we can nod knowingly and feel all
>> superior...
>>
>> W
>> P.S: Note: I did *not* say what should happen with the current
>> pseudo-TLDs / colliding names. They can move under .ALT or they can
>> not. The IESG can reserve them, or not, or bury them in peat, or paint
>> them purple and dress them in wellies. I have views on what I think
>> makes sense, but that's a separate mail.
>>
>>
>>
>>
>>
>>
>>
>>>
>>> Joe
>>> ___
>>> DNSOP 

Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

[joel jaeggli]

On 2/16/14, 8:48 AM, Joe Abley wrote:

> 
> We can't do anything that will cause larger responses, because EDNS
> support is not widespread, and in any case the network can't reliably
> deliver fragments.

in the context of reflection attacks (next paragraph) more packets is
perhaps not the most helpful thing.

> If we believe all these problems are intractable, then we might as
> well just accept that overloading TXT records and reflection attacks
> are a fact of life, and stop worrying about them.
> 



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt

[joel jaeggli]

On 2/12/14, 10:40 AM, Ted Lemon wrote:
> On Feb 12, 2014, at 1:24 PM, Joe Abley  wrote:
>> I suspect that there would be fewer roadblocks involved in choosing
>> an anchor ALT.ARPA than ALT, since ARPA is under the control of an
>> IETF family member while the root is controlled by distant cousins.
>> If I'm right that this proposal is for future, as-yet-unknown
>> applications, then the choice of anchor should be arbitrary; it
>> feels in that case like the path of least resistance is the right
>> one.
> 
> It really shouldn't be difficult to make this work, although if .ALT
> is already spoken for a different name might be needed.   If it is in
> fact difficult, then RFC 6761 is pretty pointless.

this discuss could dangerously veer into vanity territory and I'm
probably doing so by dorking with it but.

.IANA

seems kind of unambiguous as to where the registry for these things
would be.

> I agree with your other point, though—this may be useful for future
> efforts, but doesn't address the same problem as the other two
> documents we've talked about.
> 
> ___ DNSOP  mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

[joel jaeggli]

On 2/4/14, 12:42 AM, Stephane Bortzmeyer wrote:
> On Mon, Feb 03, 2014 at 09:54:41PM +,
>  jonne.soini...@broadcom.com  wrote 
>  a message of 112 lines which said:
> 
>> maybe we should consider to discuss the principles under which TLDs
>> can be reserved for special use and consider a re-spin or an update
>> to RFC6761.
> 
> So, RFC 6761 was written just to allow Apple to register .local and,
> once it is done, we close the door to new registrations?

That in and of itself would be a bit of a moral hazard. it's plausible
that this one case is simply more clear cut (certainly in the minds of
the authors) then others.

I don't believe that we did this (6761) so that we could treat this as a
one-off event.

it's my personal opinion that application specific namespaces should be
treated differently in some way, if resolver libraries are being asked
to make a decision on the basis of .tld how to handle a query we gone
down an extensibility rathole that's hard to get out of.

> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] dnsop co-chair announcement.

[joel jaeggli]

Folks,

First I'd like to thank everyone new and from the previous round of
volunteers. With respect to qualified and involved candidates v6ops has
many and that's really heartening to see.

Suzanne Woolf has accepted the role and will be joining Tim as co-chair.

Thank you Suzanne for volunteering.

Regards
Joel



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] New chair selection process.

[joel jaeggli]

Folks,

When Stephen Morris stepped down in March we solicited volunteers for
his replacement. It is likely that over the next couple of days  that we
will revisit that list for potential candidates as that was relatively
recent.

If you would like to be considered for the role dnsop chair and you did
not at that time contact me, please consider doing so soon.

I am mindful that there are impending holidays for many participants  so
we'll work around that.

thanks
joel



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] a change for the dnsop wg

[joel jaeggli]

Thank you very much Peter for your effort.

I greatly appreciate your enduring involvement, in particular across the
AD transition and through to the present. I hope and expect that you'll
continue to keep me honest with respect to DNSOP and IETF DNS activities
in general.

Regards
joel

On 12/10/13, 9:23 AM, Peter Koch wrote:
> Dear DNSOP WG,
> 
> this is interesting times for the DNS, in operations and elsewhere.
> We have recently seen increased interest in DNS and privacy/confidentiality
> as well as in the topic of "new TLDs", scratching the boundaries between
> ICANN and the IETF, again.  There are lots of new uses of the DNS one
> way or another, good and challenging, in various parts of the IETF and it is
> good to see that we maintain a committed core of DNS people within our
> standards body. With the protocol being "ready", this is just the start of
> another journey.
> 
> At this time, after 25 IETF meetings, I have informed our AD that I'd
> like to step down from the position of a DNSOP co-chair and hand over
> the responsibility to somebody else to join Tim in chairing the group.
> 
> It was a pleasure to serve the WG and the community and I owe a lot of thanks
> to a lot of people for their work as reviewers, scribes, editors, 
> contributors,
> monitors (in the ancient sense of the word) and, not the least, fellow
> co-chairs and advising ADs. Thank you!
> 
> Best regards,
>Peter
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

[joel jaeggli]

On 12/3/13, 9:08 AM, Stephane Bortzmeyer wrote:
> On Mon, Dec 02, 2013 at 11:00:30AM -0500,
>  Joe Abley  wrote 
>  a message of 20 lines which said:
> 
>> Saying that using a non-IN class is a non-starter seems about as
>> silly 
> 
> There have been an ITU project to use classes (UN instead of IN?) to
> have different namespaces, probably to have the new spaces managed by
> the ITU. The project was named Net4d (Web site seems down now).
> 
> AFAIK, the project did not even attempt to actually test (at least in
> in the lab) that it was feasible to use other classes. Knowing what
> we know about the ossification of the Internet and the DNS, there are
> very good reasons to be pessimistic.

using a new class for a greenfield seems somewhat different then
expecting it to work across the population of internet resolvers that
are already deployed.

> If we want actual testing of the ability to run non-IN classes, I
> accept donations in bitcoins to do so in my lab :-) But, anyway, you
> have very little chance of convincing any developer to spend time in
> this direction, which is clearly dead.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS privacy draft

[joel jaeggli]

On 12/1/13, 1:06 PM, Paul Hoffman wrote:
> On Dec 1, 2013, at 12:09 PM, Stephane Bortzmeyer 
> wrote:
> 
>> On Wed, Nov 27, 2013 at 09:42:16AM -0800, Paul Hoffman
>>  wrote a message of 52 lines which said:
>> 
>>> Ummm, yes, but your message (and the Introduction) made it sound 
>>> like the emphasis of the draft is on listing the privacy 
>>> implications, and not the suggested changes to deal with them.
>>> Choose a story and stick to it. :-)
>> 
>> Let me rephrase it to be sure I've understood: I should split the 
>> draft in two, one draft only exposing the privacy issues and
>> another one (or several?) describing the proposed solutions.
>> Correct?
> 
> Or retitle the draft from "DNS privacy problem statement" to "List of
> Solutions for DNS Privacy". When I started reading, I assumed that
> this was really a problem statement. That was further emphasized by
> the lead-in to Section 5 that says "Remember that the focus of this
> document is on describing the threats, not in detailing solutions."
> 
>> If so, what is the opinion of the rest of this working group?
> 
> This still feels like a misuse of the DNSOP WG. The beginning of
> Section 5.1.2 declares (I believe correctly) "To really defeat an
> eavesdropper, there is only one solution: encryption." The section
> then goes on to show why that is not possible with today's protocols.
> Thus, this seems exactly wrong for the DNSOP WG. I strongly propose
> that this type of DNS work be done in the Applications Area because
> it is those applications that need to be analyzed and likely changed
> to fit the scenarios you describe.

I see that as an operational problem. Protocol changes are probably not
something we should do here by if you need to talk about the problem
from the vantage point of a consumer or an operator that seems ok.

>>> We haven't gotten into commenting on the stuff in section 5. When
>>> we do, I'll point out the futility of gratuitous queries.
>> 
>> Please go ahead, you can discuss any part of the draft you want.
> 
> Here's a start: "Padding the DNS query stream will have a negative
> effect on the DNS systems as a whole, but will only thwart passive
> surveillance for those attackers who cannot store and process the
> larger stream. There is no current evidence that the bad actors in
> question have such limitations."
> 
>> 
>>> "has a relationship" is fairly weak. Rendering the web page
>>> returned by a browser query can easily generate 50 DNS queries to
>>> places the user has never heard of. Your document needs to cover
>>> the privacy implications of DNS requests that were done without 
>>> intention. Further, the world is more than browsers. The fact
>>> that an app I am using is doing a lookup for imap.badplace.org is
>>> also important.
>> 
>> Send text :-)
> 
> It's not just added text, and nor does it have a smiley. It is a
> completely different view than what you have in the current
> document.
> 
>> I suggest not to do this myself but to point to the various studies
>> using the DNS traffic to find out what the people are doing. Would
>> it address your request?
> 
> Not really, because almost no one reading this document will actually
> read the studies. It would be better if the draft itself described
> what we know about how users' applications tend to do DNS requests
> for the users and not make any implication that the user understands
> this.
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Moving parent-child-update documents forward

[joel jaeggli]

On Nov 6, 2013, at 10:55 AM, Tim Wicinski  wrote:

> (I will speak only as myself for the moment )
> 
> I am in solid agreement that we need to move these documents forward. In 
> Berlin, we sent back Wes, Warren and Olafur to resolve their differences, 
> merge them (if possible) and present the various options. I've think they've 
> done that and don't it admirably.  I believe that we should call for adoption 
> on these two documents:
> 
> http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-05
> http://tools.ietf.org/html/draft-hardaker-dnsop-csync-01
> 
> As it was said, "Adoption does not mean it will get published."   All the 
> authors agree with this.  I also feel that their is enough consensus to move 
> on these. 
> 
> With Mark Andrew's document:
> draft-andrews-dnsop-update-parent-zones-00

So a question I have here with respect to conversations between authors that 
I’ve heard…

is the model more appropiate if the zone and corresponding number of updates is 
very large?

> I agree with Dan here that we need some more time to see how this will work.  
> A functional example perhaps or some more time and more eyeballs on it.  I 
> can see where both this and Wes's documents can work for different 
> organizations.  I don't think we're far enough along to pick A vs B but we 
> are far enough along to adopt and move forward. 
> 
> Personally, I've been following dnsop and dnsext for many years. One thing 
> I've felt is the turgid pace of document flow. I feel that we need to move 
> things forward or decide why not and send them back.  One of the things I 
> want to do as co-chair is "step up the pace."  From talking with folks on the 
> committee, I have gotten the feedback this is needed. (If you think 
> otherwise, please reach out to me directly).   
> 
> I serve at the whim of the AD, and to serve the community, and until my body 
> is found in a dumpster, I'm working in a more forward direction. 
> 
> tim
> 
> 
> On 11/6/13 5:49 AM, Dan York wrote:
>> Peter & Tim,
>> 
>> Unfortunately we ran out of time in the DNSOP session yesterday and I don't 
>> feel we left with a plan to move forward on the various 
>> "parent-child-update" documents and scenarios.  However I think it is 
>> *critical* that we DO move forward with these documents as this issue is one 
>> of the big barriers for smoother operation of DNSSEC.
>> 
>> I think there was a strong sense in the room that we definitely need to work 
>> on this overall issue and I think at the end we were getting hung up on some 
>> process points (and I admit that *I* was contributing to that confusion)... 
>> and then we simply ran out of time.
>> 
>> What do you see as a path forward here?  How can we progress these documents?
>> 
>> The point I was trying to make in the final minutes was that we need 
>> something *more* than just these documents to help get these solutions 
>> actually out there and deployed.  I think we need to provide operational 
>> guidance to registrars and registries on the different mechanisms for 
>> updating these type of DNS records and explain the options that we have 
>> available.  We need to make it easy for them to understand how the 
>> mechanisms fit together and can be used in different situations.
>> 
>> But I think that kind of document can be written separately from moving the 
>> other documents forward (and yes, I'm willing to help with text and not just 
>> say that "someone" should write a doc).
>> 
>> I don't see why we can't adopt the CDS/CDNSKEY and CSYNC drafts as working 
>> group documents and continue to move them along - we've had significant 
>> discussion on these over the past several meetings and also on the lists:
>> 
>> http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-05
>> http://tools.ietf.org/html/draft-hardaker-dnsop-csync-01
>> 
>> Similarly, I think Mark's draft could be another one to consider adopting 
>> for situations where people want to operate the push-style model:
>> 
>> http://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-00
>> 
>> I think we need some more discussion on that document before we adopt it (I 
>> haven't seen any on the list, or did I miss it?) but I don't see any issue 
>> with ALSO having a document like it as a working group document.  There will 
>> be multiple models for different situations.
>> 
>> Additionally, I think Paul's document on use cases is one that we should be 
>> bringing back into circulation (thanks, Matthijs, for the pointer after Paul 
>> mentioned it yesterday):
>> 
>> http://tools.ietf.org/html/draft-wouters-dnsop-secure-update-use-cases-00
>> 
>> Anyway - I think we do need to move this whole area of work forward as 
>> rapidly as we can.  
>> 
>> My 2 cents,
>> Dan
>> 
>> --
>> Dan York, dan-i...@danyork.org
>> http://danyork.me   http://twitter.com/danyork
>> 
>> 
>> ___
>> DNSOP mailing list
>> 
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/lis

Re: [DNSOP] Discussing dnsext drafts during Vancouver Session

[joel jaeggli]

On Oct 21, 2013, at 9:58 AM, Ted Lemon  wrote:

> On Oct 21, 2013, at 12:49 PM, Tim Wicinski  wrote:
>> Since dnsext is no longer, Paul has contacted me about having some time to 
>> discuss these during the meeting in Vancouver.  I felt this was an excellent 
>> idea since the many of the comments are from same folks involved in DNSOP.   
>> I understand that this may not be the 'proper' place for this discussion, 
>> but I'm willing to move forward unless the AD or the WG direct me otherwise.
> 
> You could reasonably bring them up in intarea.   I don't get the impression 
> from what you are saying that they are ops documents, so they probably don't 
> belong in dnsop.

I don't think there's any likelyhood of them being acepted here. cross-area 
socialization if appropiate is not a problem imho.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-hoffine-already-dotless

[joel jaeggli]

Thought the working group might be somewhat interested in:

https://datatracker.ietf.org/doc/draft-hoffine-already-dotless/?include_text=1

in relation to:

http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.

[joel jaeggli]

On 6/18/13 10:47 AM, sth...@nethelp.no wrote:

Unfortunately the former are far too prevalent.  It's undoubtedly too
late, but unfortunately it might have been better to do the
fragmentation within the UDP payload (i.e. inside DNS) somehow (c.f.
http://tools.ietf.org/html/rfc5405#section-3.2).

It is *never* too late.  For IPv6 we are still in the very
early days.

but, what about the 'vast install base'  ?

There isn't a "vast install base" of firewalls (border routers).
If there was we would have 99% IPv6 traffic instead of 1.6% IPv6
traffic.
So I like the assumption that I should limit edns0 responses to 
something  I don't have to fragment.


My goal as it were was to look at if fragmentation were expected to work 
that I don't really want to expose myself to reciving a 4k response (via 
UDP) because the risk of an amplification attack becomes very large 
indeed. Even if I filter fragments (because I have to or as a product of 
limitations such an attack my be targeted at the infrastructure rather 
than the endpoint that's the notional target.

I'm afraid I have to disagree. There is a significant installed base
of border routers doing *stateless* firewall functions for various
reasons. Some of these border routers already have IPv6 turned on,
and many more of them *will* have IPv6 turned on in the near future.

Changes to IPv6 handling that require new software for these routers
is certainly possible - you "only" need to sell such a change to the
vendors.

Changes that require hardware replacement (and therefore significant
capex) are obviously much harder.

Steinar Haug, AS 2116



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.

[joel jaeggli]

I'm interested in the intersection between the requested payload size 
and the use of the v6 fragmentation header, 6891 I think is missing some 
advice to implementers that might reasonably prevent fragmented replies 
from being dropped and limit the degree of amplification that can be 
achieved with large RRsets.


Are there thoughts about this based on experience?

thanks
joel
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...

[joel jaeggli]

On 4/14/13 9:40 AM, Michael StJohns wrote:

What exactly is the purpose for  this document?  Specifically, please

> describe the concept of operations for the use of this record.

The rational described on this list a month ago was as follows:

 Original Message 
Subject: [dnsext] Fwd: New Version Notification for 
draft-jabley-dnsext-eui48-eui64-rrtypes-00.txt

Date: Tue, 19 Mar 2013 10:33:04 -0400
From: Joe Abley 
To: dns...@ietf.org Group 

Hi all,

During a conversation about an attempt to stuff IP and subscriber MAC 
addresses into the DNS (something that is happening operationally in 
Canada, related to wholesale cable internet service) I noticed that 
there is currently no clean way to represent ethernet MAC addresses. 
People are either using TXT records, or encoding MAC addresses into PTR 
RDATA, and it's all a bit messy.


Assuming that this is not the last time that someone will find a reason 
to encode layer-2 addresses in the DNS, I thought it worthwhile to 
define a cleaner option.


The draft referenced below defines two new RRTypes, EUI48 (for EUI-48 
addresses, which is what prompted this line of thinking) and EUI64 (for 
EUI-64 addresses, since it seems silly to accommodate one without the 
other).


The wire format is pretty trivial (network byte order, simple octet 
string), the RRTypes chosen are unremarkable (not sure what else you'd 
call an EUI-48 address RRType than EUI48) and the presentation format 
should be familiar. The examples given use the ethernet address of the 
wireless adapter on my laptop and its EUI-64 mapping, for lack of any 
documentation OUI that I could find. The IEEE references are consistent 
with the references for EUI-64 in IPv6, e.g. in RFC 4291. The expert 
review template for the RRType application is included as an appendix.


In the event that this proposal doesn't meet with projectile heartburn, 
I would hope that this could be adopted, discussed, refined and 
last-called before the demise of dnsext. Alternatively, assuming again 
that the expert review raises no concerns and code points are assigned, 
it could proceed as an individual-track submission.


Comments welcome.


Joe






> Mapping a name directly to a MAC address seems somewhat problematic
> and perhaps even dangerous to consistency.
>
> I understand storing things in the DNS system is attractive, but
> adapting it to store L2 data may be going a bit too far past it's
> designed scope,

The scope in which such a mapping is useful is clearly fairly limited, I 
imagine there are provisioning/subscriber managment systems that would 
adopt such a representation, but  I imagine the author has a more 
specifc example.



I would object to the document  absent a clear and convincing

> description of why it is needed and what applications will use it.
>
> Mike
>
> Sent from my iPad
>
> On Apr 14, 2013, at 11:55, joel jaeggli  wrote:
>
>> I've been asked to take this document on as AD sponsored individual
>> submission.
>>
>> http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02
>>
>>
>>
If there's anyone who has strenuous objections to that, please let me know.



>> joel ___ dnsext mailing
>> list dns...@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
>


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...

[joel jaeggli]

 Original Message 
Subject: 	draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored 
individual sumission...

Date:   Sun, 14 Apr 2013 08:55:52 -0700
From:   joel jaeggli 
To: dns...@ietf.org, dns...@ietf.org
CC: draft-jabley-dnsext-eui48-eui64-rrty...@tools.ietf.org



I've been asked to take this document on as AD sponsored individual
submission.

http://tools.ietf.org/html/draft-jabley-dnsext-eui48-eui64-rrtypes-02

If there's anyone who has strenuous objections to that, please let me know.

joel



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] please welcome the new co-chair Tim Wicinski

[joel jaeggli]

Folks,

First off let me thank you for the enthusiasm displayed by the 
participants on this list, we had over a dzoen volunteers to fill the 
slot vacated by Stephen. I've elected at this time to invite Tim to 
share the dutires with Peter.


I greatly appreciate all the advice I recived on what we should be doing 
in/with DNSOP.


joel

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop