Subject: [DNSOP] Clarifying referrals (#35)

From: Andrew Sullivan <[email-masked]>
Date: Sun, 12 Nov 2017 02:54:46 -0500

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
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 12 Nov 2017 21:18:31 +0800

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

> "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?)
<https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful>

---

From: Paul Vixie <[email-masked]>
Date: Sun, 12 Nov 2017 09:20:37 -0800

Stephane Bortzmeyer wrote:
>   Andrew Sullivan<[email-masked]>  wrote

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

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 12 Nov 2017 20:44:46 -0500

> <https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful>

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
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sun, 12 Nov 2017 18:04:06 -0800

Andrew Sullivan wrote:
> 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

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

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 12 Nov 2017 21:07:37 -0500

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
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sun, 12 Nov 2017 18:42:18 -0800

Andrew Sullivan wrote:
> ...

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

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 12 Nov 2017 22:26:41 -0500

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:

> 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
[email-masked]

---

From: John Kristoff <[email-masked]>
Date: Mon, 13 Nov 2017 08:52:35 -0600

On Mon, 13 Nov 2017 03:26:41 +0000
Andrew Sullivan <[email-masked]> wrote:

> 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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Nov 2017 14:53:38 +0000

At the tail of this thread, I'll add my (random) thoughts.

1) Upward referrals are an example of something that started out as a good idea, good intention, but ran into operational problems as the DNS setting changed.  Early, in the late 90's, a popular DNS implementation would chase an upward referral meant to indicate a lame delegation, resulting in an infinite loop in iteration.  (Better coding stopped that.  See also ARIN Policy [proposal] 2002-01 as an artifact of that time.)  Later, upward referrals were seen as a tool in building a flood attack, which is what cause implementations to stop using them as lame delegation notices.

2) I learned this long ago (while implementing ancient DNSSEC code) - the DNS tree is inherently unidirectional.  A parent knows about its children and not vice versa.  DNSSEC wanted to have arbitrary security chains but had to settle for on-tree ("Domain Name System Security (DNSSEC) Signing Authority" aka RFC 3008).  The same issue came into play when trying to design the "Automating DNSSEC Delegation Trust Maintenance" - related to scaling (the parent has to poll the children, not the other way around).  (In "Detecting a Changed CDS/CDNSKEY", the parent either polls or has to have something out-of-DNS-band: " The delegation user interface has a button".)

I.e., trying to see referrals as going anyway but down is an uphill battle.

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Nov 2017 15:19:23 +0000

Edward Lewis <[email-masked]> wrote:
>
> The same issue came into play when trying to design the "Automating
> DNSSEC Delegation Trust Maintenance" - related to scaling (the parent
> has to poll the children, not the other way around).  (In "Detecting a
> Changed CDS/CDNSKEY", the parent either polls or has to have something
> out-of-DNS-band: " The delegation user interface has a button".)

Funny you should mention that - I have been thinking about it. One of the
most common reactions I have seen to RFC 7344 is the scaling issue (though
you need to be over a million signed delegations before it gets seriously
problematic, I guess).

It seems to me that a reasonable in-band mechanism would be to send a
NOTIFY to the parental agent. I can only find a little discussion of this
idea in 2014, and it wasn't very enthusiastic - there were questions like,
how do you know where to send the NOTIFY? On the other hand there are
similar questions about how you would make an out-of-band request.

(From my point of view, adding some also-notify configurations would be a
lot easier than implementing draft-latour-dnsoperator-to-rrr-protocol!)

Dunno if this is worth pursuing ...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Fitzroy: Northeasterly 4 or 5, occasionally 6 in east. Moderate or
rough. Fair. Good.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 08:14:14 -0800

Andrew Sullivan wrote:
> 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
> 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.

> with the text, though I'm aware that there's controversy over using

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 08:28:12 -0800

> 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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 13 Nov 2017 18:30:04 +0000

> similar questions about how you would make an out-of-band request.

Mark's idea to push updates to the parent instead of relying on polling
used a SRV query to identify the correct recipient of an UPDATE:

https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04

The same trick could be used to find the right NOTIFY target.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 13 Nov 2017 10:37:22 -0800

On 13 November 2017 at 06:52, John Kristoff <[email-masked]> wrote:

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Nov 2017 18:45:42 +0000

On 11/13/17, 13:30, "DNSOP on behalf of Evan Hunt" <[email-masked] on behalf of [email-masked]> wrote:

>Mark's idea to push updates to the parent instead of relying on polling used a SRV query to identify the correct recipient of an UPDATE:
>
>    ...draft-andrews-dnsop-update-parent-zones-04...
 
This would mean then signing all the SRV sets, so I assume to preserve the benefits of "OPTOUT", you'd want these only for the names that had DS sets.  For the others, I assume either no answer or the wildcard ... in the TLD.  (That latter thought might be unsettling to some people.)  What I mean is that there is still a scaling problem, in some dimension, to deal with because the DNS is inherently a "down-only" tree.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 10:53:20 -0800

> The same trick could be used to find the right NOTIFY target.

+1.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 10:55:34 -0800

Matthew Pounsett wrote:
>
>
> On 13 November 2017 at 06:52, John Kristoff <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> 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:

-- 
P Vixie

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 13 Nov 2017 11:12:52 -0800

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

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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 11:28:43 -0800

Matthew Pounsett wrote:
>
>
> On 13 November 2017 at 10:55, Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> 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."

> 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

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 13 Nov 2017 11:59:35 -0800

On 13 November 2017 at 11:28, Paul Vixie <[email-masked]> wrote:

> since he wasn't seeing spoofed-source ddos attacks any more, we should all
> stop worrying about them.
>

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.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 12:14:47 -0800

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

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

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 13 Nov 2017 15:20:20 -0500

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?

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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 13 Nov 2017 21:19:41 +0000

On Mon, Nov 13, 2017 at 11:12:52AM -0800, Matthew Pounsett wrote:
> 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.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Nov 2017 09:16:43 +1100

> On 14 Nov 2017, at 5:45 am, Edward Lewis <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

That part of the namespace doesn’t require signing as the UPDATES themselves are signed
and can be easily split off as a separate zone.  The worst that  would happen is that the
UPDATE request would be blocked if a spoofed response was accepted.  Using servers
that relay the UPDATE request (which is what slave zones do today for UPDATE) only
requires a single SRV record.

Even if the SRV records are all signed and the registry doesn’t run a UPDATE relay there
still isn’t a scaling issue.  It is possible to serve COM with every delegation being a secure
delegation even though we don’t do it today.  At worst this creates a zone of slightly smaller
size.  Add to that there would be a ramp up process as registrars come online supporting
this method.

Remember the draft was designed to handle ALL record updates to the parent zone
after being approved by the registrar in a unified manner.  NS, DS, A, DNAME, AAAA, TXT,
CNAME, etc. This isn’t restricted to DS records.  

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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 13 Nov 2017 23:37:56 +0000

On Tue, Nov 14, 2017 at 09:16:43AM +1100, Mark Andrews wrote:
> Remember the draft was designed to handle ALL record updates to the
> parent zone after being approved by the registrar in a unified manner.
> NS, DS, A, DNAME, AAAA, TXT, CNAME, etc. This isn’t restricted to DS
> records.  

In the present context, I was only suggesting this method be used for
NOTIFY, not UPDATE -- to signal the parent that it should poll the child
for CDS/CDNSKEY.  (I guess CSYNC could be included in the mix as well,
though, for updating NS and glue.)

I would suggest the child should be polled periodically regardless. If
the SRV record were spoofed, causing the child to send a NOTIFY to the
wrong address, synchronization should still occur, just not as quickly.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Nov 2017 20:49:06 -0500

> I'd suggest a new draft be produced with which discussion could ensue.

Given the discussion that ensued only here, it's pretty clear that
some new text is needed.  If nobody else writes one before I get the
round tuit, I will, and will update the text about referrals also.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 20:11:37 -0800

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

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

> server might be able to answer if "someone else" asks the question come

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Nov 2017 01:32:10 -0500

Hi,

On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote:
> 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.

> administrative denial, and repurposing it would not be effective at this

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
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Nov 2017 23:03:11 -0800

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

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

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

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

---

From: Evan Hunt <[email-masked]>
Date: Tue, 14 Nov 2017 08:06:38 +0000

On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote:
> 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.

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

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.

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Nov 2017 00:21:11 -0800

> 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 AAAA or A to send to.

> 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

---

From: Mark Elkins <[email-masked]>
Date: Tue, 14 Nov 2017 11:15:17 +0200

> wrong address, synchronization should still occur, just not as quickly.

Getting the parent to examine the child in order to examine changes in
CDS/CDNSKEY is something I'd dearly like to see done.
With foot firmly stuck in mouth and probably breaking all protocols....

Who am I:
I'm a 'local' Registrar (Non-ICANN Accredited), running DNSSEC for
clients. I speak EPP mainly to the ZACR (South African Central Registry)
- usually for the CO.ZA Domain name space. I also speak EPP to a bunch
of other people.
I either run the DNS zone for the client - so know when to send an EPP
update to the Registry (this is totally automated) or run a
"Registration Only" service where clients run their own (DNSSEC Signed)
zones. When the latter do a KSK rollover, they are currently obliged to
login to https://vweb.co.za into their account, find their Domain and
push a [Reread Zone info] button which does a DNS Lookup over TCP using
a DNSSEC aware recursive resolver to see what NS and DNSKEY records have
changed, brings them back and presents them to the user. I automatically
generate CDS records from the DNSKEY. A short time later - these are
pushed to the Parent via EPP.

More ideally, this [Reread Zone info] button should be triggered by the
client using a well documented standard (RFC?), probably a URL and
passing to the URL the Domain Name to "check". (I like to call this the
"tickle RFC").

The same could be used directly with Registry systems...
If you want to get CO.ZA to "Poll" your Nameservers, look for a DNS
record (lets call it TCKL) in the top of the zone which should return a
web like URL which you can then "GET" with... (GET seems more simple
than POST)

co.za    IN    TCKL    "https://poll.registry.net.za?Domain="
(Most ccTLD's might do the same?)

For myself, I'd tell my clients mentioned above to look for:

vweb.co.za    IN    TCKL    "https://tickle.vweb.co.za?Domain="
(Most COM type Registrars might do the same?)

I guess one could have multiple answers for redundancy.
No "security" as in passwords should be needed.
I don't see this being used to DDOS Registries, only do something
further if the domain is one of yours, only if it is already DNSSEC
signed, and only trust the answer if the DNS Connection validates
properly, any faults - wait 5 seconds and then report an error (if so
desired).

I don't quite see how a SVR record could do this as per

I also don't remember seeing any DNS record types where the RHS is a full URL.

To me, for now, this would only be used for DNSSEC updates (i.e. CDS/CDNSKEY where the Child Zone is already signed)

Anyway - that's my baby step, so just a small foot in my mouth. Please be gentle.

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
[email-masked]       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Nov 2017 04:50:45 -0500

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.

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

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

> <<For example, a name server may not wish to provide the information to the
> 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.

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

Well, I want to be neither talmudic nor supreme.  I don't think I
disagree with your view (though FWIW I find your tone a little
patronizing), but I think we are doing two things in this discussion:

    1.  Providing fodder for a draft I've already started writing that
    provides guidance not to return upward referrals.

    2.  Providing the necessary information for the terminology
    document so that we have written down our current best
    understanding of terms as people use them.

I do not believe that (2) ought to include an effort to define terms
to exclude operations we (for some value of we) think are a bad idea.
IMO, the goal of 7719bis is not to define problems out of existence
but to give us a clear and common set of terms to talk about all of
this, _so that_ we can specify improvements to what the traditional
specifications say.

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

And that "permanent failure" marks the server dead, not the
server-qname or even server-zone combination dead, I guess.  I think I
have seen this too.  That seems like another thing that ought to be
documented, however, as a possible issue: at least one full service
resolver interprets an RCODE somewhat more liberally than the
specification does under some (other) plausible reading.  I'm here to
document things so that we can maximise interoperation, not specify
what is Correct.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 14 Nov 2017 12:08:59 +0000

> though, for updating NS and glue.)

Yes.

> wrong address, synchronization should still occur, just not as quickly.

The starting point for this thread was parental agents saying they don't
like polling, but having thought about this a bit more I think I agree
that it would be unwise not to poll. If there's a way to get polled early
by NOTIFY then that's probably still good for both parent and child -
parent can poll more slowly, and child can get prompt updates.

I read Mark Elkins' article with interest. I would prefer to use NOTIFY
rather than a web hook because it's much more plausible to imagine
supporting this inside a DNS server with some kind of notify-parent
feature.

I like the idea of being able to automatically discover where to send
parental notifies. But this can only work if the parental agent doesn't
require TSIG. On the other hand, we can't rely on autodiscovery because
I wouldn't bet on the registries publishing the necessary SRV records...

Any opinions on whether this is worth pursuing?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire: Northwesterly backing westerly 5 to 7. Moderate or
rough, occasionally very rough later in north. Squally showers. Good.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 14 Nov 2017 17:53:00 +0000

On Tue, Nov 14, 2017 at 12:21:11AM -0800, Paul Vixie wrote:
> 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.

---

From: Jacques Latour <[email-masked]>
Date: Tue, 14 Nov 2017 20:02:28 +0000

Parental synchronization is inevitable so we would be better to find the
best way to make it happen.  I think there are 3 plausible methods to do
the synchronization.

1. Child Notification: Child sends NOTIFY to a predefined parental
destination. The parent then polls the child zone for changes and EPP
commands issued to reflect the changes.

2. DNS Operator Notification: DNS Operator changes the child zone. DNS
Operator finds parental agent API via RDAP or TCKL to notify of changes to
be performed. The parent then polls the child zone for changes and EPP
commands issued to reflect the changes.

	- 
https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-0
4
	- parental agent can be the registrar or the registry

3. Parent Polling*: On a batch/regular basis, the parent then polls all
child zones for changes and EPP commands issued to reflect the changes.
 *The parent can be the registrar or the registry.

	- a la cz.nic, full zone polling
(https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/)
	- it would be nice to send an EPP poll message to the registrar when a
domain is changed by the TLD
	- some of the research we¹ve done shows that there are no ICANN policy
impact of doing #3 across the board (ccTLD and gTLD).

Personally, I like a mix of #3 and #1, on a regular basis poll the entire
zone for changes, and have a mechanism to listen to child notifications
for urgent changes.

_AND_ remember, the preferred method by far is to submit a DS/DNSKEY
record is via the RRR EPP model.  The above is when that RRR EPP model is
non functional.

Jack

---

From: Dave Lawrence <[email-masked]>
Date: Tue, 14 Nov 2017 21:04:36 -0500

> authority, is the one that's mis-using REFUSED; REFUSED only makes sense on

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Nov 2017 19:42:45 -0800

>> authority, is the one that's mis-using REFUSED; REFUSED only makes sense on

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.

> 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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Nov 2017 23:59:19 -0500 (EST)

> zone for changes, and have a mechanism to listen to child notifications

Agreed.

> record is via the RRR EPP model.  The above is when that RRR EPP model is

That preference might be political not technical. I personally like the
DNS based solutions over the EPP based one, because it requires no
humans or webgui's :)

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Nov 2017 12:18:25 +0000

Paul Vixie <[email-masked]> 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  <[email-masked]>  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.

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Nov 2017 15:35:32 +0000

Yes.

> DNS based solutions over the EPP based one, because it requires no

EPP isn't available to most registrants or operators, since it's a
registrar <-> registry protocol -- remember the motivation for CDS/CSYNC
was lack of any operator <-> registrar update protocol, and lack of any
way to provide registrar credentials to DNS operators.

