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 
> 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.or

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] 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"  wrote:
>
>
>> The RIPE staff has been very nice and made a room available at RIPE-70
>> :
>>
>>   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

[Niall O'Reilly]

On Thu, 30 Apr 2015 15:35:31 +0100,
Andrew Sullivan wrote:
> 
> On Wed, Apr 29, 2015 at 07:28:21PM +, Edward Lewis wrote:
> 
> > 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.

  ISTM that in such a case, the resolver is ignoring the
  updated/(re)moved delegation, rather than that the delegation hasn't
  moved.

  Niall O'Reilly
  

___
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

[Niall O'Reilly]

On Thu, 30 Apr 2015 15:35:31 +0100,
Andrew Sullivan wrote:
> 
> On Wed, Apr 29, 2015 at 07:28:21PM +, Edward Lewis wrote:
> 
> > 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.

  ISTM that in such a case, the resolver is ignoring the
  updated/(re)moved delegation, rather than that the delegation hasn't
  moved.

  Niall O'Reilly
  

___
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

[Jim Reid]

On 1 May 2015, at 08:31, Patrik Fältström  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.

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

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.

___
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  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] Terminology: forwarding and forwarder

[Tony Finch]

Paul Hoffman  wrote:
>
>Forwarder -- Section 1 of [RFC2308] describes a forwarder as "a
>nameserver used to resolve queries instead of directly using the
>authoritative nameserver chain".  [RFC2308] further says "The
>forwarder typically either has better access to the internet, or
>maintains a bigger cache which may be shared amongst many resolvers."

The following two sentences don't agree with each other very well. The
first is wrong because there can be chains of forwarders. The second
sentence is more correct, though I don't understand the distinction
between "is iterative-only or can be a full resolver" because an
iterative-only resolver is a full resolver.

>That definition appears to suggest that forwarders normally only
>query authoritative servers.

>[RFC2308]
>is silent on whether a forwarder is iterative-only or can be a full
>resolver.

This sentence disagrees with the RFC 2308 meaning:

>  In current use, however, forwarders
>often stand between stub resolvers and recursive servers.

The RFC 2308 usage is:

stub -> recursive server 1 -> recursive server 2

RS1 is configured to use RS2 as a forwarder.

In this definition "forwarder" is not a description of an individual
server, it is a description of how a server (RS1) is configured to use
another server (RS2). Neither RS1 nor RS2 are (by themselves) forwarders.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Irish Sea: East 4 or 5, veering southeast 5 to 7, perhaps gale 8 later. Slight
or moderate, becoming moderate or rough. Occasional rain later. Good, becoming
moderate or poor later.

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

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

[Tony Finch]

Paul Hoffman  wrote:

> Greetings again. Based on Casey's proposal, I would like to make the
> following changes. Thoughts?

I'm not entirely sure, because it loses the RFC 2136 concept of "primary
master" which is the root of the zone transfer / update forwarding graph,
and I think demoting "primary" to the weaker meaning that "master" has
would be confusing.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Irish Sea: East 4 or 5, veering southeast 5 to 7, perhaps gale 8 later. Slight
or moderate, becoming moderate or rough. Occasional rain later. Good, becoming
moderate or poor later.

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

Re: [DNSOP] Terminology: policy-implementing resolver

[Tony Finch]

Paul Hoffman  wrote:
>
> Good question, and no. "Policy-based" and "policy-implementing" are
> those kind of terms we hear bandied about in operator circles but not
> written about in RFCs because it is supposedly outside the purview of
> the IETF. If someone has a reasonable reference we can point to, that
> would be great.

As well as Hugo's link, there is http://dnsrpz.info which has some more
helpful context and practical info.

But in practice people seem to be using the term "DNS firewall" much more
than "policy-implementing resolver", though it seems to be quite closely
associated with RPZ - e.g. the PowerDNS recursor scripting documentation
doesn't use either term.

http://www.circleid.com/posts/20120103_dns_firewalls_in_action_rpz_vs_spam/
http://www.securityweek.com/why-dns-firewalls-should-become-next-hot-thing-enterprise-security
https://kb.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
https://www.infoblox.com/products/secure-dns/dns-firewall
http://www.efficientip.com/dns-firewall/
https://doc.powerdns.com/md/recursor/scripting/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Hebrides, Bailey: East or southeast 3 or 4, increasing 5 or 6. Slight or
moderate. Showers. Good.

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

Re: [DNSOP] draft-ietf-dnsop-edns-client-subnet-00 Birthday Attack

[Wilmer van der Gaast]

Hello,

I was just pointed at this message.

On 22 April 2015 at 12:49, Yuri Schaeffer  wrote:
>> Replies coming from servers not supporting edns-client-subnet or
>> otherwise not containing an edns-client-subnet option SHOULD be
>> considered as containing a SCOPE NETMASK of 0 (e.g., cache the
>> result for 0.0.0.0/0 or ::/0) for all the supported families.
>
> These two excerpts directly contradict in my opinion and DO make ECS
> enabled resolvers vulnerable for cache poisoning.
> ...
> 3) attacker sends flood of spoofed responses with evil content and
> without the ECS option. It has a high success rate due to the
> birthday problem.

