Re: [DNSOP] NOTIFY: How to locate the target

[Jaap Akkerhuis]

 Michael Bauland writes:

 > Therefore you need to know what endpoint of the registry you need to 
 > send the NOTIFY to. This would just be a service listening for NOTIFYs 
 > to re-initiate the scanning, but it's not a name server at all. Setting 
 > this endpoint in the TLD zone's SOA record as a pseudo primary name 
 > server does not seem to be a good approach. We would a different way to 
 > specify the NOTIFY target.

Various name servers allow you to specify notify targets. One could
use that mechanism.

jaap

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

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

[Jaap Akkerhuis]

Let me make some pedantic remarks about the terms used in this
discussion.

 Joe Abley writes:

  > 1. Certain ISO-3166-2 codepoints are designated as being for private
  > use by ISO and will not be assigned for use by countries, economies, etc;

What you mean here is the ISO 3166 Part 1 (ISO 3166-1 Country codes)
and just the "alpha-2" codes (two letters).

[Part two from ISO 3166 is about subdivision codes. Subdivision
codes in Part 2 consist of alpha-2 country codes, hyphen and one or
more characters (as in AU-QLD for Queensland).]


 > 2. Those ISO-3166-2 codepoints continue to be used for
 > correspondingly-private applications in a variety of applications
 > that have nothing to do with the DNS, so the designation from (1) is
 > recognised and widely used;
 >
 > 3. ICANN does not assign two-character labels as TLDs except by
 > reference to ISO-3166-2;

The ISO 3166 term forthese code points is "User Assigned".

Regards,

jaap

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Jaap Akkerhuis]

 Tim Wicinski writes:

 > 
 >
 > Please review this draft to see if you think it is suitable for adoption by
 > DNSOP, and comments to the list, clearly stating your view.

Reviwed and yes, this is suitable. It addresses operational problems.

 >
 > Please also indicate if you are willing to contribute text, review, etc.

Willing to contribute.

jaap

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

Re: [DNSOP] on private use TLDS

[Jaap Akkerhuis]

 Doug Barton writes:

 > I don't doubt Jaap.

Thank you.

 > What I doubt is that any organization as political 
 > as ISO (or ICANN) will hold preferences stable in the absence of a 
 > controlling policy.

Here are some more facts from the trivia corner.

The ISO was started from 1947. The first edition of the 3166 standard
is from 1974 and defined the User assigned codes as:

The series of letters AA, XA to XZ, and ZZ, and the series AAA to AAZ, 
XAA
to XZZ and ZZA to ZZZ respectively, are available for private use, and 
for
provisional codes which should be recorded as soon as possible by the
maintenance agency. An existing alpha-1 code which is in agreement with
the first letter of the alpha-2 code may be used for an appropriate time
to be fixed by the agency.

The second edition (1981) said:

The series of letters AA, OM to QZ,XA to XZ, and ZZ,and the
series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ
respectively and the series of numbers 900 to 999, are
available for individual use.

so it did add the ranges starting with a Q. 

The later editions are all defining the same name space (with sometimes
different wording).

A similar exercise can be done for ICANN en TLD name space but I
leave that up to the reader(s).

However, I cannot help noticing that for years I hear from various
ICANN stakeholders that ICANN should start to use alpha-2 codes as
well. Most recently in the meetings of the GNSO newgtld working
group, subgroup wt-5. The motivation is that then Volkswagen can
have its TLD ".vw" and the Bank of America (why not bank of Albania?)
".ba".

jaap

PS. [Apparently proponents of ba for a bank don't realize that it
is assigned to Bosnia and Herzegovina].

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

Re: [DNSOP] On .ZZ

[Jaap Akkerhuis]

 Erwin Lansing writes:

 >
 > Beware of assumptions. I would never have imagined in my wildest
 > dreams for St. Maarten to be assigned SX.

It was on request of Dutch Sint Maarten. The argued that they where know for the
airport code for the well-known Princess Juliana International Airport  But that
is nir really related to the origonal proposal

jaap

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

Re: [DNSOP] On .ZZ

[Jaap Akkerhuis]

 Bill Woodcock writes:

 > Again, this is an argument from principle rather than an argument based 
 > on the specific case at hand.  I just think that we have a
 > well-established precedent that all two-letter TLDs are derived from ISO
 > 3166 Alpha-2, and it's bad form to cross back over and start 
 > poaching in their territory.

Nope, it ain't. That part of the so 3166 name space is speially set
aside by the standard for private use.

jaap

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

Re: [DNSOP] On .ZZ

