Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation

From: David Conrad <[email-masked]>
Date: Sat, 3 Jan 2015 11:17:13 -0800

Some comments on the qname-minimisation draft:

In general, while I like the idea of qname minimization, much of this draft reads like a series of complaints about bad DNS operational practices instead of providing a detailed explanation of how to minimize the query names and what that might imply.

- Section 1:

While the pointer to the dns-privacy draft is helpful as a reference, I figure the introduction/background section should provide an introduction to the specific problem the draft is attempting to address and why it is a problem.

- Section 2:

"It can be noted that minimising the amount of data sent also
 partially addresses the case of a wire sniffer, not just the case of
 privacy invasion by the servers."

This probably needs a bit more explanation. If you're sniffing the wire, you'll see the final query for the full QNAME/QCLASS/QTYPE and all the intervening NS queries can simply be ignored, no? Or is the sniffer on a different wire?

"Sending the full qname
 to the authoritative name server is a tradition, not a protocol
 requirment."

I'd actually call it an optimization, not a tradition.

- Section 3:

"On the other hand, it will decrease their legal responsability, in many cases."

I'm not sure it's worth raising this as "legal responsibility" in an engineering document sounds like a 'rathole of unusual size' to me.

'As an example of today, look at www.ratp.fr (not ratp.fr), which is
 delegated to two name servers that reply properly to "A www.ratp.fr"
 queries but send REFUSED to queries "NS www.ratp.fr".'

I suspect this particular brokenness will be fixed at some point in the future, thus I doubt this example will be useful.

'Another way to deal with such broken name servers would be to try
 with A requests (A being choosen because it is the most common and
 hence the least revealing qtype).'

I'm unclear as to how the QTYPE being requested provides significantly more information leakage -- isn't the real information leakage the actual QNAME?

'For such a name, a cold resolver will, depending how qname
 minimisation is implemented, send more queries.'

It might be useful to go discuss ways in which qnames can be implemented.

- Section 4:

Might rename this section to "Performance Implication" and, in addition to discussing the negative caching stuff, provide some examples of the increase in round trips necessary to deal with probing to find zone cuts.

Hope this helps.

Regards,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 4 Jan 2015 20:36:02 +0100

On Sat, Jan 03, 2015 at 11:17:13AM -0800,
 David Conrad <[email-masked]> wrote 

> Some comments on the qname-minimisation draft:

Many of them integrated in the live text at
<https://github.com/bortzmeyer/my-IETF-work/tree/master/draft-ietf-dnsop-qname-minimisation>
Expect a new release next week.

> While the pointer to the dns-privacy draft is helpful as a
> reference, I figure the introduction/background section should
> provide an introduction to the specific problem the draft is
> attempting to address and why it is a problem.

I tend to disagree. The whole point of the reference to
draft-ietf-dprive-problem-statement is to avoid repeating. That's why
it's a normative reference.

>  partially addresses the case of a wire sniffer, not just the case
>  of privacy invasion by the servers."
> 
> This probably needs a bit more explanation. If you're sniffing the
> wire, you'll see the final query for the full QNAME/QCLASS/QTYPE and
> all the intervening NS queries can simply be ignored, no? Or is the
> sniffer on a different wire?

Yes, the sniffer may be in many places. If it is between the user and
the recursive resolver, of course, it will see everything, qname m12n
or not. But it may be, for instance, between the recursive resolver
and the authoritative name servers of a TLD. That's a very important
point of DNS privacy, and a reason why the DNS privacy issue is not
just a subset of general IP privacy issues. See section 2.4 of
draft-ietf-dprive-problem-statement-00.

> "Sending the full qname to the authoritative name server is a
>  tradition, not a protocol requirment."
> 

In many cases, sending the full qname degrades performance so I would
not call it an optimization. (Apparently, there is no published
rationale for this choice.)

> I'm not sure it's worth raising this as "legal responsibility" in an
> engineering document sounds like a 'rathole of unusual size' to me.

I'm inclined in that direction, too. What is the advice of the working
group? Are there examples of RFCs with such "legal" mentions?

>  delegated to two name servers that reply properly to "A
>  www.ratp.fr" queries but send REFUSED to queries "NS www.ratp.fr".'
> 
> I suspect this particular brokenness will be fixed at some point in
> the future, thus I doubt this example will be useful.

