Re: [DNSOP] Clarifying referrals (#35)

[Johannes Naab]

On Mon, Jan 15, 2018 at 04:39:20PM -0500, Andrew Sullivan wrote:
>   A response that has only a referral contains an empty answer
>   section.  It contains the NS RRset for the referred-to zone in the
>   authority section.  It may contain RRs that provide addresses in
>   the additional section.  The AA bit is clear.

Hi all,

the behaviour with respect to the (clear) AA bit is not completely
observed in the wild:

ba.anycastdns.cz (185.38.108.108, 185.28.194.194) is authoritative for
..ba given by the root zone, they return the following referrals:

% dig +norec @185.28.194.194 google.ba.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48224
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;google.ba. IN  A

;; AUTHORITY SECTION:
google.ba.  86400   IN  NS  ns1.google.com.
google.ba.  86400   IN  NS  ns2.google.com.

;; Query time: 70 msec
;; SERVER: 185.28.194.194#53(185.28.194.194)
;; WHEN: Sat Mar 24 00:01:18 CET 2018
;; MSG SIZE  rcvd: 84

I.e. a referral, but with AA-bit.

Both Unbound and BIND appear to treat this as delegation:
https://github.com/NLnetLabs/unbound/blob/release-1.7.0/iterator/iter_resptype.c#L270
(since at least 2007, including the comment about the AA-bit)

https://gitlab.isc.org/isc-projects/bind9/blob/b2307b25465c16d37ff6de22438a2d214287417c/lib/dns/resolver.c#L603
 and L7314
(Not 100% sure)

RFC 2308 2.2 does not specifically care about the AA-bit:

>   It is possible to distinguish between a NODATA and a referral
>   response by the presence of a SOA record in the authority section or
>   the absence of NS records in the authority section.


My current take away:
The clean interpretation would be a NODATA response.
But based on practical evidence and implementations, such responses are
to be treated as referrals.
anycastdns.cz should change the name servers behaviour.

Best regards,
Johannes

-- 
Johannes Naab

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

Re: [DNSOP] Clarifying referrals (#35)

[Wessels, Duane]

> On Jan 15, 2018, at 4:39 PM, Andrew Sullivan  wrote:
> 
> Some people regard upward referrals as a sign
>  of a misconfiguration or error.

Perhaps worth also noting that some people consider upward referrals harmful 
because they enable amplification attacks?

Of course there are more effective amplification-type responses, but 
nonetheless the size of the referral is larger than the size of the query and 
the size of a REFUSED.

DW

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

Re: [DNSOP] Clarifying referrals (#35)

[Evan Hunt]

On Tue, Jan 16, 2018 at 03:33:11PM -0500, Bob Harold wrote:
> That sounds clear and complete to me!

+1

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

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

Re: [DNSOP] Clarifying referrals (#35)

[Bob Harold]

On Mon, Jan 15, 2018 at 4:39 PM, Andrew Sullivan 
wrote:

> Hi all,
>
> Some of you will perhaps recall that previous efforts at text on
> referrals were unsuccessful.  I've had another go.  I _think_ it
> addresses all the comments so far, without actually causing the
> terminology draft to drift into prescribing protocol.  It is
> unfortunately quite a bit longer, but that seems to be the cost of
> making all the points from the discussion.  Thoughts are solicited:
>
>Referral:  A type of response in which a server, signalling that it
>   is not (completely) authoritative for an answer, provides the
>   querying resolver with an alternative place to send its query.
>   Referrals can be combined with partial answers.
>
>   A referral arises when a server is not performing recursive
>   service while answering a query.  It appears in step 3(b) of the
>   algorithm in [RFC1034], Section 4.3.2.
>
>   There are two types of referral response.  The first is a downward
>   referral (sometimes described as "delegation response"), where the
>   server is authoritative for some portion of the QNAME.  The
>   authority section RRset's RDATA contains the name servers
>   specified at the referred-to zone cut.  In normal DNS operation,
>   this kind of response is required in order to find names beneath a
>   delegation.  The bare use of "referral" means this kind of
>   referral, and many people believe that this is the only legitimate
>   kind of referral in the DNS.
>
>   The second is an upward referral (sometimes described as "root
>   referral"), where the server is not authoritative for any portion
>   of the QNAME.  When this happens, the referred-to zone in the
>   authority section is usually the root zone (.).  In normal DNS
>   operation, this kind of response is not required for resolution or
>   for correctly answering any query.  There is no requirement that
>   servers send them.  Some people regard upward referrals as a sign
>   of a misconfiguration or error.
>
>   A response that has only a referral contains an empty answer
>   section.  It contains the NS RRset for the referred-to zone in the
>   authority section.  It may contain RRs that provide addresses in
>   the additional section.  The AA bit is clear.
>
>   In the case where the query matches an alias, and the server is
>   not authoritative for the target of the alias but it is
>   authoritative for some name above the target of the alias, the
>   resolution algorithm will produce a response that contains both
>   the authoritative answer for the alias, and also a referral.  Such
>   a partial answer and referral response has data in the answer
>   section.  It has the NS RRset for the referred-to zone in the
>   authority section.  It may contain RRs that provide addresses in
>   the additional section.  The AA bit is set, because the first name
>   in the answer section matches the QNAME and the server is
>   authoritative for that answer (see [RFC1035], section 4.1.1).
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>


That sounds clear and complete to me!

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi all,

Some of you will perhaps recall that previous efforts at text on
referrals were unsuccessful.  I've had another go.  I _think_ it
addresses all the comments so far, without actually causing the
terminology draft to drift into prescribing protocol.  It is
unfortunately quite a bit longer, but that seems to be the cost of
making all the points from the discussion.  Thoughts are solicited:

   Referral:  A type of response in which a server, signalling that it
  is not (completely) authoritative for an answer, provides the
  querying resolver with an alternative place to send its query.
  Referrals can be combined with partial answers.

  A referral arises when a server is not performing recursive
  service while answering a query.  It appears in step 3(b) of the
  algorithm in [RFC1034], Section 4.3.2.

  There are two types of referral response.  The first is a downward
  referral (sometimes described as "delegation response"), where the
  server is authoritative for some portion of the QNAME.  The
  authority section RRset's RDATA contains the name servers
  specified at the referred-to zone cut.  In normal DNS operation,
  this kind of response is required in order to find names beneath a
  delegation.  The bare use of "referral" means this kind of
  referral, and many people believe that this is the only legitimate
  kind of referral in the DNS.

  The second is an upward referral (sometimes described as "root
  referral"), where the server is not authoritative for any portion
  of the QNAME.  When this happens, the referred-to zone in the
  authority section is usually the root zone (.).  In normal DNS
  operation, this kind of response is not required for resolution or
  for correctly answering any query.  There is no requirement that
  servers send them.  Some people regard upward referrals as a sign
  of a misconfiguration or error.

  A response that has only a referral contains an empty answer
  section.  It contains the NS RRset for the referred-to zone in the
  authority section.  It may contain RRs that provide addresses in
  the additional section.  The AA bit is clear.

  In the case where the query matches an alias, and the server is
  not authoritative for the target of the alias but it is
  authoritative for some name above the target of the alias, the
  resolution algorithm will produce a response that contains both
  the authoritative answer for the alias, and also a referral.  Such
  a partial answer and referral response has data in the answer
  section.  It has the NS RRset for the referred-to zone in the
  authority section.  It may contain RRs that provide addresses in
  the additional section.  The AA bit is set, because the first name
  in the answer section matches the QNAME and the server is
  authoritative for that answer (see [RFC1035], section 4.1.1).

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Florian Weimer]

On 11/28/2017 08:50 PM, Andrew Sullivan wrote:

That leaves the task of the referrals definition.  I have some new
text below:

---%<---cut here---

Referral: A type of response in which a server, signalling that it is
not authoritative for an answer, provides the querying resolver with
an alternative place to send its query.  A referral contains an empty
answer section.  It contains the NS RRset for the referred-to zone in
the authority section.  It may contain RRs that provide addresses in
the additional section.  The AA bit is clear.


Is the goal to describe behavior of current (and perhaps past) 
implementations, or what the behavior should be under ideal circumstances?


Thanks,
Florian

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Wed, Nov 29, 2017 at 11:34:12PM +, Tony Finch wrote:
> 
> Normal (downward) referrals come from authoritative data, and indicate the 
> server is saying to the client, you need to ask here next; on the other hand 
> these special kinds of referrals come from the cache. An implicit referral 
> comes in a full-fat RD=1 RA=1 answer, and indicates the server is telling the 
> client where the answer came from; if RD=0 or RA=0 you can get an upward 
> referral, which indicates the server is telling the client where the server 
> would ask next in order to fill its cache.
>

I think that's correct.  But what is not plain to me in my reading,
insistent noises on the list notwithstanding, is whether the second ¶
in step 3.b of the algorithm in section 4.3.2 of RFC 1034 is still
part of what "a referral" means.  The ordinary English meaning, as far
as I can tell, of that 3.b subsection is that everything one does as
part of step 3.b is a referral response.

The problem is that "Go to step 4" is part of that last ¶, not a new
¶, and so what I think is obscure in the algorithm text is whether the
stuff you're copying into the response in step 4.

I tend to agree that the other parts of STD 13 argues in favour of at
least "upward referrals are a degenerate case" and maybe even "upward
referrals are _not_ referrals in the bare word sense."

But while I find that reading persuasive, there are two important
facts to consider: for a long time, that was not actually the reading
people adhered to, and there does not seem to have been a lot of
complaining about it (indeed, even djb's remarks about DNS barely
suggest this is a fault of the server, and AFAICT he thought that BIND
was responsible for bubonic plague when he wrote those notes).
Second, we should not expect, in fairness, an earnest reader to do the
same synoptic reading that others have done, or to reach the same
conclusion.  It's at least as likely that such a reader will conclude
that RFCs 1034 and 1035 are written with a certain lack of
terminological rigour -- which is perhaps borne out by the effort we
apparently need to make to clarify a term as fundamental as
"referral".

I don't think anyone in this discussion disagrees about how things
_ought_ to operate.  But in the terminology document, I think we have
tried to preserve the meanings that persist on the Internet.  I find
it very hard to convince myself either that upward referrals are dead,
or even that lots of people don't use "referral response" to mean
"referral to the root".  I encounter both of these ways of speaking
with some regularity.  Maybe my sample is really skewed; but I think
it is at least as plausible that people who are clued into the DNS
think that upward referrals are bad and that therefore all referrals
must be down.

> implicit referrals and upward referrals are supposed to be cache-filling 
> gossip (in the distributed systems sense of gossip protocols).
> 

I like this observation.  Thanks.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Tony Finch]

> On 29 Nov 2017, at 23:13, Tony Finch  wrote:
> ... you get an implicit referral from the cache (which can be upwards).

I just realised this might be a useful point.

Normal (downward) referrals come from authoritative data, and indicate the 
server is saying to the client, you need to ask here next; on the other hand 
these special kinds of referrals come from the cache. An implicit referral 
comes in a full-fat RD=1 RA=1 answer, and indicates the server is telling the 
client where the answer came from; if RD=0 or RA=0 you can get an upward 
referral, which indicates the server is telling the client where the server 
would ask next in order to fill its cache.

Normal (downward) referrals are instructions to iterative resolvers; implicit 
referrals and upward referrals are supposed to be cache-filling gossip (in the 
distributed systems sense of gossip protocols).

Tony.
-- 
f.anthony.n.finch    http://dotat.at
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Tony Finch]

> On 29 Nov 2017, at 21:18, Dick Franks  wrote:
>> On 29 November 2017 at 12:17, Andrew Sullivan  
>> wrote:
>> 
>> Right, and the authoritative server can't proceed, but the referral is
>> necessary.  Good, this is helpful, thanks.  This also means, of
>> course, that in such a response the answer section isn't empty.  Is
>> this why you call it a "partial referral"?
> 
> And said referral could be to an arbitrary node in the DNS tree,  i.e. 
> possibly "upward"?
> 
> Or am I missing something?

In this case we’re dealing with an authoritative answer containing a CNAME 
pointing out of the server’s authoritative data.

If the server is authoritative only, then there are three cases: (1) the CNAME 
points to a child zone, so the authority section contains a referral - this is 
the partial answer plus referral case that Mark described; (2) the CNAME points 
to a different non-child zone and the server provides full answers, in which 
case the authority section contains the apex records of the zone containing the 
CNAME owner; or (3) same as (2) but the server sends minimal answers with an 
empty authority section.

If it is a 1034 hybrid rec+auth server, the 4.3.2 algorithm step 4 requires the 
same referral in case (1) because there is a “delegation from authoritative 
data”; in case (2) you get an implicit referral from the cache (which can be 
upwards).

Tony.
-- 
f.anthony.n.finch    http://dotat.at___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Wed, Nov 29, 2017 at 09:18:39PM +, Dick Franks wrote:
> 
> And said referral could be to an arbitrary node in the DNS tree,  i.e.
> possibly "upward"?
> 
> Or am I missing something?

That depends on whether you believe the later part of the algorithm in
RFC 1034 (where it says to do things from the cache) is part of the
"referral" part, particularly in a mixed-mode server where it has
received a query with RD=0.  The list appears to have strong feelings
about that.  It's why Joe and I wrote draft-sullivan-dnsop-refer-down.

As I've said many times, I don't believe that settling that question
is appropriate for the terminology document.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Dick Franks]

On 29 November 2017 at 12:17, Andrew Sullivan 
wrote:

> On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote:
> > When the CNAME refers to a name that is out of zone and the target zone
> is below
> > a zone that the server serves you will have CNAME (DNAME) + referral.
> >
> > 4.3.2 loops.
>
> This part I got.
>
> >   pass 1 -> 3a  (adds CNAME, AA is set as it matches the question
> section, QNAME is updated).
>
> This is the CNAME response, yes, ok.
>
> >   pass 2 -> 3b  (we have a partial match with a bottom of zone cut
> which adds the referral).
> >
>
> Right, and the authoritative server can't proceed, but the referral is
> necessary.  Good, this is helpful, thanks.  This also means, of
> course, that in such a response the answer section isn't empty.  Is
> this why you call it a "partial referral"?
>

And said referral could be to an arbitrary node in the DNS tree,  i.e.
possibly "upward"?

Or am I missing something?




>
> 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] Clarifying referrals (#35)

[Evan Hunt]

On Wed, Nov 29, 2017 at 07:25:53AM -0500, Andrew Sullivan wrote:
> How about, "This kind of response is not required for resolution or
> for correctly answering any query, and in practice some authoritative
> server operators will not return referral responses beyond those
> required for delegation"?

Up to the comma looks fine. The part after the comma strikes me
as over-wordy, and I suggest "and there is no requirement that
authoritative servers send them".

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

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

Re: [DNSOP] Clarifying referrals (#35)

[Tony Finch]

Andrew Sullivan  wrote:

> But I shall not include a change to the definition of referrals such
> that upward referrals are defined away.  They exist, today, all over the
> Internet, and it would be extremely foolish lexicography to attempt to
> hide that.

Upward referrals exist, but bare "referral" is short for "downward
referral". Other things that look like referrals (such as upward
referrals or implicit referrals) have to have a qualifier.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall, Malin, Hebrides: North 5 to 7. Moderate or rough. Showers,
but fair for a time later. Good, occasionally moderate.

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Wed, Nov 29, 2017 at 01:55:29PM +, P Vix wrote:
> Please do not write anything that blurs or softens the clear language of 
> downwards-ness in 1034. If you can't keep the clear spirit and intent of the 
> existing document then please write nothing at all.
>

I don't believe 1034 is anywhere near as clear as you are insisting it
is; and the empirical evidence of that lack of clarity is the very
thing you feel the need to recant.  If the WG believes otherwise, then
I think it is free to write the definition as it wishes, but only if
it removes me as an editor of the terminology document.

I do wish to make the definition clear, and I have no complaint where
the definition might note that not every operator agrees about
providing upward referrals (the text proffered already says that, I
think).  But I shall not include a change to the definition of
referrals such that upward referrals are defined away.  They exist,
today, all over the Internet, and it would be extremely foolish
lexicography to attempt to hide that.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[P Vix]

No, sir. Closer means downward. Nobody believes otherwise. Not even you, or 
Joe. The only person ever to get it wrong was me, and I have recanted. Please 
do not write anything that blurs or softens the clear language of 
downwards-ness in 1034. If you can't keep the clear spirit and intent of the 
existing document then please write nothing at all.

On November 29, 2017 8:28:11 PM GMT+08:00, Andrew Sullivan 
 wrote:
>On Wed, Nov 29, 2017 at 12:23:36PM +, P Vix wrote:
>> 1034 cannot be reasonably read that way.
>
>Sure it can.  See the discussion in draft-sullivan-dnsop-refer-down
>and on the list not two weeks ago for how.  I think it should _not_ be
>read that way, but an honest reader could read it that way, and the
>terminology document is not the place to rule on the way people should
>read a text.  We're supposed to be doing description, not prescription.
>
>Best regards,
>
>A
>
>
>-- 
>Andrew Sullivan
>a...@anvilwalrusden.com
>
>___
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Tony Finch]

Andrew Sullivan  wrote:
>
> I'm not totally convinced, but I can certainly see the argument.  If
> we added to the text I proposed something like, "Many people use the
> unqualified term 'referral' to mean only a downward referral," would
> that help?

Well, I would say, s/many people/Paul Mockapetris/  :-)

> > answer the query. I have also seen the term "implicit referral" meaning
> > the authority section from a recursive response, since the idea was that a
> > downstream cache might use those records to answer future queries more
> > efficiently (though doing that is no longer considered safe).
>
> Hmm.  It seems like we ought to add that point about implicit
> referral.

Oh, actually, (now I re-read my old definition properly) that term is used
in RFC 2308 section 6.

> I wonder how this is related to the "partial referral" Mark
> is talking about (see elsewhere in this thread).

They look similar but have different AA bits, if I understand correctly.
An implicit referral comes from the cache whereas Mark's CNAME plus
referral comes from authoritative data.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
North Utsire, South Utsire: Northerly or northeasterly 5 or 6, decreasing 4 at
times. Moderate or rough. Wintry showers. Good occasionally poor.

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Wed, Nov 29, 2017 at 12:23:36PM +, P Vix wrote:
> 1034 cannot be reasonably read that way.

Sure it can.  See the discussion in draft-sullivan-dnsop-refer-down
and on the list not two weeks ago for how.  I think it should _not_ be
read that way, but an honest reader could read it that way, and the
terminology document is not the place to rule on the way people should
read a text.  We're supposed to be doing description, not prescription.

Best regards,

A


-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Wed, Nov 29, 2017 at 02:37:20AM +, Evan Hunt wrote:
> 
> I think the phrasing is unclear because "this response is not required to
> work" is ambiguous. The response *itself* doesn't have to work?  Or the
> resolver can get along without this response?  I took it to mean the
> latter, but I see how it could be confusing.

Yep, got it.

> I'd suggest something like "this response is not strictly speaking
> necessary, as it provides no information the resolver didn't already
> have; resolution can succeed without it."

How about, "This kind of response is not required for resolution or
for correctly answering any query, and in practice some authoritative
server operators will not return referral responses beyond those
required for delegation"?

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[P Vix]

1034 cannot be reasonably read that way. I am asking for a clarification not a 
rule change. 

On November 29, 2017 8:21:01 PM GMT+08:00, Andrew Sullivan 
 wrote:
>On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote:
>> that's fatally unclear.
>
>So I gather :)
>
>> then the thing to say would be "a referral should always be downward,
>and if
>> a non-downward referral is received, it should be treated as a
>network data
>> configuration error".
>
>No, that is attempting to define away other kinds of referrals, which
>is precisely the discussion we were previously having (and why Joe and
>I wrote that other draft).  The terminology draft should not, in my
>opinion, attempt to change any RFC; and, IMO, 1034 defines referrals
>in such a way that someone _could_ think that upward referrals are
>sometimes a normal part of operation.  If we want to change the advice
>of what to do there, I think a different document is needed.
>
>Best regards,
>
>A
>
>-- 
>Andrew Sullivan
>a...@anvilwalrusden.com
>
>___
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote:
> that's fatally unclear.

So I gather :)

> then the thing to say would be "a referral should always be downward, and if
> a non-downward referral is received, it should be treated as a network data
> configuration error".

No, that is attempting to define away other kinds of referrals, which
is precisely the discussion we were previously having (and why Joe and
I wrote that other draft).  The terminology draft should not, in my
opinion, attempt to change any RFC; and, IMO, 1034 defines referrals
in such a way that someone _could_ think that upward referrals are
sometimes a normal part of operation.  If we want to change the advice
of what to do there, I think a different document is needed.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote:
> When the CNAME refers to a name that is out of zone and the target zone is 
> below
> a zone that the server serves you will have CNAME (DNAME) + referral.
>  
> 4.3.2 loops.

This part I got.

>   pass 1 -> 3a  (adds CNAME, AA is set as it matches the question 
> section, QNAME is updated).

This is the CNAME response, yes, ok.

>   pass 2 -> 3b  (we have a partial match with a bottom of zone cut which 
> adds the referral).
> 

Right, and the authoritative server can't proceed, but the referral is
necessary.  Good, this is helpful, thanks.  This also means, of
course, that in such a response the answer section isn't empty.  Is
this why you call it a "partial referral"?  

Best regards,

A

> > On 29 Nov 2017, at 1:03 pm, Andrew Sullivan  wrote:
> > 
> > Hi Mark,
> > 
> > On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote:
> >> You can answer only responses, you can have referral only responses,
> >> you can partial answer + referral responses.
> > 
> > Where in the algorithm in section 4.3.2 of 1034 (or other, derived
> > cases like DNAME) is this "partial answer + referral responses"
> > described?  If this is well-defined somewhere, I want to refer to it.
> > If it is not, I wish to describe it clearly, because it seems pretty
> > obvious given the amount of discussion we've had on this topic that
> > the notion of referral is nowhere near as clear as people seem to
> > think it is.  I'm not sure I understand your cryptic remark above, but
> > I am certain  I can't make it more comprehensible to others without
> > you telling me that I'm wrong and need to do it over.  So I'm
> > appealing to you to try to make your view as clear as possible.
> > 
> > Best regards,
> > 
> > A
> > 
> 

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi,

On Wed, Nov 29, 2017 at 11:16:28AM +, Tony Finch wrote:
> 
> Regarding the definition of referrals from older RFCs, see my
> terminology review from May 2015:
> https://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html

Yes, it's your review that has caused this issue :)

> I think that quote implies that other less formal uses of "closer"
> specifically mean downward in the DNS tree.

That's plausible.
 
> So I think unqualified "referral" means "downward referral" (from
> authoritative data)

I'm not totally convinced, but I can certainly see the argument.  If
we added to the text I proposed something like, "Many people use the
unqualified term 'referral' to mean only a downward referral," would
that help?

> answer the query. I have also seen the term "implicit referral" meaning
> the authority section from a recursive response, since the idea was that a
> downstream cache might use those records to answer future queries more
> efficiently (though doing that is no longer considered safe).

Hmm.  It seems like we ought to add that point about implicit
referral.  I wonder how this is related to the "partial referral" Mark
is talking about (see elsewhere in this thread).

Thanks,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Tony Finch]