[Jaap Akkerhuis]

 Shane Kerr writes:

 > Hm... this is an interesting point.
 >
 > I just checked the ISO 3166 glossary:
 > https://www.iso.org/glossary-for-iso-3166.html
 >
 > And it says:
 >
 > "User-assigned codes - If users need code elements to represent country 
 > names not included in ISO 3166-1, the series of letters AA, QM to QZ, XA 
 > to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and 
 > ZZA to ZZZ respectively, and the series of numbers 900 to 999 are available.
 > NOTE: Please be advised that the above series of codes are not 
 > universal, those code elements are not compatible between different 
 > entities."

The glossary is not authoritative, but it is a reformulation of a
note to Section 8.1.3 in the standard (ISO 3166:1,Third edition,
2013-11-05):

   "NOTE Users are advised that the above series of codes are
not universals, those code elements are not compatible
between different entities."

 >
 > So the intention of the ISO at least is that these codes are used by 
 > users. (I'm not sure what the scary warning means.)

It means what it says. In the context of the stamdard, these are
not garanteed to be unique. The 3166/MA get sometimes requests to
reserve/allocate/assign codes from these blocks to make them unique
and always says no. (There used to be a note somewhere asking to
send the secretary of the 3166/MA information which User Assigned
Code was used and for what, but hardly anybody ever did and when
they did, users expected their particular code to be unique. Therefore
the MA dropped the note and does not keep a record of the User
Assigned Codes).

 > Certainly I have 
 > made heavy use of .Q* and .X* in my own testing, with the assumption 
 > that these would never be assigned (and yes, there is .TEST but 
 > sometimes you need more than one one TLD).

Yes, that is the ia perfect legit use use. (Trivia tidbit: The
rumour is that in Argentinia these codes are used to brand mark
cows).

jaap

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

Re: [DNSOP] On .ZZ

[Jaap Akkerhuis]

 Paul Wouters writes:

 > 
 >
 >
 > > On Nov 21, 2019, at 15:18, Alexander Mayrhofer 
 > >  wrote:
 > > 
 > > 
 > > ..ZZ would remind me of long beards and loud motorcycles for the rest
 > > of my life.. https://de.wikipedia.org/wiki/ZZ_Top
 >
 > English speaking people can’t even agree on how to pronounce this name..
 >
 > Having an undelegated .zz is also not guaranteed to be free of security 
 > issues, for example if ICANN delegates .zzz there will be interesting typo 
 > attacks possible in this weird private space.
 >

The code zzz is also private space

 > Finally, I agree. People want something semantic and more pronounceable.

In what language? Furtherore, there are a sle of codes to choose
from. Currently the principle choice is wether one wants to use
these 'User Assigned' ISO codes.

jaap

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

Re: [DNSOP] RFC7720 and AXFR

[Jaap Akkerhuis]

 Mukund Sivaraman writes:

 > There's no requirement for AXFR and some root letters don't serve
 > AXFR. E.g., L and M don't whereas F does.
 >

For AXFR from L, see 

jaap

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

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

[Jaap Akkerhuis]

 Warren Kumari writes:

 >
 > i *seem* to remember something happening with .de a few years back --
 > IIRC, slaves did a zone transfer, ran out of disk and truncated the
 > file, and so only had a partial zone file to serve - something like
 > 2/3ds of the .de zone "disappeared". A zone checksum would allow the
 > nameserver to know that they do not have a full zone file.
 >
 > My memory is hazy, because I would have expected the AXFR to fail and
 > the nameserver to just continue using the old zone. Perhaps there was
 > some other transfer mechanism and it involves restaring the
 > nameserver? I'm sure someone must remember more detail on this event.

It was more complicated then just a full disk and a corrupt AXFR.
It has also to do with moving to new server hardware and the old
servers interfering. I too forgot the details, but Peter Koch might
jump in here.

jaap

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

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

[Jaap Akkerhuis]

 Warren Kumari writes:

 > "Throughout this document, we are using A to refer to an Address
 > record (either 'A' or  '') " -- having "A or " scattered all
 > over the document makes it now flow as nicely...

Just for fun, turn that around: "Throughout this document, we are
using  ... either A of ".

jaap

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Jaap Akkerhuis]

 Petr Špaček writes:

 > 
 >
 > An example: RFC 4033 clearly states what should be done if result of
 > validation is "Bogus". Nonetheless, Unbound has "val-permissive-mode:
 > yes" which enables admin to pass bogus answers.
 >
Note that the default setting is "val-permissive-mode: no".  It is
just a knob for all those people who want to shoot themselves in
the foot.