Right for a RFC, which must be stable. I rewrote it (with a note about
www.ratp.fr, to be deleted before publication: in an Internet-Draft, I
think actual examples are good).

> It might be useful to go discuss ways in which qnames can be

New paragraph. Does it address (at least partially) your concern?

<t>As mentioned before, there are several ways to implement qname
minimisation. Two main strategies are the aggressive one and the lazy
one. In the aggressive one, the resolver only sends NS queries as long
as it does not know the zone cuts. This is the safest, from a privacy
point of view. The lazy way "piggybacks" on the traditional resolution
code. It sends traditional full qnames and learn the zone cuts from
the referrals received, then switching to NS queries. This leaks more
data but probably requires less changes in the existing resolver
codebase.</t>

---

From: David Conrad <[email-masked]>
Date: Sun, 4 Jan 2015 12:13:35 -0800

Stephane,

> it's a normative reference.

I wasn't suggesting removing the reference, rather I was suggesting the intro/background should discuss the subset of the more general DNS privacy problem that QNAME minimization is intended to solve/help with.

> draft-ietf-dprive-problem-statement-00.

Right, so perhaps something like:

"It can be noted that minimising the amount of data sent can reduce the exposure of the full query name to any wire sniffer that may be in the path between the resolver and any (except the last) authoritative server the resolver needs to iterate through." (or something like that)?

> not call it an optimization.

If there are cases in which sending the full QNAME degrades performance, it might be useful to document them in the draft (off the top of my head, I can't imagine non-broken cases where that would be true, but I haven't thought about it too long).

The reason I'd call it an optimization is that in the case where a server is authoritative for multiple layers of hierarchy, sending the full QNAME allows that server to bypass the referrals for all intermediate layers of hierarchy and simply respond to the depth it knows.  If QNAME minimization is applied, that shortcut isn't possible.

> data but probably requires less changes in the existing resolver

Sure.

Thanks,
-drc

---

From: Rubens Kuhl <[email-masked]>
Date: Sun, 4 Jan 2015 20:11:50 -0200

> data but probably requires less changes in the existing resolver

One easy strategy could be assuming a zone cut between the root and TLDs, which is a known one, and not sending 4LD and beyond to TLD servers. This would accommodate both 2LD and 3LD delegation TLDs, without much analysis.

It would work like this:

www.janet.ac.uk <http://www.janet.ac.uk/>

Question to root: uk
Answer from root: .uk delegated servers
Question to .uk delegated servers: janet.ac.uk <http://janet.ac.uk/>
Answer from .uk delegated servers: ac.uk <http://ac.uk/>
Question to .ac.uk <http://ac.uk/> delegated servers: www.janet.ac.uk <http://www.janet.ac.uk/>
Answer from .ac.uk <http://ac.uk/> delegated servers: janet.ac.uk <http://janet.ac.uk/>
Question to janet.ac.uk <http://janet.ac.uk/> delegated servers: www.janet.ac.uk <http://www.janet.ac.uk/>
Answer from janet.ac.uk <http://janet.ac.uk/> delegated servers: final end node

www.ja <http://www.janet.ac.uk/>.net

Question to root: net
Answer from root: .net delegated servers
Question to .net delegated servers: www.ja.net <http://www.ja.net/>
Answer from .net delegated servers: ja.net <http://ja.net/>
Question to .ja. <http://ac.uk/>net delegated servers: www.ja <http://www.janet.ac.uk/>.net
Answer from ja.net <http://janet.ac.uk/> delegated servers: final end node

My guess is this would even accommodate cases such as dotless domains (like dk) and in-addr.arpa. 

Rubens

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 Jan 2015 08:33:31 -0800

> The reason I'd call it an optimization is that in the case where a server is authoritative for multiple layers of hierarchy, sending the full QNAME allows that server to bypass the referrals for al…

+1 to David's comment. I have always heard that sending the full name was an optimization for authoritative severs that spanned more than one level, and that such servers were common in "the early days". It is worth pointing this out in this draft, and to also say that that situation may be much less common now than it was in antiquity.

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Mon, 5 Jan 2015 11:55:31 -0500

Does anyone have actual data on how common it is, so we can make an
informed decision?

I would expect "www.something..." to be in the same zone as "something..."
in most cases, so I think it is actually very common to have more than one
level on the same DNS.

-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
[email-masked]
734-647-6524 desk

On Mon, Jan 5, 2015 at 11:33 AM, Paul Hoffman <[email-masked]> wrote:

> > If there are cases in which sending the full QNAME degrades performance,
> it might be useful to document them in the draft (off the top of my head, I
> can't imagine non-broken cases where that would be true, but I haven't
> thought about it too long).
> >
> > The reason I'd call it an optimization is that in the case where a
> server is authoritative for multiple layers of hierarchy, sending the full
> QNAME allows that server to bypass the referrals for all intermediate
> layers of hierarchy and simply respond to the depth it knows.  If QNAME
> minimization is applied, that shortcut isn't possible.
>
> +1 to David's comment. I have always heard that sending the full name was
> an optimization for authoritative severs that spanned more than one level,
> and that such servers were common in "the early days". It is worth pointing
> this out in this draft, and to also say that that situation may be much
> less common now than it was in antiquity.
>
> --Paul Hoffman
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Jan 2015 17:01:01 +0000

Paul Hoffman <[email-masked]> wrote:
>
> +1 to David's comment. I have always heard that sending the full name
> was an optimization for authoritative severs that spanned more than one
> level, and that such servers were common in "the early days".

It's also an optimization for dual-purpose authoritative + recursive
servers, in the days before they were considered a bad idea.

> It is worth pointing this out in this draft, and to also say that that
> situation may be much less common now than it was in antiquity.

I don't think you have to go that far back to find (e.g.) root servers
also authoritative for big GTLDs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight, Portland, Plymouth: South 5 or 6, veering southwest 6 to gale 8,
becoming cyclonic 4 or 5 later. Moderate or rough, occasionally very rough in
Portland and Plymouth. Rain. Good, occasionally poor.

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 5 Jan 2015 15:04:22 -0200

> Em 05/01/2015, à(s) 14:33:000, Paul Hoffman <[email-masked]> escreveu:
> 

I can point to 25 million domain names that currently benefit from such optimization in .br and .uk alone, probably more if you add other TLDs that register on the 3rd level. 

Rubens

---

From: Paul Vixie <[email-masked]>
Date: Sun, 04 Jan 2015 14:15:17 -0800

> Rubens Kuhl <mailto:[email-masked]>
> Sunday, January 04, 2015 2:11 PM
>
>
> ...
>

i prefer the more aggressive approach, because caching.

also noting, dotless domains exist. dotless hostnames (for mail, web,
etc) by def'n do not.

-- 
Paul Vixie

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 6 Jan 2015 09:36:39 +0100

On 01/05/2015 05:55 PM, Bob Harold wrote:
> I would expect "www.something..." to be in the same zone as
> "something..." in most cases, so I think it is actually very common to
> have more than one level on the same DNS.
> 

Would you? I'd expect 'www' there to be in 'something', and 'something'
to be in a TLD (assuming context of a 3-label domain, not counting root)

So for www to be in the same as something would mean it'd be in the TLD...

Not saying that it might still not be common, but 'www' is not a good
example, IMHO.

The other question is not whether it is common, but whether the
optimization is actually as benificial as one might think.

Jelte

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Jan 2015 10:16:56 +0000

> So for www to be in the same as something would mean it'd be in the TLD...

I think Bob means that www.something is not a zone cut. If it is a zone
cut then the authoritative RRs for www.something can be on different name
servers to something, e.g.

.		NS	a.root-servers.net
at.		NS	d.ns.at.
dotat.at.	NS	black.dotat.at.
www.dotat.at.	NS	lb.dotat.at
www.dotat.at.	SOA	lb.dotat.at. (...)
www.dotat.at.	AAAA	2001:...

So if you use an NS query to probe zone cuts, a straightforward
implementation of query minimization requires four queries for a three
label name (if the resolver has a primed but empty cache).

If you use A queries you save a lookup in the common case where there
isn't a zone cut at the leaf.

Tony.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 06 Jan 2015 07:19:31 -0800

> Tony Finch <mailto:[email-masked]>
> Tuesday, January 06, 2015 2:16 AM
>
> ...
>

that's true in an empty cache. but that emptiness will be short lived.
at stead state, query-minimization has no more queries than longest-match.
> isn't a zone cut at the leaf.

since the intermediate queries (all but for the qname itself) are
intended to solicit referrals, the qtype on those doesn't matter. they
should probably use the original qtype, because of middleboxes who would
see qtype=NS as unnatural.

-- 
Paul Vixie

---