So this is indeed tricky. Yes, a valid x.x.x.x/(non0)/0 response
addresses birthday attack scenarios, and that should work.

We've discussed this risk here quite long ago but clearly the draft
needs an update. :-( If an authority is known to support ECS, a
response without ECS should in fact be discarded, not treated as 0/0.
This is easy to do when you work with a whitelist, though of course
there's the risk of an authority (temporarily) dropping ECS support.

> I'm not sure where to go from here. Not echoing the option after all
> is the proper EDNS way of signalling lack of support for said option.
> So dropping the option-less answer is also not a good idea.
>
Probably the safest, and then reissue a single query without ECS
instead of continuing the flood.


Cheers,

-- 
Wilmer van der Gaast, London Traffic/Edge SRE.

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

Re: [DNSOP] Yet another thought on draft-ietf-dnsop-dns-terminology

[Tony Finch]

Edward Lewis  wrote:

> I'd been forgetting to mention this outside my head.
>
> I suggest a section describing names give to messages.

Yes, I have had the same thought, and I think this could help with the
iteration / recursion / server role question. I have some text in the
works.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber, Thames: Northeast veering east 4 or 5. Slight or moderate. Fair. Good.

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

Re: [DNSOP] draft-ietf-dnsop-dns-terminology needs to define "label"?

[Tony Finch]

Eric Brunner-Williams  wrote:

> i'd like to think of it as a sequence of bits having having no infix dots and
> having no semantics, e.g., directionality, arising externally to itself.

Dots are allowed in labels but have to be escaped in the presentation
format. RFC 1035 section 5.1:

\X  where X is any character other than a digit (0-9), is
used to quote that character so that its special meaning
does not apply.  For example, "\." can be used to place
a dot character in a label.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
East Sole, Lundy, Fastnet: Cyclonic at times in east Sole, otherwise
southeasterly 5 to 7. Moderate or rough. Occasional rain, fog patches.
Moderate, occasionally very poor, becoming good at times.

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

Re: [DNSOP] Terminology: country

[Tony Finch]

They are country-code TLDs because they use the country codes from
ISO 3166. "Country codes" is the title of part 1 of ISO 3166.
http://www.iso.org/iso/country_codes.htm

There are also the IDN ccTLDs which do not use country codes but which
are allocated based on the ISO 3166 eligibility criteria.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: In southeast, northwesterly 4 or 5. In northwest, southwesterly 5
or 6. In southeast, slight or moderate. in northwest, moderate or rough. In
southeast, fair. In northwest, occasional rain. In southeast, good. In
northwest, good, occasionally poor.

___
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

[Tony Finch]

Warren Kumari  wrote:
>
> NXDOMAIN -- A colloquial expression for RCODE 3, also commonly written
> as 'NXDomain' or 'Non-Existent Domain'

NXDOMAIN etc. are not colloquialisms, they come from the 4.3BSD resolver
API. (Spelling them in lower case is weird if not wrong.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Dover, Wight, Portland: Northeast veering southeast, 5 to 7. Mainly moderate.
Occasional rain. Moderate or good, occasionally poor later.

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

Re: [DNSOP] Terminology: country

[Bob Harold]

On Thu, Apr 30, 2015 at 2:18 PM, Bill Woodcock  wrote:

> ...
> >> 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?
> >
> > I would be fine with that wording, but it doesn't hint at what "cc"
> stands for. Again, Jon Postel used the word "country code" and "country
> this" and "country that" quite liberally in RFC 1591. I'm not convinced we
> need to step away from that now.
>
> The “what’s a country” issue is one that we confront constantly, as people
> ask us for statistics about Internet bandwidth production, traffic flows,
> and yes, even TLDs.  There’s just no clean answer.  Whether that be the
> island of Sint Maarten/Saint-Martin (half constituent country of the
> Kingdom of the Netherlands, half overseas collectivity of France) or
> Cyprus, mention of which always triggers pro-forma outrage from Turkey.
>
> I completely agree that we should be clear that “cc” stands for Country
> Code, and I think we should defer to ISO for their own definition of ISO
> 3166: "ISO 3166 is the International Standard for country codes and codes
> for their subdivisions” no matter how inaccurate that actually seems.
> Because it’s good enough, and this is a complex issue that we’re not going
> to solve, given how many other people have tried and failed.
>
>
"we should be clear that “cc” stands for Country Code" even if that is not
technically exact.


> But we can acknowledge the complexity, and use some word other than
> “country” to describe how the Internet uses these codes.
>
> For instance, we could refer to domains associated with “geographic
> territories,” including both ccTLDs, geographic ngTLDs, and geographic IDN
> TLDs.
>
> -Bill
>

-- 
Bob Harold
___
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

[Paul Vixie]

Tony Finch wrote:
> Warren Kumari  wrote:
>> NXDOMAIN -- A colloquial expression for RCODE 3, also commonly written
>> as 'NXDomain' or 'Non-Existent Domain'
>
> NXDOMAIN etc. are not colloquialisms, they come from the 4.3BSD resolver
> API. (Spelling them in lower case is weird if not wrong.)

according to

http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

it's in mixed case.

if we don't want iana to register "NXDomain" as the "name" of this rcode, we'll 
have to change that registry. 


-- 
Paul Vixie

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

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

[Edward Lewis]

On 4/30/15, 10:35, "Andrew Sullivan"  wrote:

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

The context here is the definition of the term "delegation".

In operations, it's expected that a parent could remove a delegation (in
the policy sense) and because of TTL's, the child's presence sticks in the
cache.  This is a legitimate outcome of the use of caching.  (It can be
abused, of course, but I'm just trying to stick to definitions of terms,
not operational issues.)

In my personal judgement, the mere fact that there is a transitional state
of a half-baked delegation is not significant.  Perhaps there's a need to
"name" this state (I can see trying to explain this to a customer).  But
to me that doesn't mean the definition of delegation has to take this into
account.

In "policy time" the delegation ends when the parent's zone serial is
incremented and the cut point is gone.  In "real time" the delegation ends
in the eyes of a resolver when it discovers there is no cut point.  Yes,
these are different, but to define "delegation" I would stick to the
perspective of the parent because it is the one legitimately holding the
cards.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-dns-terminology needs to define "label"?

[Edward Lewis]

On 5/1/15, 8:20, "Tony Finch"  wrote:

>Eric Brunner-Williams  wrote:
>
>> i'd like to think of it as a sequence of bits having having no infix
>>dots and
>> having no semantics, e.g., directionality, arising externally to itself.
>
>Dots are allowed in labels but have to be escaped in the presentation
>format. RFC 1035 section 5.1:
>
>\X  where X is any character other than a digit (0-9), is
>used to quote that character so that its special meaning
>does not apply.  For example, "\." can be used to place
>a dot character in a label.

Had the same thought too.

The context in which infix dots and directionality come to light is in the
registration of names, particularly IDNs.  But that is not a universal
concern in when it comes to defining a label.

A label is a component of a domain name.  That applies to the wire format
or the printed representation.  On the wire it is an octet indicating type
and length followed by the data.  In printed form it is the stuff between
unescaped separators [which happen to be '.' now/but don't have to be].


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terminology: forwarding and forwarder

[Shumon Huque]

On Fri, May 1, 2015 at 6:39 AM, Tony Finch  wrote:

> Paul Hoffman  wrote:
> >
> >Forwarder -- Section 1 of [RFC2308] describes a forwarder as "a
> >nameserver used to resolve queries instead of directly using the
> >authoritative nameserver chain".  [RFC2308] further says "The
> >forwarder typically either has better access to the internet, or
> >maintains a bigger cache which may be shared amongst many resolvers."
>
> The following two sentences don't agree with each other very well. The
> first is wrong because there can be chains of forwarders. The second
> sentence is more correct, though I don't understand the distinction
> between "is iterative-only or can be a full resolver" because an
> iterative-only resolver is a full resolver.
>
> >That definition appears to suggest that forwarders normally only
> >query authoritative servers.
>
> >[RFC2308]
> >is silent on whether a forwarder is iterative-only or can be a full
> >resolver.
>
> This sentence disagrees with the RFC 2308 meaning:
>
> >  In current use, however, forwarders
> >often stand between stub resolvers and recursive servers.
>
> The RFC 2308 usage is:
>
> stub -> recursive server 1 -> recursive server 2
>
> RS1 is configured to use RS2 as a forwarder.
>
> In this definition "forwarder" is not a description of an individual
> server, it is a description of how a server (RS1) is configured to use
> another server (RS2). Neither RS1 nor RS2 are (by themselves) forwarders.
>

In light of the self contradictory text in RFC 2308, which in turn
conflicts with RFC 5625's equating DNS proxies with forwarders, perhaps
it's time for this draft to provide a new authoritative definition of
forwarder. To add further confusion to this topic, see ISC's own blog
article on forwarders, which defines a range of possible entities from
simple proxies to full resolvers as forwarders:

https://www.isc.org/blogs/dns-forwarders/

Personally, I prefer a definition that says that a forwarder is an entity
that forwards DNS queries to another system for resolution rather than
directly querying the authoritative DNS hierarchy. This seems the most
intuitive to me. If the forwarder is by implication of RFC 2308 the
opposite, i.e. the thing that receives forwarded queries and uses the
authoritative nameserver chain for resolution, then this just means we've
unnecessarily added another term to a full resolver (setting aside chains
of forwarders for the moment). It seems to me that the thing that is
forwarding queries is the thing that needs a new definitional term. But
maybe for some, that is a DNS proxy?

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

Re: [DNSOP] Terminology: forwarding and forwarder

[Tony Finch]

Shumon Huque  wrote:
>
> In light of the self contradictory text in RFC 2308,

I don't think it is self-contradictory; it just has a slightly weird
definition. (Maybe this draft should note that where RFC 2308 says
"forwarder" it actually means "recursive server used by a forwarder". The
"forwarders" configuration in BIND is similar.)

> Personally, I prefer a definition that says that a forwarder is an entity
> that forwards DNS queries to another system for resolution rather than
> directly querying the authoritative DNS hierarchy.

Yes, that's the more usual meaning.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Faeroes: Variable 4, becoming south or southeast 4 or 5. Slight or moderate.
Wintry showers. Good, occasionally moderate.

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

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

[Shumon Huque]

On Fri, May 1, 2015 at 6:52 AM, Tony Finch  wrote:

> Paul Hoffman  wrote:
>
> > Greetings again. Based on Casey's proposal, I would like to make the
> > following changes. Thoughts?
>
> I'm not entirely sure, because it loses the RFC 2136 concept of "primary
> master" which is the root of the zone transfer / update forwarding graph,
> and I think demoting "primary" to the weaker meaning that "master" has
> would be confusing.
>

I agree. My suggestion is to add a definition for "Primary Master" and
remove "Primary". Then we end up with:

Primary Master server
Master server
Secondary server (synonym: Slave server)

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

Re: [DNSOP] Terminology: country

[Jaap Akkerhuis]

 Tony Finch writes:

 > They are country-code TLDs because they use the country codes from ISO
 > 3166. "Country codes" is the title of part 1 of ISO 3166.
 > http://www.iso.org/iso/country_codes.htm
 > 
 > There are also the IDN ccTLDs which do not use country codes but which
 > are allocated based on the ISO 3166 eligibility criteria.

Indeed. And trying to cram both of these different means (and with
that, years of policy discussions, exceptions, mistakes such as AC
etc.) into one definition is doomed to fail.

For the purpose of this document a definition such as Kim Daves
proposed seems to me good enough.

jaap

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

Re: [DNSOP] draft-livingood-dnsop-negative-trust-anch...@tools.ietf.org

[神明達哉]

At Fri, 24 Apr 2015 23:59:22 -0400,
Warren Kumari  wrote:

> So, I have gone back through previous mail and it seems that this was
> the only email that got missed.
> Anyway, it seems that other folk also made similar comments, and so,
> by -03, we had addressed almost all of them.
>  Apologies again for not seeing and responding to your mail.

No worries, and thanks for addressing these so quickly.

> >   I agree with the sense of the statement, but specifically how can
> >   the operator confirm that it's misconfiguration? [...]
>
> My last update (a few days ago) included inserting an Appendix that
> covers some of this. It is somewhat rough,and more conversational in
> tone than if it were in the main part of the draft, but I think
> strikes a nice balance.

Do you mean Appendix B?  It certainly looks good enough to me to
address this point.

> > - Also on that sense and this one in Section 8:
> >
> >Use of a
> >Negative Trust Anchor MUST NOT be automatic.
> >
> >   Again, I agree with the sense, but I wonder whether players like big
> >   ISPs or public DNS services are really willing to follow the
> >   suggestion of human intervention and/or ban of automation.
[...]
> >   For these recommendations to be really effective rather than just
> >   ignored, I think we need to provide some more information, e.g.,
> >   statistics on how often these events are happening in actual
> >   providers that use NTAs, show example of operational practices
> >   (which I guess would include some level of automation).
>
> We don't really have anything published, but I spoke with the person
> who deals with these and it is around once per quarter (it has slowed
> down). This year we have only done it once - for the .KE keyroll event
> ( thread here: 
> https://lists.dns-oarc.net/pipermail/dns-operations/2015-March/013060.html
> )

Okay, then I'd suggest adding some brief note on this point.  One
possibility would be to add something like this to the end of the
first paragraph of Section 2:

   [... prior to implementing the Negative Trust Anchor.]  Involving
   trained technical personnel is costly, but operations experiences
   so far suggest that this is a very rare event such as around once
   per quarter or even less.

(and if we can include a concrete reference, do that)

> > - Also on Section 8:
> >
> >Finally, a Negative Trust Anchor SHOULD be used only in a specific
> >domain or sub-domain and MUST NOT affect validation of other names up
> >the authentication chain.
> >
> >   I think it would also help clarify that the deepest anchor should be
> >   used, whether positive or negative. [...]
>
> Actually, an NTA stops validation at that point, which includes things
> under that.
> Here is text (which probably changed after your comment:
> "This Negative Trust Anchor can potentially be implemented at any
> level within the chain
>  of trust and would stop validation from that point in the chain down."
>
> This gave us the needed behavior when .ke broke...
> Yes, turning off validation for an entire ccTLD is a big hammer --
> but, it is better than turning off validation for *everyone*, or just
> leaving an entire country unresolvable for many hours

Hmm...first, if this is really the intent, I'd suggest revising
Section 8, too, to state it more explicitly (also possibly with an
example).

Secondly, does it make most sense?  If we have a manually configured
positive trust anchor for "good.example.ke", isn't it better to still
use it for anything on or below that, but skip DNSSEC validation for
everything else on or under .ke?  At least this shouldn't mean
"turning off validation for *everyone*" or "just leaving an entire
country unresolvable for many hours", so such arguments don't seem to
be a reason for not doing this.

> > - Section 10
> >
> >validates can have security considerations.  It is therefore
> >recommended that NTA implementors should periodically attempt to
> >validate the domain in question, for the period of time that the
> >
> >   I wonder whether this 'should' may better be SHOULD.  Not a strong
> >   opinion, but it seems to be similar to other recommendations using
> >   the capitalized keyword in Section 8.
>
> So, I went to go make that change, and discovered it is already a SHOULD.
> Sometime between when you wrote this mail (11/14) and version -03 I
> incorporated this change.

It's still a "should" in the 04 version:

   validates can have security considerations.  It is therefore
   recommended that NTA implementors should periodically attempt to
   validate the domain in question, for the period of time that the
   Negative Trust Anchor is in place, until such validation is again
   successful.
(from https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04)

> > - Appendix A: not intending to endorse a particular implementation(s),
> >   but I'd suggest clarifying which specific implementations support
> >   various recommendations of t

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

[Paul Hoffman]

Are y'all looking at the -01 draft? Because it defines "primary server" and 
"primary master", both using quotes from RFCs. Are those quotes not correct?

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

Re: [DNSOP] draft-ietf-dnsop-dns-terminology needs to define "label"?

[Stephane Bortzmeyer]

On Wed, Apr 29, 2015 at 03:39:15PM -0700,
 Paul Hoffman  wrote 
 a message of 12 lines which said:

> What do others think?

I regret that draft-ietf-dnsop-dns-terminology-01 keeps using a wrong
definition for "RRset", which is contradictory with the definitions
proposed in this thread for "label":

A set of resource records with the same label, class and type, but
with different data.

While it should be:

A set of resource records with the same owner name (FQDN), class and
type, but with different data.


___
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

[Stephane Bortzmeyer]

On Fri, May 01, 2015 at 09:31:11AM +0200,
 Patrik Fältström  wrote 
 a message of 189 lines which said:

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

There is a risk that the very long discussion about what is a country
distracts us from an important point I would like to be added in the
definition:

>From the point of view of the DNS, there is no difference between a
ccTLD and a gTLD. This distinction is relevant only for policies.

___
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

[Marc Blanchet]

> Le 2015-05-01 à 14:47, Stephane Bortzmeyer  a écrit :
> 
> On Fri, May 01, 2015 at 09:31:11AM +0200,
> Patrik Fältström  wrote 
> a message of 189 lines which said:
> 
>> 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.
> 
> There is a risk that the very long discussion about what is a country
> distracts us from an important point I would like to be added in the
> definition:
> 
>> From the point of view of the DNS, there is no difference between a
> ccTLD and a gTLD. This distinction is relevant only for policies.

right. I completly agree and I was going to write almost the same thing.

suggest to remove ccTLD/gTLD and stick with TLD.

Marc.

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

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

Re: [DNSOP] Terminology: forwarding and forwarder

[Stephane Bortzmeyer]

On Fri, May 01, 2015 at 05:42:28PM +0100,
 Tony Finch  wrote 
 a message of 25 lines which said:

> Maybe this draft should note that where RFC 2308 says "forwarder" it
> actually means "recursive server used by a forwarder".

No, it means "forwarder" and it has always been used that way (for
instance in BIND configuration).

Note that this meaning is not BIND-specific and is used by other
programs such as dnssec-trigger
 ("to use the DHCP
obtained forwarders if possible, and fallback to doing its own AUTH
queries if that fail")


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

Re: [DNSOP] Draft on censorship, and DNS

[Stephane Bortzmeyer]

On Fri, Nov 07, 2014 at 08:39:31AM -0800,
 Stephane Bortzmeyer  wrote 
 a message of 14 lines which said:

> There is an Internet-Draft "A Survey of Worldwide Censorship
> Techniques" draft-hall-censorship-tech-00 which is on the agenda of
> the Security Area Open Meeting next week at IETF 91 Honolulu.
> 
> I applaud the effort, I've reviewed the DNS part and I find it of low
> quality, with sloppy terminology. 

Version -01 was published and the DNS part is not better. May be
people who find this work important could help the authors by
submitting pull requests on Github
?

___
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

[Paul Hoffman]

On May 1, 2015, at 11:56 AM, Marc Blanchet  wrote:
>>> From the point of view of the DNS, there is no difference between a
>> ccTLD and a gTLD. This distinction is relevant only for policies.
> 
> right. I completly agree and I was going to write almost the same thing.
> 
> suggest to remove ccTLD/gTLD and stick with TLD.

Just to be clear: you want to remove terms that are commonly used in talking 
about the DNS from the terminology draft? I am hesitant to do this, given that 
they appear in DNS-related RFCs, but if the WG wants to remove them instead of 
defining them in a way that gets consensus, we can do that.

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

Re: [DNSOP] draft-ietf-dnsop-dns-terminology needs to define "label"?

[Paul Hoffman]

On May 1, 2015, at 11:50 AM, Stephane Bortzmeyer  wrote:
> 
> I regret that draft-ietf-dnsop-dns-terminology-01 keeps using a wrong
> definition for "RRset", which is contradictory with the definitions
> proposed in this thread for "label":
> 
> A set of resource records with the same label, class and type, but
> with different data.

And, two sentences later, it says:
   As a clarification, "same label" in this definition means "same owner name".

> While it should be:
> 
> A set of resource records with the same owner name (FQDN), class and
> type, but with different data.

We coud do that, and change the attribution to be "(Definition derived from 
from {{RFC2181}})", but is that really needed, given the current clarification?

--Paul Hoffman
___
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

[Marc Blanchet]

> Le 2015-05-01 à 15:27, Paul Hoffman  a écrit :
> 
> On May 1, 2015, at 11:56 AM, Marc Blanchet  wrote:
 From the point of view of the DNS, there is no difference between a
>>> ccTLD and a gTLD. This distinction is relevant only for policies.
>> 
>> right. I completly agree and I was going to write almost the same thing.
>> 
>> suggest to remove ccTLD/gTLD and stick with TLD.
> 
> Just to be clear: you want to remove terms that are commonly used in talking 
> about the DNS from the terminology draft? I am hesitant to do this, given 
> that they appear in DNS-related RFCs, but if the WG wants to remove them 
> instead of defining them in a way that gets consensus, we can do that.

I understand the point. I’m saying that defining ccTLD/gTLD does not really 
bring anything and has Stéphane wrote, is on the policy side. If we want to be 
exhaustive in defining all keywords and terms, I would suggest then:

ccTLD: a TLD
gTLD: a TLD
TLD: the more exhaustive version…

that way, we can achieve the goal of being « exhaustive » while not entering 
into various policies and exceptions that is a rathole.

Marc.


> 
> --Paul Hoffman

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

[DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01

[Evan Hunt]

Greetings,

The current DNS Cookies document (draft-ietf-dnsop-cookies-01) has two
similar but distinct protocols described in it: the DNS Cookie option as
designed by Donald Eastlake, and the Simple DNS Cookie option designed by
Mark Andrews and experimentally implemented (under the name Server Identity
Token, or SIT) in BIND 9.10.

The chief difference between the two is the presence of an error code field
in Eastlake cookies; Andrews found it redundant/unnecessary (as discussed
in https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html).
The hope was that including both mechanisms in the draft would lead to
a working group discussion about whether the error code is, in fact,
necessary or desirable; unfortunately, not much discussion has happened
yet.

I would very much like to see this protocol nailed down enough that
we can request a code point and start including this feature in BIND
without the #ifdef's around it.  I'm hoping for WGLC in the Prague
timeframe.  May I request that people weigh in on the error code
issue?

Speaking for myself, I agree with Mark: the benefits of including error
codes in the option are slim and other mechanisms such as FORMERR work
just as well in almost every scenario, so it doesn't justify the cost in
additional complexity.

Thanks,

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01

[Wessels, Duane]

> On May 1, 2015, at 4:21 PM, Evan Hunt  wrote:
> 
> Speaking for myself, I agree with Mark: the benefits of including error
> codes in the option are slim and other mechanisms such as FORMERR work
> just as well in almost every scenario, so it doesn't justify the cost in
> additional complexity.

I'm inclined to agree.  I was a bit torn because there have been so many other
times I wished a certain feature had additional error signaling, but I found it
hard to justify the complexity in this case.

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