jaap

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

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

[Jaap Akkerhuis]

 Jim Reid writes:

 > 
 > 
 > > On 21 Mar 2017, at 14:09, Paul Wouters  wrote:
 > > 
 > > Can we tell from the queries or a timeline of query quantity if this
 > > is generic .home pollution that predates the homenet protocol suite,
 > > or actually the result the homenet protocol suite being deployed?
 > 
 > What's this "we"? :-)
 > 
 > The short answer to your question Paul is I don't know. If someone
 > could confirm what qname/qtype tuples are limited to the homenet
 > suite, I could go looking for them in the DITL datasets. This will
 > not be a trivial task. One year's DITL data generally consists of a
 > few TB of data spread over 300K compressed pcap files containing a
 > total of ~100B queries. It takes about 1 day of elapsed time and a
 > few CPU-weeks to chug through that.

It has been done. See page 25 of the CDAR report

which was announced two weeks ago
.

jaap

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

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

[Jaap Akkerhuis]

 Stephane Bortzmeyer writes:

 > On Wed, Dec 21, 2016 at 10:05:03PM +0100, Jaap Akkerhuis
 >  <j...@nlnetlabs.nl> wrote a message of 16 lines which said:
 > 
 > > As part of the IDNA discussion there is an RFC (or parts of it) >
 > pointing out how uesless classes are.  I seem to remember it was >
 > from the IAB and one of the authors was Klensin.
 > 
 > I was not able to find it. Anyone has a reference?

Looks like it was only a draft as well:
<https://archive.icann.org/en/meetings/stockholm/draft-klensin-i18n-newclass-00.txt>

jaap

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

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

[Jaap Akkerhuis]

 Stephane Bortzmeyer writes:

 > What did we publish on classes? If you refer to
 > draft-sullivan-dns-class-useless, it was never published (which is
 > bad).

As part of the IDNA discussion there is an RFC (or parts of it)
pointing out how uesless classes are.  I seem to remember it was
from the IAB and one of the authors was Klensin.

jaa[

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

Re: [DNSOP] Fwd: [homenet] WGLC on "redact" and "homenet-dot"

[Jaap Akkerhuis]

 Ray Bellis writes:

 > On 14/12/2016 20:14, Jaap Akkerhuis wrote:
 > > Any reason why homenet shuld use a TLD? What is wrong with something
 > > like homenet.arpa (or thuisnet.arpa, or bob.arpa).
 > 
 > 

Which hat?

 > 
 > It's not considered user-friendly enough.
 > 
 > The historic meaning of ARPA is considered by some to be problematic in
 > the consumer space that Homenet is targeting.
 > 
 > It's unfortunate that it's the only top-level name under IAB control.
 > The current expansion of the acronym to "Address and Routing Parameter
 > Area" is itself not a good fit for this somewhat more generic use case.

But is there a technical argument? Or is this just a well a believe
it doesn't fit perfectly. Does it really matter how the identifier
is called?

jaap

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

Re: [DNSOP] Fwd: [homenet] WGLC on "redact" and "homenet-dot"

[Jaap Akkerhuis]

 Ted Lemon writes:

 > I hope it was obvious that I was pretty confident that you actually had a
 > reason.   :)
 > 
 > The issue what what you are saying is that sometimes it is technically
 > correct for a name to not be validatable.   The reason we want an unsecured
 > delegation for .homenet is that .homenet can't be validated using the root
 > trust anchor, because the name is has no globally unique meaning.   So the
 > reason that you've given doesn't apply to this case, although I completely
 > agree with your reason as it applies to the case of names that are globally
 > unique.

Any reason why homenet shuld use a TLD? What is wrong with something
like homenet.arpa (or thuisnet.arpa, or bob.arpa).

jaap

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

Re: [DNSOP] DNSSEC operational issues long term

[Jaap Akkerhuis]

 Philip Homburg writes:

 > >Did you see my original response? Proposals for automatic DNSSEC trust
 > >anchor updating *do* exist.
 > 
 > Is there any document that deals with the situation where a device has
 > been in a box for 10 years and then has to bootstrap automatically?
 > 
 > I'm not aware of any. But maybe there is.

I remember
. At
that time some other proposals were floating around as well.

jaap

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

Re: [DNSOP] DNSSEC operational issues long term

[Jaap Akkerhuis]

 Mikael Abrahamsson writes:

 > So if it's manufactured the day before a new key is publically released, 
 > when is the key material it has built in no longer viable to have 
 > successful DNSSEC validation?