Andrew Sullivan  wrote:
>
> Joe Abley and I have just submitted a draft
> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
> that is intended to capture the discussion here about referrals and
> how to describe them.  It is intended for BCP, and it discourages
> upward referrals by authoritative servers.
>
> That leaves the task of the referrals definition.  I have some new
> text below:

Regarding the definition of referrals from older RFCs, see my
terminology review from May 2015:
https://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html

As far as I can tell, RFC 1034 uses the term "referral" for downward
referrals. For instance, section 4.2.1:

  To fix this problem, a zone contains "glue" RRs which are not
  part of the authoritative data, and are address RRs for the servers.
  These RRs are only necessary if the name server's name is "below" the
  cut, and are only used as part of a referral response.

Section 4.3.1:

 A referral to name servers which have zones which are closer
 ancestors to the name than the server sending the reply.

I think that quote implies that other less formal uses of "closer"
specifically mean downward in the DNS tree.

The downward meaning is most clear in the algorithm in section 4.3.2.
Step 3 deals with authoritative data, and says:

 b. If a match would take us out of the authoritative data,
we have a referral.  This happens when we encounter a
node with NS RRs marking cuts along the bottom of a
zone.

Step 4 is where upward referrals come from (when the cache only contains
root hints and no authoritative zone matches the qname), but it does NOT
use the term "referral":

   4. Start matching down in the cache.  If QNAME is found in the
  cache, copy all RRs attached to it that match QTYPE into the
  answer section.  If there was no delegation from
  authoritative data, look for the best one from the cache, and
  put it in the authority section.  Go to step 6.

So I think unqualified "referral" means "downward referral" (from
authoritative data); it's OK to use the term "upward referral" to mean a
response from the cache that looks like a referral but doesn't help to
answer the query. I have also seen the term "implicit referral" meaning
the authority section from a recursive response, since the idea was that a
downstream cache might use those records to answer future queries more
efficiently (though doing that is no longer considered safe).

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fisher: Northerly 3 or 4, increasing 5 or 6, then becoming cyclonic later.
Moderate, occasionally rough in west. Showers, wintry later. Good,
occasionally poor later.

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Andrew Sullivan wrote:

On Tue, Nov 28, 2017 at 03:18:57PM -0800, Paul Vixie wrote:


what would "to work" mean in the above text?


"Not strictly speaking required to work" was intended to observe that,
if you didn't get a referral under this condition, nothing ought to
break (or, if it did, it was already broken).


that's fatally unclear.


... The point is in contrast to the downward referrals case, which
_must_ work or delegation doesn't. I'm nervous about someone running
off saying, "IETF says referrals don't work," which is clearly not
the point.


then the thing to say would be "a referral should always be downward, 
and if a non-downward referral is received, it should be treated as a 
network data configuration error".



that an upward referral could "work" in the above-reference sense
seems to imply that the authority server you've queried, knows more
about where the zone really is, than you could learn by walking
down from the root. that's a walking talking nonsequitur. could you
tell me what you really mean by "to work" since it can't possibly
be that?


Indeed, it is not that. Suggestions on how to make this clearer are
welcome.


Evan Hunt wrote:

I'd suggest something like "this response is not strictly speaking
necessary, as it provides no information the resolver didn't already
have; resolution can succeed without it."


i don't think we can walk this path without touching the "should" fire.

-- P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Evan Hunt]

> "Not strictly speaking required to work" was intended to observe that,
> if you didn't get a referral under this condition, nothing ought to
> break (or, if it did, it was already broken). 

I think the phrasing is unclear because "this response is not required to
work" is ambiguous. The response *itself* doesn't have to work?  Or the
resolver can get along without this response?  I took it to mean the
latter, but I see how it could be confusing.

I'd suggest something like "this response is not strictly speaking
necessary, as it provides no information the resolver didn't already
have; resolution can succeed without it."

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

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