From: Shumon Huque <[email-masked]>
Date: Tue, 6 Jan 2015 10:49:04 -0500

On Mon, Dec 29, 2014 at 5:22 PM, Brian Dickson <
[email-masked]> wrote:

>
> - Another thing to possibly call out is the behavior of some name servers
> when the QNAME is an Empty Non-Terminal, e.g. a non-zone-cut with a child,
> but no RRs at the owner name. I seem to recall something along those lines
> but don't recall details, e.g. which software, version, etc., has this
> issue.
>

Here's one example I'm familiar with (the website of my previous employer,
U of Penn, which uses the Akamai CDN):

$ ./test.py www.upenn.edu

>> Query: edu. A IN at zone .
>>        [Got Referral to zone: edu.]
>> Query: upenn.edu. A IN at zone edu.
>>        [Got Referral to zone: upenn.edu.]
>> Query: www.upenn.edu. A IN at zone upenn.edu.
www.upenn.edu. 300 IN CNAME www.upenn.edu-dscg.edgesuite.net.
>> Query: net. A IN at zone .
>>        [Got Referral to zone: net.]
>> Query: edgesuite.net. A IN at zone net.
>>        [Got Referral to zone: edgesuite.net.]
>> Query: edu-dscg.edgesuite.net. A IN at zone edgesuite.net.
ERROR: NXDOMAIN: edu-dscg.edgesuite.net. not found

www.upenn.edu is an alias for www.upenn.edu-dscg.edgesuite.net.  The Akamai
DNS server for zone edgesuite.net incorrectly responds with NXDOMAIN
(rather than NOERROR, empty answer) for the intermediate qname "
edu-dscg.edgesuite.net." and thus halts the resolution there. It also
provides NXDOMAIN at the next query name "upenn.edu-dscg.edgesuite.net.".

This seems to be the case with other Akamaized sites too, e.g. www.apple.com,
which goes through akadns.net. I'm assuming this will get fixed as qname
minimization gets deployed, but I'm wondering if anyone from Akamai can
comment on this behavior.

Shumon.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 6 Jan 2015 12:31:47 -0500

> I can point to 25 million domain names that currently benefit from such optimization in .br and .uk alone, probably more if you add other TLDs that register on the 3rd level.

I'm sorry, but I think that that gives somewhat of a false impression
- while there may be many millions of names of the form foo.bar.co.uk,
if only takes one query to get that into the cache for 48h[0].

So, what you say is technically true (which is, of course, the best
kind of true), it overpaints the effect.

W

[0]: or until the recursive gets bored, or runs out of cache, or
restarted, or...

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 6 Jan 2015 13:01:33 -0500

On Mon, Dec 29, 2014 at 5:22 PM, Brian Dickson
<[email-masked]> wrote:
> I'm a big fan of this.
>
> These comments are meant to be constructive, and with the goal of improving
> the draft quality and/or quality of the underlying protocol.
>
> And, of course, I speak only for myself.
>
> In no particular order:
>
> - In section 3, it might be good to add a paragraph about the implications
> for HAMMER. Specifically, in addition to pre-fetching records that would
> otherwise expire, it is probably worth probing for the introduction of zone
> cuts where none previously existed (i.e. confirm their continued absence, or
> discover them.)
>
> - Another comment for Section 4 (other advantages), it may be worth
> mentioning improved look-up performance for TLD operators, which offsets the
> loss of query data. A 2-label QNAME query is optimal for finding the
> delegation owner name in a delegation-only TLD.
>
> Hope this is helpful.

... and below are some nits. I'd originally sent them off-list
(because they were just minor) but it was requested that I send them
onlist, so...

------

Below are some nits for draft-ietf-dnsop-qname-minimisation.

They are in Original, Proposed, Comment format.
Feel free to accept, reject or ignore them :-)

They were minor enough that I didn't try edit them in GitHub.

W

1.  Introduction and background

   The problem statement is exposed in
   [I-D.bortzmeyer-dnsop-dns-privacy].  The terminology ("qname",
   "resolver", etc) is also defined in this companion document.  This
   specific solution is not intended to completely solve the problem,
   far from it.  It is better to see it as one tool among a toolbox.
[O] specific solution is not intended to completely solve the problem,
far from it.  It is better to see it as one tool among a toolbox.
[P] specific solution is not intended to fully solve the problem;
instead, it should be viewed as one tool amongst many.

   It follows the principle explained in section 6.1 of [RFC6973]: the
   less data you send out, the less privacy problems you'll get.

