Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Paul Vixie]

Ray Bellis wrote:

... returning NOTIMP for ANY queries, ...

...

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.


the RFC was treated as a general guideline by most implementers, and 
once the code for some client or server appeared to work, it was 
shipped. it is that code which constraints our work now, not the RFC.



Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur. If as a result NOTIMP
is really not usable then IMHO this should also be documented.


i think you'll find that NOTIMP causes try-next-server for many clients, 
but without poisoning, so if all servers return NOTIMP, then all those 
same servers will be tried again, without delay.


sometimes, withholding a response is the only way to keep the client out 
of this bombardment-mode. sometimes returning something poisonous like 
ANCOUNT=0 is nec'y. again, our guide today is how to get clients to do 
something constructive, ideally constructive for both them and us. it 
doesn't have to be true, and it doesn't have to be documented in an 
older RFC.


i agree that writing a new RFC whenever something like this is found to 
be necessary, and putting into that RFC more specific advice to client 
implementers so that the future might possibly improve, is a great idea.


-- P Vixie

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Paul Vixie]

Ray Bellis wrote:

... returning NOTIMP for ANY queries, ...

...

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.


the RFC was treated as a general guideline by most implementers, and 
once the code for some client or server appeared to work, it was 
shipped. it is that code which constraints our work now, not the RFC.



Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur.  If as a result NOTIMP
is really not usable then IMHO this should also be documented.


i think you'll find that NOTIMP causes try-next-server for many clients, 
but without poisoning, so if all servers return NOTIMP, then all those 
same servers will be tried again, without delay.


sometimes, withholding a response is the only way to keep the client out 
of this bombardment-mode. sometimes returning something poisonous like 
ANCOUNT=0 is nec'y. again, our guide today is how to get clients to do 
something constructive, ideally constructive for both them and us. it 
doesn't have to be true, and it doesn't have to be documented in an 
older RFC.


i agree that writing a new RFC whenever something like this is found to 
be necessary, and putting into that RFC more specific advice to client 
implementers so that the future might possibly improve, is a great idea.


--
P Vixie

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

Re: [DNSOP] Status of "let localhost be localhost"?

[Erik Nygren]

On Mon, Aug 7, 2017 at 4:41 AM, Mike West  wrote:

>
> I poked at the draft a bit over the weekend, reworking it into a
> stand-alone document in https://tools.ietf.org/
> html/draft-west-let-localhost-be-localhost-04. I think it ends up being
> clearer overall, and hopefully y'all agree.
>


This is looking good.  Thank you for driving this forward.

I think it is crucial to make the "localhost" abstraction be usable without
concerns
(but with caveats and guide-rails as proposed in the doc).  Otherwise we'll
be stuck eternally with people using "http://127.0.0.1/; URLs and will need
to special-case that when we want to retire IPv4 off of hosts.

It might make sense to collect some statistics on how often "localhost"
is looked up on various recursive resolvers to determine how big of a
problem
it will be for them to "NXDOMAIN".

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

Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Edward Lewis]

On 8/7/17, 11:45, "DNSOP on behalf of Ray Bellis"  wrote:

>On 07/08/2017 16:44, Ólafur Guðmundsson wrote:
>
>> This was the original proposal, 
>> the drawback is that resolvers to not cache the answer, and to make
>> things worse they ask ALL NS addresses for listed domain 
>> thus it acts as a DDoS against the domain in question.  
>
>Indeed - I've since confirmed that BIND does this.
>  
>I think my point still stands that this behaviour should be documented
>in the section that talks about a possible new RCODE and why that option
>was rejected.

This thread is why I'd like to return "what the querier should do next" instead 
of "why I didn't answer". ;) 


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Ray Bellis]

On 07/08/2017 16:44, Ólafur Guðmundsson wrote:

> This was the original proposal, 
> the drawback is that resolvers to not cache the answer, and to make
> things worse they ask ALL NS addresses for listed domain 
> thus it acts as a DDoS against the domain in question.  

Indeed - I've since confirmed that BIND does this.

I think my point still stands that this behaviour should be documented
in the section that talks about a possible new RCODE and why that option
was rejected.