Re: [DNSOP] Clarifying referrals (#35)

[Mark Andrews]

When the CNAME refers to a name that is out of zone and the target zone is below
a zone that the server serves you will have CNAME (DNAME) + referral.
 
4.3.2 loops.

pass 1 -> 3a  (adds CNAME, AA is set as it matches the question 
section, QNAME is updated).
pass 2 -> 3b  (we have a partial match with a bottom of zone cut which 
adds the referral).

> On 29 Nov 2017, at 1:03 pm, Andrew Sullivan  wrote:
> 
> Hi Mark,
> 
> On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote:
>> You can answer only responses, you can have referral only responses,
>> you can partial answer + referral responses.
> 
> Where in the algorithm in section 4.3.2 of 1034 (or other, derived
> cases like DNAME) is this "partial answer + referral responses"
> described?  If this is well-defined somewhere, I want to refer to it.
> If it is not, I wish to describe it clearly, because it seems pretty
> obvious given the amount of discussion we've had on this topic that
> the notion of referral is nowhere near as clear as people seem to
> think it is.  I'm not sure I understand your cryptic remark above, but
> I am certain  I can't make it more comprehensible to others without
> you telling me that I'm wrong and need to do it over.  So I'm
> appealing to you to try to make your view as clear as possible.
> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Clarifying referrals (#35)

[Mark Andrews]

And you can have partial answer and with no referral data responses
which are confusable with NOERROR NODATA.  We really should do
EDNS(1) and add NXRRSET to the list of rcodes for QUERY. 

> On 29 Nov 2017, at 12:57 pm, Mark Andrews  wrote:
> 
> You can answer only responses, you can have referral only responses,
> you can partial answer + referral responses.
> 
>> On 29 Nov 2017, at 12:53 pm, Andrew Sullivan  wrote:
>> 
>> On Wed, Nov 29, 2017 at 12:46:07PM +1100, Mark Andrews wrote:
>>> GO READ STD13!
>> 
>> I thought I had, and I thought indeed that I was quoting it to you (or
>> at least making references).
>> 
>> I _suspect_ that you're referring to 4.1.1 in 1035 which describes AA.
>> But that says that it "that the responding name server is an authority
>> for the domain name in question section."  This does not seem to me to
>> line up clearly with the cases called a "referral" in 1034.
>> 
>> I'm not trying to be religious about this or claim that I have the
>> right answer.  I'm just trying to write down the historical lore, so
>> that future people don't have to be this bored again.
>> 
>> Thanks,
>> 
>> A
>> 
>> 
>> -- 
>> Andrew Sullivan
>> a...@anvilwalrusden.com
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi Mark,

On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote:
> You can answer only responses, you can have referral only responses,
> you can partial answer + referral responses.

Where in the algorithm in section 4.3.2 of 1034 (or other, derived
cases like DNAME) is this "partial answer + referral responses"
described?  If this is well-defined somewhere, I want to refer to it.
If it is not, I wish to describe it clearly, because it seems pretty
obvious given the amount of discussion we've had on this topic that
the notion of referral is nowhere near as clear as people seem to
think it is.  I'm not sure I understand your cryptic remark above, but
I am certain  I can't make it more comprehensible to others without
you telling me that I'm wrong and need to do it over.  So I'm
appealing to you to try to make your view as clear as possible.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Mark Andrews]

You can answer only responses, you can have referral only responses,
you can partial answer + referral responses.

> On 29 Nov 2017, at 12:53 pm, Andrew Sullivan  wrote:
> 
> On Wed, Nov 29, 2017 at 12:46:07PM +1100, Mark Andrews wrote:
>> GO READ STD13!
> 
> I thought I had, and I thought indeed that I was quoting it to you (or
> at least making references).
> 
> I _suspect_ that you're referring to 4.1.1 in 1035 which describes AA.
> But that says that it "that the responding name server is an authority
> for the domain name in question section."  This does not seem to me to
> line up clearly with the cases called a "referral" in 1034.
> 
> I'm not trying to be religious about this or claim that I have the
> right answer.  I'm just trying to write down the historical lore, so
> that future people don't have to be this bored again.
> 
> Thanks,
> 
> A
> 
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Yes, what I just sent.  So how does one end up in 3.b with the AA bit
and still have a "referral" according to 1034, section 4.3.2?

A

On Wed, Nov 29, 2017 at 12:49:48PM +1100, Mark Andrews wrote:
> AA  Authoritative Answer - this bit is valid in responses,
> and specifies that the responding name server is an
> authority for the domain name in question section.
> 
> Note that the contents of the answer section may have
> multiple owner names because of aliases.  The AA bit
> corresponds to the name which matches the query name, or
> the first owner name in the answer section.
> 
> > On 29 Nov 2017, at 12:46 pm, Mark Andrews  wrote:
> > 
> > GO READ STD13!
> > 
> >> On 29 Nov 2017, at 12:44 pm, Andrew Sullivan  
> >> wrote:
> >> 
> >> Hi,
> >> 
> >> On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote:
> >>> The AA bit may or may not be set depending upon whether the response 
> >>> contains
> >>> a CNAME/DNAME or not.  
> >>> 
> >> 
> >> I replied with an enthusiastic "thanks" because this struck me as
> >> obviously correct, but then I though I'd better look at the algorithm
> >> again.  And now I have a problem.
> >> 
> >> 3.a is the CNAME case, but it's not a referral in the 1035 sense.
> >> 
> >> 3.b takes us out of the authoritative data, so AA should not be set.
> >> 
> >> Now, in RFC 6672 the DNAME processing happens at step 3.C, which
> >> undertakes the DNAME processing.  The resulting answer goes into the
> >> answer section and processing continues.
> >> 
> >> None of these steps seems to provide the case where a referral happens
> >> but the AA bit is set.  So, while I feel like I agree that in some
> >> cases the AA bit should be set and not clear in case the response
> >> contains a CNAME or DNAME, I'm trying to figure out whether such
> >> responses are really referrals or else just intermediate steps. RFC
> >> 6672 doesn't call them referrals.  Maybe this is a bit of informal
> >> jargon that needs clarifying?
> >> 
> >> Thanks for the contribution, and best regards,
> >> 
> >> A
> >> 
>  On 29 Nov 2017, at 6:50 am, Andrew Sullivan  
>  wrote:
>  
>  Dear colleagues,
>  
>  Joe Abley and I have just submitted a draft
>  (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
>  that is intended to capture the discussion here about referrals and
>  how to describe them.  It is intended for BCP, and it discourages
>  upward referrals by authoritative servers.
>  
>  That leaves the task of the referrals definition.  I have some new
>  text below:
>  
>  ---%<---cut here---
>  
>  Referral: A type of response in which a server, signalling that it is
>  not authoritative for an answer, provides the querying resolver with
>  an alternative place to send its query.  A referral contains an empty
>  answer section.  It contains the NS RRset for the referred-to zone in
>  the authority section.  It may contain RRs that provide addresses in
>  the additional section.  The AA bit is clear.
>  
>  There are two types of referral response.  The first is a downward
>  referral (sometimes described as "delegation response"), where the
>  server is authoritative for some portion of the QNAME.  The Authority
>  section RRset's RDATA contains the name servers specified at the
>  referred-to zone cut.  In normal DNS operation, this kind of response
>  is required in order to find names beneath a delegation.
>  
>  The second is an upward referral (sometimes described as "root
>  referral" or just "referral response", as distinct from the delegation
>  response above), where the server is not authoritative for any portion
>  of the QNAME.  When this happens, the referred-to zone in the
>  Authority section is usually the root zone (.).  In normal DNS
>  operation, this kind of response is not strictly speaking required to
>  work, and in practice some authoritative server operators will not
>  return referral responses beyond those required for delegation.
>  
>  [optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
>  only include this reference if the other draft reaches WG consensus
>  before terminology-bis]
>  
>  ---cut here--->%---
>  
>  Comments, please.  Also, Joe and I solicit comments on the referrals
>  draft proper, but it would be nice to put that in a different thread.
>  
>  Best regards,
>  
>  A
>  
> >>> 
> >> 
> > 
> 

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Wed, Nov 29, 2017 at 12:46:07PM +1100, Mark Andrews wrote:
> GO READ STD13!

I thought I had, and I thought indeed that I was quoting it to you (or
at least making references).

I _suspect_ that you're referring to 4.1.1 in 1035 which describes AA.
But that says that it "that the responding name server is an authority
for the domain name in question section."  This does not seem to me to
line up clearly with the cases called a "referral" in 1034.

I'm not trying to be religious about this or claim that I have the
right answer.  I'm just trying to write down the historical lore, so
that future people don't have to be this bored again.

Thanks,

A


-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Mark Andrews]

AA  Authoritative Answer - this bit is valid in responses,
and specifies that the responding name server is an
authority for the domain name in question section.

Note that the contents of the answer section may have
multiple owner names because of aliases.  The AA bit
corresponds to the name which matches the query name, or
the first owner name in the answer section.

> On 29 Nov 2017, at 12:46 pm, Mark Andrews  wrote:
> 
> GO READ STD13!
> 
>> On 29 Nov 2017, at 12:44 pm, Andrew Sullivan  wrote:
>> 
>> Hi,
>> 
>> On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote:
>>> The AA bit may or may not be set depending upon whether the response 
>>> contains
>>> a CNAME/DNAME or not.  
>>> 
>> 
>> I replied with an enthusiastic "thanks" because this struck me as
>> obviously correct, but then I though I'd better look at the algorithm
>> again.  And now I have a problem.
>> 
>> 3.a is the CNAME case, but it's not a referral in the 1035 sense.
>> 
>> 3.b takes us out of the authoritative data, so AA should not be set.
>> 
>> Now, in RFC 6672 the DNAME processing happens at step 3.C, which
>> undertakes the DNAME processing.  The resulting answer goes into the
>> answer section and processing continues.
>> 
>> None of these steps seems to provide the case where a referral happens
>> but the AA bit is set.  So, while I feel like I agree that in some
>> cases the AA bit should be set and not clear in case the response
>> contains a CNAME or DNAME, I'm trying to figure out whether such
>> responses are really referrals or else just intermediate steps. RFC
>> 6672 doesn't call them referrals.  Maybe this is a bit of informal
>> jargon that needs clarifying?
>> 
>> Thanks for the contribution, and best regards,
>> 
>> A
>> 
 On 29 Nov 2017, at 6:50 am, Andrew Sullivan  
 wrote:
 
 Dear colleagues,
 
 Joe Abley and I have just submitted a draft
 (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
 that is intended to capture the discussion here about referrals and
 how to describe them.  It is intended for BCP, and it discourages
 upward referrals by authoritative servers.
 
 That leaves the task of the referrals definition.  I have some new
 text below:
 
 ---%<---cut here---
 
 Referral: A type of response in which a server, signalling that it is
 not authoritative for an answer, provides the querying resolver with
 an alternative place to send its query.  A referral contains an empty
 answer section.  It contains the NS RRset for the referred-to zone in
 the authority section.  It may contain RRs that provide addresses in
 the additional section.  The AA bit is clear.
 
 There are two types of referral response.  The first is a downward
 referral (sometimes described as "delegation response"), where the
 server is authoritative for some portion of the QNAME.  The Authority
 section RRset's RDATA contains the name servers specified at the
 referred-to zone cut.  In normal DNS operation, this kind of response
 is required in order to find names beneath a delegation.
 
 The second is an upward referral (sometimes described as "root
 referral" or just "referral response", as distinct from the delegation
 response above), where the server is not authoritative for any portion
 of the QNAME.  When this happens, the referred-to zone in the
 Authority section is usually the root zone (.).  In normal DNS
 operation, this kind of response is not strictly speaking required to
 work, and in practice some authoritative server operators will not
 return referral responses beyond those required for delegation.
 
 [optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
 only include this reference if the other draft reaches WG consensus
 before terminology-bis]
 
 ---cut here--->%---
 
 Comments, please.  Also, Joe and I solicit comments on the referrals
 draft proper, but it would be nice to put that in a different thread.
 
 Best regards,
 
 A
 
>>> 
>> 
>> -- 
>> Andrew Sullivan
>> a...@anvilwalrusden.com
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Tue, Nov 28, 2017 at 03:18:57PM -0800, Paul Vixie wrote:

> what would "to work" mean in the above text?

"Not strictly speaking required to work" was intended to observe that,
if you didn't get a referral under this condition, nothing ought to
break (or, if it did, it was already broken).  The point is in
contrast to the downward referrals case, which _must_ work or
delegation doesn't.  I'm nervous about someone running off saying,
"IETF says referrals don't work," which is clearly not the point.

> that an upward referral could "work" in the above-reference sense seems to
> imply that the authority server you've queried, knows more about where the
> zone really is, than you could learn by walking down from the root. that's a
> walking talking nonsequitur. could you tell me what you really mean by "to
> work" since it can't possibly be that?

Indeed, it is not that.  Suggestions on how to make this clearer are
welcome.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Mark Andrews]

GO READ STD13!

> On 29 Nov 2017, at 12:44 pm, Andrew Sullivan  wrote:
> 
> Hi,
> 
> On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote:
>> The AA bit may or may not be set depending upon whether the response contains
>> a CNAME/DNAME or not.  
>> 
> 
> I replied with an enthusiastic "thanks" because this struck me as
> obviously correct, but then I though I'd better look at the algorithm
> again.  And now I have a problem.
> 
> 3.a is the CNAME case, but it's not a referral in the 1035 sense.
> 
> 3.b takes us out of the authoritative data, so AA should not be set.
> 
> Now, in RFC 6672 the DNAME processing happens at step 3.C, which
> undertakes the DNAME processing.  The resulting answer goes into the
> answer section and processing continues.
> 
> None of these steps seems to provide the case where a referral happens
> but the AA bit is set.  So, while I feel like I agree that in some
> cases the AA bit should be set and not clear in case the response
> contains a CNAME or DNAME, I'm trying to figure out whether such
> responses are really referrals or else just intermediate steps. RFC
> 6672 doesn't call them referrals.  Maybe this is a bit of informal
> jargon that needs clarifying?
> 
> Thanks for the contribution, and best regards,
> 
> A
> 
>>> On 29 Nov 2017, at 6:50 am, Andrew Sullivan  wrote:
>>> 
>>> Dear colleagues,
>>> 
>>> Joe Abley and I have just submitted a draft
>>> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
>>> that is intended to capture the discussion here about referrals and
>>> how to describe them.  It is intended for BCP, and it discourages
>>> upward referrals by authoritative servers.
>>> 
>>> That leaves the task of the referrals definition.  I have some new
>>> text below:
>>> 
>>> ---%<---cut here---
>>> 
>>> Referral: A type of response in which a server, signalling that it is
>>> not authoritative for an answer, provides the querying resolver with
>>> an alternative place to send its query.  A referral contains an empty
>>> answer section.  It contains the NS RRset for the referred-to zone in
>>> the authority section.  It may contain RRs that provide addresses in
>>> the additional section.  The AA bit is clear.
>>> 
>>> There are two types of referral response.  The first is a downward
>>> referral (sometimes described as "delegation response"), where the
>>> server is authoritative for some portion of the QNAME.  The Authority
>>> section RRset's RDATA contains the name servers specified at the
>>> referred-to zone cut.  In normal DNS operation, this kind of response
>>> is required in order to find names beneath a delegation.
>>> 
>>> The second is an upward referral (sometimes described as "root
>>> referral" or just "referral response", as distinct from the delegation
>>> response above), where the server is not authoritative for any portion
>>> of the QNAME.  When this happens, the referred-to zone in the
>>> Authority section is usually the root zone (.).  In normal DNS
>>> operation, this kind of response is not strictly speaking required to
>>> work, and in practice some authoritative server operators will not
>>> return referral responses beyond those required for delegation.
>>> 
>>> [optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
>>> only include this reference if the other draft reaches WG consensus
>>> before terminology-bis]
>>> 
>>> ---cut here--->%---
>>> 
>>> Comments, please.  Also, Joe and I solicit comments on the referrals
>>> draft proper, but it would be nice to put that in a different thread.
>>> 
>>> Best regards,
>>> 
>>> A
>>> 
>> 
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi,

On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote:
> The AA bit may or may not be set depending upon whether the response contains
> a CNAME/DNAME or not.  
> 

I replied with an enthusiastic "thanks" because this struck me as
obviously correct, but then I though I'd better look at the algorithm
again.  And now I have a problem.

3.a is the CNAME case, but it's not a referral in the 1035 sense.

3.b takes us out of the authoritative data, so AA should not be set.

Now, in RFC 6672 the DNAME processing happens at step 3.C, which
undertakes the DNAME processing.  The resulting answer goes into the
answer section and processing continues.

None of these steps seems to provide the case where a referral happens
but the AA bit is set.  So, while I feel like I agree that in some
cases the AA bit should be set and not clear in case the response
contains a CNAME or DNAME, I'm trying to figure out whether such
responses are really referrals or else just intermediate steps. RFC
6672 doesn't call them referrals.  Maybe this is a bit of informal
jargon that needs clarifying?

Thanks for the contribution, and best regards,

A

> > On 29 Nov 2017, at 6:50 am, Andrew Sullivan  wrote:
> > 
> > Dear colleagues,
> > 
> > Joe Abley and I have just submitted a draft
> > (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
> > that is intended to capture the discussion here about referrals and
> > how to describe them.  It is intended for BCP, and it discourages
> > upward referrals by authoritative servers.
> > 
> > That leaves the task of the referrals definition.  I have some new
> > text below:
> > 
> > ---%<---cut here---
> > 
> > Referral: A type of response in which a server, signalling that it is
> > not authoritative for an answer, provides the querying resolver with
> > an alternative place to send its query.  A referral contains an empty
> > answer section.  It contains the NS RRset for the referred-to zone in
> > the authority section.  It may contain RRs that provide addresses in
> > the additional section.  The AA bit is clear.
> > 
> > There are two types of referral response.  The first is a downward
> > referral (sometimes described as "delegation response"), where the
> > server is authoritative for some portion of the QNAME.  The Authority
> > section RRset's RDATA contains the name servers specified at the
> > referred-to zone cut.  In normal DNS operation, this kind of response
> > is required in order to find names beneath a delegation.
> > 
> > The second is an upward referral (sometimes described as "root
> > referral" or just "referral response", as distinct from the delegation
> > response above), where the server is not authoritative for any portion
> > of the QNAME.  When this happens, the referred-to zone in the
> > Authority section is usually the root zone (.).  In normal DNS
> > operation, this kind of response is not strictly speaking required to
> > work, and in practice some authoritative server operators will not
> > return referral responses beyond those required for delegation.
> > 
> > [optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
> > only include this reference if the other draft reaches WG consensus
> > before terminology-bis]
> > 
> > ---cut here--->%---
> > 
> > Comments, please.  Also, Joe and I solicit comments on the referrals
> > draft proper, but it would be nice to put that in a different thread.
> > 
> > Best regards,
> > 
> > A
> > 
> 

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Excellent point!  Thanks.

--
Please excuse my clumbsy thums



--
On November 28, 2017 15:40:14 Mark Andrews  wrote:


The AA bit may or may not be set depending upon whether the response contains
a CNAME/DNAME or not.


On 29 Nov 2017, at 6:50 am, Andrew Sullivan  wrote:

Dear colleagues,

Joe Abley and I have just submitted a draft
(https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
that is intended to capture the discussion here about referrals and
how to describe them.  It is intended for BCP, and it discourages
upward referrals by authoritative servers.

That leaves the task of the referrals definition.  I have some new
text below:

---%<---cut here---

Referral: A type of response in which a server, signalling that it is
not authoritative for an answer, provides the querying resolver with
an alternative place to send its query.  A referral contains an empty
answer section.  It contains the NS RRset for the referred-to zone in
the authority section.  It may contain RRs that provide addresses in
the additional section.  The AA bit is clear.

There are two types of referral response.  The first is a downward
referral (sometimes described as "delegation response"), where the
server is authoritative for some portion of the QNAME.  The Authority
section RRset's RDATA contains the name servers specified at the
referred-to zone cut.  In normal DNS operation, this kind of response
is required in order to find names beneath a delegation.

The second is an upward referral (sometimes described as "root
referral" or just "referral response", as distinct from the delegation
response above), where the server is not authoritative for any portion
of the QNAME.  When this happens, the referred-to zone in the
Authority section is usually the root zone (.).  In normal DNS
operation, this kind of response is not strictly speaking required to
work, and in practice some authoritative server operators will not
return referral responses beyond those required for delegation.

[optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
only include this reference if the other draft reaches WG consensus
before terminology-bis]

---cut here--->%---

Comments, please.  Also, Joe and I solicit comments on the referrals
draft proper, but it would be nice to put that in a different thread.

Best regards,

A

--
Andrew Sullivan
a...@anvilwalrusden.com

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


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
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] Clarifying referrals (#35)

[Paul Vixie]

Andrew Sullivan wrote:

Dear colleagues,

Joe Abley and I have just submitted a draft
(https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
that is intended to capture the discussion here about referrals and
how to describe them.  It is intended for BCP, and it discourages
upward referrals by authoritative servers.

That leaves the task of the referrals definition.  I have some new
text below:

---%<---cut here---

...

The second is an upward referral (sometimes described as "root
referral" or just "referral response", as distinct from the delegation
response above), where the server is not authoritative for any portion
of the QNAME.  When this happens, the referred-to zone in the
Authority section is usually the root zone (.).  In normal DNS
operation, this kind of response is not strictly speaking required to
work, and in practice some authoritative server operators will not
return referral responses beyond those required for delegation.

...

---cut here--->%---

Comments, please.  Also, Joe and I solicit comments on the referrals
draft proper, but it would be nice to put that in a different thread.


what would "to work" mean in the above text? if you ask some authority 
server a question, it is either authoritative for some part of it in 
which case you'll get NOERROR and either an answer or a referral, or it 
is not authoritative and nothing it can tell you will help in any way 
other than some kind of "i am not authoritative for any part of the 
question you have asked me".


that an upward referral could "work" in the above-reference sense seems 
to imply that the authority server you've queried, knows more about 
where the zone really is, than you could learn by walking down from the 
root. that's a walking talking nonsequitur. could you tell me what you 
really mean by "to work" since it can't possibly be that?


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Mark Andrews]

The AA bit may or may not be set depending upon whether the response contains
a CNAME/DNAME or not.  

> On 29 Nov 2017, at 6:50 am, Andrew Sullivan  wrote:
> 
> Dear colleagues,
> 
> Joe Abley and I have just submitted a draft
> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/)
> that is intended to capture the discussion here about referrals and
> how to describe them.  It is intended for BCP, and it discourages
> upward referrals by authoritative servers.
> 
> That leaves the task of the referrals definition.  I have some new
> text below:
> 
> ---%<---cut here---
> 
> Referral: A type of response in which a server, signalling that it is
> not authoritative for an answer, provides the querying resolver with
> an alternative place to send its query.  A referral contains an empty
> answer section.  It contains the NS RRset for the referred-to zone in
> the authority section.  It may contain RRs that provide addresses in
> the additional section.  The AA bit is clear.
> 
> There are two types of referral response.  The first is a downward
> referral (sometimes described as "delegation response"), where the
> server is authoritative for some portion of the QNAME.  The Authority
> section RRset's RDATA contains the name servers specified at the
> referred-to zone cut.  In normal DNS operation, this kind of response
> is required in order to find names beneath a delegation.
> 
> The second is an upward referral (sometimes described as "root
> referral" or just "referral response", as distinct from the delegation
> response above), where the server is not authoritative for any portion
> of the QNAME.  When this happens, the referred-to zone in the
> Authority section is usually the root zone (.).  In normal DNS
> operation, this kind of response is not strictly speaking required to
> work, and in practice some authoritative server operators will not
> return referral responses beyond those required for delegation.
> 
> [optional: see draft-sullivan-dnsop-refer-down-00 or whatever.  We'll
> only include this reference if the other draft reaches WG consensus
> before terminology-bis]
> 
> ---cut here--->%---
> 
> Comments, please.  Also, Joe and I solicit comments on the referrals
> draft proper, but it would be nice to put that in a different thread.
> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] Clarifying referrals (#35)

[Stephane Bortzmeyer]

On Tue, Nov 14, 2017 at 09:04:36PM -0500,
 Dave Lawrence  wrote 
 a message of 17 lines which said:

> I'd be surprised to see REFUSED from a resolver.

% dig +norec @9.9.9.9 A www.afnic.fr
; <<>> DiG 9.10.3-P4-Debian <<>> +norec @9.9.9.9 A www.afnic.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 4022
;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 6 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Thu Nov 23 17:11:30 CET 2017
;; MSG SIZE  rcvd: 12

:-)

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

Re: [DNSOP] Clarifying referrals (#35)

[Tony Finch]

Paul Vixie  wrote:
>
> the reason i use SERVFAIL for NOTAUTH is because what i want the initiator to
> do when i'm configured as primary but can't read my zone file, or am
> configured as secondary but can't write my zone file, is the same as what i
> want when i'm not configured for the zone: cache this failure under a
> hold-down timer so as not to melt the tubez, but do try again later in case
> i'm merely late to change my config, or flubbed my config in some way.

I'm interested in this discussion.

Recently I changed private.cam.ac.uk so that queries from off-campus get
NXDOMAIN instead of REFUSED. This had the unanticipated effect of halving
the query load on our authoritative servers. Not really surprising except
perhaps for the size of the effect.

I've had a skim through BIND's resolver code to see how the lame server
cache works. It's, um, not simple :-) but as far as I can see, both
SERVFAIL and REFUSED responses get the server put in the lame cache.

(BIND's servfail cache is different - that's for failures of this server
itself, not the servers it is sending queries to.)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fisher, German Bight: Northwest backing south 4 or 5, veering southwest 5 to 7
later. Moderate, occasionally rough. Showers. Moderate or good.

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Dave Lawrence wrote:

Evan Hunt writes:

Okay. I haven't encountered a resolver that propgates REFUSED from the
authority to the stub.  If there is such a beast, then IMHO that, not the
authority, is the one that's mis-using REFUSED; REFUSED only makes sense on
a hop-by-hop basis.


i'll stop arguing about it.


Very much agree.  I'd be surprised to see REFUSED from a resolver.


i think you'd be within your rights as a stub to treat REFUSED as your 
lack of permission to use that recursive, and not an end-to-end signal. 
this bolsters evan's observation of its ambiguity.



Now on the other hand, using extended-error for signalling from a
resolver that the known authorities all returned REFUSED, that's
interesting and can be made unambiguous as a code apart from the
currently proposed extended-error 4, "Prohibited".


for each code we have to be explicit about what we expect the initiator 
to do in response.


the reason i use SERVFAIL for NOTAUTH is because what i want the 
initiator to do when i'm configured as primary but can't read my zone 
file, or am configured as secondary but can't write my zone file, is the 
same as what i want when i'm not configured for the zone: cache this 
failure under a hold-down timer so as not to melt the tubez, but do try 
again later in case i'm merely late to change my config, or flubbed my 
config in some way.


i think the need for a hold-down timer on cached SERVFAIL may be 
catching a number of you by surprise. but really, what we want for 
NOTAUTH, we already have to have for SERVFAIL.


administrative denial is something else.

--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Dave Lawrence]

Evan Hunt writes:
> Okay. I haven't encountered a resolver that propgates REFUSED from the
> authority to the stub.  If there is such a beast, then IMHO that, not the
> authority, is the one that's mis-using REFUSED; REFUSED only makes sense on
> a hop-by-hop basis.

Very much agree.  I'd be surprised to see REFUSED from a resolver.

Now on the other hand, using extended-error for signalling from a
resolver that the known authorities all returned REFUSED, that's
interesting and can be made unambiguous as a code apart from the
currently proposed extended-error 4, "Prohibited".

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

Re: [DNSOP] Clarifying referrals (#35)

[Evan Hunt]

On Tue, Nov 14, 2017 at 12:21:11AM -0800, Paul Vixie wrote:
> i mean propagating REFUSED back to the stub so that it can return an 
> error to its application or user.

Okay. I haven't encountered a resolver that propgates REFUSED from the
authority to the stub.  If there is such a beast, then IMHO that, not the
authority, is the one that's mis-using REFUSED; REFUSED only makes sense on
a hop-by-hop basis.

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

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi,

On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote:
> 
> there is no reason for an authority server to know who the root name servers
> are. so, there can be no expectation that it would know any "closer" name
> server set than the one at its zone bottom.

I think your claim there depends on a strict role separation that is
not in the protocol definition (yet).  It implies that there is such a
thing as "an authority server", whereas it seems to me that we have
not defined servers quite so exclusively (yet).  Interestingly (and
really helpfully I must emphasise), you have just made me realise that
there's actually a problem in the definition of "authoritative server"
in 7719 and -bis.

In that definition, we quote 2182:

A server that knows the content of a DNS zone from local
  knowledge, and thus can answer queries about that zone without
  needing to query other servers.

But then we go on to say that the server has been configured to answer
with AA set for the zone.  Yet that is not entailed by 2182's
definition, for it seems to me that 2182's definition of "knows the
content" could under one reading include the root hints file.  I note
that RFC 8109 doesn't actually cover the case of an authoritative
server, and of course we haven't (yet) got consensus that mixed-mode
servers are harmful, either.

Now, one might argue (I can see such a reading, and I think it is what
you are arguing) that the root hints file is RFC 1034's SBELT
structure, and that 1034 defines SBELT is to "be used when the
resolver doesn't have any local information to guide name server
selection", and that the SBELT structure is anyway defined only for
resolvers and not servers.  All of that _should_ mean that a server
that is only ever authoritative ought not to have this sort of
information and probably also that it ought never to reveal it when
the RD bit is clear even if it did have it.  I think it is reasonble
to say, however, that this information is not entirely clear from the
RFCs as they currently stand, particularly since the algorithm in
section 4.3.2 of RFC 1034 seems explicitly to contemplate having a
cache, and it's not clear (at least to me) in that algorithm whether
there are ever cases where a cache ought to be excluded completely
from consideration.

> since RFC 1034 talks about zone bottoms, and "closest enclosing", and its
> algorithm speaks specifically of a referral being generated by copying
> non-authoritative NS RRs from the zone bottom into the answer, there is no
> reasonable interpretation of "closer" other than an NS RRset which is
> closer, along the path from the zone apex to the qname, than the zone apex
> was. in fact, from that algorithm, there is no way to generate a referral
> other than by copying along-the-path data into an answer.

Step 4 of the algorithm in RFC 1034 reads to me like a flat-out
contradiction of your claim there:

   4. Start matching down in the cache.  If QNAME is found in the
  cache, copy all RRs attached to it that match QTYPE into the
  answer section.  If there was no delegation from
  authoritative data, look for the best one from the cache, and
  put it in the authority section.  Go to step 6.

So your entire argument turns on whether a server should ever have a
root hints file and use it.  If there is written down somewhere advice
that some class of servers should never have such information, I have
overlooked it.

> > This, too, seems to be a claim that is at best poorly justified.  It
> > might be that it is how BIND interprets the RCODE, but it's not what
> > it is defined to be.
> 
> it's defined as "administrative denial" not merely "widely interpreted as
> administrative denial" as i wrote above.

Where is it defined that way?  RFC 1035 just says it is refused "for
policy reasons", and the IANA registry is less descriptive than that
because it refers to RFC 1035.  I'm unaware of another place this is
defined.

> "no." the client isn't asking for an upward referral, it's asking for an
> answer, and is expecting either an answer (positive or negative or empty) or
> an on-the-path referral copied from the non-authoritative data at the bottom
> of the authority zone.

I don't think that you have shown this follows from the algorithm, and
the fact that clients seem not to spit up on root referrals strikes me
as empirical evidence that your assertion of what the client is
expecting is at least in doubt.

> < particular requester

Right.  Such as, for instance, not wishing to provide the upward
referral (or anything else).  The particular requester might be a
member of the class, "all requesters asking for zones for which I am
not authoritative".  I get why your interpretation is one plausible
one, but I do not see that it is the _only_ one.

> as witnessed in discussions of the u.s. constitutions and the christian
> bible, arguments about the literal intent of the authors are interesting
> mostly to scholars, whereas our concern 

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Evan Hunt wrote:

On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote:

while specific guidance was not given as to resolver action in response
to each possible authority RCODE, i have both witnessed and implemented
full resolvers which treated REFUSED as a permanent failure whereas
SERVFAIL was a temporary failure.


What do you mean by "permanent" in this context?


i mean propagating REFUSED back to the stub so that it can return an 
error to its application or user. in SMTP terms this would cause a 4xx 
rather than a 5xx. in fact, SMTP might bounce the e-mail rather than 
requeuing it for later retry, if an SMTP relay got REFUSED from DNS 
rather than SERVFAIL when looking up an MX or  or A to send to.



i have heard a number of folks argue that this logic is common, but i
have heard noone argue that it is superior to known alternatives. can we
hear someone who is in favour of this for reasons beyond "five million
frenchmen cannot be wrong"?


I wish NOTAUTH had been defined in 1035. Since it wasn't, there are only
three answers that make any sense: NOERROR with upward referral, SERVFAIL,
REFUSED.  We already disposed of upward referral.  SERVFAIL gets you
spurious retries.


SERVFAIL's retries aren't spurious.


...  REFUSED makes the querant go away for a sensible amount
of time;


SERVFAIL's have to be cached. perhaps we should document that fact as 
part of explaining why REFUSED is wrong-headed for this signaling purpose.



... we have ten years of operational experience with it.  I don't see
the problem.


i think we have to be very careful reasoning about nonexistence from an 
absence of evidence. not everyone who could be having problems related 
to BIND's use of REFUSED from this will recognize it as a BIND problem 
or even as a DNS problem, and even if they do, they may not know to 
contact ISC or to join this mailing list.


this is one of the few areas in which i agree with the robustness 
principle. what you're not seeing doesn't matter nearly as much as what 
the people you're not seeing may have coded by looking only at the spec.


at some time when we know how and why to increment the EDNS version 
number we should start using NOTAUTH. until then we should be using 
SERVFAIL. and we should document the need to cache SERVFAILs.


REFUSED has a well understood purpose when RD=1 and the server has an 
ACL, which may mean a mixed-mode server has an "allow-query-cache" ACL. 
let us please not treat that as a reason to repurpose REFUSED when RD=0.


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Evan Hunt]

On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote:
> while specific guidance was not given as to resolver action in response 
> to each possible authority RCODE, i have both witnessed and implemented 
> full resolvers which treated REFUSED as a permanent failure whereas 
> SERVFAIL was a temporary failure.

What do you mean by "permanent" in this context?

As far as I know, BIND treats REFUSED as persistent during the resolution
process -- i.e., it won't bother to retry the same server with the same
query immediately.  It would go to the next delegated name server, and if
all servers refused, eventually it would return SERVFAIL to the client.

It might add the address to a bad server cache; I'm not actually sure
whether it does that in this scenario, I'd have to check.  If it does, that
would keep it from retrying the server for 30 minutes, which is a
reasonable recovery time for the "haven't caught up with my inbox"
class of error.

> treating "i don't have the zone configured" as a REFUSED condition, 
> while treating "i can't write the secondary zone" or "i can't read the 
> primary zone" as SERVFAIL conditions, adds no value, but does subtract 
> it.

I'm not seeing the value subtracted.  In those two cases, your server knows
that it's *supposed* to be authoritative for the zone in question, and that
there's a problem preventing it from answering.  This fits the definition
of SERVFAIL, "unable to process this query due to a problem with the name
server", and the other case doesn't.

> usually when i don't have a zone configured that is delegated to me, 
> it's because i have not caught up with my inbox, or i have FUBAR'd my 
> configuration file using "git" or similar. in those cases, the name 
> being looked up _might exist_ and retrying later _might succeed_.

Or, very likely, the parent zone is misconfigured or out of date, in which
case the name doesn't exist and retrying later won't sucseed.  Perhaps you
run a secondary name service and your customer hasn't paid the bill, or
they're in the process of switching to a new provider, or they just put in
the wrong glue.  Your server isn't failing; it's just being asked for a
name it never heard of.

> i have heard a number of folks argue that this logic is common, but i 
> have heard noone argue that it is superior to known alternatives. can we 
> hear someone who is in favour of this for reasons beyond "five million 
> frenchmen cannot be wrong"?

I wish NOTAUTH had been defined in 1035. Since it wasn't, there are only
three answers that make any sense: NOERROR with upward referral, SERVFAIL,
REFUSED.  We already disposed of upward referral.  SERVFAIL gets you
spurious retries.  REFUSED makes the querant go away for a sensible amount
of time; we have ten years of operational experience with it.  I don't see
the problem.

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

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Andrew Sullivan wrote:

Hi,

On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote:

If I ask the authoritative server for example.com about a name
label.example.net, in a graph-theoretic sense the NS RRset for the
root zone is clearly closer to label.example.net than anything else I
can give.

dns is not that kind of graph.

...


Obviously.  But your example is still on the current tree, just not
immediately below.  The example I gave is in a completely different
section of the tree, and my point is that none of the text you quoted
shows why "." isn't the "closer server" that an authoritative server
somewhere beneath com. can give in response to a qname that is
somewhere beneath net.  We might think today that is a misfeature in
STD13, but I don't think it's a misinterpretation of what STD13 says.
I don't know what kind of graph would make that false.


actually, i had misread you (com vs net). i apologize. let me re-answer.

there is no reason for an authority server to know who the root name 
servers are. so, there can be no expectation that it would know any 
"closer" name server set than the one at its zone bottom.


since RFC 1034 talks about zone bottoms, and "closest enclosing", and 
its algorithm speaks specifically of a referral being generated by 
copying non-authoritative NS RRs from the zone bottom into the answer, 
there is no reasonable interpretation of "closer" other than an NS RRset 
which is closer, along the path from the zone apex to the qname, than 
the zone apex was. in fact, from that algorithm, there is no way to 
generate a referral other than by copying along-the-path data into an 
answer.


any attempt to interpret "closer" in an off-the-path way is a clear 
misinterpretation of RFC 1034. we are only on "the current tree" here.



as i wrote during the SOPA wars, REFUSED has been widely used as an
administrative denial, and repurposing it would not be effective at this
late date.


This, too, seems to be a claim that is at best poorly justified.  It
might be that it is how BIND interprets the RCODE, but it's not what
it is defined to be.


it's defined as "administrative denial" not merely "widely interpreted 
as administrative denial" as i wrote above.



... I'm anyway not sure your description in the circleid piece (or
elsewhere) is inconsistent with the RFC 1035 definition of RCODE 5:
"The name server refuses to perform the specified operation for
policy reasons."  Refusing to respond to this or that IP address is a
policy, and refusing to perform upwardreferrals is also a policy, no?


"no." the client isn't asking for an upward referral, it's asking for an 
answer, and is expecting either an answer (positive or negative or 
empty) or an on-the-path referral copied from the non-authoritative data 
at the bottom of the authority zone. it is not expecting its query to be 
interpreted as a request for an upward referral, so, it cannot treat 
REFUSED as an administrative denial of that upward referral.


the rest of the text of the definition of REFUSED makes this clearer:

>


the word "particular" appears four times.

as witnessed in discussions of the u.s. constitutions and the christian 
bible, arguments about the literal intent of the authors are interesting 
mostly to scholars, whereas our concern should be with the actions taken 
by the far end given the data pattern we transmit and the circumstances 
as we know them.


while specific guidance was not given as to resolver action in response 
to each possible authority RCODE, i have both witnessed and implemented 
full resolvers which treated REFUSED as a permanent failure whereas 
SERVFAIL was a temporary failure. that is, receipt of a REFUSED from any 
authority consulted during iteration would cause a final error code 
(assuming no other authority gave a more useful answer) of NO_RECOVERY, 
whereas if only timeouts and SERVFAILs were heard, the final error code 
would be TRY_AGAIN. (these are BSD h_errno values, but modern API's have 
equivalents.)


---

treating "i don't have the zone configured" as a REFUSED condition, 
while treating "i can't write the secondary zone" or "i can't read the 
primary zone" as SERVFAIL conditions, adds no value, but does subtract 
it. usually when i don't have a zone configured that is delegated to me, 
it's because i have not caught up with my inbox, or i have FUBAR'd my 
configuration file using "git" or similar. in those cases, the name 
being looked up _might exist_ and retrying later _might succeed_.