2.  Qname minimisation

   The idea is to minimise the amount of data sent from the DNS
   resolver.  When a resolver receives the query "What is the AAAA
   record for www.example.com?", it sends to the root (assuming a cold
   resolver, whose cache is empty) the very same question.  Sending
   "What are the NS records for .com?"  would be sufficient (since it
   will be the answer from the root anyway).  To do so would be
   compatible with the current DNS system and therefore could be easily
   deployable, since it is an unilateral change to the resolvers.

   If "minimisation" is too long, you can write it "m12n".

Bortzmeyer               Expires April 25, 2015                 [Page 2]
Internet-Draft             Qname minimisation               October 2014

   To do such minimisation, the resolver needs to know the zone cut
   [RFC2181].  There is not a zone cut at every label boundary.  If we
[O] There is not a zone cut at every label boundary.
[P] Zone cuts do not necessarily exist at every label boundary.
[R] Readability
   take the name www.foo.bar.example, it is possible that there is a
   zone cut between "foo" and "bar" but not between "bar" and "example".
   So, assuming the resolver already knows the name servers of .example,
   when it receives the query "What is the AAAA record of
   www.foo.bar.example", it does not always know if the request should
   be sent to the name servers of bar.example or to those of example.
   [RFC2181] suggests a method to find the zone cut (section 6), so
   resolvers may try it.

   Note that DNSSEC-validating resolvers already have access to this
   information, since they have to find the zone cut (the DNSKEY record
   set is just below, the DS record set just above).

   It can be noted that minimising the amount of data sent also
   partially addresses the case of a wire sniffer, not just the case of
   privacy invasion by the servers.

[O]  It can be noted that minimising the amount of data sent also
   partially addresses the case of a wire sniffer, not just the case of
   privacy invasion by the servers.
[P] Minimising the amount of data sent also, in part, addresses the
case of a wire sniffer as well the case of privacy invasion by the
servers.
[R] Readability.

   One should note that the behaviour suggested here (minimising the
   amount of data sent in qnames) is NOT forbidden by the [RFC1034]
   (section 5.3.3) or [RFC1035] (section 7.2).  Sending the full qname
   to the authoritative name server is a tradition, not a protocol
   requirment.

3.  Operational considerations

   The administrators of the forwarders, and of the authoritative name
   servers, will get less data, which will reduce the utility of the
   statistics they can produce (such as the percentage of the various
   qtypes).  On the other hand, it will decrease their legal
   responsability, in many cases.

[O] responsability
[P] responsibility
[R] spelling
   Some broken name servers do not react properly to qtype=NS requests.
   As an example of today, look at www.ratp.fr (not ratp.fr), which is
   delegated to two name servers that reply properly to "A www.ratp.fr"
   queries but send REFUSED to queries "NS www.ratp.fr".  This behaviour
   is a gross protocol violation and there is no need to stop improving
   the DNS because of such brokenness.  However, qname minimisation may
[O] This behaviour is a gross protocol violation and there is no need
to stop improving
   the DNS because of such brokenness.
[P] This behaviour  is a gross protocol violation, and there is no
need to stop improving
   the DNS because of such brokenness.
[R] Added comma before "and" to prevent run on sentence.
   still work with such domains since they are only leaf domains (no
   need to send them NS requests).  Anyway, such setup breaks many
   things (besides qname minimisation), it breaks negative answers as
   the servers don't return the correct SOA.  It also breaks anything
   that depends on NS and SOA records existing at the top of the zone.
[O] Anyway, such setup breaks many
   things (besides qname minimisation), it breaks negative answers as
   the servers don't return the correct SOA.  It also breaks anything
   that depends on NS and SOA records existing at the top of the zone.
[P]Such setup breaks more than just qname minimisation. It breaks
negative answers, since the servers don't return the correct SOA, and
it also breaks anything dependent upon NS and SOA records existing at
the top of the zone.
[R] Grammar and readability

   Another way to deal with such broken name servers would be to try
   with A requests (A being choosen because it is the most common and
[O] choosen
[P] chosen
[R] spelling

   hence the least revealing qtype).  Instead of querying name servers

Bortzmeyer               Expires April 25, 2015                 [Page 3]
Internet-Draft             Qname minimisation               October 2014

   with a query "NS example.com", we could use "A _.example.com" and see
   if we get a referral.

   Other strange and illegal practice may pose a problem: for instance,
