Re: [DNSOP] Meaning of lame delegation

[Patrik Fältström]

On 12 Apr 2023, at 21:37, Joe Abley wrote:

> With regard to a flock of drones providing service for a single nameserver I 
> agree there are other exciting failure modes to look forward to. But, as 
> before, I don't think we have a shortage of ways to describe them -- no need 
> to economise by using a single term to describe everything that can possibly 
> go wrong.

And no need to invent precise terms for every different failure mode.

Or, how I now and then deal with discussions where special words are used:

Person: I think FOO is the best there is!

Me: Can you say the same sentence again, without the use of the word "FOO"?

Person: Hmm[some good explanation which makes me understand what the person 
meant with the term FOO in *this* context of *this* discussion]

I.e. trying to compile explanatory text into single words is in most cases 
impossible. The question is how useful it is? Sometimes maybe non-precise 
language is needed to ensure people use more words.

"Broadband" anyone?

   Patrik



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

Re: [DNSOP] Meaning of lame delegation

[Patrik Fältström]

On 12 Apr 2023, at 20:56, Niall O'Reilly wrote:

> I have, or think I have, always understood the NS RRset at a zone
> cut to advertise a set of delegations, each to a distinct server.

And if you use anycast, where some of the servers in the anycast cloud respond 
and some do not?

   Patrik


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

Re: [DNSOP] Wildcard junk vs NXDOMAIN junk

[Patrik Fältström]

On 7 Apr 2022, at 18:50, John R. Levine wrote:

> A friend of mine asserts that wildcard DNS records are a problem because 
> hostile clients can use them to fill up DNS caches with junk answers to 
> random queries that match a wildcard.  But it seems to me that you can do it 
> just as well with random queries that match nothing and fill up the cache 
> with NXDOMAIN junk answers.  Am I missing something here?

I don't think so, part from of course that the TTL of the cached data might be 
different depending on whether the query matches something or not.

   Patrik

> If you add DNSSEC, with or without RFC 8198 response synthesis, the details 
> change but I don't think answer does, it's about the same either way.
>
> I can see attacks where you might use URLs with wildcard names to fill web 
> caches with junk pages (see https://www.web.sp.am/) but that's different.
>
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> 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-hoffman-dns-terminology-ter-01.txt - some comments

[Patrik Fältström]

On 23 Jul 2019, at 20:10, Puneet Sood wrote:

>> draft-hoffman-dns-terminology-ter-01.txt says:
>>   Applications Doing DNS (ADD):  Applications that act as stub
>>   resolvers.  This is in contrast to the way that applications
>>   traditionally have gotten DNS information, which is to use system
>>   calls to the operating system on the computer, and have the
>>   operating system act as the stub resolver.  "Applications Doing
>>   DNS" is not limited to particular transports: it applies equally
>>   to DNS-over-TLS, DNS-over-HTTPS, Do53, and future DNS transports.
>>   ( Temporary note, to be removed before publication as an RFC:
>>   there is a mailing list discussing Applications Doing DNS at
>>   https://www.ietf.org/mailman/listinfo/add )
>>
>> While I agree that “add” today covers discussion around the case described 
>> in here, but the reason that it covers it  is because “add” acts as a "catch 
>> all bucket" for “various DNS things not well defined”.
>> If we want to cover the case of an application acts as/embed a stub 
>> resolver, we may want to define a term (and draft) that covers exactly that, 
>> instead of using the much wider term.
>
> I like this clarification of what people are using ADD to mean. As I am 
> listening to the ADD BoF talks, I want to point out that
> applications *have* been doing - just using a system API. The discussion and 
> activity is now around applications embedding stub resolver functionality. So 
> I propose term like Embedded Application Resolver Stub (EARS).

First of all, the calls being used by applications are not system calls. Not 
the definition of system calls I know of at least.

The difference between traditional DNS and what we have here to be is that in 
traditional DNS the configuration and control of where to send the DNS packets 
is made by the operating system, while with ADD it is done by the application.

The rest of the stuff is very similar. Still RD flag set. Still not much clue 
on the client side etc.

Then, as others have said, discussion about other transport protocols have been 
sneaking in here, but that does not really matter for me when talking about 
traditional DNS or ADD. Do53 or DoT or whatever is just another transport.

Good to define the terms though! But if you have different DoT things for when 
RD flag is set or not, why not also for Do53?

   Patrik


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

Re: [DNSOP] extension of DoH to authoritative servers

[Patrik Fältström]

On 12 Feb 2019, at 21:48, Paul Vixie wrote:

> whether the situation turns out to be temporary or not is important to your 
> final argument. probably you shouldn't go there so soon. spammers also 
> believe that network operators should not be able to control their own 
> networks, and malware authors, and botnet creators, and IoT innovators, and 
> surveillance capitalists. none of those matters seem like they are, or will 
> ever be, settled. so, none are "temporary".

The current legal system and court decisions require access providers to have 
some control. Today it is "enough" for the access providers to block DNS lookup 
of certain domain names. We on THIS list understand how easy it is to go around 
that kind of blocking, but that does not matter. It is enough for the legal 
systems in the world.

If the control over the DNS lookups is no longer possible by the access 
provider, then the access providers by law have to use other tools to control 
the traffic from their customers.

So, it is not only their choice.

   Patrik


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

Re: [DNSOP] Root zone KSK-2010 is now revoked

[Patrik Fältström]

Well done Matt and others! Appreciate your work!

   Patrik

On 12 Jan 2019, at 0:07, Matt Larson wrote:

> Dear colleagues,
>
> A few moments ago, at 1400 UTC today, 11 January 2019, ICANN's root zone 
> management partner, Verisign, published root zone serial number 2019011100 
> with the RFC 5011 REVOKE bit set. As a result, KSK-2010's key tag has changed 
> from 19036 to 19164. In addition, the root DNSKEY RRset is now signed with 
> two KSKs: the current KSK (KSK-2017) as well as the former KSK (KSK-2010). 
> The second signature is required by RFC 5011 to prove possession of 
> KSK-2010's private key to assert the revocation. This second signature makes 
> the response to a query for the root zone's DNSKEY RRset increase in size 
> from 1414 bytes to 1425 bytes.
>
> We don't expect any operational issues from this change. The DNSKEY RRset 
> size increase is small, and other zones currently publish considerably larger 
> apex DNSKEY RRsets without apparent issue. In addition, because KSK-2010 has 
> not been used for signing since the root KSK rollover to KSK-2017 on 11 
> October 2018, no DNSSEC validators that are currently validating correctly 
> can be depending on it.
>
> Nevertheless, please let us know if you suspect any issues or have any 
> questions.
>
> May we also suggest subscribing to ksk-rollo...@icann.org to receive 
> announcements and participate in discussion about the KSK rollover process in 
> particular and DNSSEC in the root zone in general.
>
> For the root zone management partners,
>
> Matt
> --
> Matt Larson, VP of Research
> ICANN Office of the CTO
> matt.lar...@icann.org
>
> ___
> 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] Variant bad idea of the day

[Patrik Fältström]

On 1 Jan 2019, at 18:00, John R Levine wrote:

>> If you get a request that include any of the code points {n1, n2,...}, 
>> return a CNAME where nM is replaced with foo?
>
> Not just at foo, but do the same thing on any name under foo.  The idea is to 
> publish the LGR for the subtree and the server can handle all of the variants 
> from one zone.

Got it. As long as the query reaches this server of course. You also mean auth 
servers from delegated zones can query for this explicitly and load its 
internal LGR from its parent?

   Patrik


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

Re: [DNSOP] Variant bad idea of the day

[Patrik Fältström]

On 1 Jan 2019, at 1:28, John R Levine wrote:

> foo VARIANT n1 n2 n3 n4 ...
>
> The fields are 32 bit ints, each of which is interpreted as a UTF-32 code 
> point.  The meaning is that in the subtree at and below this name, n1 is a 
> canonical code point and the rest are variants.  If you get a request with an 
> a-label that doesn't exist, turn it in to a u-label, replace any of the 
> variants n2..nx with canonical n1, turn it back into an a-label and try 
> again.  It might synthesize new RRs for the requested name, or CNAMEs give or 
> take the CNAME at the apex issue.

Hmm...you mean:

If you get a request that include any of the code points {n1, n2,...}, return a 
CNAME where nM is replaced with foo?

   Patrik


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-extended-error-03.txt

[Patrik Fältström]

On 21 Dec 2018, at 21:28, Warren Kumari wrote:

> On Fri, Dec 21, 2018 at 12:52 PM Wes Hardaker 
> <[wjh...@hardakers.net]()> wrote:
>
>> Jared Mauch <[ja...@puck.nether.net]()> writes:
>>
>>  > We went through some of this in IDR about routing protocols and how to 
>> leave
>>  > a partner device a message.  UTF-8 is the supported method.  7-bit ASCII 
>> lacks
>>  > language support.
>>
>>  That's a fair point.  I'd be happy with a change to it. 
>
> +1. Wes and I had a chat about this before specifying ASCII - he was all for 
> specifying UTF-8, I suggested ASCII because it is the "standard" in DNS, and 
> I was arguing for simplicity.

RFC2130, updated by RFC6055.

Be careful though as UTF-8 is only an encoding. Matching or comparing strings 
in UTF-8 is not something that should be done without a bunch of extra rules. 
See IDN.

But for "display strings", perfect!

UTF-8 please!

   Patrik


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

[DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME vs URI vs NAPTR

[Patrik Fältström]

Note changed subject...

Sure, I think of course the URI RR is the best thing since sliced bread, but 
same for each one of the proponents of the other RRs.

I think we could look at the various deployment scenarios and demonstrate what 
design features each one of the RRs have. And with such a description, 
including why the life of the web hosting provider and web site owner ends up 
being easier it is possible to have a better discussion with implementors of 
various libraries that do http fetch. Like libcurl.

When comparing the RRs I agree with the features the other records have, but I 
want to because of this mention why URI is defined as it is.

1. NAPTR did not scale as the size of the RRSet ends up being so large. The 
selection of the subset of potential records one want should be in the initial 
query (QNAME, CLASS, TYPE) and not on the client side. Originally URI was 
because of that designed to replace NAPTR for the ENUM service, to make the 
algorithm simpler. But that was not accepted as people already had implemented 
the (nasty) NAPTR algorithm.

2. URI is a RR type that do use a prefix. It is correct one can not have a 
wildcard, but instead must explicitly have records for all hostnames in the URI 
that is served. This is though a conscious choice. See [3].

3. URI is a RR type that do use a prefix and thanks to this one can delegate 
the _tcp.example.com domain name to a separate DNS server and that way delegate 
across administrative boundaries. Like we already today handle quite often 
Active Directory and service discovery based on the AD mechanisms Microsoft 
have deployed. That way the AD server do not have to be the one that faces the 
internet etc. XFR ends up being simpler and what not.

4. URI do have as RDATA a full URI and not only a new hostname, and that way 
can be part of the rewrite that is to happen. One do not have to follow 
whatever well known URI scheme is to be used, but can instead directly refer to 
the new URI.

4.1. http://www.example.se/path=1

4.2. Look up _http._tcp.www.example.se -> https://example.se/site3/

4.3. Fetch with HOST=www.example.se https://example.se/site3/path=1

This is why I still push URI because I feel 1, 3 and 4 together outweighs 3.

But as other writes, what we lack is code.

   Patrik


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

Re: [DNSOP] Fundamental ANAME problems

[Patrik Fältström]

On 6 Nov 2018, at 22:30, Ray Bellis wrote:

> You can have wildcard support, or you can have prefixes (hence
> delegation), but you can't have both.

Thats exactly my point. URI solves "the other problem".

   Patrik


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

Re: [DNSOP] Fundamental ANAME problems

[Patrik Fältström]

On 6 Nov 2018, at 17:51, Joe Abley wrote:

>> On Nov 6, 2018, at 20:44, Tony Finch  wrote:
>>
>> Joe Abley  wrote:
>>>
>>> Specifically, I s the wildcard owner name a real problem in the grand
>>> scheme of things?
>>
>> My understanding is that wildcards don't work for SRV because the
>> _prefixes are used to disambiguate which service you are asking for,
>> effectively to extend the RR TYPE number space. So if you wildcard a SRV
>> record then the target port has to support every possible protocol :-)
>
> Right, but my point was that wildcard owner names aren't seen at the apex, so 
> a solution to the problem of what to do at the apex doesn't need to worry 
> about them.
>
> Ray has wider aspirations than just the apex. This may well be sensible, but 
> I think it's worth calling out the scope creep.

We should also remember that there is a different goal as well, and that is to 
be able to delegate the zone within which "the records dealing with web" is 
managed so that the administrative responsibility is separated between the one 
which run the zone for example.com and the ones that run for 
_http._tcp.example.com (or _tcp.example.com).

   Patrik


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

Re: [DNSOP] Fundamental ANAME problems

[Patrik Fältström]

On 3 Nov 2018, at 23:32, Måns Nilsson wrote:

> _http._tcp.example.org. IN URI10 20   
> "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/;

Btw, this is sort of what I am thinking of for URI, cooked up directly after 
dinner. Could be a wrapper around curl that fetches stuff. Probably hundreds of 
bad stuff in what I have below, but still...you get the point.

You can try with http://www.frobbit.se/ or http://frobbit.se/ for example, as I 
have URI records for them.

#!/bin/sh

PREFIX=_http._tcp
DOMAIN=`echo "$1" | sed 's/^.*\/\/\([^\/]*\)\/.*$/\1/'`
QUERY=`echo "$1" | sed 's/^.*\/\/[^\/]*\/\(.*\)$/\1/'`
URI=`dig "$PREFIX.$DOMAIN." URI +short`
if [ "x$URI" = x ]; then
   NEWURI="$1"
else
   NEWURI="`echo $URI | awk '-F"' '{ print $2 }'`${QUERY}"
fi

echo curl -H "HOST:$DOMAIN" "$NEWURI"


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

Re: [DNSOP] Fundamental ANAME problems

[Patrik Fältström]

On 4 Nov 2018, at 11:10, Ray Bellis wrote:

> -1

:-)

> What are the semantics of this?

The semantics is exactly like a CNAME + HTTP Redirect.

Provisioning is like any provisioning in the DNS, with the advantage that you 
can delegate the prefix:ed domain just like you can do with any _tcp and 
similar prefix domain to whatever administrative entity that manage the web. 
You can that way separate the DNS and web administration between two different 
entities.

That some people want a record at the apex is a big mistake as one that way 
must mix explicitly the administration of that name between two entities that 
do different things.

See how well the AD delegation works where you can split the AD functionality 
from the DNS functionality by doing "the right delegations", which makes 
enterprise DNS much easier to set up than if (more) stuff is to be entered at 
the apex.

We have apex overload, and that must be taken care of.

   Patrik

> - What appears in the user's UI when the URI record completely replaces the 
> site name entered by the user?
>
> - Which domain name is the SSL cert validated against?
>
> - Which domain name appears in the HTTP Host: header?
>
> - What is the HTTP "Origin" of the resultint content,
>   and which domain's cookies are accepted / sent?
>
> - What if there's also a URI record for 'example-lb-frontend.hosting.namn.se' 
> ?
>
> - How do I provision a wildcard record for this?
>
> I see absolutely zero chance of the web community embracing this.
>
> Ray
>
> ___
> 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] Fundamental ANAME problems

[Patrik Fältström]

On 3 Nov 2018, at 23:32, Måns Nilsson wrote:

> _http._tcp.example.org. IN URI10 20   
> "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/;
>
> We already have this. We need not build a new mechanism.

+1

   Patrik


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

Re: [DNSOP] SRV and HTTP

[Patrik Fältström]

On 11 Jul 2018, at 8:21, Mark Andrews wrote:

> As for lib curl, there is not a RFC that says to lookup SRV records for HTTP 
> or HTTPS.

Agree, and I have wanted it to be part of HTTP/2, or at least resolve this 
mess, but it did not happen.

This is my recurring discussion with Daniel when we have beer :-D

   paf


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

Re: [DNSOP] SRV and HTTP

[Patrik Fältström]

On 11 Jul 2018, at 5:16, John R Levine wrote:

> It's always been my impression that the http crowd believe that the
> overhead of a two DNS lookups is too slow, for some meaning of too slow.

They rather stay in the space they know, HTTP resolution, and do multiple HTTP 
requests instead of multiple DNS requests.

Just like we DNS people rather do more in DNS.

   paf


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

Re: [DNSOP] SRV and HTTP

[Patrik Fältström]

On 11 Jul 2018, at 3:30, Mark Andrews wrote:

> I think there are three main objections.
>
> 1) Wildcards don’t work with prefixes.
> 2) Additional data isn’t always returned it may require multiple round trips.
> 3) Additional data processing doesn’t support negative responses.

4) Various libraries in PHP and ultimately lib curl do not include SRV in the 
resolution

5) New resource record types are very hard to implement (same argument as why 
we use TXT for SPF and not SPF for example)

6) You "only" change hostname with SRV and not a "complete change of the URL"

> All of these issues are trivially easy to fix.  It just require willingness 
> to implement.
>
> 1) is addressed by defining a new type(s) rather than using prefixes.
> 2) is addressed by getting recursive servers to fill in missing additional 
> data before returning.  Named has code in review for this for SRV as proof of 
> concept.
> 3) is addressed by adding some signalling between the client and recursive 
> server to indicate if the additional section is complete or not.

4) Is of course "just code" in lib curl and what not

5) Is like (4) but possibly harder if you want it implemented in PHP, 
javascript etc and not in the underlying libraries

6) This is why I came up with URI which is supposed to be a competitor to "well 
known URI"

   paf


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

Re: [DNSOP] updating fragile dnssec, was Fwd: New Version

[Patrik Fältström]

On 18 Aug 2017, at 4:39, John R Levine wrote:

> Some do it one way, some do it the other, and the registars and registries 
> I've talked to feel very strongly about whichever way they do it.

Correct, and that is why my only strong view is that both mechanisms can be 
implemented by the solution IETF develops (including ability to say "NO" to the 
not chosen option).

   Patrik


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

Re: [DNSOP] .arpa

[Patrik Fältström]

On 27 Mar 2017, at 14:41, Ray Bellis wrote:

> On 27/03/2017 02:52, Patrik Fältström wrote:
>
>> One important part is in the letter from NTIA (Karen Rose) to ICANN
>> (Louis Touton) in Appendix A.
>>
>> A letter sent April 28, 2000.
>
> Is it online?   I can't find it in the ICANN correspondence archive.

RFC 3172, Appendix A.

<https://tools.ietf.org/html/rfc3172>

   paf


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

Re: [DNSOP] .arpa

[Patrik Fältström]

On 26 Mar 2017, at 17:17, Ozgur Karatas wrote:

> 22.03.2017, 10:05, "Jim Reid" :
>
>>>  On 21 Mar 2017, at 14:53, Suzanne Woolf  wrote:
>>>
>>>  RFC 3172 was written in 2001…
>
> the last updated was made in 2013, right?

One important part is in the letter from NTIA (Karen Rose) to ICANN (Louis 
Touton) in Appendix A.

A letter sent April 28, 2000.

   Patrik


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

Re: [DNSOP] .arpa

[Patrik Fältström]

On 22 Mar 2017, at 8:05, Jim Reid wrote:

>> On 21 Mar 2017, at 14:53, Suzanne Woolf  wrote:
>>
>> RFC 3172 was written in 2001…
>
> RFC 3172 was an attempt to rewrite history and contrive an acronym: Address 
> and Routing Parameter Area - really?
>
>> Respectfully, I’ve always wondered who has this problem (US or non-US) 
>> besides network infrastructure geeks Of a Certain Age (yes, including 
>> myself, and many IETF participants).
>
> It's a convenient tool for those hostile to USG "control" of the Internet: ie 
> the US military is responsible for everything under .arpa, the US military's 
> ARPA has still got some special status in the operation/development/control 
> of the Internet, etc, etc. [And say things like "if .arpa isn't for US 
> military control, why can't the string be changed?" or ".arpa hasn't been 
> renamed since the Internet started 25-30 years ago. That proves ARPA/DoD is 
> in charge of the Internet.".] It's utter nonsense of course. But that doesn't 
> stop government officials and policymakers from making these arguments. I 
> have seen them do this many times. Sigh. RFC3172 didn't make things better.

The important thing in RFC3172 is Appendix A, the letter by which US Government 
(via Karen Rose), that was then in charge, set the scope for the IANA and use 
of .ARPA.

The next big step was the end of the contract(s) between US Gov and ICANN Oct 1 
2016.

Many steps of course remain, but it is important to separate facts from rumors, 
while at the same time not ignore the need for proper and correct information 
and informed discussions.

   paf


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

Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Patrik Fältström]

On 4 Feb 2017, at 2:57, Andrew Sullivan wrote:

> On Fri, Feb 03, 2017 at 12:21:16PM -0800, Steve Crocker wrote:
>
>> And just to stir the pot a bit, what would you have ICANN do if someone 
>> applies for .alt as a top level domain?  Is it ok if we say yes and delegate 
>> the name?  If not, what is the basis for us to say no?
>
> If alt ends up in the 6761 special-use names registry, that seems a
> reason for ICANN not to delegate the name.  For adding something to
> the 6761 special-use names registry removes it from the possible pool
> of names that can be in the root zone.

This would be my suggestion.

What worries me is not names in 6761 special-use names registry but other names 
ICANN "should not" add to the root zone.

   paf


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

Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

[Patrik Fältström]

On 4 Aug 2016, at 18:55, Dave Crocker wrote:

>>> For URI records RFC 7553 says they're either named the same as SRV
>>> records, or they use enumservice names from the Enumservice
>>
>> Declaring a namespace as the union of two, independently-maintained
>> registries is a very efficient way to encourage -- actually in
>> theoretical terms, it guarantees -- collisions.
>>
>
> I see this as a fundamental problem with the URI spec, for the reason cited.  
> I also think the current spec should be careful not to promote that problem.
>
> Suggestions?

Add text that say that to resolve conflicts (what prefixes to use for URI or 
SRV for "the web"?), it is encouraged to write explicit documents that say what 
is to be used.

I just submitted draft-faltstrom-httpbis-dns-00.txt is an example of what I am 
thinking of, for URI and "the web", which explicitly say what to enter into the 
registry that is defined by this document. My envision is to add more text on 
the recommended way to use DNS in the case of "the web".

TL;DR: draft-faltstrom-httpbis-dns-00.txt recommends _web._http for "the web". 
Regardless of the registration of both ENUM services HTTP and HTTPS, regardless 
of the various "names" used for port number 80 (etc) and regardless of whether 
TCP or UDP (and other things being part of the HTTP evolution...).

It is "just" used for rewrite of the URI before the HTTP protocol takes over.

   Patrik


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

Re: [DNSOP] draft-ietf-dnsop-terminology-bis-01

[Patrik Fältström]

On 17 Jul 2016, at 11:16, Dan York wrote:

> The new -01 draft looks good.  I need to do a deeper read but I'll point out 
> one additional term we found in the development of  
> https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
>   

Not all registries accept DS. Some require DNSKEY.

   paf


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

Re: [DNSOP] New usage for TXT RR type on radar: Kerberos service discovery

[Patrik Fältström]

On 31 May 2016, at 21:13, John R Levine wrote:

>> It is a big failure and problem for the Internet that there is no support 
>> for unknown resource record types.
>
> No kidding. The problem isn't with DNS server software like BIND and NSD, 
> which are updated regularly.

Correct!

> The problem is the Web Crudware(tm) that most people use to manage their 
> zones.
>
> See https://datatracker.ietf.org/doc/draft-levine-dnsextlang/
>
> I think I have funding to revise and implement this, by the way.

Excellent! Me like!

   paf


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

Re: [DNSOP] New usage for TXT RR type on radar: Kerberos service discovery

[Patrik Fältström]

It is a big failure and problem for the Internet that there is no support for 
unknown resource record types.

See RFC 3597 (from 2003) and followers.

   Patrik -- that because of this will continue to object to use of TXT, as we 
all have our windmills



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]

[Patrik Fältström]

On 24 Apr 2016, at 16:20, Paul Hoffman wrote:

> On 23 Apr 2016, at 19:58, Ted Lemon wrote:
>
>> Bottom line: this is not actually the intended way things should work for
>> naming in homenets, and a lot of people missed it.   Sigh.
>
> ...for well over a year. You see that exact phrase in the draft over many 
> revisions. This is a sign that maybe the 6761 problem is going to be harder 
> than some people think.

Now it is at least possible to point to 6761, which I think is a step forward 
-- EVEN IF people think 6761 must be replaced, updated and what not.

;-)

   Patrik


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]

[Patrik Fältström]

Noted!

And I saw more email messages on this topic after I wrote this email of mine.

Happy to see not only I "miss" things when being AD :-)

All the best!

   Patrik

On 24 Apr 2016, at 15:22, Ted Lemon wrote:

> Patrik, I think that it's fairly clear that the authors were assuming that 
> .home would be documented elsewhere when they wrote that text, so the problem 
> is simply that they never added a normative reference to the document 
> describing what .home does, and because of that nobody noticed that it was 
> being defined here for the first time.
>
> On Sun, Apr 24, 2016 at 2:18 AM, Patrik Fältström <p...@frobbit.se> wrote:
>
>> On 24 Apr 2016, at 3:01, David Conrad wrote:
>>
>>> I would agree that it is interesting.  Unsurprisingly, it is not in
>> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.
>> My gut feeling is that this is a process failure, but will admit that the
>> whole question is quite unclear given the continuing uncertainty about the
>> process described in 6761.
>>
>> There is also nothing in the IANA Considerations Section about adding
>> .HOME to the registry, which I think is a big mistake.
>>
>> Either .HOME should not have been mentioned, or it should be added to the
>> registry.
>>
>>Patrik
>>
>> ___
>> 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]

[Patrik Fältström]

On 24 Apr 2016, at 3:01, David Conrad wrote:

> I would agree that it is interesting.  Unsurprisingly, it is not in 
> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.
>  My gut feeling is that this is a process failure, but will admit that the 
> whole question is quite unclear given the continuing uncertainty about the 
> process described in 6761.

There is also nothing in the IANA Considerations Section about adding .HOME to 
the registry, which I think is a big mistake.

Either .HOME should not have been mentioned, or it should be added to the 
registry.

   Patrik


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

[Patrik Fältström]

On 30 Mar 2016, at 1:23, Suzanne Woolf wrote:

> Doubtless I’m missing something though….is there a citation we can ask the 
> draft authors to incorporate in the future?

The formal references we in SSAC have found are the following:

For .corp and .home:



For .mail:



Note that the rationale include:

> Requirements for ICANN:
>
> Work within the IETF and with other relevant technical communities to 
> identify a notification mechanism for IPv6 that provides similar 
> functionality to that available in IPv4's "Loopback" reserved prefix.
>
> Defer delegating .MAIL indefinitely, and collaborate with the technical and 
> security community to identify the best way to handle .MAIL (e.g. permanent 
> reservation through the IETF process).

   Patrik



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

Re: [DNSOP] statistics of deployment

[Patrik Fältström]

On 6 Jan 2016, at 17:16, Hosnieh Rafiee wrote:

> Thanks a lot to all of you who provided me with the information.
>
> I am quite amazed with all these statistics :).. very good job! I knew there 
> are a lot of efforts on the deployment but didn't know as that much.

Btw, as I presume there is some background thinking what you should use the 
statistics for, it would be appreciated if you one day report back what you 
wanted to use it for, what your initial strategy was, how that worked, how you 
adjusted and what the final outcome was.

So that we can learn from each others successes and mistakes.

Thanks!

   Patrik


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

Re: [DNSOP] code points for brainpool curves for DNSSEC

[Patrik Fältström]

I have nothing to add to what Ólafur wrote below. I agree with his statement.

   Patrik

On 10 Dec 2015, at 1:33, Ólafur Guðmundsson wrote:

> Stephen,
>
> Sorry for being so blunt below.
>
> The document totally content free as to why this makes any sense in an 
> operational context.
> DNSSEC algorithms should not be given out lightly as there is a significant 
> COST to deploy support for each additional algorithm.
>
> While I strongly support having better ECC algorithm that the currently 
> specified curves, adding a new ones SHOULD take place via a performance 
> oriented process.
> Thus I strongly advocate that this publication be held up until we can 
> compare this curve with other curves being proposed.
>
> Background I'm currently fighting an multifaceted battle to have various 
> entities adding support for ECDSAP256, specified over 3 years ago.
>
> Adding and deploying a new DNSKEY algorithm does not just require changes to
> -- DNS servers, libraries and resolvers.
>
> That is just the top of the iceberg,  but also to
> -  DNS provisioning systems, DNSSEC signing systems, DNS testing tools, - 
> user interfaces for registrars, hosting providers, third party DNS operators, 
> CDN's,  etc.
> - TLD and ccTLD policy documents, EPP implementations, plus in some cases 
> security evaluations,
> - not to mention firewalls, network monitoring tools 
> and number of other things I had no idea existed and majority of which is not 
> maintained anymore.
>
> There are only so many times that one can get everyone's attention to upgrade 
> DNS stuff, thus requiring the change process to be run should not be taken 
> lightly.
> If on the other hand if the editors are only interested in vanity algorithm 
> assignment without any deployment then ...
>
> Olafur
>
>
> On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell 
> wrote:
>
>>
>>
>>
>>  Forwarded Message 
>> Subject: code points for brainpool curves for DNSSEC
>> Date: Wed, 9 Dec 2015 18:00:18 +
>> From: Stephen Farrell 
>> To: s...@ietf.org
>>
>>
>> Hiya,
>>
>> The brainpool folks have written an I-D [1] that they are pushing
>> through the rfc editor's independent stream. [2]
>>
>> That I-D wants to register code points for using their curves for
>> DNSSEC.
>>
>> For documents that come through the independent stream, the IESG
>> does an RFC 5742 [3] conflict review. The purpose of that review
>> is to check that the RFC doesn't conflict with ongoing work in
>> the IETF.
>>
>> If you have thoughts on this, please let me know before Dec 17th.
>> I'll forward this to the dnsop, cfrg and curdle mailing lists
>> to check there too. Apologies if you get >1 copy of this. Please
>> try follow up on the saag list if you can.
>>
>> Thanks,
>> Stephen.
>>
>>
>> [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec
>> [2] https://www.rfc-editor.org/pubprocess/
>> [3] https://tools.ietf.org/html/rfc5742
>>
>>
>>
>> ___
>> 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 Resource record?

[Patrik Fältström]

On 9 Dec 2015, at 21:25, Hosnieh Rafiee wrote:

> I would like to suggest the following format (this is the rough version and 
> it is not exact but only giving you an idea that what is the purpose) for a 
> new resource record to store the reference information of bounding of 
> authentication and authorization where authentication can be based on public 
> keys or certificates.
> This means each reference no represents an actual policy template in other 
> security system or other services. This means if a certificates bound to more 
> than one references, then more than one of this section is added to RDATA 
> section of the DNS query. This also should be updatable by the DDNS protocol.
> BTW, I skipped the header and other parts of RR and this part is only the 
> RDATA section.
>
> ---
> |flag| reference no   |
> ---
> | some human readable |
> |   text  |
> ---
>
> The processes are also simple, when a node query the certificates, DNS server 
> also includes this RR if it exists on the DNS server so that when the querier 
> retrieves this information, it can query other services for the given value 
> to authorize the other host on the network.

A few things:

1. Do not use TXT RR. We have already too much use of TXT, and you should 
define a new RRType

2. There are multiple reasons why you should not use TXT record or even the 
structure of the TXT RR, most notably the length of the "some human readable 
text" portion. I suggest you have, just like in the URI RRType, the length of 
the "some human readable text" be set by the length of the RR as a whole minus 
the flag, reference no, header etc. That way the length can be longer than what 
you otherwise can (in a TXT for example). You also do not end up having trouble 
defining how to handle multiple strings in the RR, like you have if you try to 
stuff things into a TXT.

3. Think about (as you did in a later message) the owner as well as the RData. 
The right prefix might be key to the usage pattern.

   Patrik


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-adpkja-dnsop-special-names-problem-00.txt

[Patrik Fältström]

On 26 Nov 2015, at 18:05, Joe Abley wrote:

> On 25 Nov 2015, at 0:40, Patrik Fältström wrote:
>
>> I have read this draft and have a number of comments. I can not say these 
>> are the only ones, but at least some :-)
>>
>> The dominant protocol for name resolution on the Internet is the
>> Domain Name System (DNS).  However, other protocols exist that are
>> fundamentally different from the DNS, but which have syntactically-
>> similar namespaces.
>>
>> I claim that if it is syntactically similar and the names are used 
>> interchangeable in protocols (see below) we actually DO talk about use of 
>> the same namespace. This is the camel in the tent, and I think we should 
>> just admit, or say clearly whether we do talk about, which I think we do, 
>> one name space with multiple resolution mechanisms.
>
> That's a possible direction. However, I don't know how far we will get with 
> that approach, since every additional example of a name resolution protocol 
> comes with an attendant list of exceptions, e.g.
>
> - LOCALHOST -- it's a single, dotless name, and there's no hierarchy
> - LOCAL -- child labels can contain spaces and UTF-8-encoded symbols, 
> single-label depth
> - ONION -- a single, fixed-width second-level label (base32-encoded first 80 
> bits of a SHA-1 hash) and anything at all under that (not relevant to the 
> name resolution protocol, but perhaps useful to applications)
>
> I think the useful point to make is that the intersection of all these sets 
> of possible names is non-empty -- that is, you can trivially find examples of 
> names that are legitimate to more than one name resolution protocol, and 
> hence a potential source of confusion to end-users and applications.

Hmm...I think I understand what you mean here. What I was after was that the 
strings are replaceable in the various protocol definitions where "domain name" 
is supposed to be. Then of course certain combination of octet values are not 
possible depending on various rules. By the protocol where the string is in 
use, and (as you point out) because of the different resolution mechanisms.

When thinking of what comes below, what do you say about EXAMPLE? What are the 
rules for that? ;-)

>> It is not so much different protocols as different resolution mechanisms. If 
>> you say "protocol" here, it might sounds like if with the DNS protocol you 
>> can not use multiple different resolution mechanisms (which I think one can 
>> -- one of them using the root managed by ICANN).
>
> Yes, I think it would be better to choose a distinct phrase for what we're 
> talking about here and define it early. I've used "name resolution protocol" 
> for this, but no doubt there are better alternatives.

Hmm...if I knew a good name, I would suggest it. I just stumbled myself over 
the word "protocol".

>> What about EXAMPLE?
>
> I think (but have no citations handy to support my thinking) that EXAMPLE is 
> a reserved top-level label in the DNS, not an example of what Alain called a 
> protocol switch.

;-)

To some degree it is a protocol switch, right? It should never ever be used. 
/dev/null comes to mind... :-)

>> Well...in the architecture we have both the URI scheme and if you look 
>> further the URN definition to manage all different kind of switches. And we 
>> do not have to wake up the old discussion again whether HTTP://EXAMPLE.COM/ 
>> in reality should be URI:HTTP://EXAMPLE.COM/
>
> I think we were imagining that if we could go back in time and insist that 
> URIs such as
>
> http://blah-blah-base32-blah-blah!onion/index.html
>
> unambiguously referred to the onion name resolution protocol, then there 
> would be little chance that these names would leak into other name resolution 
> protocols' infrastructure (like the DNS) and that might provide the basis of 
> some kind of solution to the problem of random (e.g.) e-mailed URLs causing 
> leakage when encountered by end-users and robots that don't know about (say) 
> onion names.
>
> Unfortunately, all attempts to confirm that time travel will be available to 
> me in the future have failed, to date. So either returning to the past to 
> change the URI specification would cause a world-ending rift in space-time, 
> or time travel is fictional. Just quietly, I suspect it's the former.

...or of course ask whether all HTTP scheme URIs use DNS, which imply one 
should place the switch regarding resolution in the URI scheme...

> So, given that it's too dangerous to cross the time streams to fix the URI 
> format, let's go with the ugly but de-facto identifier we have, which is the 
> top label. We don't have to like it, we just have to acknowledge begrudgingl

Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

[Patrik Fältström]

Hi,

I have read this draft and have a number of comments. I can not say these are 
the only ones, but at least some :-)

   The dominant protocol for name resolution on the Internet is the
   Domain Name System (DNS).  However, other protocols exist that are
   fundamentally different from the DNS, but which have syntactically-
   similar namespaces.

I claim that if it is syntactically similar and the names are used 
interchangeable in protocols (see below) we actually DO talk about use of the 
same namespace. This is the camel in the tent, and I think we should just 
admit, or say clearly whether we do talk about, which I think we do, one name 
space with multiple resolution mechanisms.

   When an end-user triggers resolution of a name on a system which
   supports multiple, different protocols for name resolution, it is
   desirable that the protocol to be used is unambiguous, and that
   requests intended for one protocol are not inadvertently addressed
   using another.

It is not so much different protocols as different resolution mechanisms. If 
you say "protocol" here, it might sounds like if with the DNS protocol you can 
not use multiple different resolution mechanisms (which I think one can -- one 
of them using the root managed by ICANN).

   Such usage, which a few commenters have referred to as "protocol
   switching," is not limited to "protocol switch" in the strict sense
   of indicating specific protocols on the wire.  It could indicate to
   switch to another name space (eg .onion), use a different protocol
   (eg tor, or mdns), or indicate to use a local DNS scope by not using
   the DNS root for name resolution (eg .home in homenet) or something
   else altogether.

It is important (which I think also Stephane indicated) that we talk about 
different resolution mechanisms for the name itself. We do not talk about how 
to access the service in question.

   At the time of writing, three top-level domain names reserved by
   inclusion in the Registry are used by name resolution protocols other
   than the DNS:

  LOCALHOST is used to refer to the host on which the name
  resolution takes place, without reference to the DNS;

  LOCAL is used by the Multicast DNS protocol specified in [RFC6762]
  which is similar in some respects to the DNS, but which uses
  different well-known port number and is limited to a particular
  multicast scope;

  ONION is used to construct names that designate anonymous hidden
  services reachable via the Tor network using onion routing.

I think a better text to describe ONION would be:

  ONION is used to construct names that designate
  services reachable via the Tor network using onion routing.

What about EXAMPLE?

   The lack of a more elegant way to specify a
   name resolution protocol in (for example) a URI amounts to an
   architectural oversight.

Well...in the architecture we have both the URI scheme and if you look further 
the URN definition to manage all different kind of switches. And we do not have 
to wake up the old discussion again whether HTTP://EXAMPLE.COM/ in reality 
should be URI:HTTP://EXAMPLE.COM/

I think the key issue here is that the different "strings" that look like 
"domain names" (i.e. are within the same name space) are used interchangeable 
wherever in the URI (or even URN) definition where "domain names" are to be 
used.

   If we accept the notion that the most significant label of a domain
   name is actually a protocol switch, it implies that we are actually
   building a catalog of all top level domains that explain which are
   are switches.

What about not-yet-allocated strings in this catalog?

I think it is important to say that as of today (at least), the default 
resolution mechanism is to use the DNS, although a non-existing string today 
imply one apply the search path algorithm to chase down names.

   In the case of [I-
   D.ietf-dnsop-onion-tld], leakage of ONION queries on the Internet
   might lead to disclosure of private information that, in some cases,
   might pose a risk to the personal safety of end-users.

More, less or similar to leakage when people use non-FQDN and their search path 
create surprises?

   This document aims to provide a problem statement that will inform
   future work.  Whilst security and privacy are fundamental
   considerations, this document expects that that future work will
   include such analysis, and hence no attempt is made to do so here.

See among other places SAC-057 


   Patrik


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

Re: [DNSOP] Registry of non-service _prefix names?

[Patrik Fältström]

On 13 Nov 2015, at 19:00, John Levine wrote:

> It's not a substitute for a
> new RRTYPE; they need the prefix whether the data is TXT or a new type.

Clarification, my english is not good enough...

What you mean is that they believe they do need the prefix regardless of what 
RRType they will use, including TXT?

   Patrik


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

Re: [DNSOP] Asking TLD's to perform checks.

[Patrik Fältström]

On 11 Nov 2015, at 11:42, Stephane Bortzmeyer wrote:

> On Wed, Nov 11, 2015 at 11:29:41AM +0100,
> Patrik Fältström <p...@frobbit.se> wrote
> a message of 57 lines which said:
>
>> Some registries even requires MX records at the zone apex! Even more weird.
>
> Less so now that we have RFC 7505.

Sure, but still do for example FI, DE and HU this. TR even require a web page.

   Patrik


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

Re: [DNSOP] Asking TLD's to perform checks.

[Patrik Fältström]

On 11 Nov 2015, at 11:17, Havard Eidnes wrote:

> A zone registered with delegation records, but where none of the
> name servers respond to queries for the zone does noone any good,
> so why must it be acceptable?

Because only registration of the domain name is what is wanted.

No one want records in the DNS for the domain name. No one asks for such 
things. Except the registry in some cases.

Some registries even requires MX records at the zone apex! Even more weird.

   Patrik


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

Re: [DNSOP] Asking TLD's to perform checks.

[Patrik Fältström]

On 11 Nov 2015, at 11:17, Havard Eidnes wrote:

> Does the scenario look like this?
>
> * Client asks to registrar to set up frobbit.se

Yes, someone want to register frobbit.se domain name. For pure IPR reasons. It 
should not resolve.

> * Registrar is lazy and doesn't want to set up a separate zone, so
> instead sets up his own fake .se zone where he puts the data for
> frobbit.se, including delegating NS records which points
> towards the servers serving the fake .SE zone.

Registry requires NS records and not only a creation of the domain object.

Registrar because of this adds fake NS records.

> * Registrar contacts the registry to have frobbit.se registered
> as a delegation

To register a domain name in this example, the TLD do require not only a 
creation of the domain object, but also link between domain object and some 
(fake) host records.

The example of your is a way weird though as .SE do allow creation of domain 
objects without delegations.

Other TLDs are different.

   Patrik


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

Re: [DNSOP] [ccnso-techwg] Re: Asking TLD's to perform checks.

[Patrik Fältström]

> On 11 nov. 2015, at 08:11, Dr Eberhard W Lisse  wrote:
> 
> So whatever comes out of that could, eventually, also go in.

I completely agree.

My only point is that I urge IETF to write text som that any(!) reader can 
understand there will always be cases where "errors" for various reasons are 
reasonable or even ok.

Any tests will bring down errors a lot.

But last 10-15% is hard.

So let's bring down errors "some" and declare success.

   Patrik

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

Re: [DNSOP] Asking TLD's to perform checks.

[Patrik Fältström]

On 10 Nov 2015, at 22:24, Jim Reid wrote:

>> Or perhaps we should not.
>
> +1

This discussion on making tests is coming back now and then. In RIPE, in IETF, 
in discussions around TLDs (specifically ccTLDs).

I have run one such initiative myself.

Everything has so far collapsed into collision between tech people not agreeing 
on what is right and wrong. It also collapses into clashes between registry 
policy and the tests made. I.e. just the registration policy is setting blocks 
and constraints on what tests must be made (or can not be made). And 
harmonization of such rules is just impossible (we have seen).

That said, initiatives like the one I did run did push errors (for some 
definition of errors) from 22% to maybe 17% in .SE and my inspection of the 
rest say that getting errors down to 15% is possible, but more is very hard.

And, having a BCP or such that give suggestions on what can be viewed as 
"correct" would not be bad, but how to use it must be up to the reader.

I think the IETF should be careful on writing too prescriptive text, I say 
being one hit by "rfc compliance" people that point at old whois related RFCs 
that "require" things that in fact is illegal in Sweden. I.e. by being 
compliant to Swedish law regarding privacy, I violate a very old RFC and 
because of that I am black listed.

So be careful.

   Patrik


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

Re: [DNSOP] My "toxic" remark at the mic today

[Patrik Fältström]

On 6 Nov 2015, at 4:54, Andrew Sullivan wrote:

> On Thu, Nov 05, 2015 at 03:32:43PM +0900, Paul Hoffman wrote:
>
>> No, but there is an RFC from the IAB about what labels should not be into
>> the root without further consideration: RFC 4690. That has been widely
>> interpreted as "do not put X into the root", so it is similar to "do not put
>> RRtype Y into the root".
>
> With respect, labels and RRTYPEs are quite different things.  I think
> perhaps conflating these two things is not super helpful.  But I don't
> have a strong feeling about this, so long as we're not saying anything
> that can be construed as positive advice about what should go into the
> zone.

Paul, you are sure you talk about RFC4690 and not RFC5507?

Being one of the editors of RFC5507 (and 4690!) let me emphasize what Andrew 
wrote here. Yes, maybe people have conflated and simplified what we wrote, but 
the RFC is actually trying to be very very careful with wording and it would be 
said if text that once was very specific once again end up being watered down.

The key message in RFC5507 is that one should minimize the RRSet size, and 
think carefully if the selection criteria between RR is in the RRType or owner.

   Patrik


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

Re: [DNSOP] My "toxic" remark at the mic today

[Patrik Fältström]

On 5 Nov 2015, at 11:50, John Levine wrote:

> I'm not sure how toxic it is, but I agree that we are unlikely to have
> anything useful to say on the topic.

Speaking personally, I do not see DNAME toxic, but the question has almost 
always been:

- Whether clients do handle DNAME correctly
- How to resolve an interest for having DNAME "work" for the zone apex itself

I think the 2nd of these is a non-issue if "we" do have the assumption data in 
TLDs are "delegation only", which I do know is not true for all TLDs, but it is 
still what i personally think is the best to do.

   Patrik


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

Re: [DNSOP] My "toxic" remark at the mic today

[Patrik Fältström]

On 5 Nov 2015, at 5:47, Andrew Sullivan wrote:

> Is
> there a document that says not to put such a record into the root,
> however?  If not, why should DNSOP say anything about this?  It seems
> like a job for SSAC to me.

SSAC wrote about DNAME in March 2006 in SAC-009 ("Alternative TLD Name Systems 
and Roots: Conflict, Control and Consequences"):

> Recommendation (1): ICANN and the community at large should take appropriate 
> measures to ensure that a thorough analysis of two candidate methods for 
> encoding strings in TLD labels - DNAME Equivalence Mappings and use of IDNA 
> encodings – is concluded quickly. Based on the conclusions and 
> recommendations of parties responsible for this analysis, ICANN should adopt 
> the preferred method.

Unfortunately I can not remind myself that recommendation has been followed...

On top of this,  SAC-053 ("SSAC Report on Dotless Domains") where SSAC have the 
following recommendation:

> Recommendation: Dotless domains will not be universally reachable and the 
> SSAC recommends strongly against their use. As a result, the SSAC also 
> recommends that the use of DNS resource records such as A, , and MX in 
> the apex of a Top- Level Domain (TLD) be contractually prohibited where 
> appropriate and strongly discouraged in all cases.

Let me remind people SSAC recommendations do only have weight based on the 
quality of the report itself. There is no requirement for anyone to follow the 
recommendations. That said, ICANN Board must take SSAC (and other ICANN AC) 
advisories and recommendations into account, i.e. at least explain why the 
advice was not followed.

   Patrik Fältström
   SSAC Chair


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)

[Patrik Fältström]

On 21 Aug 2015, at 21:15, Stephen Farrell wrote:

 Do ICANN have any process for allocating special-use names that will
 not be used in the DNS?

ICANN today do not have any process for doing anything regarding anything in 
the domain namespace except managing the strings that where applied for in the 
previous round of ability to get new TLDs.

ICANN has initiated discussions internally on what must be done before a 
potential next round of TLDs.

It is not possible to know, of course, what those discussions will lead to.

I.e. you have been able to apply for a TLD that is not only allocated for you 
in the namespace, you also get it delegated in the DNS in the root that is 
managed under the contract with NTIA.

You have never been able to request strings for special use that is not created 
as a TLD.

The policy for the previous round of TLDs included a list of strings that one 
could not apply for.

On top of that ICANN have made decisions for a few of the strings, where the 
decisions are:

- Delay delegation indefinitely (sort of, there are many more words)

- Delay delegation as long as the string is viewed as being in the category of 
high risk strings (according to an evaluation process...etc etc)


To conclude, today you can in practice not go to ICANN and request any string 
any kind of status except the TLDs allocated or the strings that are part of 
the current new gTLD round.


personal view
My personal view is that the outcome of these discussions in the IETF is very 
important input to the policy process in ICANN because I think the most 
important thing is that the processes must together cover the complete 
namespace used for, among other things, DNS.
/personal view

   Patrik


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

Re: [DNSOP] My remarks at the mic in the DNSOP meeting the other day

[Patrik Fältström]

On 26 Jul 2015, at 3:06, Andrew Sullivan wrote:

 I wanted to follow up to the list to try again to make clear what I said in 
 the DNSOP meeting the other day.

 In the first place, the point I was trying to make in the business model 
 remark is just this: some of the drafts trying to register special-use names 
 that Christian Grothoff talked about hive out of the DNS uses of names that 
 create a resolution system only in some special network context.  So, just as 
 local. marks something as to be looked up only with mDNS, onion. and exit. 
 both mark something as to be looked up only under onion routing (or maybe, 
 depending on your view, only using Tor).  But others of these proposals, such 
 as bit., mark out a name space and associated protocol that competes with the 
 DNS.
 It is a fully parallel name resolution universe, applicable to absolutely any 
 network application.  My point was that the second class of these basically 
 puts us in the position of approving a special-use registration that is 
 effectively an attack on someone else's business model (ICANN's and that of 
 the various registries and registrars).  I believe that draws the IETF into a 
 political battle for which it is unprepared, and that's really why I object 
 to these registrations.

I agree with this differentiation.

 In the second place, I only now (while checking the recording to make sure I 
 didn't say anything inconsistent with the above) saw Ted Lemon's remarks in 
 the chat.  In response, I don't see what the fact of my being IAB chair has 
 to do with any of this: the IAB chair (and indeed the IAB) has no special 
 power with respect to these
 registrations.  Additionally, in any case I did not get up as IAB chair and I 
 should like to hope it was clear I was speaking only as an individual (but in 
 case it was not, let me emphasise now that I was).
 While it is true that I have made the argument more than once, I think it is 
 a principled argument and given that these applications continue to be under 
 consideration I see nothing wrong with repeating the arugment.  Finally, I 
 don't believe I have ever accused people of being bad actors on this and I 
 should like very much a pointer to an example of my saying that; but in any 
 case, should I somehow ever have said that let me be clear that I do not 
 think _ad hominem_ arguments are valid and I don't think bad actor would be 
 a reason to reject an application.  I am worried about the consequences for 
 the IETF here, not the moral state of the people who are proposing a 
 registration

1. I personally did not misunderstand you.

2. IAB do have a special role here as it is IAB that:

2.1. Is the party responsible for .ARPA

2.2. Is the party that have made statements like for example RFC 2826

I hope and take for granted IAB, and because of that that you WHEN you speak on 
behalf of IAB strongly protect these things. Unless IAB first change the 
situation by saying something else.

   Patrik


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

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

[Patrik Fältström]

On 20 Jul 2015, at 10:22, David Conrad wrote:

 On Jul 20, 2015, at 5:53 AM, David Cake d...@difference.com.au wrote:

 Of course, ICANN has already determined that .corp does pose a security 
 issue of sufficient  significance that .corp will not be delegated.

 For clarity, I believe ICANN has placed the delegation of .CORP on hold 
 indefinitely. I do not believe ICANN has stated that .CORP will not be 
 delegated. Part of the reason for this discussion is due to this fact.

.MAIL is is on hold indefinitely, while .HOME and .CORP (classified as high 
risk) is on hold until they can be reclassfied as low risk.

See for example 
https://features.icann.org/name-collision-occurrence-management-framework

   Patrik


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

[DNSOP] Clarification

[Patrik Fältström]

At the end of the meeting I was the last person at the microphone, and what I 
said was confusing. Let me explain...

First of all, I mentioned I was chair of SSAC. That was not the slightest a way 
of convincing you to listen more to me than others. It was a disclosure. My 
apologies if people did think the intention was different. I have been talking 
with the chair of the meeting (Suzanne) about the issue.

Secondly, what I said was that we do not have any process to add anything to 
the root at the moment. This because the round of new gTLDs ICANN did run has 
closed and you simply can not apply for new TLDs.

Questions have started to be asked to the various constituencies inside ICANN 
(including SSAC) what must be made, if anything, before a potential next round 
has started.

Because of this, whatever IETF will say/do (even if the result is to in a 
conscious way be silent) is timely, and might be extremely important input to a 
potential PDP inside ICANN related to more TLDs.

And this includes of course that SSAC might come with more advice to ICANN to 
work with IETF than what we already have made, for example:

 Resolved (2014.03.27.06), the Board adopts the SSAC advice in SAC062, and 
 directs ICANN's President and CEO, or his designee, to proceed with 
 implementing the recommendations in SAC062.


 :
 :

 The action being approved today is to accept the SSAC's recommendations 
 contained in SAC062 concerning name collisions. As noted in SAC062, the SSAC 
 in general supports the NGPC proposal. SAC062 focuses on three specific areas 
 of the NGPC proposal where SSAC has advice: the action on high-risk strings, 
 trial delegation, and the development of a monitoring framework for the root 
 zone. Specifically, the SSAC recommendations are as follows:

 Recommendation 1: ICANN should work with the wider Internet community, 
 including at least the IAB and the IETF, to identify (1) what strings are 
 appropriate to reserve for private namespace use and (2) what type of private 
 namespace use is appropriate (i.e., at the domain top-level only or at any 
 additional lower level).

   Patrik


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

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

[Patrik Fältström]

On 19 Jul 2015, at 10:02, Steve Crocker wrote:

 When I was chair of ICANN’s Security and Stability Advisory Committee (SSAC) 
 we noted that .belkin was one of the undelegated names that shows up quite 
 frequently at the root.  If .belkin were delegated in the root, it would 
 instantly change the responses those queries are currently receiving, thus 
 raising some questions about security and/or stability for those end systems 
 that have been generating bogus .belkin queries to root for many years.

Later SSAC has continued to look at various namespace collision issues and have 
repeated the comments that various leakages is a. something that will happen 
(as Steve said), and b. because of the leakage it is important names are only 
used within the context they are intended to be used (so that the number of 
false positives is minimized).

If more information is sought for, let me or any SSAC member know, or have a 
look yourself at https://www.icann.org/groups/ssac/documents.

   Patrik Fältström
   Current SSAC Chair ;-)


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

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

[Patrik Fältström]

On 14 Jul 2015, at 22:16, Ted Hardie wrote:

 Further, I believe this stretches the special handling requirement of RFC 
 6761 to the breaking point.  This does not describe special handling _within 
 the DNS_, but instead removes a portion of the global namespace from the DNS 
 at all.  To me, at least, this does not seem to me to meet the analogy RFC 
 6761 provides to IP multicast ranges or local addresses.   Whether it is 
 permitted or not by RFC 6761, it is a bad idea.

Speaking personally I think the intention of RFC6761 was to allow any kind of 
splitting of the namespace used by for example the global DNS so that there 
would not be any confusion and/or questions on how to resolve a specific 
string. See other similar specifications regarding .EXAMPLE, .LOCAL and such. 
And I think this is exactly the kind of need that exists for .ONION. The 
reference (normative or informative) is something I agree can be discussed 
whether it should not have been normative.

If the wording in RFC6761 is such that we do not agree that this is the 
process, but instead that RFC6761 is only for specifications that use the DNS 
for resolution, then I think RFC6761 should be made more clear, and not this 
document.

RFC6761 should be about namespace management, which I think is what we discuss 
here.

Because of this, I think this RFC should be published modulo resolution of the 
question about the reference.

 ​My opinion only,

Likewise ;-)

   Patrik


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?

[Patrik Fältström]

On 4 Jul 2015, at 1:56, manning wrote:

 So I -think- we are on the same page here, although I would replace your use 
 of the phrase, “name space” with domain.  We have empirical evidence of 
 multiple domains using the same name space.
 (Fred Baker persuaded me that there is a single name space, but we 
 partition/segregate by function/purpose).   The same name space for UUCP, 
 CHAOS, Internet, Onion, etc…  just different domains.

This is why I do NOT want to use the word domain, but name space, and why I 
suggest discussion must start there.

Because we, as Warren explained, are discussing collision avoidance when there 
is a risk the same name have multiple use.

   Patrik


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?

[Patrik Fältström]

On 4 Jul 2015, at 8:31, John Levine wrote:

 I guess my question here is, what would prevent House Finch Feathers OY from 
 applying
 for the DNS(IN) string ONION from ICANN because they want that as a TLD in 
 the IN
 class?


 At the moment, nothing.

 Remember, we also have a draft about .HOME and .CORP and .MAIL.  ICANN
 says they're not planning to delegate those names, but they have about
 20 active applications and $3.7M in application fees for those names
 which suggests that their plan may not be entirely final.  That's why
 I think we need an ongoing way to identify names that should stay out
 of the DNS for engineering reasons.

+1

Once again:

ICANN do say what strings in the name space should be TLDs.

IETF do say what strings in the name space should NOT be TLDs.

The rest are just strings waiting to end up in one of the two groups.

   Patrik


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?

[Patrik Fältström]

On 4 Jul 2015, at 18:29, Suzanne Woolf wrote:

 It seems to me, from long experience of both organizations, that ICANN says 
 what names should and shouldn’t be in the DNS root zone—

Well, I have never seen ICANN saying definite no to any string. ICANN only 
say no, this string is not to be ok in THIS round of gTLD applications (as 
part of the result of the PDP), or we defer delegation indefinitely.

If you have other data, please let me know.

As a chair of SSAC I am interested... ;-)

   Patrik


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?

[Patrik Fältström]

Unfortunately I think we all in this discussion [again] mix up discussion about 
DNS with the discussion about the name space that is in use for example by what 
we know as the domain name system rooted at the root zone managed by IANA.

I think we just must force ourselves to stay focused on namespace management. A 
portion of that name space is to be accessed using DNS. Some other portions of 
that very same name space is access using other mechanisms.

This is not easy, but I think that is the way to attack the problem.

And given such a view, IETF is to decide what strings are to be used by other 
mechanisms so that [for example] they can and should never ever be accessed by 
the domain name system.

This while ICANN have processes for deciding what string should be TLDs, based 
on the standards created by for example the IETF.

Maybe a document is needed that describes that namespace? How it is partitioned?

  Patrik

On 3 Jul 2015, at 16:21, manning wrote:

 Thanks for that.  The original claim was that these name spaces were global 
 in scope, but not part of the Internet.
 So I took that as face value.  Your example, while perhaps a valid 
 interpretation, is not what was asked for.
 If it is, then namespace/class specific applications/extentions need to be 
 developed/deployed, OR folks need to suck it up and just use the Internet 
 portion of the DNS (and its associated rules, e.g. new TLDs are defined by 
 ICANN)

 /bill


 On 3July2015Friday, at 7:01, Warren Kumari war...@kumari.net wrote:

 On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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...

 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 bmann...@karoshi.com wrote:


 On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws 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



 -- 
 I don't think the execution is relevant when it was obviously a bad
 idea in the first place.
 This is like putting rabid weasels in your pants, and later expressing
 regret at having chosen those particular rabid weasels and that pair
 of pants.
 ---maf

 ___
 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?

[Patrik Fältström]

On 3 Jul 2015, at 20:11, manning wrote:

 I guess my question here is, what would prevent House Finch Feathers OY from 
 applying for the DNS(IN) string ONION from ICANN because they want that as a 
 TLD in the IN class?

Nothing, if that is the goal, which I claim it is not.

The goal is to ensure that portion of the name space, rooted at ONION, is _not_ 
existing the portion of the name space reachable by the normal DNS. To ensure 
the name space is properly partitioned.

  Patrik


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

Re: [DNSOP] Character encoding of URI Target RDATA?

[Patrik Fältström]

On 18 Jun 2015, at 6:53, Tony Finch wrote:

 Patrik Fältström p...@frobbit.se wrote:


 The over arching issue here is that there is no right answer regarding
 non ascii in URIs.


 What about RFC 3987 ?

Not everyone have implemented it, and the consensus when creating the URI RR 
was that the RR should not be limited to only IRIs.

I see an issue with IETF not stating clearly IRI's (i.e. UTF-8 and then 
%-encoding) are in use is a problem both here and there. And such a statement 
is what I think is needed for not only the URI RR but also other cases.

   paf


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

Re: [DNSOP] Character encoding of URI Target RDATA?

[Patrik Fältström]

On 17 Jun 2015, at 16:52, bert hubert wrote:

 At least if the RFC does not specify it, we should pick something.

The over arching issue here is that there is no right answer regarding non 
ascii in URIs.

A URI is a sequence of characters, but in HTTP the path must be ascii only, and 
can have %-encoded bytes -- without telling what charset is in use.

Because of this, I would say one can in RDATA store a URI in any charset, but 
when the URI is used, it should have 8-bit bytes %-encoded.

That said, libcurl do happily(?) send whatever bytes you give it over the HTTP 
connection, so %-encoding must happen before libcurl is used.

Earlier versions of the draft suggested one should use UTF-8 for the URIs in 
RDATA, which imply among other things the path should be %-encoded, but the 
question then was whether it also should be normalized etc etc...

And what if someone want non-UTF-8 in a URI?

What we have to remember is that whoever knows the URI and creates the RR also 
run the web site (for example) that is to be accessed. Because of this, the 
only question has to do with the %-encoding.