kind regards,

Ray

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Ólafur Guðmundsson]

This was the original proposal,
the drawback is that resolvers to not cache the answer, and to make things
worse they ask ALL NS addresses for listed domain
thus it acts as a DDoS against the domain in question.

Olafur


On Mon, Aug 7, 2017 at 7:14 AM, Ray Bellis  wrote:

> Having looked at this a few months ago when one of our partners was
> (briefly) returning NOTIMP for ANY queries, I find myself wondering why
> this isn't discussed in the draft?
>
> The draft does talk about *new* RCODEs, but not existing ones.
>
> My reading of RFC 1035 is that it would be a perfectly appropriate
> response from a server that doesn't support ANY.
>
> Unfortunately the retry semantics of DNS are not well specified and
> therefore implementation differences may occur.  If as a result NOTIMP
> is really not usable then IMHO this should also be documented.
>
> Ray
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

[Petr Špaček]

On 24.7.2017 15:43, Tony Finch wrote:
> Peter van Dijk  wrote:
>>
>> One could make $GENERATE more efficient without actually implementing
>> the BULK RR, by taking your pattern matching logic and implementing it
>> inside the name server.
> 
> Andrew Sullivan was right to say that there is an advantage to having BULK
> as an RR compared to the $GENERATE master file directive, because an RR
> makes it easier to interoperate across multiple providers in a
> multi-master DNS setup.
> 
> I guess a BULK that is just a standardized version of $GENERATE (with
> multi-master-only online signing when there's an unfeasible number of
> generated records) isn't a completely terrible idea, though it's a lot
> less complicated than the current draft.

I agree that a BULK version simplified to bare bones (auth side only)
might closer to acceptable. Still, it will not solve interoperability
problem because we would need a mechanism to transfer signing keys along
the BULK RR.

> I'd still like to see lots more specific examples of how it could be used
> other than for v6 reverse DNS.

Yes please, use-cases would be very welcome.


Right now it seems like *a lot* of complexity which is in my eyes not
justified. Thank you for understanding.

-- 
Petr Špaček  @  CZ.NIC

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

[DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Ray Bellis]

Having looked at this a few months ago when one of our partners was
(briefly) returning NOTIMP for ANY queries, I find myself wondering why
this isn't discussed in the draft?

The draft does talk about *new* RCODEs, but not existing ones.

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.

Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur.  If as a result NOTIMP
is really not usable then IMHO this should also be documented.

Ray

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček

[Petr Špaček]

On 26.7.2017 12:56, Tony Finch wrote:
> Joe Abley  wrote:
>>
>> If anybody else here has thoughts about specific text or violent
>> objections to including QTYPE=RRSIG in general, please let me know (I
>> looked in the mail archive but couldn't find any there).
> 
> I think it's helpful to mention RRSIG explicitly since it isn't
> immediately obvious that it's a stealth ANY query. (It becomes
> apparent to implementers fairly rapidly tho!)
> 
>> As we discuss (see Stephane's points) in the case of multiple
>> transports, perhaps we can also recommend that implementors provide
>> configuration options to allow administrators to deal with ANY, RRSIG,
>> neither or both. That way we get flexibility that matches deployment,
>> but we also get a reference for handling RRSIG in a predictable way.
> 
> I think the draft should recommend a simple on/off switch and describe
> sensible behaviour when it is on. Mainly because I think we know what
> that sensible behaviour is, and I don't think it's a big enough feature
> to deserve a lot of configuration and documentation complexity.

I agree with Tony that we know what that sensible behaviour is so, with
my implementor hat on, I would be perfectly happy with
implementation-specific behavior with no knobs at all. If you don't like
it, feel free to pick another implementation.

Petr Špaček  @  CZ.NIC

> 
> Having said that, the initiator side (section 5) needs a bit of work.
> Something like,
> 
>ANY queries SHOULD be sent using the same choice of transport as other
>queries (typically, try UDP first, and only use TCP if the response is
>truncated). As an exception, debugging and diagnostics tools MAY have
>a special case for ANY queries.
> 
> (bleeding-edge versions of `dig` use TCP for ANY)
> 
> Tony.

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