There are plenty of parent zones which don't have an EPP back end -
examples I care about include the reverse DNS, ac.uk, cam.ac.uk, etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire, Southeast Forties: Northwesterly backing southerly 5 or 6,
increasing 7 or gale 8 later. Moderate or rough. Showers, rain later. Good,
occasionally poor later.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Nov 2017 17:12:08 +0100

On Tue, Nov 14, 2017 at 09:04:36PM -0500,
 Dave Lawrence <[email-masked]> 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

:-)

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Nov 2017 14:50:25 -0500

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
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2017 07:39:42 +1100

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 <[email-masked]> wrote:
> 
> Dear colleagues,
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Nov 2017 15:18:57 -0800

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Nov 2017 20:17:34 -0500

Excellent point!  Thanks.

-- 
Please excuse my clumbsy thums

----------

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Nov 2017 20:44:36 -0500

Hi,

> The AA bit may or may not be set depending upon whether the response contains

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

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2017 12:46:07 +1100

GO READ STD13!

> On 29 Nov 2017, at 12:44 pm, Andrew Sullivan <[email-masked]> wrote:
> 
> Hi,
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Nov 2017 20:47:48 -0500

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
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2017 12:49:48 +1100

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 <[email-masked]> wrote:
> 
> GO READ STD13!
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Nov 2017 20:53:03 -0500

> 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
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Nov 2017 20:54:27 -0500

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

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2017 12:57:26 +1100

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 <[email-masked]> wrote:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Nov 2017 21:03:47 -0500

Hi Mark,

> 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
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2017 13:04:19 +1100

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 <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2017 13:14:13 +1100

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 <[email-masked]> wrote:
> 
> Hi Mark,
>

---

From: Evan Hunt <[email-masked]>
Date: Wed, 29 Nov 2017 02:37:20 +0000

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Nov 2017 19:08:01 -0800

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

> have; resolution can succeed without it."

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

-- P Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Nov 2017 11:16:28 +0000

> That leaves the task of the referrals definition.  I have some new

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:

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:

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

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  <[email-masked]>  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.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Nov 2017 07:11:30 -0500

Hi,

> https://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html

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

> specifically mean downward in the DNS tree.

That's plausible.
 
> 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?

> 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
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Nov 2017 07:17:06 -0500

> a zone that the server serves you will have CNAME (DNAME) + referral.

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

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Nov 2017 07:21:01 -0500

> 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
[email-masked]

---

From: P Vix <[email-masked]>
Date: Wed, 29 Nov 2017 12:23:36 +0000

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 <[email-masked]> wrote:
>and if

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2017 23:24:27 +1100

> On 29 Nov 2017, at 11:17 pm, Andrew Sullivan <[email-masked]> wrote:
> 
> this why you call it a "partial referral”?  

I said “partial answer + referral”, and yes.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Nov 2017 07:25:53 -0500

> latter, but I see how it could be confusing.

Yep, got it.

> 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
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Nov 2017 07:28:11 -0500

On Wed, Nov 29, 2017 at 12:23:36PM +0000, 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
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Nov 2017 12:32:32 +0000

> unqualified term 'referral' to mean only a downward referral," would

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

> 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

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  <[email-masked]>  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.

---

From: P Vix <[email-masked]>
Date: Wed, 29 Nov 2017 13:55:29 +0000

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.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Nov 2017 09:08:06 -0500

On Wed, Nov 29, 2017 at 01:55:29PM +0000, 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
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Nov 2017 15:06:02 +0000

Andrew Sullivan <[email-masked]> 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  <[email-masked]>  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.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 29 Nov 2017 07:17:59 -0800

> referrals or implicit referrals) have to have a qualifier.

Yes, please. This is good formulation for our definitional problems.

--Paul Hoffman

---

From: Evan Hunt <[email-masked]>
Date: Wed, 29 Nov 2017 19:30:46 +0000

> referrals or implicit referrals) have to have a qualifier.

+1

---

From: Evan Hunt <[email-masked]>
Date: Wed, 29 Nov 2017 19:37:31 +0000

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

---

From: Dick Franks <[email-masked]>
Date: Wed, 29 Nov 2017 21:18:39 +0000

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Nov 2017 16:23:54 -0500

> 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
[email-masked]

---

From: Dick Franks <[email-masked]>
Date: Wed, 29 Nov 2017 22:23:34 +0000

> about that.  It's why Joe and I wrote draft-sullivan-dnsop-refer-down.

Mark's example involved two unrelated (which I mistakenly referred to as
arbitrary) zones, and a server having authoritative data for both.
Cached data not involved.

Until Mark's intervention, I was convinced that referrals were downwards
only.
I was trying to establish if this creates a counter-example, which might
require
me to unconvince myself.

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Nov 2017 23:13:06 +0000

> On 29 Nov 2017, at 21:18, Dick Franks <[email-masked]> wrote:
>> On 29 November 2017 at 12:17, Andrew Sullivan <[email-masked]> wrote:
>> 
> And said referral could be to an arbitrary node in the DNS tree,  i.e. possibly "upward"?
> 

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  <[email-masked]>  http://dotat.at

---

From: Dick Franks <[email-masked]>
Date: Wed, 29 Nov 2017 23:28:17 +0000

On 29 November 2017 at 23:13, Tony Finch <[email-masked]> wrote:

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

I get the picture.  Many thanks

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Nov 2017 23:34:12 +0000

> On 29 Nov 2017, at 23:13, Tony Finch <[email-masked]> 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.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Nov 2017 20:59:00 -0500

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

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
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 29 Nov 2017 18:43:51 -0800

andrew, et al, i see that the discussion continued overnight (i'm here 
in beijing) and i hope you can reach a consensus on the matter. here's 
my input to the terminology of referrals.

---

According to RFC 1034 section 4.3.2 step 3 substep B, a referral 
"happens when we encounter a node with NS RRs marking cuts along the 
bottom of a zone" and is constructed by copying "the NS RRs for the 
subzone into the authority section of the reply" and putting "whatever 
addresses are available into the additional section, using glue RRs 
if the addresses are not available from authoritative data or the 
cache." By this definition, an answer whose answer section is empty and 
whose authority section contains an NS RR set, is only a "referral" if 
the NS RRs refer to a subzone of an authority server's zone data.

===

in other words, we need not argue about what a supposedly reasonable 
person may be able to understand or misunderstand from the RFC 1034 text 
and then rephrase it in some way that may raise or lower the risk of 
misunderstanding, or change the results of understanding. all we need to 
is quote the actual 1034 text and hope that whatever supposedly 
reasonable person reads this document, will come to the same conclusions 
they came to when reading 1034.

vixie

---

From: Florian Weimer <[email-masked]>
Date: Thu, 30 Nov 2017 12:14:27 +0100

> 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

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Nov 2017 12:24:14 +0000

> part of step 3.b is a referral response.

Yes. ¶2 tells you how to construct a referral.

> stuff you're copying into the response in step 4.

I think you're missing a word or two here :-) but the key part of step 4
wrt referrals is "If there was no delegation from authoritative data",
i.e. if we already have a referral, don't overwrite it.

The "go to step 4" is a switch from serving authoritative data to
gossiping cached data, when the auth data can only provide part of the
answer. (There's also more gossiping in step 6.)

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

It seems to me that these RFCs were written with a great deal of care, but
their informality makes them appear less precise than they are - you have
to read between the lines to work out the implicit meanings of the
technical terms. But I don't think the terms are used inconsistently.

> tried to preserve the meanings that persist on the Internet.

I think it's worth being precriptive, but carefully. That is, telling
readers of the terminology RFC that if they are using a term precisely in
a document they are writing, they should only use it with the preferred
meaning - but some people use it with these different meanings so readers
need to be aware of these variations.

e.g. for referrals, saying something like "the term referral is sometimes
used in a way that also covers implicit referrals and upward referrals
(qv) but precise writing should only use referral to mean a downward
referral from authoritative data".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy, Sole: Northerly or northeasterly 5 or 6, occasionally 7 in east.
Moderate or rough. Showers. Good.