My PERSONAL preference would be to allow either %-encoded or non-%-encoded 
bytes in RDATA and that whoever consumes RDATA have to decide whether 
%-encoding should be applied or not. I would apply it if I where a programmer. 
:-)

Because of this, Bert, I would store things in UTF-8, and hope for the best :-)

   Patrik


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

Re: [DNSOP] Character encoding of URI Target RDATA?

[Patrik Fältström]

On 16 Jun 2015, at 22:45, Robert Edmonds wrote:


John Levine wrote:
What I'm asking is how the octet sequences provided by the URI RR 
RFC
are decoded into the sequences of URI characters used by the URI 
RFC.

Is there a generic way to do this, or does it depend on the specific
protocol (e.g., HTTP), or is it left up to the application?


As far as I can see, RFC 3986 defines URIs as sequences of ASCII
characters.  In the few places where they mention non-ASCII material,
it says to represent them as percent encoded UTF-8, so it's still all
ASCII.


OK.  That RFC seems to distance itself from mere octets.


Can you give an example of URI RDATA where it would make sense to
interpret it other than as ASCII?


This is the FTP example from the URI RR RFC, to which the UTF-8 byte 
order mark has been gratuitously added:


Hmm...what RFC are you referring to? I can not find this in RFC 7553.

 TYPE256 \# 36 
000a0001efbbbf6674703a2f2f667470312e6578616d706c652e636f6d2f7075626c6963


or, equivalently,

 URI 10 1 \239\187\191ftp://ftp1.example.com/public;

Attempting to decode it as ASCII simply does the wrong thing, but I 
don't see any reason that it's not a valid URI RR, and, knowing that 
it's encoded as UTF-8 w/ BOM, it can be successfully parsed into a URI 
(provided the Target field is handed off to the URI-parsing 
application as raw bytes, and not as a string with DNS zone file \DDD 
style escapes).


The RFC says this:

This field holds the URI of the target, enclosed in double-quote
characters (''), where the URI is as specified in RFC 3986
[RFC3986].  Resolution of the URI is according to the definitions for
the Scheme of the URI.


I suppose to be perfectly clear we might either say percent encode
everything or we might say unencoded UTF-8 is allowed.  They're
both unambigious, and I expect most parsers can handle both.


It would be very nice indeed if application developers did not have to 
guess at the encoding of the bytes.


Earlier versions of the I-D did say explicitly that UTF-8 encoded 
characters is how the Target is to be interpreted, but feedback gave 
that it is better to just reuse the same specification as URIs. I.e. the 
interpretation is according to RFC 3986 (which implies unclear where 
3986 might be unclear).


   Patrik

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

Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps

[Patrik Fältström]

On 28 May 2015, at 11:17, Suzanne Woolf wrote:

 The IETF doesn't decide what goes into the root zone. ICANN does

The IETF decide what does NOT go into the root zone, while ICANN do decide what 
goes into the zone.

ICANN can only delay their decision of adding things by not yet saying 
yes.

That's the difference I see.

   Patrik


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

Re: [DNSOP] Agenda and logistics Re: Reminder: Interim Meeting on Special Names and RFC 6761 12-May-2015

[Patrik Fältström]

People might not come before the main session has ended.

:-)

   Patrik

On 12 May 2015, at 17:26, Kaveh Ranjbar wrote:

 Hello,

 If you are at the RIPE Meeting:

 The room is called MEERMAN I/II , right next to the elevators. There are blue 
 sheets ready here and we will try to put the projector and external 
 speaker/microphone we have here to use.

 All the best,
 Kaveh.

 On 12 May 2015, at 16:30, Suzanne Woolf suzworldw...@gmail.com wrote:

 For those attending RIPE, we've been told a room has set aside.


 ___
 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] EU ISO-3166 code (was Re: I-D Action: draft-ietf-dnsop-dns-terminology-01.txt)

[Patrik Fältström]

On 4 May 2015, at 7:16, Patrik Fältström wrote:

 I.e. 3166/MA is very careful with it not being the ones that register codes.

Let me add...but they have not been so careful with what codes they reserve. 
Remember that in those days the list of reserved codes was not public (although 
IANA did have access to it as part of the coordination I try to describe).

The issue with referencing something only being reserved by ISO 3166/MA and not 
registered implied a much lower barrier had been passed to get a ccTLD. It 
would only require being on the reserved list. When in reality ISO 3166/MA 
rather want ICANN to decide what should be a ccTLD (part from registered codes) 
and then when ICANN had allocated something that was not registered, it could 
become registered by 3166/MA.

The reserved list was made for, as you imply make it easier for people like 
ICANN to do the allocation. But ICANN can not do the allocation with the 
argument that it is reserved. ICANN could have said we allocate this because 
we a. want to, and b. because according to what we see in the material ISO 
8859/MA produces, there is a very low risk of future collissions.

But instead ICANN have, and still am, referring to EU be on the reserved list 
(and now exceptionally reserved) as a reason to allocate as a ccTLD.

I.e. I have to try to explain this story about every year, to ICANN staff, 
which I feel is sad.

   Patrik


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

Re: [DNSOP] EU ISO-3166 code (was Re: I-D Action: draft-ietf-dnsop-dns-terminology-01.txt)

[Patrik Fältström]

On 4 May 2015, at 10:25, Suzanne Woolf wrote:

 On May 4, 2015, at 9:22 AM, Andrew Sullivan a...@anvilwalrusden.com wrote:
 I still think that defining TLD is
 useful, and I suspect in that definition we'd want to add the
 sentence, TLDs are often divided into ccTLDs and gTLDs; the division
 is a matter of policy in the root zone, and beyond the scope of this
 document. Or something like that.  Any objection?  The point of
 adding this is to give people some clue about these terms when they
 come across them and to indicate that it's a matter of policy and not
 protocol.

 This is exactly what needs to be said. I don’t think you can go further 
 without getting lost in the weeds, and I don’t think it’s necessary— 
 operators just need to know the distinction isn’t protocol.

Agree. I think the largest issue is:

a. Policy in general (how the TLD is approved, registry appointed/redelegated 
etc)

b. Eventual contractual arrangements with ICANN corp

   paf


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-dns-terminology-01.txt

[Patrik Fältström]

On 4 May 2015, at 3:22, David Conrad wrote:

 Patrik,

 Also note that there are ccTLDs allocated for codes that are not 
 registered in ISO3166 (UK, EU etc).

 IIUC these two are on the 3166 list as exceptionally reserved codes.

 Yes, but not REGISTERED, and that difference is something that created more 
 than just a little bit of excitement including ISO asking whether ICANN do 
 not understand what a registered code is when .EU was allocated.

 Are you using a formal definition of registered in this context?

Yes.

 Also, I'm curious: was there any excitement and/or did ISO ask similar 
 questions when (say) .AC was created (in 1997, as opposed to .EU, which was 
 created in 2005, according to IANA's whois)?

Not that I know of.

 That is, was Jon's (apparent) policy of allocating TLDs for exceptionally 
 reserved codes (a policy continued by ICANN) a source of 
 excitement/questions from ISO or others or was the eyebrow raising just 
 because ICANN was involved in .EU?

What ISO 3166/MA said was that the _only_ difference between the two, and the 
reason why they reacted on .EU, was that ICANN referred to .EU being reserved 
as a reason for registration. More below. If ICANN had only been registered EU 
with reference to what EU themselves had done, that would have been different. 
Yes, pedantic, but if that is what 3166/MA wants I think they should get that. 
And at the same time allow ccTLDs to be created more freely. If you understand 
what I mean.

 I was just after 1. trying to not use the term country and 2. pointing out 
 a recognition that some ccTLDs are allocated with two character codes which 
 are not *registered* in ISO 3166.

 My understanding of the usage of Exceptionally Reserved codes is that they 
 are codes that have been reserved for a particular use at special request of 
 a national ISO member body, governments or international organizations and 
 that as such, those codes cannot be used for any other country.  That would 
 appear to fit the definition of registered to me, but I'm unsure what 
 definition of register you're using.

Registered is a special table at ISO 3166/MA uses, which are not the reserved 
or exceptionally reserved.

 The point of this pedantism is that RFC 1591 (the basis for using 3166 for 
 two-letter TLDs as far as I am aware) did not say that only general purpose 
 codes could be used for ccTLDs, it merely said the two letter country 
 codes from ISO-3166. Since ISO defines everything in ISO-3166-1 Alpha-2 as 
 a country code (even things that are clearly not countries, e.g., UM and 
 FX), it would seem reasonable to me to simply put country in quotes (with 
 perhaps a footnote saying the countries are more than just countries).

According to 3166/MA, _any_ code that people want to use can be used for 
anything. They *register* what _other_ organizations use. So the sensitivity 
here is in what direction the pointer is pointing.

3166/MA is specifically reserving things that other organization uses. I.e. 
3166/MA want to have an exceptionally reserved code of EU just because ICANN 
has decided to use EU as a ccTLD. To be able to do that, they do not want ICANN 
to register a ccTLD of .EU with an argument that 3166/MA has reserved EU. That 
would end up being a circular reference.

A *registration* in 3166/MA on the other hand is something that happens because 
someone else (UN Statistics Division, UPU or someone) decides to use a code, 
and 3166/MA decides to actually register the code. That can be referenced by 
anyone (except the one that have done the registration).

I.e. 3166/MA is only acting based on decisions other parties have made, not the 
other way around.

   Patrik


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-dns-terminology-01.txt

[Patrik Fältström]

On 30 Apr 2015, at 16:40, George Michaelson wrote:

 economy and economycode is a useful concept sometimes. it avoids the CN/TW
 issue. and encompasses HK.

 state or territory can be useful. covers some of the intermediate things.
 eg much of the CIS is a 'transitional state' according to the UN.

 iso-3166 encompasses non-state entities, AP is reserved for the african
 fisheries forum.

 EU is delegated. its not the same as INT.

 BTW, at some stage, its possible the economies will usurp the 3 letter
 codes and assert a right to have them in the DNS...

Also note that there are ccTLDs allocated for codes that are not registered in 
ISO3166 (UK, EU etc).

Suggested new text:

ccTLD -- A TLD that is allocated to distinct economies.  Historically, these 
were two-letter TLDs, and were allocated to economies using the two letter code 
for the economy taken from the ISO 3166-1 alpha-2 standard [ISO3166] although 
exceptions exists. In recent years, there have been allocations of TLDs that 
conform to IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and 
[RFC5894]); these are still treated as ccTLDs for policy purposes.

   Patrik

 On Thu, Apr 30, 2015 at 4:35 PM, Andrew Sullivan a...@anvilwalrusden.com
 wrote:

 On Wed, Apr 29, 2015 at 07:28:21PM +, Edward Lewis wrote:
 #ccTLD -- A TLD that is allocated to a country.  Historically, these
 #were two-letter TLDs, and were allocated to countries using the two-
 #letter code from the ISO 3166-1 alpha-2 standard [ISO3166].  In
 #recent years, there have been allocations of TLDs that conform to
 #IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]);
 #these are still treated as ccTLDs for policy purposes.

 Country is a loaded term.  I don't have a better suggestion in mind but
 there are many instances where a ccTLD is a territory, etc.  I don't mean
 to open a rathole, just point this out.

 If we changed this to say, A TLD that is allocated using the UN
 country list using the the two-letter code from the ISO 3166-1 alpha-2
 standard [ISO3166], would that address your concern?

 Might as well also list sTLD for sponsored.  Technically there is no
 difference, it's all in the way the registry has been instituted.

 ICANN's own policies don't actually seem to enforce the sTLD/gTLD
 distinction, and nobody ever mentions sTLDs, so I'd as soon leave it
 out.

 I never thought NODATA meant NOERROR, just simply an empty answer
 section.

 NODATA comes with a NOERROR header, or it's not a NODATA response.

 # 6.  Zones

 #Parent -- The domain in which the Child is registered.  (Quoted from
 #[RFC7344], section 1.1) Earlier, parent name server was defined in
 #[RFC0882] as the name server that has authority over the place in
 #the domain name space that will hold the new domain.

 Speaking from personal experience, I'd use delegated and not
 registered.
 In my world, there is a distinction in what is registered and what is
 delegated.  I don't mean to derail this into a registry vs. DNS
 operations discussion, just saying that the term registered means
 something different in a field (registration of domain names and internet
 numbers) very close to DNS.

 We want to cleave to the quoted documents, but do you wnat us to add
 discussion about the distinction between registration and
 delegation?  There's in fact a distinction also with allocation,
 but I'm not sure it belongs here.

 #Delegation -- The process by which a separate zone is created in the
 #name space beneath the apex of a given domain.  Delegation happens
 #when an NS RRset is added in the parent zone for the child origin,
 #and a corresponding zone apex is created at the child origin.
 #Delegation inherently happens at a zone cut.

 I agreed up until and a corresponding...  Once the parent creates the
 zone cut, the delegation is made.  The distinction is that in the world
 of
 operations, the child's servers may be unavailable (down or cut off the
 net).  The delegation is still there, no one can confirm the
 corresponding stuff mentioned here.

 Hmm, this is an interesting point.

 Vice versa, once the parent removes
 the NS set, the delegation is removed regardless of what the child
 thinks.

 Well, effectively maybe not.  If a resolver sticks on the child,
 then the delegation won't move regardless.

 #Referrals -- ...  Historically, many
 #authoritative servers answered with a referral to the root zone when
 #queried for a name for which they were not authoritative, but this
 #practice has declined.

 Not declined - seen as a vulnerability and removed from code.

 That's one kind of decline, isn't it?

 A

 --
 Andrew Sullivan
 a...@anvilwalrusden.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

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

[Patrik Fältström]

On 30 Apr 2015, at 19:10, Alain Durand wrote:

 On 4/30/15, 11:23 AM, Warren Kumari war...@kumari.net wrote:


 The RIPE staff has been very nice and made a room available at RIPE-70
 https://ripe70.ripe.net/:

   Meerman I/II for ~30 people on Tuesday 12 May 18:00- 20:00 Amsterdam

   Jaap



 Very cool. Do we need to sign up?

Ill be there!

   paf


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-dns-terminology-01.txt

[Patrik Fältström]

On 30 Apr 2015, at 18:34, Kim Davies wrote:

 If an allusion to the purpose is useful, then:

 A TLD that is allocated for use based on an entry in the ISO 3166-1
 standard [ISO 3166-1]. The ISO 3166 standard provides codings of
 countries and their subdivisions.

A TLD that is allocated for use based on an entry in the ISO 3166-1 standard 
[ISO 3166-1], although exceptions do exist. The ISO 3166 standard provides 
codings of countries and their subdivisions.
 
   Patrik


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-dns-terminology-01.txt

[Patrik Fältström]

On 1 May 2015, at 12:00, Jim Reid wrote:

 On 1 May 2015, at 08:31, Patrik Fältström p...@frobbit.se wrote:

 Also note that there are ccTLDs allocated for codes that are not registered 
 in ISO3166 (UK, EU etc).

 IIUC these two are on the 3166 list as exceptionally reserved codes.

Yes, but not REGISTERED, and that difference is something that created more 
than just a little bit of excitement including ISO asking whether ICANN do 
not understand what a registered code is when .EU was allocated.

I.e. ISO 3166/MA had nothing against .EU be allocated. In fact, given .EU was 
allocated as a ccTLD there was so much more reason to have EU as an 
exceptionally reserved code in 3166. But not the other way around.

 Suggested new text:

 ccTLD -- A TLD that is allocated to distinct economies.  Historically, these 
 were two-letter TLDs, and were allocated to economies using the two letter 
 code for the economy taken from the ISO 3166-1 alpha-2 standard [ISO3166] 
 although exceptions exists. In recent years, there have been allocations of 
 TLDs that conform to IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], 
 and [RFC5894]); these are still treated as ccTLDs for policy purposes.

 I think it is unwise to use terms like economies. Some ccTLDs on ISO 3166 
 are uninhabited and/or have no economy. Mentioning allocation could raise the 
 unwelcome issue of who/what these TLDs get allocated to.

That is fine with me.

I was just after 1. trying to not use the term country and 2. pointing out a 
recognition that some ccTLDs are allocated with two character codes which are 
not *registered* in ISO 3166.

 This definition may be better:

 ccTLD -- A two letter string taken from the ISO 3166-1 alpha-2 standard 
 [ISO3166] although there are some exceptions. TLDs conforming to IDNA2008 
 ([RFC5890-4]) have been created for some of these ccTLD and these IDNA2008 
 strings are treated as ccTLDs for policy purposes.

Works for me.

   Patrik


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

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

[Patrik Fältström]

 On 2 apr 2015, at 21:51, Paul Hoffman paul.hoff...@vpnc.org wrote:
 
 Given this thread, I propose the following for the draft:

Well, I would change things around so that it is more clear primary and 
secondary are the terms to use today, like:

Primary servers and secondary servers --- These where historically named 
master server and slave server, which were the terms used in the early DNS 
RFCs. The current common usage has shifted to primary and secondary.

Secondary server --- An authoritative server which uses zone transfer to 
retrieve the zone. (See {{RFC1996}}, section 2.1) {{RFC2182}} where secondary 
(slave) servers are described in detail.

Primary --- Any authoritative server configured to be the source of zone 
transfer for one or more secondary servers. (See {{RFC1996}}, section 2.1) 
{{RFC2136}} where primary (master) servers are described as an authoritative 
server configured to be the source of AXFR or IXFR data for one or more slave 
servers.

It should be noted that both of these are roles. For example, a server that is 
secondary can also act as a primary server for another secondary server.

   Patrik



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

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

[Patrik Fältström]

 On 2 apr 2015, at 20:50, Dave Lawrence t...@dd.org wrote:
 
 Paul Hoffman:
 I added the synonym for slave. How do people feel about primary
 and master?
 
 Personally I'm not fond of the master/slave language and avoid the
 terms.  I recognize their historic computer use and don't feel the
 need to be preachy about it, but in my own speech I use
 primary/secondary.

+1

   Patrik



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

Re: [DNSOP] Using NSEC3 for opt-out, was Re: Comments regarding the NSEC5

[Patrik Fältström]

 On 15 mar 2015, at 17:30, Ondřej Surý ondrej.s...@nic.cz wrote:
 
 JFTR .cz was asked by The Office for Personal Data Protection to implement 
 measures to protect the personal data for domain holders.  NSEC3 was part of 
 the solution.

Can you explain more how that was part of the solution?

   Patrik



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

Re: [DNSOP] Using NSEC3 for opt-out, was Re: Comments regarding the NSEC5

[Patrik Fältström]

 On 15 mar 2015, at 21:19, Ondřej Surý ondrej.s...@nic.cz wrote:
 
 This is really vague memory of it, but the main problem was that NSEC 
 enumeration with public whois allowed data scraping.

Ok, but the real problem was then that all registered domain names where also 
delegated? Together with all data existing in Whois?

Not really DNSSEC related.

 Thus whois rate limiting, implementation of hide-this flags and NSEC3 was 
 deployed to prevent majority of it. Some limits were also implemented in the 
 registry to prevent cross-registrar data digging via EPP.

Ok.

   paf




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

Re: [DNSOP] Is there a concise and comprehensive definition of a zone file?

[Patrik Fältström]

 On 22 feb 2015, at 20:58, Paul Hoffman paul.hoff...@vpnc.org wrote:
 
 As for Måns original question: converting wire-format IDNA to some encoding 
 of Unicode characters is unstable because some registries use IDNA2003 rules, 
 others use IDNA2008 rules, and some labels in the former can't be represented 
 in the latter. Yes, IDNA2008 obsoleted IDNA2003; that is irrelevant to the a 
 good chunk of the operator community.

It is correct that the policy for what Unicode Characters are allowed have 
changed over time (even for IDNA2008 it changes when the Unicode version 
changes).

But the _encoding_ of the characters is the same.

So maybe some of the maybe disagreements are not disagreements after all?

   paf



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

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

[Patrik Fältström]

Now at last I have had time to read this...sorry for the late response.

Let me suggest first of all a change in the structure of the document.

For example, in section 2 where you talk about message format, just talk 
about the message format. Query, Answer, Additional information etc. How these 
play in queries and responses. How EDNS0 fit into this. What header flags are 
and what they mean.

Then you go into resource record sets.

And then resource records.

That is for the DNS server side and you can move to the client side.

And if you define a term like owner, then you should use it yourself and not 
say label as you do in definition of resource record type (or vice versa) :-)

   Patrik

 On 28 nov 2014, at 16:28, Paul Hoffman paul.hoff...@vpnc.org wrote:
 
 Greetings. Andrew and Kazunori and I have prepared the first draft of what 
 will hopefully be a useful document collecting definitions that useful in the 
 DNS community. We fully admit that this is quite rough, and didn't even try 
 to do definitions for some of the terms that we expect to be filled in before 
 we are done.
 
 The idea is that this will be an IETF consensus document, if possible, but we 
 are not yet asking for adoption in the DNSOP WG, and we might not even later. 
 For now, we'd like to hear what additional terms should be added, what 
 clarifications to the terms we already have would be helpful, and so on.
 
 --Paul Hoffman
 
 A new version of I-D, draft-hoffman-dns-terminology-00.txt
 has been successfully submitted by Paul Hoffman and posted to the
 IETF repository.
 
 Name:draft-hoffman-dns-terminology
 Revision:00
 Title:   DNS Terminology
 Document date:   2014-11-28
 Group:   Individual Submission
 Pages:   9
 URL:
 http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-00.txt
 Status: 
 https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/
 Htmlized:   http://tools.ietf.org/html/draft-hoffman-dns-terminology-00
 
 
 Abstract:
  The DNS is defined in literally dozens of different RFCs.  The
  terminology used in by implementers and developers of DNS protocols,
  and by operators of DNS systems, has sometimes changed in the decades
  since the DNS was first defined.  This document gives current
  definitions for many of the terms used in the DNS in a single
  document.
 
 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop



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

Re: [DNSOP] DNS URI code point wire format

[Patrik Fältström]

On 31 jul 2014, at 06:14, Mark Andrews ma...@isc.org wrote:

   When DNS code points are issued based on the request template
   the wire and presentation values are supposed to be fixed.
 
   URI was issued against draft-faltstrom-uri-05/06.  The wire
   format has been changed in draft-faltstrom-uri-08 in
   particular how the target field is encoded.
 
   named implemented URI as per draft-faltstrom-uri-05/06
   unbound implemented URI as per draft-faltstrom-uri-08
 
   We now have two incompatible implementations in the wild.
 
   We are going to change named to implement draft-faltstrom-uri-08.
   The changes were just committed and will be available in
   the upcoming maintainence releases.
 
   I would suggest that IANA update or otherwise make a note
   that the wire encoding is that from draft-faltstrom-uri-08
   or else there will be future incompatibilities.

FWIW, I am in discussion with IESG on the need for publication of the I-D as an 
RFC that IANA can reference.

   Patrik



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

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

[Patrik Fältström]

On 8 jul 2014, at 08:22, David Conrad d...@virtualized.org wrote:

 On Jul 7, 2014, at 10:02 PM, Patrik Fältström p...@frobbit.se wrote:
 The main argument against slaving the root I've seen appears to me to be 
 FUD: people running resolvers are too stupid to configure slaving the root 
 correctly so root data will go stale! (paraphrased).
 
 I am a bit disappointed that you David do summarize the arguments against 
 this proposal in this way.
 
 Sorry to disappoint you by stating how the main arguments against the draft 
 appear to me.

That I understand, and I myself react like that regarding arguments both in 
favor and against the proposal. One could say the discussion is a typical 
non-constructive IETF discussion which too many are.

 What I have recommended Warren to do is to properly list the arguments, make 
 a proper analysis (an attack tree would be one good start) because my 
 largest fear is that the various issues that might look like weaknesses of 
 the proposal must be analyzed, and that they are not.
 
 I'm sure Warren will do an outstanding job if he chooses to obey your 
 recommendation.
 
 Perhaps one of the undoubtedly many reasons for your disappointment is that I 
 am taking the system as it currently exists (as least as I understand it). As 
 far as I am aware, that system does not have any solution to:
 
 - Lack of DNSSEC validation
 - The fact not all data in the root zone is signed
 - Lack of legal protection of the root zone itself
 
 Do you believe the current system addresses these concerns? If so, how?

The discussion about these things, and the differences between a cache and 
authoritative server I would like to have in a room where people are not 
shouting at each other. There are differences, and you know that as well as I.

 With respect to the others:
 
 - Recovery process when bad data end up in the resolver (cache v.s. auth)
 
 As I've pointed out, if bad data is being served to clients of a resolver, 
 those affected can call up their resolver operator and demand they fix it. 
 Since the users of the resolver may actually be paying customers, there might 
 even be a chance that the resolver operator will listen.

The market economy forces fixing things is correct. What I was thinking of is 
for example the difference between restarting a caching resolver and re-priming 
an auth server. Sure, everyone can learn both recovery mechanisms, but restart 
your server is quite simple task. Once again, I want the arguments listed.

 What would be the recovery process if the existing root server system 
 distributed bad data?  If I root started serving bad data, how would anyone 
 non-technical know even who to call?  Assume they know how to call their 
 ISP's help desk and that help desk is able to figure out it is the I root 
 server that is serving the bad data. How will that help desk implement a fix 
 on the I root server? What is the likely timeframe from detection of 
 problem to fix compared to the slaving the root scenario?

You here list a few to me different problems. If people get wrong data from the 
IP address of I they call Netnod.

 More generally, what recourse does _anyone_ have if a root server operator 
 (say) chooses not to upgrade bandwidth to their root when it drops the 
 majority of queries? Or goes off the air for a few days? Or doesn't deploy 
 IPv6?

That is, as you know, also an interesting discussion.

 - Routing issues (which is what I see the largest burden of a root server 
 operator)
 
 Must have missed this one and am unsure what it means in this context. What 
 routing issues were asserted that resolver operators that slave the root are 
 going to have?  It would seem to me that the slaving the root approach can 
 vastly simplify the routing (no need for inter-AS anycast) so I must be 
 missing something.

What I want to have examined is how to ensure the right data is coming to 
whoever wants it, and who is responsible to clean up when there are issues.

Today, as you say yourself, the responsibility is on the root server operators.

 - Political/regulative implications (to ensure a different TA is used than 
 ICANN)
 
 I'm confused. Did you mean to stop someone from using a different TA? What's 
 to stop someone from doing that now?

I see it as a big difference between having auth data (explicitly changed) 
within a difficult democracy and having caches of the data. Sure, some of them 
have already implemented what you talk about but having IETF explicitly saying 
auth data is coming from recursive resolvers will from my point of view 
drastically increase the amount of blocked DNS traffic across the global 
Internet and that will indeed impact network neutrality.

 ...and possibly more.
 
 Yes, perhaps there are more and perhaps if Warren obeys your recommendation, 
 they'll be discovered. However, as many people have pointed out, _people are 
 already slaving the root_ and oddly disaster has not befallen the Internet

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

[Patrik Fältström]

Note that I only listed a hand full of issues I immediately think of that I 
think needs to be compared and evaluated. Like Suzanne wrote. In some cases 
there is no difference between an auth server and cache, in other cases there 
might be.

 On 8 jul 2014, at 16:18, Paul Hoffman paul.hoff...@vpnc.org wrote:
 
 On Jul 7, 2014, at 10:02 PM, Patrik Fältström p...@frobbit.se wrote:
 
 - Recovery process when bad data end up in the resolver (cache v.s. auth)
 
 That's the cache has gone stale issue that David raised. It is dealt with 
 in the current draft. There is no other way for bad data to be in the cache 
 other than by having it come from a signed root zone that has changed.

Not all data in a signed zone is signed. But I appreciate you say you feel you 
have been thinking about it.

My point is that I really really really want to know that the unsigned info in 
a signed zone is NOT treated differently in an auth server than a cache.

Once again, I list questions.

 - Routing issues (which is what I see the largest burden of a root server 
 operator)
 
 The draft does not impose any routing issue on the root. In fact, it says 
 that the signed root might be gotten from entities that are not root zone 
 operators.

I understand my statement was weird. Today when clients get weird responses 
they look where they get the response from, identify one of the 13 ip addresses 
and contact the root server that quite often do various monitoring and 
protection of the routing of that very IP address. I.e. responding to DNS 
queries is one thing, managing one of the key ip addresses is another.

Yes, I understand that is not really an issue if the resolver is auth for the 
root zone.

 
 - Lack of DNSSEC validation
 
 The draft says repeatedly that the information is only entered if it is 
 DNSSEC validated. If you can find any sentence in the draft that says 
 differently, I'll fix it immediately.

How is that policed?

Yes, people can say that that already happens which of course is true. But I 
see a difference between recommending this and just making it possible, from 
the IETF.
 
 - The fact not all data in the root zone is signed
 
 That is a statement with no effect. If the data is not signed when it is 
 retrieved from the signed root zone, it will be unsigned when retrieved using 
 normal queries to the root zone.

See above.

 - Political/regulative implications (to ensure a different TA is used than 
 ICANN)
 
 That is a statement with no effect. Nothing in the draft changes the TA used 
 to validate the root zone, so a validating recursive resolver acts 
 identically whether it uses the mechanism or not.

Not really.

If you are auth, then queries by definition do not leak to a place where a 
different TA is needed.

 - Lack of legal protection of the root zone itself
 
 Please try to explain this. The root zone operators current serve the root 
 zone signed with DNSSEC. This draft doesn't change that, so there are no new 
 legal implications.

The root server operators (at least for example the three outside of the US) 
have an MOU with ICANN that say we will serve the zone ICANN serves. Where is 
the same protection between end users in $state using $isp under 
$regulative_policy that the same zone is served?

In this case I want $state to have for example have signed a treaty saying the 
root zone is not to be modified.

 ...and possibly more.
 
 That is not helpful.

Well, I was responding to drc that wrote something in affect, and my intention 
was to show a subset of issues to address and look at, as a longer list that 
what drc listed.

 ...and of course a combination of these.
 
 Umm, that is not helpful either.

That was to protect myself. For example, the fact not everything in the root 
zone is signed, ability to sign and produce a new root server with new TA with 
not a complete root zone in $state under some interesting $regulation. Possibly 
using the same (or different ip addresses) than what is used today.

I hope proponents of this proposal can explain why this is different than an 
alternate root.

 Once again, this is such a large issue that I would prefer a bit better 
 arguments than what is demonstrated here.
 
 The reason that there are not arguments in the -01 draft to deal with your 
 issues above is that they seem unrelated to the draft. It is hard to have a 
 section that says Someone objected that this does X, but they are wrong 
 that has a finite length.
 
 Yes, I know you wrote in affection, but let this remind all of us that we 
 can do better.
 
 Sure, but bringing up issues that are just as true whether or not the draft 
 is implemented is not doing better. Having a list of issues that come from 
 what the draft changes would be great: we can deal with those.

Understood. Once again, I responded more to the mail from drc than address the 
draft per se.

   Patrik

 
 --Paul Hoffman
 
 P.S. None of the above relates to Joe's big issue, which is that implementing

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