A properly designed device will discover that its preconfgured trust
anchor differs from what it finds online. It will not trust either
of these but offers the user a way to afind the proper trust anchor.

jaap

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

Re: [DNSOP] Looking for IANA registry for --xn

[Jaap Akkerhuis]

 Robert Edmonds writes:

 > Donald Eastlake wrote:
 > > Sure, you can consider the root zone to be the registry for TLDs but the
 > > point is the xn-- labels are recommended to be interpreted specially at the
 > > user interface at all levels...
 > 
 > Nor would this say anything about "CCHH" prefixed labels in general.
 > 

RFC 3490 does say something about the ACE prefix.

jaap

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

[Jaap Akkerhuis]

 Stephane Bortzmeyer writes:

 > 
 > As you can imagine, I disagree.
 > 
 > > Domain names are written left to right.
 > 
 > In english, yes, not in general. They are always written from the
 > beginning to the end (obviously) and the final label can be at the
 > left in a RTL script.

There is no such thing as a language attribute to doamain names.
They are just strings.

jaap

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

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

[Jaap Akkerhuis]

 David Conrad writes:

 > 
 > I'd really like to say yes, but ISO-3166/MA appears to have removed 
 > references
 > to "User Assigned" in their official ISO-3166 two letter code w=
 > webpage.

Only the the standard is normative.

 > I'm trying to understand if they've changed their mind, but no answer yet.

The standard hasn't changed in that reqpect for the last twenty five year of so.

jaap

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

Re: [DNSOP] Thoughts on the top level name space

[Jaap Akkerhuis]

 David Conrad writes:

  
  In the past, ISO-3166/MA maintained a color-coded decoding table that
  clearly identified the user assigned 2-letter ISO codes. However, for
  reasons that I'm sure made sense to someone, they stopped publishing the
  decoding table (http://www.iso.org/iso/iso-3166-1_decoding_table.html)
  it now is found on the Wikipedia page for ISO 3166-1 Alpha-2
  (https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table). 

The official decoding table got lost when ISO revamped their website.
More people have complained about that (including me).

One can get something similar by going to
https://www.iso.org/obp/ui/#home, select the country codes in the
search box, and then do an empty search (just hit enter). That gets
you a complete a table (and you might want to set results per page on
maximum). Unfortunately, the User Assigned code are missing.

The last time I looked at the Wikipedia it was a bit out of date but I
just looked and someone seems to have updated it.
 
  I haven't looked particularly closely but I've been unable to locate an
  official reference to user assigned codes any more (e.g., that term
  isn't in the glossary at
  http://www.iso.org/iso/country_codes_glossary.html).
  
  Is there an official, ISO maintained, listing of ISO-3166 user
  assigned codes?
  

The standard itself is authoritative for definitions of
terms, to quote from ISO 3166-1:2013 Clause 8.1.3 says:

8.1.3 User-assigned code elements

If users need code elements to represent country names not
included in this part of ISO 3166, the series of letters AA,
QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to
QZZ, XAA to XZZ, and ZZA to ZZZ respectively, and the series
of numbers 900 to 999 are available.

I just took a trip along memory by means of the WayBack Machine. It
shows me on olde ISO site[1] (from 2009, just picked a random year),
which has the definition in the glossary[2]. That has the same quote
as above (from ISO 3166-1:2006) and some explanatory text.

But yes, it would be nice to have it back on the current site (and the
codes in the database).

jaap

 
[1] 
http://web.archive.org/web/20090707104326/http://www.iso.org/iso/iso-3166-1_decoding_table

[2] 
http://web.archive.org/web/20081205170501/http://www.iso.org/iso/customizing_iso_3166-1.htm

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

Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

[Jaap Akkerhuis]

 Warren Kumari writes:
 
  
  This number comes from Evan :-)
  
  Less flippantly, it is in this email:
  https://www.ietf.org/mail-archive/web/dnsop/current/msg13004.html  I
  don't think that we have a really good motivation for a week, other
  than that is feels sort of like a good, human scale timeframe to
  recheck on things. We really want there to be a limit on the lifetime,
  a week felt right... but, I still like because Evan said so...
  
  Are you OK with leaving it unmotivated[0], because there isn't really
  a good motivation?
  

RFC 1035 considers in Section 7.3 that a week for a TTL is excessive.
So you might use that as a (weak) guideline.

jaap

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

Re: [DNSOP] Thoughts on the top level name space

[Jaap Akkerhuis]

 Steve Crocker writes:

   For the alpha 3-code the complete user assigned set is:
   
  AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ
   
   so one could argue that the delegations for TLD xyz (and maybe xxx) is
   a actually against the rules in ICANN�s Application Guide Book.
  
  It's my understanding that only the two character codes are included in the 
  relationship between DNS top level names and ISO 3166-1.  Three letter codes 
  aren't included, so there's no conflict.

There is a relation between aplha-3 codes and gTLDS. In my reading of
Applicants Guide Book Section 2.2.1.4 point 1, apha-3 codes are
considered an off limits if listed in ISO 3166-3. (That's why google
retracted some applications because they collided with his rule).

Of course, the list above is 1918-like space but still so it doesn't
matter that much;. However, one might want to be consistent in
threating 1918-like thingies.

jaap

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

Re: [DNSOP] Thoughts on the top level name space

[Jaap Akkerhuis]

 Steve Crocker writes:

 xq
   
   'pq' is a better example.  'xq' is classified as User Assigned, which
   means it has been assigned for use by anyone for their own purposes.  'pq'
   is (using Wikipedia�s term) unassigned.
  
  Thanks.  I didn't check the tables before writing.  I was pretty sure
  xq wasn't already assigned to a specific country or territory, but I
  didn't think about a '1918' style designation of two letter codes.
  Perhaps we need another subset to put these into. It would be a
  'final' state in the sense that once a two letter code is put into
  that state, it can't move to another state. And the purview would be
  the ISO 3166-1 Maintenance Agency.

FYI: There has been attempts to move from '1918' style space to allocated
space but in the cases I know, it has been refused. by the ISO 3166/MA.

jaap

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

Re: [DNSOP] Top level names -- precision re categories and where are are the uncertainties?

[Jaap Akkerhuis]

 Steve Crocker writes:

  Folks,
  
  I`ve been watching the dialog on this list regarding to level names.
  Attached is my attempt to clarify the state of affairs and identify the
  loose ends.  Both PDF and pptx versions attached, the latter in case
  someone is moved to edit the slides directly.


Either I don't understand the slides or they seem to be inconsistent.
As an example, you defines 8 states [1] and 8 definitions (later
called Categories: when you give exanples. However the examples
doesn't match the definitions:

Definition 2: Names that have not been formally recognized but
are being used privately or for applications that have
not yet become standard

Definition 3: Two letter Latin characters that have not yet
been assigned by the ISO 3166 maintenance agency but
might be in the future.

Category 2: xq

Category 3: onion

Are these mistakes or purposely. (There seem to be more of these cases
on the slides).

jaap



[1] I'm not sure whether this is a proper term. Can one state move to another?

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

Re: [DNSOP] Thoughts on the top level name space

[Jaap Akkerhuis]

Not taking a stand on this, but some more remarks on these thoughts.

 Edward Lewis writes:

  
  On 7/5/15, 7:26, DNSOP on behalf of Steve Crocker
  dnsop-boun...@ietf.org on behalf of st...@shinkuro.com wrote:
  
  3. (ICANN) Two letter Latin characters that have not yet been assigned by
  the ISO 3166 maintenance agency but might be in the future.  Names in
  this subset may move to subset 7 to become active ccTLDs.  Examples:
  
  xq
  
  'pq' is a better example.  'xq' is classified as User Assigned, which
  means it has been assigned for use by anyone for their own purposes.  'pq'
  is (using Wikipedia's term) unassigned.

Indeed. The complete user assigned set is:

AA, QM-QZ, XA-XZ and ZZ

For the alpha 3-code the complete user assigned set is:

AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ

so one could argue that the delegations for TLD xyz (and maybe xxx) is
a actually against the rules in ICANN's Application Guide Book.

  
  In recognition of this, though, I'd lump all of the alpha-2 codes
  ([A-Z][A-Z]) into category 3, and call it informally being at the mercy
  of the ISO 3166-1 Maintenance Agency.

But given that they can be freely used, one could consider them as
candidates for non-TLD use in the name space.

  
  4. (IETF) Names the IETF has formally recognized as reserved for
  particular non-DNS uses.  Names in this subset are effectively permanent.
   (=E2=80=9CEffectively permanent=E2=80=9D means they are expected to remain 
   in this
  subset forever and there is no defined process for changing the status of
  names in this subset.)  Examples:
  
  example, local
  
  (Left in for the discussion later in this message.)
  
  7. (ICANN) ccTLDs, both Latin and IDN.  Names in this subset are expected
  to last indefinitely.  If they are taken out of service they move to
  subset 8.  Examples:
  
  jp, uk, na, xn--fzc2c9e2c
  

I would recommend to not use UK as an example in this discussion. If I
remember correctly, the use as a TLD stems from the time before the
iso alpha-2 codes got adopted as TLDs.

  The quirk I have here is the IDN Fast Track
  [https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and
  trying to anticipate what names will be in that.   The Latin ccTLD codes I
  can anticipate from category 3 above.  But the IDN ccTLD names aren't
  distinguishable from other IDN names without consulting the Fast Track and
  even so, well I'll put this under - I don't understand if a name coming
  through the Fast Track might also be on a generic TLD track.

As far as I know, the Fast-Track IDN process uses the ISO standard to
see whether the requested name can be applied as ccTLD. so something like
Scandinavia will drop because because there is no ISO code for the 
corresponding country or (administrative) territory.

  
  As far as I know, if the Fask Track the only source of IDN ccTLD names?
  
  8. (ICANN) Previously used TLDs that have been taken out of service.
  Names in this subset must remain out of service for a very long time,
  currently estimated at 50 years, to avoid unintended consequences.
  Examples:
  
  cs

CS has been used twice by ISO 3166. It is now in the 50 year cool-off period.

  
  Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which
  have been rescinded (NS records removed) are eligible to be reinstated if
  needed for further testing.  I've been told means that I have never seen
  this in print and thus have no citation to give.

And there are other cases; Official assigned by ISO but not used as
TLD (um comes  to mind).


jaap

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

[Jaap Akkerhuis]

 Patrik Fältström writes:

  
  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.
  

If one read the board resolution approving EU as a (cc-)TLD, one will
notice that this is really an exception [1]
https://community.icann.org/display/tap/2005-03-21+-+Delegation+of+.EU.
In the second Whereass, the board takes, I think, a liberty mentioning
TLD. As far as I know, the possibility of using EU as an TLD is not
explicitly mentioned by the MA. The reason that the board could made
tte exception is the footnote in the List of exceptionally reserved
alpha-2 code elements stating that In August 1999, extension of scope
to any application needing to represent the name European Union. [2]

But yes, EU was originally reserved for ISO 4127 to be used in valuta
code. Valuta codes consist of an alpha-2 3166 code + a single letter
saying something about the name of the money. So one has the USD, AUD,
SGD (US, Australian  Singapore Dollar) the SEK, DKK (Danish  Swedish
Krone) the INR  EUR (Indian Rupee  Euro). (Yes, that single letter
is used inconsistently).

In March 1998 the scope was extended so th code could be used by the
international securities identification numbering system (ISIN). These
guys to have asked (and received) for more codes for securities, but I
digress. Apparently in August 1999 the scope was extended again, given
fuel for the EURid get the delegation. I wasn't around at that time so
I cannot comment how and on the later extension was made and on
behalve of whom.

jaap



[1] https://community.icann.org/display/tap/2005-03-21+-+Delegation+of+.EU.
For fun, see also
http://www.iana.org/reports/2005/eu-report-05aug2005.pdf for the public
IANA report.

[2] 
http://web.archive.org/web/20030801082348/http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html.

[3] 
http://web.archive.org/web/20030810102245/http://www.iso.org/iso/en/prods-services/iso3166ma/04background-on-iso-3166/reserved-and-user-assigned-codes.html#reserved.

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

[Jaap Akkerhuis]

 Andrew Sullivan writes:

  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?
 
No 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.

Yep. One could name sTLD (Sponsored TLD) and infrastructural TLDs as
well although it might distract again from the main point: There is a
difference between protocol and naming policy.

jaap

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

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

[Jaap Akkerhuis]

 Jaap Akkerhuis writes:
 
Oops, wrong message went out.

   Tim Wicinski writes:
  
This is a multi-part message in MIME format.
--010907040103080303070203 Content-Type: text/plain;
charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit



All

We've finalized the Interim Meeting to discuss the questions around
RFC 6761 and the Special Names Registry.

Details:

Date: Tuesday, 12 May 2015 Time: 1600-1800 UTC (1200-1400 EDT)


But what I wanted to say:

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

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

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

[Jaap Akkerhuis]

 Tim Wicinski writes:

  Jaap Akkerhuis was the Arranger of the room.

Too much honour. I was indeed arranging a room (for somthing else)
and then Kaveh Ranjbar suggested to arrange a room for dnsop as
well.

  
  I Initially thought a polycom type thing could cause a muddle of
  voices.  But I'm willing to listen to reason and logic.

Noted. Let's see what is possible.

jaap

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

Re: [DNSOP] RFC 6761 discussion (“special names”)

[Jaap Akkerhuis]

 Tim Wicinski writes:

  The WG has several documents that we need to spend time in Dallas moving 
  towards completion. But we also believe the RFC 6761 drafts should not 
  be given short shrift.
  
  Accordingly, we are tentatively planning a Virtual Interim Meeting to 
  dive a little deeper on the special names drafts, including possible 
  architectural implications of the apparent increase in interest in RFC 
  6761, as we attempt to muddle through the questions we’ve seen and the 
  ones we anticipate.
  

Following this discussion from a distance, I cannot help wondering
whether this is special names stuff might in violate RFC 2860 section 4.3.

jaap

___
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

[Jaap Akkerhuis]

 When a DNS operator first signs their zone, they need to communicate their
 keying material to their parent through some out-of-band method to 
complete



And changing opening sentence to:

The first time a DNS operator signs the zone, they need to
communicate the keying ...

Make it even more clear.

jaap (nitpicking mode)

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

Re: [DNSOP] on Negative Trust Anchors

[Jaap Akkerhuis]

On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote:
 More pragmatically, while I understand the theory behind rejecting NTAs,
 I have to admit it feels a bit like the IETF rejecting NATs and/or DNS
 redirection. I would be surprised if folks who implement NTAs will stop
 using them if they are not accepted by the IETF.
 
 it is still not a reason for the IETF to standardize this.

With the implication that multiple vendors go and implement the
same thing in incompatible ways. I always get a headache when
this sort of thing happens as the increased operational costs
of non-interoperable implementations usually seems more damaging
to me than violations of architectural purity. Different
perspectives I guess.

If people have to do te hack themselves, they are more likely to
understand what they are doing. If you want to give a standard tool
they might apply it just because it is there. It is like the BIND
(temporary?) delegation only  hack. Lots of people applied it
without understanding.

As an example, when some authoritative domains brough all there
name servers in balliwick, it broke the lookup for those domains and
people couldn't figure out why.

And apart from this operational problem, there are more principal
objections such as pointed out by Doug.

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

Re: [DNSOP] on Negative Trust Anchors

[Jaap Akkerhuis]

...
More pragmatically, while I understand the theory behind rejecting NTAs,
I have to admit it feels a bit like the IETF rejecting NATs and/or DNS
redirection. I would be surprised if folks who implement NTAs will stop
using them if they are not accepted by the IETF.

Doing the validation on my machine makes it easy for me to realize
who to blame when things break but I realize others don't have that
insight or run validators, so I see the pain for the validating
ISP. However, it is still not a reason for the IETF to standardize
this.

(paf)
 But, all of this thinking leads me to think about DNSSEC validation
 risks are very similar to the risk with deploying IPv6?
 We have an IPv6 day, but why not a DNSSEC day? One day where
 *many* players at the same time turn on DNSSEC validation?

(drc)
Definitely a good idea.

It is seems a nice idea but a problem is that a single day is
probably not enough.  IPv6 problems are (nearly) instantaneous but
with DNSSEC problems start to arise when things expire.

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

Re: [DNSOP] Updated DNS Redirect Draft

[Jaap Akkerhuis]

Didn't I also a 00 draft about DNS Redirect and malware protection
passing by?

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

Re: [DNSOP] m.root-servers.net DNSSEC TCP failures

[Jaap Akkerhuis]

m.root-servers.net 

is now serving DNSSEC, but does not have TCP, so the following
queries all fail

They works for me but not behind the linksys router of the meeting I'm
currently in.

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

Re: [DNSOP] automatic update of DS records

[Jaap Akkerhuis]

On Wed, Mar 03, 2010 at 11:28:36AM +0100, Jaap Akkerhuis wrote:
 
 Antoin says:
 So there's one more logical entity involved; most likely this way:
 
   jaap
 ___


did i miss something?  Antoin sez that where?

Oops, apparently Alfred said so. But who sais what is irrelevat on the
discussion. The oint I was making is that there should not be a fixed
aministrative model.

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

Re: [DNSOP] automatic update of DS records

[Jaap Akkerhuis]

   either have a bof (formal) or a small lunch mtg 
   during the week of IETF77?
 
   I'd be glad to attend.
 ...
 
going to be there and he agreed to attend the BoF.

Note, it is way past the time to request a BOF so I geuss the only
option is something informal.

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

Re: [DNSOP] Priming query transport selection

[Jaap Akkerhuis]

What does a DNSSEC-protected priming query gain you?

I was about to ask the same question.

Accepting any old priming query and having a root SEP configured, if 
the query is right all things work.  If the query is wrong/forged you 
won't get anywhere any how.  (Without going into the weeds here - 
what if one IP address were forged, what if it were 6, 16, or all of 
them?)

(13 name servers = 13 A records + 7  records last check)

Besides the warm and fuzzy feeling, what do you gain? (Keep in mind 
all of the TCP traffic it would take to get warm and fuzzy.)

I think that this is also discussed in Koch's priming draft.

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

Re: [DNSOP] Priming query transport selection

[Jaap Akkerhuis]

Well having TCP used for all priming queries would make me feel better
as TCP traffic is harder to forge.

So let's forget about dnssec an do everything over TCP?

But seriously DNSSEC signed and validated data should protect the
the resolver from going to the forged addresses.

So you wasn't serious? 

Yes someone can forge the answer and DoS the resolver into believing that
nothing works.
The situation is . and root-servers.net. zones are hosted on the
root servers, thus the same servers will get all follow-up questions
about signed address sets as the priming query.
Resolvers like to ask the close servers for information thus it
is almost certain that over time the resolver will send a question
to all root servers.

Based on this I think one TCP connection is better than 14-27
UDP ones. (Resolver that only supports one transport should never
ask for the address records it will not use).
We can even take this one step further and ask both priming questions
over the same TCP connection that is NS and DNSKEY.

Ed in my mind this is straight forward engineering question,
which approach is better as in cheaper/faster/safer.

But then I expect some decent answers and not some handwaving and flip-flopping
between being serious and not.

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

Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt

[Jaap Akkerhuis]

Does not ISO3166 solve that problem for us with regards to allowed
characters in the TLD label?

No. The alpha-2 used for ccTLD labels (and also the alpha-3) codes
are restricted to the set A-Z.

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

Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt

[Jaap Akkerhuis]

 does this mean my chances for  ^B. are nil?  :)

Go for it!

I claim ^S

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

Re: [DNSOP] Microsoft updates RFC 2606

[Jaap Akkerhuis]

I just discovered that Microsoft registered tempuri.com (and .org) and
apparently promotes them for use in documentation and examples,
ignoring RFC 2606.

Actually, if you read the text at that link, it is for using in
experimental XML namespaces.

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

[DNSOP] numeric labels

[Jaap Akkerhuis]

I haven't read the draft yet, but the discussion whether numeric
labels are allowed seems to get slightly out of hand.

Anybody can use them and apparently people are. That is easily
proved but running something like:

for i in `seq 1 1 1000`; do echo $i; dig +short $i.com; done

and replace .com with different TLDs such as .info, .biz, .pro,
.cn, .nl etc. as well.  (Variations in the boundaries is also
advised so you can stumble on 4711 and similar trademarks).

Whatever the scriptures are saying or how they can be interpreted,
I haven't seen seen the network crashing down due to this practice.

That using multiple numeric domains can backfire and that if you
open a web-shop at the host named 127.0.0.1 might not result in a
stellar sized customer base is something completely different. You
just get what you ask for.

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

Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

[Jaap Akkerhuis]

On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:

 it in their products or services.  Peter Koch did provide an interesting 
 data point that warrants further investigation (20-35% of queries having 
DO 
 bit on seems a bit high to me) and someone else responded privately that 

I seem to remember that some time back (two years or so?) RIPE-NCC
also published data points and they were in about the same range.

Some searching reveals:

Ref:ripe-352
Title:  Measuring the resource requirements of DNSSEC
Author: Olaf Kolkman
RIPE NCC / NLnet Labs
Date:   October 2005
Format: PDF=5367108

The URL for this: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf.

Already three years ago, time flies

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

Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))

[Jaap Akkerhuis]

 Also, a well behavng resolver
 has way less request to the root servers then to other servers.

Why, do you think, that servers other than the root servers won't
reply with oversized messages?

Don't twist my words. I never said that.

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

Re: [DNSOP] New Draft Charter

[Jaap Akkerhuis]

On 11-Mar-2008, at 10:37, Dean Anderson wrote:

 So root and gTLD DNS server operations supervision is off the charter?

I'm not sure it was ever on the charter.

It is in the current charter ...

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

[DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

[Jaap Akkerhuis]

There are two major reasons for an organization to not want roaming 
users to trust locally-assigned DNS servers.

Open recursive servers doesn't help in against man in the middle
attacks. If you want to avoid that use VPN's or (for DNS) TSIG.

I seem to remember that the ID actually mentions that.

jaap

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

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