[O] practice
[P] practices
   there is a common DNS anti-pattern used by low-end web hosters that
   also do DNS hosting that exploits the fact that the DNS protocol
   (pre-DNSSEC) allows certain serious misconfigurations, such as parent
   and child zones disagreeing on the location of a zone cut.
   Basically, they have a single zone with wildcards like:

  [ SNIP ]

4.  Other advantages

   The main goal of qname minimisation is to improve privacy, by sending
[O] privacy, by sending
[P] privacy by sending
[O] readability; no comma needed
   less data.  However, it may have other advantages.  For instance, if
   a root name server receives a query from some resolver for A.CORP
   followed by B.CORP followed by C.CORP, the result will be three
   NXDOMAINs, since .CORP does not exist in the root zone.  Under query

> Brian Dickson

---

From: Shumon Huque <[email-masked]>
Date: Tue, 6 Jan 2015 13:14:30 -0500

from draft-ietf-dnsop-qname-minimisation:

2.  Qname minimisation
>    If "minimisation" is too long, you can write it "m12n".

I generally dislike these kinds of contractions, but I assume you meant
"m10n". There are 10 letters between m and n. (contrast i18n and l10n).

Shumon Huque

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 6 Jan 2015 14:08:17 -0500

> On Jan 5, 2015, at 12:04 PM, Rubens Kuhl <[email-masked]> wrote:
> 
>> 

Of those the ones using DNSSEC will suffer due to the difficulty of getting DNSKEY and DS records for the “skipped” delegations. 

Olafur

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 6 Jan 2015 17:42:24 -0200

> Of those the ones using DNSSEC will suffer due to the difficulty of getting DNSKEY and DS records for the “skipped” delegations. 

You can corroborate or negate the mentioned difficulty using foo.eng.br <http://foo.eng.br/> as an example, since it's signed at all levels. 

Rubens

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 08 Jan 2015 10:39:18 +0000