i have heard a number of folks argue that this logic is common, but i 
have heard noone argue that it is superior to known alternatives. can we 
hear someone who is in favour of this for reasons beyond "five million 
frenchmen cannot be wrong"?


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi,

On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote:
> > If I ask the authoritative server for example.com about a name
> > label.example.net, in a graph-theoretic sense the NS RRset for the
> > root zone is clearly closer to label.example.net than anything else I
> > can give.
> 
> dns is not that kind of graph.
> 
> if the qname is acetes.pa.dec.com and the query is being processed by the
> dec.com authority server who knows that pa.dec.com is a delegation, then
> pa.dec.com is closer to acetes.pa.dec.com than the root would be.

Obviously.  But your example is still on the current tree, just not
immediately below.  The example I gave is in a completely different
section of the tree, and my point is that none of the text you quoted
shows why "." isn't the "closer server" that an authoritative server
somewhere beneath com. can give in response to a qname that is
somewhere beneath net.  We might think today that is a misfeature in
STD13, but I don't think it's a misinterpretation of what STD13 says.
I don't know what kind of graph would make that false.

> as i wrote during the SOPA wars, REFUSED has been widely used as an
> administrative denial, and repurposing it would not be effective at this
> late date.

This, too, seems to be a claim that is at best poorly justified.  It
might be that it is how BIND interprets the RCODE, but it's not what
it is defined to be. I'm anyway not sure your description in the
circleid piece (or elsewhere) is inconsistent with the RFC 1035
definition of RCODE 5: "The name server refuses to perform the
specified operation for policy reasons."  Refusing to respond to this
or that IP address is a policy, and refusing to perform upward
referrals is also a policy, no?

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Robert Edmonds wrote:

Paul Vixie wrote:

the implication of REFUSED is that if someone else asked this question, we
might be able to answer. so if BIND is doing what you say, it's wrong.


In theory, any authoritative nameserver could secretly also be a
resolver that will answer from cache if the right client sends it the
same question. Does that make it OK, then?


no, because it can, should, and probably will have different responses 
and different reasons for those responses based on the query's RD value.


in this sense, we (i was at ISC when it happened) got 
"allow-query-cache" almost precisely wrong. with what confusion, you can 
now witness.



The REFUSED RCODE is documented as:

 Refused - The name server refuses to perform the specified operation
 for policy reasons.  For example, a name server may not wish to
 provide the information to the particular requester, or a name
 server may not wish to perform a particular operation (e.g., zone
 transfer) for particular data.

In this case the server's policy would be that it doesn't perform a
particular operation (i.e., QUERY) for particular data (i.e., data that
it's not authoritative for).


if the reason were due to something about the specified operation such 
as the RD bit (like, it's 1 when it has to be 0) then i'd follow your 
reasoning here.



Where does the implication that REFUSED is only appropriate if the
server might be able to answer if "someone else" asks the question come
from?


first, the example, "provide the information to the particular 
requester". as in, some other requester might get a non-REFUSED answer.


second, the example, "zone transfer". when i added my very first BIND4 
feature it was "allow-xfer" and i did indeed return REFUSED when asked 
by someone who wasn't allowed. this also happens on TSIG failures today.


third, the differences and distinctions in initiator behaviour. there is 
no difference in desired or expected initiator behaviour between "i am 
out of disk space and can't write a secondary zone file, so while i am 
configured to be a secondary server for this zone, i can't do it", vs. 
"i am configured to be a primary server for this zone but there is no 
zone file so i can't do it", vs. "i am not configured to be a server for 
this zone and either RA=0 or RD=0 or both".


in all three cases, we want the initiator to cache our inability to 
satisfy it so as not to melt the tubez with repeated (doomed) requests, 
try other name servers (but not other addresses for this name server), 
and retry here later (after, say, ten minutes) in case the situation 
improves. the only hoped-for reason i can imagine for sending SERVFAIL 
in the first two cases and REFUSED in the last case is to control the 
logging on the initiator -- expecting the sysadmin to behave differently 
when cleaning up the resulting mess.


using REFUSED vs. SERVFAIL in this case is a distinction without a 
difference, and a costly one, because REFUSED actually has a different 
intended reaction in the initiator than SERVFAIL. but i've covered that 
in the archives (several times) and won't repeat it again here.


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Evan Hunt]

On Mon, Nov 13, 2017 at 11:12:52AM -0800, Matthew Pounsett wrote:
> I haven't got the time this morning to search release notes, but I'm fairly
> sure that in 2012, when you wrote that article, current versions of BIND
> were already handing out REFUSED to indicate "I'm not authoritative for
> that."  At the very least it began doing that not long after.

That became the default behavior in 9.4.2 in Nov 2007. (It was documented
in 9.4.0 in Feb 2007, but there was a bug in how the default setting was
applied.)

The relevant change was the addition of the allow-query-cache ACL. The
REFUSED rcode in this case doesn't mean "I'm not authoritative", it
means "you're not allowed to look in my cache to see the root referral
I would've sent otherwise".

It'd be nice if we could use NOTAUTH for this, but that rcode didn't
exist when the spec was written.  REFUSED isn't an exact fit, but it's
legal, sensible in context, and gets the job done.

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

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

Re: [DNSOP] Clarifying referrals (#35)

[Robert Edmonds]

Paul Vixie wrote:
> Matthew Pounsett wrote:
> > I haven't got the time this morning to search release notes, but I'm
> > fairly sure that in 2012, when you wrote that article, current versions
> > of BIND were already handing out REFUSED to indicate "I'm not
> > authoritative for that."  At the very least it began doing that not long
> > after.
> 
> the implication of REFUSED is that if someone else asked this question, we
> might be able to answer. so if BIND is doing what you say, it's wrong.

In theory, any authoritative nameserver could secretly also be a
resolver that will answer from cache if the right client sends it the
same question. Does that make it OK, then?

The REFUSED RCODE is documented as:

Refused - The name server refuses to perform the specified operation
for policy reasons.  For example, a name server may not wish to
provide the information to the particular requester, or a name
server may not wish to perform a particular operation (e.g., zone
transfer) for particular data.

In this case the server's policy would be that it doesn't perform a
particular operation (i.e., QUERY) for particular data (i.e., data that
it's not authoritative for).

Where does the implication that REFUSED is only appropriate if the
server might be able to answer if "someone else" asks the question come
from?

-- 
Robert Edmonds

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Matthew Pounsett wrote:

... I have seen no similar discussion of REFUSED-generated chaos in
recursive servers.   If someone is seeing such brokenness, they
haven't brought it to dnsop@, or dns-operations@, or an OARC or NANOG
meeting.  If someone is seeing such brokenness, hopefully they'll
speak up so that we can advise the authoritative
implementations to change their behaviour again.


are you sure they'd be here listening, and that they would even 
understand the errors they are experiencing and connect those errors to 
this protocol change?



... but it does seem to be the consensus among the
authoritative implementors that REFUSED is the correct response.


are you sure they aren't just copying BIND's behaviour? do you remember 
when BIND only included one RR per message in outbound AXFR, and that 
there were some AXFR initiators that depended on this behaviour since 
they had never witnessed any other behaviour and hadn't read the spec?


and how do you know about that consensus -- or do you mean a consensus 
among those present on this mailing list who have chosen to speak up?



... It wouldn't be the first time that a majority of implementations
settled on a behaviour that didn't strictly follow the specification
because it was necessary for good inter-operation.


i have seen no discussion, here or anywhere else, about necessity, or 
good interoperation, regarding this apparent departure from the spec. 
can you include a URI where i can study further? in other words, who 
argues for this, and on what basis?


when we change a protocol on an existing signal path, we have a burden 
of do-no-harm to existing implementations who will never be changed. 
this burden is even higher when re-purposing existing signalling. if 
it's possible to have interpreted the old signal in some way, then we 
have to treat our change as "bearing a cost".



... Perhaps someone who was present for an implementer's internal
discussion about replacing upward referrals could comment on the
reasoning, and what (if any) collaboration occurred between the
authoritative and recursive implementations at the time.


i'd hope to see not only this, but someone currently participating in 
this discussion who can explain why an upward referral is a good signal. 
no query initiator should follow such a referral, but some may, which 
i'd view as a calamity. if the goal is some initiator reaction that is 
not what they would do if they heard SERVFAIL, then what is that goal?


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Matthew Pounsett]

On 13 November 2017 at 11:28, Paul Vixie  wrote:

>
> ... If that were a problem, given BIND's market share, we should be
>>
> seeing widespread brokenness, but I don't think we are–none that's
>> making it from my support department to me or to our hostmaster@
>> accounts, at any rate.
>>
>
> yikes! you remind me of the guy who said on nanog a few years back that
> since he wasn't seeing spoofed-source ddos attacks any more, we should all
> stop worrying about them.
>

your lived experience can be cause for concern, but never for complacency.


I don't think that word means what you think it means.  Lack of concern for
a non-problem is not complacency.

The rest of us still see spoofed-source DDoS attacks, and they're a
frequent topic of discussion in the networking and DNS communities, so even
someone who doesn't see them on their network should still be aware that
they happen.  I have seen no similar discussion of REFUSED-generated chaos
in recursive servers.   If someone is seeing such brokenness, they haven't
brought it to dnsop@, or dns-operations@, or an OARC or NANOG meeting.  If
someone is seeing such brokenness, hopefully they'll speak up so that we
can advise the authoritative implementations to change their behaviour
again.

I use the plural there deliberately.  I referenced BIND above because that
was the implementation I was most familiar with at the time the behaviour
changed ... but it does seem to be the consensus among the authoritative
implementors that REFUSED is the correct response.  It wouldn't be the
first time that a majority of implementations settled on a behaviour that
didn't strictly follow the specification because it was necessary for good
inter-operation.Perhaps someone who was present for an implementer's
internal discussion about replacing upward referrals could comment on the
reasoning, and what (if any) collaboration occurred between the
authoritative and recursive implementations at the time.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Matthew Pounsett wrote:



On 13 November 2017 at 10:55, Paul Vixie > wrote:

> why is this nor a broken configuration?


It's my understanding that SERVFAIL indicates that the server sending
the RCODE–or in the case of a recursive response, the upstream
authoritative server–has a broken configuration.  I don't believe
SERVFAIL indicates "you followed a lame delegation."  As far as I'm
aware, we don't have a clearly defined signal for that, which is why
many implementations chose to use REFUSED in that case.


someone asking you an RD=0 question about a zone you're not 
authoritative for indicates a misconfiguration somewhere. this is what 
SERVFAIL is for, because at the signalling level, it tells the client 
that no possible query about that name can succeed, and it ought to stop 
sending questions like that to this server. it's no different in 
principle from "i'm out of disk space, so i can't fetch the zone, so 
even though i'm supposed to be a secondary, i can't do it right now."



> http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/

I haven't got the time this morning to search release notes, but I'm
fairly sure that in 2012, when you wrote that article, current versions
of BIND were already handing out REFUSED to indicate "I'm not
authoritative for that."  At the very least it began doing that not long
after.


the implication of REFUSED is that if someone else asked this question, 
we might be able to answer. so if BIND is doing what you say, it's wrong.



... If that were a problem, given BIND's market share, we should be
seeing widespread brokenness, but I don't think we are–none that's
making it from my support department to me or to our hostmaster@
accounts, at any rate.


yikes! you remind me of the guy who said on nanog a few years back that 
since he wasn't seeing spoofed-source ddos attacks any more, we should 
all stop worrying about them.


your lived experience can be cause for concern, but never for complacency.

--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Matthew Pounsett]

On 13 November 2017 at 10:55, Paul Vixie  wrote:

>
>
> Matthew Pounsett wrote:
>
>>
>>
>> On 13 November 2017 at 06:52, John Kristoff > > wrote:
>>
>> REFUSED does not seem ideal to me either, but what if anything might
>> be
>> better is probably ripe discussion in a new draft.
>>
>> It makes perfect sense to me.  REFUSED is an indication that the querier
>> has been blocked from asking that question (or receiving the answer they
>> requested) by configuration, as distinct from a broken configuration
>> preventing them from getting that answer (SERVFAIL).
>>
>
> why is this nor a broken configuration?
>

It's my understanding that SERVFAIL indicates that the server sending the
RCODE–or in the case of a recursive response, the upstream authoritative
server–has a broken configuration.  I don't believe SERVFAIL indicates "you
followed a lame delegation."  As far as I'm aware, we don't have a clearly
defined signal for that, which is why many implementations chose to use
REFUSED in that case.


>
> ... Given that upward
>> referrals have obvious problems (There is no protocol or process to tell
>> a TLD operator "I am not authoritative for that delegation someone else
>> asked you to point at me") it seems to me that REFUSED is the only
>> obvious choice for indicating that an authoritative-only server is not
>> authoritative for anything at or below the QNAME.
>>
>
> i strongly disagree. this is not an administrative denial scenario. see,
> again:
>
>
> http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/
>
>
I haven't got the time this morning to search release notes, but I'm fairly
sure that in 2012, when you wrote that article, current versions of BIND
were already handing out REFUSED to indicate "I'm not authoritative for
that."  At the very least it began doing that not long after.   If that
were a problem, given BIND's market share, we should be seeing widespread
brokenness, but I don't think we are–none that's making it from my support
department to me or to our hostmaster@ accounts, at any rate.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Matthew Pounsett wrote:



On 13 November 2017 at 06:52, John Kristoff > wrote:

REFUSED does not seem ideal to me either, but what if anything might be
better is probably ripe discussion in a new draft.

It makes perfect sense to me.  REFUSED is an indication that the querier
has been blocked from asking that question (or receiving the answer they
requested) by configuration, as distinct from a broken configuration
preventing them from getting that answer (SERVFAIL).


why is this nor a broken configuration?


... Given that upward
referrals have obvious problems (There is no protocol or process to tell
a TLD operator "I am not authoritative for that delegation someone else
asked you to point at me") it seems to me that REFUSED is the only
obvious choice for indicating that an authoritative-only server is not
authoritative for anything at or below the QNAME.


i strongly disagree. this is not an administrative denial scenario. see, 
again:


http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/

--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

John Kristoff wrote:

...

Paul, are you willing and able to work on a draft for this?  For what
it's worth I'd be supportive of that work.


my drafting skills seem to be gone. nothing i've written in the last ten 
years was adopted. i think it would be better for me to review and to 
provide text, than to be named as an author or even co-author.


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Andrew Sullivan wrote:

Hi,

This is quite a helpful response, thanks.  I wonder whether more of it
ought to go in discussion (or a new draft), however.


i probably should not be involved in a new draft other than as a 
reviewer. (consider the fate of resimprove.)



For I'm struck
by this:

On Sun, Nov 12, 2017 at 06:42:18PM -0800, Paul Vixie wrote:

always be generated using only local data, and either contains the
answer to the question or a referral to other name servers "closer" to
the desired information.

the operative phrase is '"closer" to'. this is repeated in 4.3.1:


If I ask the authoritative server for example.com about a name
label.example.net, in a graph-theoretic sense the NS RRset for the
root zone is clearly closer to label.example.net than anything else I
can give.


dns is not that kind of graph.

if the qname is acetes.pa.dec.com and the query is being processed by 
the dec.com authority server who knows that pa.dec.com is a delegation, 
then pa.dec.com is closer to acetes.pa.dec.com than the root would be.



The current approaches that people have for this are either NODATA
responses and REFUSED.  Only the latter seems obviously consistent
with the text, though I'm aware that there's controversy over using
REFUSED here.


as i wrote during the SOPA wars, REFUSED has been widely used as an 
administrative denial, and repurposing it would not be effective at this 
late date.


see:

http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/

--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[John Kristoff]

On Mon, 13 Nov 2017 03:26:41 +
Andrew Sullivan  wrote:

> This is quite a helpful response, thanks.  I wonder whether more of it
> ought to go in discussion (or a new draft),

I'd suggest a new draft be produced with which discussion could ensue.
The references Paul cites would not be clear to me that closer excludes
pointing up towards the root for instance. In fact, I would have thought
this is precisely what closer would mean from a pure graph/routing
perspective in certain scenarios.

REFUSED does not seem ideal to me either, but what if anything might be
better is probably ripe discussion in a new draft.

Paul, are you willing and able to work on a draft for this?  For what
it's worth I'd be supportive of that work.

John

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi,

This is quite a helpful response, thanks.  I wonder whether more of it
ought to go in discussion (or a new draft), however.  For I'm struck
by this:

On Sun, Nov 12, 2017 at 06:42:18PM -0800, Paul Vixie wrote:
> > always be generated using only local data, and either contains the
> > answer to the question or a referral to other name servers "closer" to
> > the desired information.
> 
> the operative phrase is '"closer" to'. this is repeated in 4.3.1:

If I ask the authoritative server for example.com about a name
label.example.net, in a graph-theoretic sense the NS RRset for the
root zone is clearly closer to label.example.net than anything else I
can give.  So the upward referral doesn't seem prohibited by this at
all; on the contrary, it seems like a requirement.  Maybe I need to
read this again with better glasses.

The current approaches that people have for this are either NODATA
responses and REFUSED.  Only the latter seems obviously consistent
with the text, though I'm aware that there's controversy over using
REFUSED here.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Andrew Sullivan wrote:

...

we should note that an upward or sideways or other non-downward referral is
a sign of misconfiguration and must be treated as SERVFAIL.


I am a little uncomfortable with using this document to specify
protocol behaviour as opposed to specifying protocol behaviour already
specified elsewhere.  I may have missed them, but I am not sure either
of these requirements (musts) are stated so baldly in any RFC.  Have I
missed something?


when i stupidly introduced the idea of upward referrals while evidently 
hallucinating on crack cocaine back in the mid 1990's, the section of 
RFC 1034 that somebody should have printed, rolled up, and smacked me 
with was 4.1:



4.1. Introduction

Name servers are the repositories of information that make up the domain
database.  The database is divided up into sections called zones, which
are distributed among the name servers.  While name servers can have
several optional functions and sources of data, the essential task of a
name server is to answer queries using data in its zones.  By design,
name servers can answer queries in a simple manner; the response can
always be generated using only local data, and either contains the
answer to the question or a referral to other name servers "closer" to
the desired information.


the operative phrase is '"closer" to'. this is repeated in 4.3.1:


4.3.1. Queries and responses

The principal activity of name servers is to answer standard queries.
Both the query and its response are carried in a standard message format
which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
and QNAME, which describe the types and classes of desired information
and the name of interest.

The way that the name server answers the query depends upon whether it
is operating in recursive mode or not:

   - The simplest mode for the server is non-recursive, since it
 can answer queries using only local information: the response
 contains an error, the answer, or a referral to some other
 server "closer" to the answer.  All name servers must
 implement non-recursive queries.


here again we see '"closer" to' as the allowed behaviour. of course, we 
also see that Unbound, and BIND with "recursion no;", are out-of-spec. 
so there's evidently a lot of fuzz here. that's why i'd love to see your 
current "clarifying referrals" document reference RFC 1034 4.1 and 4.3.1 
and somehow reinforce that this wasn't a part of the spec that folks can 
just ignore, even though many have and others probably will.


in [ibid], this is reinforced a third time:


If recursive service is not requested or is not available, the non-
recursive response will be one of the following:

   - An authoritative name error indicating that the name does not
 exist.

   - A temporary error indication.

   - Some combination of:

 RRs that answer the question, together with an indication
 whether the data comes from a zone or is cached.

 A referral to name servers which have zones which are closer
 ancestors to the name than the server sending the reply.

   - RRs that the name server thinks will prove useful to the
 requester.


this time the phrase is "closer ancestors" which is even clearer than 
'"closer" to' as used earlier in the document. and then in 4.3.2 we see:



 b. If a match would take us out of the authoritative data,
we have a referral.  This happens when we encounter a
node with NS RRs marking cuts along the bottom of a
zone.


here, some inclarity is introduced by implication, since in what we now 
call a "mixed mode" name server, indirect descendant information may be 
present, and at least one name server whose innards i'm aware of would 
send a cached referral. also if a name server is authoritative for two 
zones, one the parent of the other, then when it receives a query it 
will not know which zone the iterative resolver client thinks it is "in" 
and will send the "closest" answer which may hide the parent's 
delegation to the child, effectively gluing two zones into one. i don't 
think you'll want to bite off all that in this document, but i want to 
reintroduce this problem to the e-mail archives since the last time it 
was spoken of was on the namedroppers list in the early 1990's. ("unix 
mount point" semantics are a steep climb, but the only way out.)


importantly however, the time when the algorithm described in [ibid] is 
allowed to send a referral is when a match would "take us out of the 
authoritative data", and the referral contents are copied from the 
non-authoriative NS RRset at the bottom of the zone we were searching. 
so, further evidence that upward or sideways referrals are off-spec.


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi,

On Sun, Nov 12, 2017 at 06:04:06PM -0800, Paul Vixie wrote:
> 
> they must be ignored, because they could constitute part of a referral loop.
> valid referrals are to descendants not ancestors or cousins.

[…]

> we should note that an upward or sideways or other non-downward referral is
> a sign of misconfiguration and must be treated as SERVFAIL.

I am a little uncomfortable with using this document to specify
protocol behaviour as opposed to specifying protocol behaviour already
specified elsewhere.  I may have missed them, but I am not sure either
of these requirements (musts) are stated so baldly in any RFC.  Have I
missed something?

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Andrew Sullivan wrote:

On Sun, Nov 12, 2017 at 09:18:31PM +0800, Stephane Bortzmeyer wrote:

This is an upward referral and I tought it was frowned upon since the
ISPrime attack (MUST NOT?  SHOULD NOT?)



I tend to agree, but it's certainly something that's around.  Should
we note that clients sometimes ignore such references?


they must be ignored, because they could constitute part of a referral 
loop. valid referrals are to descendants not ancestors or cousins.



Should we note
that servers often do not return these, though they used to commonly?


we should note that an upward or sideways or other non-downward referral 
is a sign of misconfiguration and must be treated as SERVFAIL.


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

On Sun, Nov 12, 2017 at 09:18:31PM +0800, Stephane Bortzmeyer wrote:
> This is an upward referral and I tought it was frowned upon since the
> ISPrime attack (MUST NOT?  SHOULD NOT?)
> 

I tend to agree, but it's certainly something that's around.  Should
we note that clients sometimes ignore such references?  Should we note
that servers often do not return these, though they used to commonly?

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Stephane Bortzmeyer wrote:

On Sun, Nov 12, 2017 at 02:54:46AM -0500,
  Andrew Sullivan  wrote
  a message of 74 lines which said:


The second is a non-delegation referral (sometimes described as
"referral response", as distinct from the delegation response
above), where the server is not authoritative for any portion of the
QNAME.  In this case, the referred-to zone in the Authority section
is usually[1] the root zone (.).


This is an upward referral and I tought it was frowned upon since the
ISPrime attack (MUST NOT?  SHOULD NOT?)


it is frowned upon, but the strongest we can do is SHOULD NOT, since 
current implementations do it, and other current implementations must 
expect it.


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Stephane Bortzmeyer]

On Sun, Nov 12, 2017 at 02:54:46AM -0500,
 Andrew Sullivan  wrote 
 a message of 74 lines which said:

> The second is a non-delegation referral (sometimes described as
> "referral response", as distinct from the delegation response
> above), where the server is not authoritative for any portion of the
> QNAME.  In this case, the referred-to zone in the Authority section
> is usually[1] the root zone (.).

This is an upward referral and I tought it was frowned upon since the
ISPrime attack (MUST NOT?  SHOULD NOT?)


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

[DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Dear colleagues,

In github tracker issue #35
(https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/35),
we have an item about the way Referral is defined in RFC 7719.  The
issue mostly comes from the (as usual incisive) observations of Tony
Finch.  I think he's right.

I think a change is in order, but I'm not fully convinced of the
following text, so that's why I'm putting it here for discussion.  My
co-editors do not deserve the brickbats, so fling them at me.  There
are questions at the end of this proposed text, because there are two
issues about which I am very much in doubt and I'm too lazy to
convince myself of the right answer when I can just ask everyone.

---%<---cut here---

Referral: A type of response in which a server, signalling that it is
not authoritative for an answer, provides the querying resolver with
an alternative place to send its query.

All referral responses follow the same form.  The response has the AA
bit cleared.  It has an empty Answer section.  It has an Authority
section containing an RRset in which the owner name is the referred-to
zone, the class is the queried class, the type is NS, and the RDATA
holds the nameservers for the referred-to owner name as known by the
responding server.  The response might also have an Additonal section
containing glue records.

There are two types of referral response.  The first is a delegation
referral (sometimes described as "delegation response"), where the
server is authoritative for some portion of the QNAME.  The Authority
section RRset's RDATA contains the name servers specified at the zone
cut.  In normal DNS operation, this kind of response is required in
order to find names beneath a delegation.

The second is a non-delegation referral (sometimes described as
"referral response", as distinct from the delegation response above),
where the server is not authoritative for any portion of the QNAME.
In this case, the referred-to zone in the Authority section is
usually[1] the root zone (.).  In normal DNS operation, this kind of
response is not strictly speaking required to work, and in practice
some authoritative server operators will not return referral responses
beyond those required for delegation.

---cut here--->%---

First, on [1], it seems to me that in principle it ought to be
possible for this sort of referral to refer to something other than
. , but I can't come up with an example where it happens or really
ought to happen.  Is this case actually necessarily a referral to the
root?  (In that case, also, the name of this type should be "root
referral", I guess?)

Second, is there any circumstance in which glue in a non-delegation
referral ought not to be treated as possible poison, and just thrown
away?  It seems to me that a root referral ought automatically to
cause the resolver to go to the results of a priming query and follow
that chain.  No?  Also, maybe that's not a terminological issue, and
so it ought to be left out of the document anyway.  In any case, I
seek guidance from the WG.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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