[Patrik Fältström]

On 8 jul 2014, at 20:30, David Conrad d...@virtualized.org wrote:

 On Jul 7, 2014, at 11:39 PM, Patrik Fältström p...@frobbit.se wrote:
 One could say the discussion is a typical non-constructive IETF discussion 
 which too many are.
 
 Seems like it has been (mostly) a constructive discussion to me.

Now yes, I completely agree!

 Once again, this is such a large issue that I would prefer a bit better 
 arguments than what is demonstrated here.
 
 Actually, since it is opt-in, it doesn't seem to be that large of an issue 
 to me, but perhaps that's because I'm not a root server operator and have 
 no particular interest in maintaining the status quo.
 
 I do not see it as opt-in. Definitely not. I see this draft be a tool that 
 is used to force opt in to a different root zone than what ICANN is 
 managing. A very effective tool regarding fragmenting the Internet.
 
 And having an incoming CTO of ICANN requesting fragmentation of the Internet 
 actually worries me a bit.
 
 Because of this, I think it must proven that increased deployment of this 
 technology will not increase fragmentation of the Internet.
 
 I'll admit I'm quite surprised and disappointed in your response here.  I 
 hope you'll forgive me if I choose not to respond to you further on this 
 thread.

That is completely understood, and excuses are not needed, if you forgive me ;-)

I was, as you saw, surprised myself over your words in the mail I responded to.

   Patrik



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

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

[Patrik Fältström]

On 8 jul 2014, at 02:55, David Conrad d...@virtualized.org wrote:

 The main argument against slaving the root I've seen appears to me to be FUD: 
 people running resolvers are too stupid to configure slaving the root 
 correctly so root data will go stale! (paraphrased).

I am a bit disappointed that you David do summarize the arguments against this 
proposal in this way. Several various weaknesses of the proposal have been 
explained at several occasions (although of course also them with a bit of hand 
waving), and they are definitely not fud and definitely not limited to people 
making mistakes.

What I have recommended Warren to do is to properly list the arguments, make a 
proper analysis (an attack tree would be one good start) because my largest 
fear is that the various issues that might look like weaknesses of the proposal 
must be analyzed, and that they are not.

I have at least heard:

- Recovery process when bad data end up in the resolver (cache v.s. auth)

- Routing issues (which is what I see the largest burden of a root server 
operator)

- Lack of DNSSEC validation

- The fact not all data in the root zone is signed

- Political/regulative implications (to ensure a different TA is used than 
ICANN)

- Lack of legal protection of the root zone itself

...and possibly more.

...and of course a combination of these.

Once again, this is such a large issue that I would prefer a bit better 
arguments than what is demonstrated here.

Yes, I know you wrote in affection, but let this remind all of us that we can 
do better.

Ok?

Patrik



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

Re: [DNSOP] Extended CNAME (ENAME)

[Patrik Fältström]

On 20 maj 2014, at 14:17, Petr Spacek pspa...@redhat.com wrote:

 Hmm, would it be too weird to use
 
 _http._srv.[name] CNAME _https._tcp.[name]
 
 as 'HTTPS required' signalization?
 
 (This is weird, I admit that. There will be troubles with DNS client 
 libraries not exposing CNAMEs etc... I just can't resist.)

_http._srv.[name] URI https:[name]

;-)

   Patrik



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

Re: [DNSOP] Extended CNAME (ENAME)

[Patrik Fältström]

On 20 maj 2014, at 16:00, Ted Lemon ted.le...@nominum.com wrote:

 On May 20, 2014, at 12:48 AM, Patrik Fältström p...@frobbit.se wrote:
 Can we not with HTTP/2 please push SRV forward?
 
 Dare I assume that you meant not for emphasis, not to ask that we not do 
 this?  :)

Argghof course.

Me and English...

I *WANT* SRV, URI or something similar.

Thanks for checking carefully!

   Patrik



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

Re: [DNSOP] Extended CNAME (ENAME)

[Patrik Fältström]

On 20 maj 2014, at 22:57, Mark Delany f...@november.emu.st wrote:

 one can lookup A,  and SRV in parallel and positive answer
 to SRV, as Paul mentioned, can have additional A and  RRs.
 
 A downside is that clients has to wait for the SRV query to complete
 so they can be sure of the presence or not of an SRV.

You have to look and count on A/ + HTTP with redirect when comparing with 
SRV+A/ or URI+A/.

I.e. some of the losses in even parallell URI/A/ are compensated by loosing 
roundtrips in HTTP.

   Patrik



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

Re: [DNSOP] Extended CNAME (ENAME)

[Patrik Fältström]

On 20 maj 2014, at 05:54, Paul Vixie p...@redbarn.org wrote:

 if we decide that web servers can be reached by SRV records, then any web 
 client can start looking for the SRV that describes that service, falling 
 back to whatever tin-cups-and-string it did before if it can't find the SRV 
 it wants.
 
 in that sense mark andrews' HTTP SRV I-D from all those years ago should not 
 have been controversial. if you want to do this, here's how everybody else 
 agreed to do it.

Speaking as an Applications Area Director of the time when SRV records where 
proposed I completely agree.

Algorithm should be defined by the service, and when done, it should be 
implemented and used.

Can we not with HTTP/2 please push SRV forward?

   Patrik



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

Re: [DNSOP] Extended CNAME (ENAME)

[Patrik Fältström]

On 17 maj 2014, at 13:51, Ted Lemon ted.le...@nominum.com wrote:

 It might be worth actively pushing the CDN folks to go the SRV direction.   
 Even if ENAME were a good idea, which is not clear to me, it's an idea that 
 would require significant infrastructure changes, whereas SRV records appear 
 to be functional now, with no DNS software changes.

As I have stated several times I disagree with any statement that claim 
significant infrastructure changes.

This usage is the reason I did define the URI resource record, so that one 
could get a redirect already in DNS instead of escaping to HTTP.

example.com. IN URI 1 2 https://foo.hosting.bar/example.com/startpage/en;

 Patrik

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

Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

[Patrik Fältström]

On 14 apr 2014, at 14:32, Antoin Verschuren antoin.verschu...@sidn.nl wrote:

 op 12-04-14 09:28, Patrik Fältström schreef:
  No, I want B. That CDS and CDNSKEY is staying in the zone.
 
 To keep it in the same thread,
 I want:
 
 C: The child MAY remove the CDS/CDNSKEY RR from the zone once the
 parent has published it, and this is how to do that safely.
 
 So I'm ok if they stay in, but we need a way to get them out for the
 ones that need that.

I am fine with C.

   paf



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

Re: [DNSOP] Spinning out of scope on draft-...-delegation-trust...

[Patrik Fältström]

On 14 apr 2014, at 15:16, Matthijs Mekking matth...@nlnetlabs.nl wrote:

 On 04/14/2014 03:05 PM, Edward Lewis wrote:
 I think it is silly to burn two RR types to communicate the same
 thing.  You’re inviting debate on testing and handling the two being
 out of sync.
 
 Would you prefer one RR type with varying RDATA format (like with
 IPSECKEY)? I don't.

...or NAPTR...

No thank you. :-)

I.e. completely agree with Matthijs!

You want RRTypes that are designed so that the triple {owner,class,type} do 
select an RRSet that is appropriate for whatever use it has.

   Patrik



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

Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

[Patrik Fältström]

On 12 apr 2014, at 15:04, Warren Kumari war...@kumari.net wrote:

 Gods I suck at this.

No, you are good at this!

   Patrik



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

Re: [DNSOP] (no subject)

[Patrik Fältström]

On 11 apr 2014, at 23:12, Warren Kumari war...@kumari.net wrote:

 Hi there all,
 
 At the moment this document says that the child SHOULD remove the
 CDS/CDNSKEY record once the parent has consumed / acted on it (this
 behavior was requested by someone -- unfortunately I cannot remember
 whom).
 
 I *think* that I'm hearing that folk would prefer that the child
 SHOULD leave it in, or, less strongly MAY remove it.
 
 This (IMO) makes the doc and the child's life simpler, but potentially
 makes a bit more work for the parent -- currently most of the
 time the parent will see no CDS, and so will go back to sleep. If the
 child leaves them around, the parent will need to check them against
 what is currently published and take action if they differ.
 
 Can folk please let us know if they would prefer:
 A: The child SHOULD remove the CDS/CDNSKEY RR from the zone once the
 parent has published it (currently documented behavior) or
 
 B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a
 small edit to the doc)
 
 My personal preference is for B - it seems more elegant, but (as
 always) we'll do whatever the WG wants.

Let me try to explain in a neutral way what I see as an issue:

As I am one of the persons that have rised the issue that we must be extremely 
clear on what we thing is ok here, let me explain the situation I am looking 
at, and that is how things work when child want to do a key rollover. I.e. 
child has for example DS foo and want to swap to DS bar. This implies having 
CDS for foo ate some point in time, CDS for foo and bar at some interval and 
then CDS for bar at some point in time. I.e. both add bar and remove foo.

This is, I think -- but can be wrong, much easier if CDS foo is in the zone all 
the time DS for foo is to be valid, and then CDS for bar is in the zone as long 
as the DS for bar is to be valid. Example below is for CDS because it is 
shorter to type, but can be valid for CDNSKEY as well of course (and yes, 
Antoine has convinced me as well that DNSKEY is the path forward...;-) ).

The argument for me is that if CDS is removed, then we have:

1. Add DS foo
1.1. Add CDS foo
1.2. Remove CDS foo

2. Add DS bar and remove DS foo
1.2. Add CDS foo
2.2. Add CDS bar
2.3. Remove CDS foo
2.4. Remove CDS bar

I am here nervous over the parent detecting 2.4 before 2.3, and the wrong DS is 
removed. Note that the last DS is never removed if the last CDS is removed from 
the zone. And the parent still must detect when CDS foo is added that that is 
already in the parent zone, and no action is needed.

If the CDS stays in the zone, we have:

1. Add DS foo
1.1 Add CDS foo

2. Add DS bar and remove DS foo
2.1. Add CDS bar
2.2 Remove CDS foo

So I am in favor of B.

   Patrik



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

Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

[Patrik Fältström]

No, I want B. That CDS and CDNSKEY is staying in the zone.

  Patrik

On 12 apr 2014, at 00:11, Warren Kumari war...@kumari.net wrote:

 [ Apologies all - I initially sent this with no subject line.
 Resending. Hopefully this makes things clearer... Also, unless we hear
 strong objections I'm planning on doing what Patrik and Matthijs
 suggested, option A ]
 
 
 On Fri, Apr 11, 2014 at 5:12 PM, Warren Kumari war...@kumari.net wrote:
 Hi there all,
 
 At the moment this document says that the child SHOULD remove the
 CDS/CDNSKEY record once the parent has consumed / acted on it (this
 behavior was requested by someone -- unfortunately I cannot remember
 whom).
 
 I *think* that I'm hearing that folk would prefer that the child
 SHOULD leave it in, or, less strongly MAY remove it.
 
 This (IMO) makes the doc and the child's life simpler, but potentially
 makes a bit more work for the parent -- currently most of the
 time the parent will see no CDS, and so will go back to sleep. If the
 child leaves them around, the parent will need to check them against
 what is currently published and take action if they differ.
 
 Can folk please let us know if they would prefer:
 A: The child SHOULD remove the CDS/CDNSKEY RR from the zone once the
 parent has published it (currently documented behavior) or
 
 B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a
 small edit to the doc)
 
 My personal preference is for B - it seems more elegant, but (as
 always) we'll do whatever the WG wants.
 
 W
 
 ___
 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: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Patrik Fältström]

On 11 apr 2014, at 11:36, Matthijs Mekking matth...@nlnetlabs.nl wrote:

 I want to know what happens both from the child and parent
 perspective IF the CDS and CDNSKEY differs.
 
 Just say what the result should be.
 
 Parent pick one at random?
 
 At random? Then you still don't really know that the result would be ;)

Exactly, thats why I think we should say MUST (but explain what we mean with 
it).

   Patrik



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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Patrik Fältström]

On 11 apr 2014, at 12:03, Antoin Verschuren antoin.verschu...@sidn.nl wrote:

 I think since this is a protocol definition, CDS and CDNSKEY MUST
 match. What a parent should do when the protocol is violated is I
 guess an implementation issue, BCP, or perhaps even local policy. A
 parent may only look at CDNSKEY or CDS or both. Saying they MUST match
 when they are both in the zone does not state anything on what the
 parent should do when they don't, same as when the Rdata is rubish.

I support this. This makes possible for parents to decide themselves whether:

1. They only fetch CDNSKEY and will not fetch CDS
2. They only fetch CDS and will not fetch CDNSKEY
3. They fetch CDNSKEY first, and then CDS if CDNSKEY does not exist
4. They fetch CDS and first, and then CDNSKEY if CDS does not exist
5. They fetch both CDS and CDNSKEY and will only pick data if the two are the 
same
6, ...

Etc.

If that is not the case, i.e. that the wg want a specific algorithm, then that 
should be explicit.

Unless we have an algorithm, then I support the fact that according to the 
protocol, they MUST result in the same result, as the parent can choose what 
algorithm they use.

   Patrik





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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Patrik Fältström]

On 10 apr 2014, at 18:34, Warren Kumari war...@kumari.net wrote:

 Because of this, I do not mind having some extra words here, like:
 
 This proposal do not include all operations needed for maintenance of 
 DNSSEC key material, specifically introduction and complete removal of all 
 keys. Because of this alternate communications mechanisms must always exist, 
 which might introduce extra complexity.
 
 DONE.

Thanks!

 2.2.1.  Solution Space
 :
 :
   Some parents want the child to express their DNSKEYS in the form of
   DS records, while others want to receive the DNSKEY records and
   calculate the DS records themselves.  There is no consensus on which
   method is better; both have good reasons to exist.  The proposal
   below can operate with both models, but the child needs to be aware
   of the parental policies.
 
 Mumble...I really dislike the fact we have not agreed on what to do. It 
 increases complexity _a_lot_. And yes, this is one of the reasons why we do 
 not see more deployment of DNSSEC.
 
 Why do we (IETF) fail on this?
 
 
 Yes; however, we want this to be deployed and usable by as many people
 as possible, so we are avoiding the religious argument in this
 document. Registry operators are entitled to their own opinion, as
 much as we dislike it

This is not YOUR fault, and you can not fix this problem in THIS draft. I just 
find it being...not fun.

 2.2.2.  DNSSEC key change process
 
   After a Child DNS operator first signs the zone, there is a need to
   interact with the Parent, for example via the delegation account
   interface, to upload / paste-in the zone's DS information.  The
   action of logging in through the delegation account user interface
   authenticates that the user is authorized to change delegation
   information for the child published in the parent zone.  In the case
   where the Child DNS Operator does not have access to the
   registration account, the Child needs to perform the action.
 
   At a later date, the Child DNS Operator may want to publish a new DS
   record in the parent, either because they are rolling keys, or
   because they want to publish a stand-by key.  This involves
   performing the same process as before.  Furthermore when this is a
   manual process with cut and paste, operational mistakes will happen
   -- or worse, the update action is not performed at all.
 
 Should it not be mentioned here that child might want to remove all keys as 
 well? I mean, if this is supposed to be a complete list of potential 
 operations the child is interested in?
 
 I see in fact (with some special cases):
 
 A. Introduction of new keys
 
 A.1. Introduction when old keys exists and can be used
 
 A.2. Introduction when no old keys can be used (because they can not be 
 trusted or because no such exists)
 
 B. Removal of keys
 
 B.1. Removal of old keys when at least one key still remains in the RRSet of 
 zone apex
 
 B.2. Removal of last key from the RRSet of the zone apex
 
 If I understand things correctly, you say this draft can only be used for 
 A.1 and B.1?
 
 I think that should be spelled out very explicitly in section 2.
 
 We had specifically decided not to allow B.2 because we don't want
 this be be used to go from signed to unsigned.

That is fine.

 You also cannot use
 this for initial enrollment of keys (A.2 - explained in Section 2.2.2
  the security considerations section), you can only use it for
 introducing new keys when you have one working key and removing all
 except the last key. Added text to clarify what use cases we do and do
 not support.

Thanks!

 We also had, in the intro: This proposal does not include all
 operations needed for the maintenance of DNSSEC key material,
 specifically the introduction or complete removal of all keys.

Yup, I did understand this, but just felt it was not really crystal clear 
enough. I know DNSSEC (I think:-) ) and still had to look at some of the 
text a few times to ensure that there where no loopholes.

 4.  Automating DS maintainance with CDS/CDNSKEY records
 
   CDS/CDNSKEY records are intended to be consumed by delegation trust
   maintainers.  The use of CDS/CDNSKEY is optional.
 
   Some parents prefer to accept DNSSEC key information in DS format,
   some parents prefer to accept it in DNSKEY format, and calculate the
   DS record on the child's behalf.  Each method has pros and cons, both
   technical and policy.  This solution is DS vs DNSKEY agnostic, and
   allows operation with either.
 
   If the child knows what the parent prefers, they can publish the
   parent's preferred record type.  If the child does not know (or
   simply chooses to), they can publish both CDS and CDNSKEY.  If the
   child publishes both, the two RRsets they SHOULD match in content.
 
 Why not a MUST?
 
 DONE.
 Ok, this is somewhat of a philosophical discussion -- I'm always
 uncomfortable putting a MUST on anything where a user enters the
 information.

Aha.

 Users (in my experience) seem to 

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Patrik Fältström]

On 3 Apr 2014, at 12:09, Patrik Fältström p...@frobbit.se wrote:

 What does would be a good idea mean in RFC 1918 speak? :-)

Hmm...not enough coffee...RFC 2119 of course.

   Patrik



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

Re: [DNSOP] CPE devices doing DNSSEC

[Patrik Fältström]

On 2014-03-08 09:00, Mark Andrews wrote:
 They have failed to invent / document a common standard way for
 machine updates to work.  They could have quite easily got together
 anytime in the last decade and done a standardised update protocol.
 
 But they haven't.

As long as the registries have _NOT_ unified their extensions of
whatever fluffy things they want, so that I as a registrar _really_ can
use the same EPP implementation to more than one (backend) registry,
then registrars have to spend energy and real $$ to implement those
incompatibilities. And do not have so much interest at all to do more
than many an API that is specific for them that faces the registrant.

We have been through this hundreds of times before and I think the
blaming _registrars_ as the ones that have an incompatible portion of
the system must stop.

Now.

   Patrik



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

Re: [DNSOP] CPE devices doing DNSSEC

[Patrik Fältström]

On 2014-03-08 11:47, Jim Reid wrote:
 Correction: some registrars are obliged to use EPP to talk to some registries.

Correction: epp is not one protocol. It is one protocol profile per
backend registry.

A big failure for IETF I must say.

The architecture is broken, but, luckily IETF has now thanks to many
people started to work on this issue.

   Patrik




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

Re: [DNSOP] CPE devices doing DNSSEC

[Patrik Fältström]

On 2014-03-09 10:19, Patrik Wallstrom wrote:
 But the fact is that EPP is several magnitudes better harmonized
 between TLDs compared to that registrars are offering their
 customers. There is no way around that today, and the registrars have
 no incentive at all to improve the situation. For all the registrars
 to offer the same API to their customers would really remove the
 lock-in effect that the proprietary interfaces that they have today.

The same lock-in as registries use already today with registrars.

My point is that there is absolutely no difference between how
registries lock in registrars (and because of that the registrants) and
how the registrars lock in customers.

Harmonizing the interface to registrars is _extremely_hard_ given how
different the epp implementation is for the registries. The registrars
that lock in (using your terminology) the registrants do that mainly
because they support a specific flavor of registries, and have designed
their API for those registries. If other registries where to be
supported, the API would be different.

 So how could we change this? I don’t see this happening from a
 standard organization at all. So yes - registrars is really a big
 reason for incompatibility. Registries could easily bypass the
 current rrr model by exposing API:s directly to registrants, but it
 wouldn’t be very popular with the registrars…

In no particular order:

1. By having people stop claiming epp is one protocol and blaming the
registrars being the problem. Pointing fingers does not help, because as
in this thread, energy has to be spent on explaining the differences in
epp between TLDs.

2. By having registries agreeing on whether DS or DNSKEY is the data
they want, or by accepting both.

3. By having the IETF effort of to start with cataloging the epp
extensions used by registries, and secondly working hard to try to
harmonize the extensions.

4. By having the registrars that have an API harmonize their efforts
just like registries harmonize theirs.

Also: note that registries do sent the wholesale price for the domain
registration, and the price on the market today for domain names is set
by the ones that cross subsidize domain name costs with income from
other services. Because of that there is a price squeeze which in some
markets turn into negative revenue for registrars that sell domain
names. Registries that now and then dump the wholesale prices does not
make the situation better, as the end users start to believe the price
is very low. Registrars complain on this behavior by registries, but the
registries continue to do price dumping -- i.e. continue the price squeeze.

Given this pricing structure, and that registries do change their
implementations far too often, where do you think registrars do spend
the money they have? They MUST support what the changes the registries
do, they do not HAVE TO implement a common API.

So, the registries MUST be the ones that start. Although there are many
registrars that will follow. Including Frobbit that I am technical lead at.

Now as I wrote above, IETF have started some very good work on epp
extensions but I am amazed how many registries refuse to participate,
complain, and fight against it. As long as they do, why should
registrars be nice(r)?

The market is broken, and as I said, I think we in IETF (when I was Area
Director btw) where too nice when the whole epp work took place.

   Patrik




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

Re: [DNSOP] CPE devices doing DNSSEC

[Patrik Fältström]

On 2014-03-09 12:55, Patrik Wallstrom wrote:
 
 Yes, there is. Let me explain how.
 
 Registries are using variants of the same protocol, EPP. Registries are 
 typically serving exactly one name space. And this is where the lock-in  for 
 the registrar come in - there are no other registries that serve the same 
 name space.
 
 Registrars are not using the same protocol, if any, as anybody else at all. 
 They typically serve multiple name spaces. The large registrars have most of 
 the name spaces available.

No Patrik. The difference is so large between registries that there is
not much money to save between implementations of epp to different
registries.

 I totally agree with your description of the registrars interface, and this 
 was my main point.
 
 Since I have looked in more detail on many registrar interfaces, they 
 typically do not resemble each other in any way at all. They all serve 
 different purposes.
 
 1. Manage domains (register or delete domains).
 2. Manage wallets (to see their invoices, refill accounts).
 3. Update zone content (unusual).
 4. Manage web sites.
 5. Manage web site content.
 6. Manage virtual private servers (VPS).
 7. Update DNSSEC material (extremely unusual).
 
 These are also all mixed up, so there is no interface that covers all of it, 
 some choose only one or two of the things in the list, with any combination 
 they choose.
 
 The API:s are also implemented in a variety of flavours as well, XMP-RPC, 
 REST, SOAP and whatever they can come up with.
 
 This also makes it extremely difficult (on a whole other level compared to 
 registrars talking to registries) for a registrant to move their automated 
 interaction with one registrar to another registrar.

To me this looks very similar to what registries do.

Compare .DK, .EU, .SE and .ORG for example.

 In no particular order:

 1. By having people stop claiming epp is one protocol and blaming the
 registrars being the problem. Pointing fingers does not help, because as
 in this thread, energy has to be spent on explaining the differences in
 epp between TLDs.
 
 Yes. Nobody is pointing any fingers here. And this is all good work.

I do not agree, there is a large portion of finger pointing going on.

 2. By having registries agreeing on whether DS or DNSKEY is the data
 they want, or by accepting both.
 
 It seems that this is not going to happen.

Then you will not see a harmonized interface to registrars either.

 3. By having the IETF effort of to start with cataloging the epp
 extensions used by registries, and secondly working hard to try to
 harmonize the extensions.
 
 This is what the eppext wg is doing now.

Correct.

 4. By having the registrars that have an API harmonize their efforts
 just like registries harmonize theirs.
 
 Have you, as a registrar, put any effort into this? Where do you suggest this 
 work is going to take place?

Oh yes. There are a number of things that must happen first, but one big
obstacle is that different registrars concentrate on certain registries,
like Frobbit concentrating on .SE. The interface to other registries is
so different that registrars that concentrate on other registries will
by definition have a different API.

Now, whether you think two REST API's with different semantics for
different registrars is better than what we have today, that is up to you.

 An “interesting idea would be having ICANN to implement the base of this as 
 part of the RAA.

No, that will not help. ccTLDs must be part of the story.

And the RAA is broken anyways, as it for example violates the regulation
and laws of the European Union, so they need to be cleaned up before for
example you can have _any_ ICANN Accredited Registrar from the European
Union (at least most member states -- it depends a bit on how they have
implemented the data protection directive).

I think CENTR, LACTLD, APTLD etc is the right forum.

 Well, registries have made registrars do DNSSEC before. So if we would 
 actually try to describe a standardised interface for the registrars, there 
 could be ways to make the registrars implement this new interface. Pressure 
 from customers, registrars and ICANN combined, perhaps?

Once again, as long as registries do NOT have the same interface for
DNSSEC from registrars, how would registries be able to force the
registrars implement the SAME interface for DNSSEC to registrants?

 There are way more problems for a registrar to implement EPP for the 
 different registries than the extensions. You know that as well.

Possibly if you strictly talk about the extension(s).

 Registries have different policies regarding what names are allowed, how 
 different objects are actually used, and different ways of handling expired 
 domains. And this is already within the defined standard without any 
 extensions.

Correct. And those differences are problematic. As well.

   Patrik





signature.asc
Description: OpenPGP digital signature

Re: [DNSOP] CPE devices doing DNSSEC

[Patrik Fältström]

On 2014-03-09 12:55, Patrik Wallstrom wrote:
 Given this pricing structure, and that registries do change their
 implementations far too often, where do you think registrars do spend
 the money they have? They MUST support what the changes the registries
 do, they do not HAVE TO implement a common API.

 Well, registries have made registrars do DNSSEC before. So if we would 
 actually try to describe a standardised interface for the registrars, there 
 could be ways to make the registrars implement this new interface. Pressure 
 from customers, registrars and ICANN combined, perhaps?

I did btw notice you did not comment on the price squeeze issue. That is
_very_ serious as at the end of the day someone have to pay for the
developer writing the code.

Registries dumping wholesale prices must stop doing that.

   Patrik



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

Re: [DNSOP] summary of WG current status

[Patrik Fältström]

WOW! This could be a week of meetings...

I guess it is not time to fold yet... :-P

   Patrik

On 2014-02-21 18:17, Suzanne Woolf wrote:
 Dear Colleagues,
 
 As we look towards the meeting in London, we have several items in
 progress, which we've organized here from the most specific and
 administratively simple tasks to the broadest discussion topics.
 
 Not everything called out here is on the London agenda, but we’ve tried
 to round up everything that’s in progress as work for the WG, formally
 or (in a few cases) informally. We expect to send this out periodically,
 not least so people have a chance to call us on it if we drop stuff.
 
 thanks,
 Your Chairs
 
 
 From our existing charter:
 
 1. RESPSIZE draft
 (http://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/)
 This item has been in our charter for a very long time, and was at
 one time considered almost ready for publication but stalled there.
 There's been recent interest in dusting it off and getting it shipped,
 and with the help of the previous authors and a new volunteer, a new
 version has been published. It’s been suggested  we might want to add
 some more material on DNSSEC and EDNS0, since the previous version only
 dealt extensively with the impact on referral size of adding 
 records and the bulk of the document was written before the root was
 signed or ICANN's registry contracts were written to require DNSSEC for
 new gTLDs.
 
 Agenda in London: flag open items, get reviewers, get a timeline for
 finishing
 
 
 2. PRIMING draft
 (http://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/)
 We’ve also got a new rev of this draft so we can resolve the open
 questions and get this published also.  
 
 Agenda in London: flag open items, get reviewers, get a timeline for
 finishing
 
 3. AS112 operations:
 http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/(WG item)
 http://datatracker.ietf.org/doc/draft-jabley-dnsop-rfc6304bis/(new)
 
 Some additional “bits and pieces” re: AS112 operations. We need
 reviewers to move forward with the DNAME one, and for 6304bis if we want
 to adopt it.
 
 Agenda in London: determine momentum for getting these reviewed,
 revised, and published. If not they will be dropped.
 
 4. CDS and related: what are we doing about the topic of DNSSEC in-band
 key maintenance? This has previously been somewhat contentious and seems
 to have stalled without resolution. We now have current versions of two
 drafts and would like to make progress on resolving differences.
 http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
 http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
 
 5. 100.64.0.0/10 to reserved list
 http://datatracker.ietf.org/doc/draft-andrews-dnsop-rfc6598-rfc6303/
 Stalled in WGLC on an administrative issue of overlapping IANA
 registries. Chairs will review discussion and propose a way forward
 soon; no WG action required
 
 
 NEW TOPICS:
 Passive DNS data format:
 http://datatracker.ietf.org/doc/draft-dulaunoy-kaplan-passive-dns-cof/:
 needs review, call for adoption
 Authority server placement: no i-d yet; agenda time requested, needs review
 
 FOR DISCUSSION, including possible charter revision:
 
 1. Privacy drafts
 There are *at least* four i-ds and a BOF in London specifically for
 discussion of privacy and confidentiality with regards to the protocol
 and operations of DNS:
 
 Stephane Bortzmeyer's problem statement draft
 (http://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-dns-privacy/) is
 reasonably on-charter for us.
 Stephane's solutions
 drafthttp://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-privacy-sol/)
 Peter Koch's draft on information leakage in the DNS
 (http://datatracker.ietf.org/doc/draft-koch-perpass-dns-confidentiality/)
 Wouter Wijngaards' draft on opportunistic encryption in the DNS
 (http://datatracker.ietf.org/doc/draft-wijngaards-dnsop-confidentialdns/)
 (plus a few other documents)
 
 We need to decide what we think a useful contribution on this broad
 topic would be for DNSOP. Stephane's problem statement draft seems
 in-scope and we'd like to call for adoption. Protocol changes as
 described in two of the drafts probably need a new WG. In between, this
 topic provides an opportunity for us to consider reasonable updates to
 our charter given evident demand from the community to examine DNS in
 light of current privacy concerns. 
 ** This is a major item for the agenda in London; please come prepared
 to discuss **
 
 2. Special names
 There are two current drafts requesting additions to the Special Use
 Names registry as per RFC
 6761,http://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/andhttp://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/.
 The process described in RFC 6761 calls for IESG action, and the IESG
 has asked for DNSOP input, including that we consider adopting these
 drafts 

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

[Patrik Fältström]

On 2014-02-18 19:58, Joe Abley wrote:
 I appreciate that knowing the process made things easier (mainly; I
 was wrong about some things and had to be educated). But I would not
 describe the process as difficult, and certainly not insurmountable.

Agree, and correct (I did the same with URI RR-Type). But then to start
to define applications using the RR... :-(

   paf



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