At Sun, 04 Jan 2015 14:15:17 -0800,
> also noting, dotless domains exist. dotless hostnames (for mail, web,

  I don't understand.
  
  Such a definition seems to be cheerfully violated in the case of
  http://dk/

  Best regards,
  Niall O'Reilly

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Jan 2015 23:23:36 +1100

>   Such a definition seems to be cheerfully violated in the case of

It is after 15 Jul 85.  "dk" is no longer a hostname.  There is
just a node in the DNS tree with a A record attached which has no
defined meaning.

Mark
 
RFC 921 (1984)

   Names

      The names are being changed from simple names, or globally unique
      strings, to structured names, where each component name is unique
      only with respect to the superior component name.

   15 Jul 85  Implementation of the Domain Naming System Completed

      The goal is to complete the switch over to the domain style names
      and the use of the servers by this date.  All programs that
      translate host name to Internet addresses should now use
      procedures based on the use of the domain style names system of
      resolvers and servers and the distributed data base.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 08 Jan 2015 13:02:13 +0000

At Thu, 08 Jan 2015 23:23:36 +1100,
> just a node in the DNS tree with a A record attached which has no

  Thanks, Mark.

  RFC 1034 (November 1987, but I'm sure you know that) uses the
  term "host name" quite freely, notably at 5.2.1.1, where the
  use of an A record for "Host name to host address translation"
  is described.

  The semantic subtlety of placing or omitting a space between
  "host" and "name" is too delicate for me.

  Best regards,
  Niall

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 Jan 2015 06:06:10 -0800

> Niall O'Reilly <mailto:[email-masked]>
> Thursday, January 08, 2015 2:39 AM

yup. and true to my words, that url will work in some places, and not in
others. as a local-seeming name it will often be tried with search lists
first, which might find a dk.vix.com or whatever locally, and it will
often not be tried as a dns name, since the definition of a "host" in
rfc 952 and elsewhere is label . label [. label] ...".

i am never cheerful about things that work differently depending on what
OS, what libraries, what browser, what ISP, or what search lists and/or
what dns content is "more local" to me. you can of course be cheerful
about those things if you want.

-- 
Paul Vixie

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 08 Jan 2015 16:08:05 +0000

Thanks, Paul.

At Thu, 08 Jan 2015 06:06:10 -0800,
Paul Vixie wrote:
> 
> yup. and true to my words, that url will work in some places, and not
> in others. as a local-seeming name it will often be tried with search
> lists first, which might find a dk.vix.com or whatever locally, and it
> will often not be tried as a dns name,

  Indeed, but that's not what I'm getting at.

> since the definition of a "host" in rfc 952
> and elsewhere is label . label [. label] ...".

  The relevant specification in 952 (at
  http://tools.ietf.org/html/rfc952) seems to be

      <hname> ::= <name>*["."<name>]

  which, IIUC, corresponds to "label [. label] ...".  After some
  moments' doubt, I noticed that other nearby use of the "*" notation
  is consistent only with an interpretation of "zero or more instances
  of the following construct" as, for example, in

      <protocol list> ::= <protocol spec> *["," <protocol spec>]

  As for "and elsewhere", I've followed the "Obsoleted/Updated By"
  reference tree from 952 (1123, 1349, 2181, 5321, 5966, 2474, 2535,
  and onwards), and can't find where a restriction to a minimum of two
  labels for a hostname is introduced.

  I'll be glad to learn that I've missed something.

> i am never cheerful about things that work differently depending on
> what OS, what libraries, what browser, what ISP, or what search lists
> and/or what dns content is "more local" to me.

  Me neither. 8-)

  Niall O'Reilly

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Jan 2015 22:12:23 +0100

On Mon, Jan 05, 2015 at 08:33:31AM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 27 lines which said:

> I have always heard that sending the full name was an optimization
> for authoritative severs 

I will check with the Highest Authorities. In the mean time, I changed
the draft to add there were reasons for this choice (sending the full
qname)
<https://github.com/bortzmeyer/my-IETF-work/commit/c4c6a71da6841af8341189213fa43e5c7539a748#diff-fe24b3ef60c80e496555988e82081362>

Remember also that qname minimisation may be an optimisation (section
4 of draft-ietf-dnsop-qname-minimisation-00).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Jan 2015 22:14:28 +0100

On Tue, Jan 06, 2015 at 07:19:31AM -0800,
 Paul Vixie <[email-masked]> wrote 

> at stead state, query-minimization has no more queries than

And this point is already mentioned in the draft. Section 3 of -00:

   Qname minimisation can decrease performance in some cases, for
   instance for a deep domain name (like
   www.host.group.department.example.com where
   host.group.department.example.com is hosted on example.com's name
   servers).  For such a name, a cold resolver will, depending how qname
   minimisation is implemented, send more queries.  Once warm, there
   will be no difference with a traditional resolver.  A possible
   solution is to always use the traditional algorithm when the cache is
   cold and then to move to qname minimisation.  This will decrease the
   privacy a bit but will guarantee no degradation of performance.

> the qtype on those doesn't matter. they should probably use the
> original qtype,

There is a (very) small gain in privacy by using a "neutral" qtype
such as A or NS, especially for rare qtypes likes LOC or SRV.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Jan 2015 22:18:11 +0100

On Tue, Jan 06, 2015 at 10:49:04AM -0500,
 Shumon Huque <[email-masked]> wrote 

> $ ./test.py www.upenn.edu

Version -01 of the draft (expected this week-end) will include one or
two paragraphs about the ENTs and the broken name servers that return
NXDOMAIN for an ENT.

> comment on this behavior.

I'm all ears, too.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Jan 2015 14:35:22 +1100

>   use of an A record for "Host name to host address translation"

And RFC 1034 also says follow the naming rules for the things you are
putting in the DNS which people seem to want to ignore.
 
_foo.example is not a host name (or hostname) regardless of whether
it has a A record or not.  Similarly dk is not a hostname.  A "A"
record does not make a hostname though it is required for a hostname.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 09 Jan 2015 09:56:42 +0000

Thanks again, Mark.

At Fri, 09 Jan 2015 14:35:22 +1100,
Mark Andrews wrote:
> putting in the DNS

  So it does.

> which people seem to want to ignore.

  All too often, and stubbornly.

> it has a A record or not.

  Indeed so; it doesn't satisfy RFC952.

> Similarly

  Eh?

> dk is not a hostname.

  Without citing a normative reference, you're leaving me to
  admire the Emperor's new clothes!

  I see that, according to RFC1178, "dk" is an undesirable choice of
  hostname.  Careful, but admittedly not exhaustive, searching in the
  Scriptures hasn't led me to discover any reason to accept that it's
  "not a hostname".

  Best regards,
  Niall O'Reilly