Re: [DNSOP] Refusing NS queries, was Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

[John Levine]

For instance, some authoritative name servers embedded in load
balancers reply properly to A queries but send REFUSED to NS queries.

>> If my policy is not to tell you about NS records, that's my policy.
>> It may be a stupid policy that causes downstream problems, but it's my
>> right to be stupid.
>
>Being listed as nameserver while unconditionally refusing all NS queries
>leads to a guaranteed failure with DNSSEC as there would not be a signed
>NS RRset published anywhere.

Yes, we agree it could have bad results.

>   The NS RR states that the named host should be expected to have a zone
>   starting at owner name of the specified class.
>
>I would interpret that to mean that a parental NS glue record signifies
>that the RDATA target must point to something that has that zone at the
>owner name. Thus the NS queries at that target should return proper
>results for NS queries (to itself)

Unless, of course, the target doesn't like you and refuses your
queries for policy reasons.  Maybe they don't want you to be able to
tell if there are delegated subzones, or they just think you're ugly.
It's still their policy, so they can refuse the queries.

The language in section 4.1.1 of RFC 1035 that defines the refused
RCODE is simple, and in a quick look at other RFCs that update 1035, I
didn't see anything that updates the definition.

R's,
John

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

Re: [DNSOP] Refusing NS queries, was Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

[Paul Wouters]

On Sun, 28 Dec 2015, John Levine wrote:


Being listed as nameserver while unconditionally refusing all NS queries
leads to a guaranteed failure with DNSSEC as there would not be a signed
NS RRset published anywhere.


Yes, we agree it could have bad results.


The NS RR states that the named host should be expected to have a zone
starting at owner name of the specified class.

I would interpret that to mean that a parental NS glue record signifies
that the RDATA target must point to something that has that zone at the
owner name. Thus the NS queries at that target should return proper
results for NS queries (to itself)


Unless, of course, the target doesn't like you and refuses your
queries for policy reasons.


Note that I said "unconditionally refusing all NS queries". Conditionally
refusing queries based on query source behaviour is off-topic.

The section in question of the draft under discussion talks about the
specific case where a load balancer is returning REFUSED because it
did not implement NS queries, and that such behaviour is a violation
of the RFC. Not implementing NS queries on an authoritative nameserver
results in a DNS implementation that indeed violates the RFC. The question
was, which part of which RFC is the best reference to point to.

Paul

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

Re: [DNSOP] Refusing NS queries, was Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

[Paul Vixie]

On Sunday, December 27, 2015 10:31:52 PM Paul Wouters wrote:
> The section in question of the draft under discussion talks about the
> specific case where a load balancer is returning REFUSED because it
> did not implement NS queries, and that such behaviour is a violation
> of the RFC.

strictly speaking, rfc's are guidelines, not to be violated or not, but only 
sometimes to be 
followed. an rfc guides sender behaviour and receiver interpretation. sometimes 
the 
receivers don't follow the interpretation guidelines, and so it is with 
REFUSED. REFUSED is 
considered by initiators to pertain to the specific 
 and 
are not therefore dispositive toward the originating application. "not 
dispositive" means the 
iteration will continue, trying other serverIP's if any are known, and 
eventually returning 
SERVFAIL to the originating application if all servers known for this closest 
encloser refuse or 
fail or time out. in that sense REFUSED is underspecified since these semantics 
are the same 
as if the server returned SERVFAIL, except the time domain. that is, SERVFAIL 
pertains to the 
 and as such, a SERVFAIL response 
should only 
be cached for a limited period. REFUSED is "forever".

> Not implementing NS queries on an authoritative nameserver
> results in a DNS implementation that indeed violates the RFC. The question
> was, which part of which RFC is the best reference to point to.

"violates" is the wrong rubric. the signal is ambiguous as specified and even 
more ambiguous 
as widely implemented. so, first mover advantage was abused, and you fight now 
as and 
where and when you are, not as and where and when you might wish to have been. 
in today's 
world, the safest interpretation is not "what the framers intended" but "how 
the world 
actually works." and that means treating REFUSED as a synonym for SERVFAIL but 
with longer 
cache retention.

do not, therefore, treat the REFUSED coming out of these load balancers as 
dispositive, and 
regard it as being specific to  such 
that varying any 
member of that tuple could be expected to produce a non-REFUSED answer.

"DNS: You will never find a more wretched hive of slop and ambiguity. We must 
be cautious." 
(Obi-Wan Mockapetris)

see also:

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

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

Re: [DNSOP] Refusing NS queries, was Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

[John Levine]

>> Unless, of course, the target doesn't like you and refuses your
>> queries for policy reasons.
>
>Note that I said "unconditionally refusing all NS queries". Conditionally
>refusing queries based on query source behaviour is off-topic.

Perhaps the target doesn't like anyone.  Here's the entire discussion
of "refused" from RFC 1034, for the benefit of people who haven't read
it lately:

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

(It really is the entire discussion, the word "refused" appears
nowhere else.)

>The section in question of the draft under discussion talks about the
>specific case where a load balancer is returning REFUSED because it
>did not implement NS queries, ...

We know what the draft says.  That case sure sounds to me like it does
"not wish to perform a particular operation for particular data",
where the operation is a query and the data is NS records.  Yeah, it's
generally a bad idea, but so what?

If anyone thinks this isn't a valid use of refused, a citation to the
RFC that updates this part of RFC 1035 would be a good place to start.

R's,
John

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

Re: [DNSOP] Refusing NS queries, was Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

[Shumon Huque]

On Sun, Dec 27, 2015 at 10:31 PM, Paul Wouters  wrote:

> On Sun, 28 Dec 2015, John Levine wrote:
>
> Being listed as nameserver while unconditionally refusing all NS queries
>>> leads to a guaranteed failure with DNSSEC as there would not be a signed
>>> NS RRset published anywhere.
>>>
>>
>> Yes, we agree it could have bad results.
>>
>> The NS RR states that the named host should be expected to have a
>>> zone
>>> starting at owner name of the specified class.
>>>
>>> I would interpret that to mean that a parental NS glue record signifies
>>> that the RDATA target must point to something that has that zone at the
>>> owner name. Thus the NS queries at that target should return proper
>>> results for NS queries (to itself)
>>>
>>
>> Unless, of course, the target doesn't like you and refuses your
>> queries for policy reasons.
>>
>
> Note that I said "unconditionally refusing all NS queries". Conditionally
> refusing queries based on query source behaviour is off-topic.
>
> The section in question of the draft under discussion talks about the
> specific case where a load balancer is returning REFUSED because it
> did not implement NS queries, and that such behaviour is a violation
> of the RFC. Not implementing NS queries on an authoritative nameserver
> results in a DNS implementation that indeed violates the RFC. The question
> was, which part of which RFC is the best reference to point to.


I certainly agree that unconditionally refusing NS queries is a bad idea.
Whether or not it is explicitly forbidden by current DNS protocol specs,
I'm not so certain about. I'd love to be corrected if anyone can point to
explicit text.

The statement Paul excerpts from RFC 1035 does not to my mind preclude
REFUSED responses to explicit NS queries; it merely states what is expected
of the named host in terms of the zone that it serves. Resolvers normally
obtain NS records not by explicit queries, but indirectly as part of data
included in referral responses. Even with DNSSEC, I think a validating
resolver could function properly without ever needing to issue explicit NS
queries (with the exception of priming queries which are directed at only
the root servers).

Query-name minimization (with query type hiding) obviously changes this
requirement.

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