Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi,

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

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

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

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

A

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

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Andrew Sullivan wrote:

...

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


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


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



4.1. Introduction

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


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


4.3.1. Queries and responses

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

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

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


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


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


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

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

   - A temporary error indication.

   - Some combination of:

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

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

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


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



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


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


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


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

Hi,

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

[…]

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

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

A

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

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

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Andrew Sullivan wrote:

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

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



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


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



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


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


--
P Vixie

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

Re: [DNSOP] Clarifying referrals (#35)

[Andrew Sullivan]

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

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

A

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

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

Re: [DNSOP] DINRG update

[Melinda Shore]

On 11/13/17 8:17 AM, Ted Lemon wrote:
> This is showing up on the agenda as canceled.

Yes, this is an informal side meeting - the actual session is
canceled.

Melinda




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DINRG update

[Ted Lemon]

On Nov 13, 2017, at 8:12 AM, Melinda Shore  wrote:
> With regrets to the fine folks of dnsop, we've scheduled the
> dinrg side meeting from 9:30 - 12:00 this morning.  We realize
> that there are many people in the dns community who are
> interested in decentralized approaches to naming but scheduling
> during this meeting has been exceptionally difficult.  We'll
> try to make sure to avoid dnsop (and other dns working group)
> conflicts in the future.

This is showing up on the agenda as canceled.

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

[DNSOP] DINRG update

[Melinda Shore]

With regrets to the fine folks of dnsop, we've scheduled the
dinrg side meeting from 9:30 - 12:00 this morning.  We realize
that there are many people in the dns community who are
interested in decentralized approaches to naming but scheduling
during this meeting has been exceptionally difficult.  We'll
try to make sure to avoid dnsop (and other dns working group)
conflicts in the future.

Melinda



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

[Paul Vixie]

Stephane Bortzmeyer wrote:

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


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


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


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


--
P Vixie

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

Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME

[Joe Abley]

An unbounded number of AS112 operators, not an inbound number.

I apologise to all present for sending mail to dnsop from a phone without
taking more time to check for autocorrect lunacy.

On Nov 12, 2017, at 11:26, Joe Abley  wrote:

On Nov 12, 2017, at 10:51, Kim Davies  wrote:

We haven't studied what would be involved, but I feel confident in

predicting the whole exercise would be non-trivial.


It seems to me that you could implement this using lawyers as easily as you
could using developers; it is after all arguably a static change in
procedure that doesn't need to be especially repeatable. If the root zone
maintainer is contracted to include a record, surely the record will be
included.

However, I think the more general idea that queries for internal names
should be leaked towards unknown AS112 operators is problematic. As an
end-user I would prefer my leaked queries to be jealously hoarded by one of
twelve root server operators than an inbound number of anonymous and
potentially ephemeral AS112 operators.

The potential for complete data collection at the root servers goes down as
resolvers implement aggressive NSEC caching. In the case of a delegation or
redirection, that potential is reduced since the non-existence of
individual names under internal is then the thing that is cached, not the
non-existence of the right-most label in the namespace.


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

Re: [DNSOP] Clarifying referrals (#35)

[Stephane Bortzmeyer]

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

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

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


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

Re: [DNSOP] draft-wkumari-dnsop-internal and DNAME

[Stephane Bortzmeyer]

On Sun, Nov 12, 2017 at 10:50:51AM +0800,
 Kim Davies  wrote 
 a message of 32 lines which said:

> Just one of the many things that would need to be looked at is how
> to transmit DNAME provisioning requests via EPP. I don't know if
> there is even an EPP mapping for this.

Interesting remark. I indeed did not find one. It should probably be a
small extension of RFC 5731:

   C:  
   C:example.com
   C:2
   C:empty.as112.arpa
   C:jd1234
   C:sh8013
   C:sh8013
   C:
   C:  2fooBAR
   C:
   C:  

I'll ask regext tomorrow about it :-)

> We haven't studied what would be involved, but I feel confident in
> predicting the whole exercise would be non-trivial.

But there is no choice. If we decide to delegate .internal to AS112
(*if*: see Joe Abley's message), we cannot use NS records because the
AS112 servers won't recognize the new TLD, and there is no way to
change them all these servers (RFC 7535, section 1).

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

[DNSOP] Jabber Scribes and Minute takers for DNSOP on Monday

[tjw ietf]

Hi

We're sending out the note requesting jabber scribes and minute takers for
DNSOP.

Also, there are a few laggards who need to send slides in.  You know whom
you are.

See you bright and early Monday Morning!

thanks,
tim/suzanne
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop