Re: [DNSOP] WGLC rfc8499bis one week extension for lame delegation definition

[John Kristoff]

On Mon, 01 May 2023 21:15:29 +
Joe Abley  wrote:

> Yes -- some people (not me) would evidently describe a server that
> they didn't receive a response from as lame.

Lots of people and organizations tend to talk about "types" or "ways"
in which a server or delegation is lame. Here are a few well known
organizations or popular pages talking about what lame means so you
know the sorts of inconsistency (that's a term I like :-) you're up
against:

  

  

  
  
  

  

John

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

[John Kristoff]

On Mon, 1 May 2023 16:09:23 +
Paul Hoffman  wrote:

> It would be grand if a bunch more people would speak up on this
> thread.

I'm not particularly satisfied with the requirement that there must be
a response to meet the definition, but that seems to be the consensus
even if most seem to agree it is imperfect.  I won't derail.  Until
someone comes up with better terminology, I'm likely still going to
refer to all those many cases we see in operation (usually due to a bad
configuration) as a form of lame delegation when a delegation is
effectively broken. :-)

John

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

Re: [DNSOP] Meaning of lame delegation

[John Kristoff]

On Mon, 10 Apr 2023 11:29:36 -0600
Paul Ebersman  wrote:

> Perhaps if we inverted the logic? I realize this does broaden the
> fundamental definition but what if, instead of saying "gave
> non-authoritative response" we define lame as "failed to give an
> authoritatve/AA response"?

Isn't that what I originally suggested and Joe disagreed with?  Let's
trust P. Hoffman to iron this all out in a revision of the definitions
RFC. :-)

John

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

Re: [DNSOP] Meaning of lame delegation

[John Kristoff]

On Mon, 10 Apr 2023 14:35:36 +
Joe Abley  wrote:

> I continue to think that if you don't get a response, you can't tell
> whether the delegation is lame. Lameness (as I use the term) relates
> the configuration of the nameserver, not it's availability.
> 
> So I prefer Duane's formulation to yours, precisely for the reason
> you gave.

I won't push on this any further after this, but the absence of a
response happens quite a bit in my experience, and it is often a lame
delegation in my view due to a problem in the delegating config or apex
config (e.g., bogus or stale address specified, system removed from
service but config not updated). A mention of this ambiguity, that it
might be lame, might not be a bad idea to cover those cases imo.

John

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

Re: [DNSOP] Meaning of lame delegation

[John Kristoff]

On Mon, 10 Apr 2023 13:39:21 +
"Wessels, Duane"  wrote:

> “A lame delegation is said to exist when one or more authoritative
> servers designated by the delegating NS rrset or by the apex NS rrset
> answers non-authoritatively for a zone”.

Perhaps, say "does not answer authoritatively for a zone"?  That would
cover the case when you get no response at all.

John

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

Re: [DNSOP] Meaning of lame delegation

[John Kristoff]

On Mon, 3 Apr 2023 20:02:16 +
"Wessels, Duane"  wrote:

> (1) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP
> address result in a REFUSED, SERVFAIL, upward referral, or some other
> indication the name server is not configured to serve the zone.

May be lame.  I could imagine an argument made that REFUSED is due to
some administrative policy applied to the specific query, but the
server is otherwise responding authoritatively for other queries.

> (2) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP
> address do not elicit a response (e.g., timeout).

May be lame.  Perhaps the lack of response is a transient network issue?

> (3) NS.EXAMPLE.ORG does not resolve to an IP address, so there is
> nowhere to send a query.

ns.example.org is lame, but since there is no mapping to an address,
is there a specific NS instance that is actually lame?  Unclear to me.

> We welcome the working group's thoughts whether "lame delegation"
> encompasses these three possibilities.

Interesting dilemmas. I'm not sure there are obvious answers.  Perhaps
lame delegation is the general concept, but specific failure modes need
better characterization?

John

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

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

[John Kristoff]

On Wed, 15 Feb 2023 13:52:03 -0500
Ted Lemon  wrote:

> It clearly is, in the sense that someone is using it and it keeps
> coming up. :)

Hi Ted,

I'm just catching up on this conversation and maybe I've missed it, but
can you point me at the implementation(s) that are setting QDCOUNT > 1?

Thanks kindly,

John

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

Re: [DNSOP] [art] [Last-Call] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[John Kristoff]

On Mon, 13 Sep 2021 21:24:37 -0400
Warren Kumari  wrote:

> As Robert Sparks helpfully pointed out on last-call list, I was only
> talking about this "particular potential BCP updating a particular
> Informational RFC both in the IETF stream.".

Hi Warren et al.,

I have this in the appendix:

   The informational document [RFC1536] states UDP is the "chosen
   protocol for communication though TCP is used for zone transfers."
   That statement should now be considered in its historical context and
   is no longer a proper reflection of modern expectations.

The "historical context" notion is my interpretation of how to handle
that early document's statement.  Is this reasonable?  Should I change
this?

John

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[John Kristoff]

On Thu, 22 Apr 2021 20:23:19 +0100
Tony Finch  wrote:

> I needed minimal-any when my auth servers were being hammered by lots of
> recursive servers making ANY requests; the responses were being truncated
> because my servers have for a long time been configured to avoid
> fragmentation, and the retries over TCP caused an overload.

Hi Tony,

Minimal answers I think is an interesting and in a more general context
I'm interested in exploring it as an operational practice (e.g. I think
it can help relieve some of the burden and problems of parent/child
inconsistency).

However, I think we'd be reluctant to say much about minimal-answers
here in a context that suggests it is some sort of DDoS mitigation
mechanism and that you need it because... "TCP".  Maybe there is some
adjustments to the text somewhere that can help highlight that certain
RRsets or settings may lead to more TCP traffic?


Thanks for taking on a bulk of replies so far.  I tend to like to
digest them first, before replying to them in rapid succession so
you're beating me to it.  I can do some of the follow up work in the
repo where I find things that are not yet addressed.

> > > Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm
> > > not sure how much UDP is used, but I certainly rely on 60+ KB updates.  
> >
> > I probably don't have enough direct experience with UPDATE to say.  If
> > it is largely over TCP then I think it should be included.  
> 
> I listed the main section numbers that mention TCP. One point in RFC 2136
> that's notable from an operational point of view is that an UPDATE client
> has to use TCP if it wants to be sure to get a response. Unlike QUERY,
> UPDATE is not idempotent so UPDATE-over-UDP can't be retried when there is
> packet loss. (But `nsupdate` still uses UDP for small changes; I run it
> over localhost which is reliable enough.)

IETF RFC 2136 (UPDATE) is already referenced in our draft, section
2.2.  Is this insufficient?

John

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

[John Kristoff]

On Mon, 19 Apr 2021 07:31:49 -0400
Joe Abley  wrote:

> NEW:
> 
>The specification of the DNS allows both UDP and TCP to be used 
>as transport protocols for exchanging unencrypted DNS messages.
>However, for various reasons, the availability of TCP transport
>has sometimes been interpreted as being optional.  This document 
>clarifies the need to provide TCP transport for both clients and
>servers and strengthens the requirement of DNS implementations
>to support both.

Hi Joe,

Thanks for your careful read and thoughtful comments.  I would just
point out that there is already a document that specifically requires
this of the implementations, IETF RFC 7766.  This draft was
specifically aimed at operators, which have that document had
sidestepped "this document makes no specific requirements for
operators".  So maybe a simple "implementations" to "operators" change
of your text would work?

John

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

[DNSOP] Wrapping up draft-ietf-dnsop-dns-tcp-requirements

[John Kristoff]

Friends,

Duane and I pushed out a recent update to this draft.  There are at
least a couple of small TODO items we have to address (search text
for TODO) before it can be published, but I think we've exhausted
largely what we set out to do for this document and would like to see
this wrapped up.

If you could give it perusal and provide and alert us to anything
needing attention that would be lovely.  Thank you,

  

   This document encourages the practice of permitting DNS messages to
   be carried over TCP on the Internet.  It also considers the
   consequences with this form of DNS communication and the potential
   operational issues that can arise when this best common practice is
   not upheld.

John

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

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

[John Kristoff]

On Thu, 3 May 2018 06:12:42 +
Amreesh Phokeer  wrote:

> We consider "lame" any NS which is either:
> - Not responding at all.
> - Responding in some way, but not for the specific domain queried.
> - Responding for the correct domain, but without the authority bit set.

Friends,

I've been referring to a class of problems I call DNS Inconsistency.
This can be thought to be a bit broader in scope than what is typically
meant by a delegation, but it is related.

I'm particularly interested in parent/child NS RRset consistency at the
moment and I recently compiled this list of possible NS RR results when
considering what may happen as one might try to traverse a graph to a
domain name node.  Imperfect list, classifications, and severity
perhaps, but maybe stimulates more useful discussion than it does
detract from it.

--- some amount of broken ---
error   |  bad type (e.g. CNAME)
error   |  bad rdata (e.g. IPaddr for NS)
error   |  TTL disagreement in the NS RRset
error   |  DNSSEC validation error
error   |  timeout/unreachable transient (e.g. down time)
error   |  timeout/unreachable permanent (e.g. misconfiguration)
query_response  |  NXDomain
query_response  |  REFUSED
query_response  |  SERVFAIL / FORMERR / NOTIMP / etc...
query_response  |  referral after a referral
query_response  |  aa==0 when aa==1 expected
query_response  |  malicious or incorrect rdata

--- properly formed answer, but not yet provably correct ---
name|  maps to an ipv4addr
name|  maps to an ipv4addr set
name|  maps to an ipv6addr
name|  maps to an ipv6addr set
name|  maps to an ipv4addr + ipv6addr
name|  maps to an ipv4addr set + ipv6addr
name|  maps to an ipv4addr + ipv6addr set
name|  maps to an ipv4addr set + ipv6addr set

John

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

Re: [DNSOP] Terminology question: split DNS

[John Kristoff]

On Mon, 19 Mar 2018 19:26:42 +
"Darcy Kevin (FCA)"  wrote:

> How about just "disjoint DNS" or "non-synchronized DNS"? Or, to
> hijack the Perl motto, TMTOWTRI (There's More Than One Way To Resolve
> It :-)

Coming up with new names though is less than ideal.  The Microsoft
community has used split-brain, which might be an option, but might
not get a lot of support from this community (including me). RFC 7719
seems to prefer the term "view" for better or worse.  I kind like that.
Paul's comment doesn't convince me it shouldn't be apportioned for this.

John

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

Re: [DNSOP] Clarifying referrals (#35)

[John Kristoff]

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

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

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

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

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

John

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

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

[John Kristoff]

On Tue, 23 May 2017 12:22:34 +
Sara Dickinson  wrote:

> I’ve reviewed this draft and as stated previously support adoption as
> a companion document to RFC7766.

Thank you for your review.

> Section 2.2: I think the argument around DNSSEC can be bolstered by
> the fact that recent root ZSK and upcoming KSK rollovers involved
> large responses.

Thank you, we can note that in a future revision.

> Section 2: I think it might be useful to include a section in section
> 2 describing the fact that the lack of, or very limited
> implementation of TCP also fed the perception that it was a security
> risk.

The references

  Cheswick, W. and S. Bellovin book
  

in section 2.4 I think may largely sums up the general concern.
Maybe the section 2.4 is not correctly titled or incompletely detailed
to highlight your point.  Any specific text or additional references are
welcome of course.

> Section 6.3  s/[RFC7766] is might be/[RFC7766] might be/

Thank you.

> Should there be a section in Section 6 about RFC7858 (DNS-over-TLS)?

Yes, thanks for pointing that out.  That section is still work in
progress.

> And since it is stated as TCP related development should RFC2136 be
> there (even though it is discussed earlier)?

Probably should be there.  Need I worry about section 6's length at
all?  It could take up a significant portion of the document given the
way this section is going.  Note, this section was added based on some
earlier feedback that having this sort of list might be helpful.
> 
> How about including a reference to
> https://datatracker.ietf.org/doc/draft-stenberg-httpbis-tcp/ ?

Looks potentially worth including this sort of work in section 4.

Thanks again,

John

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

Re: [DNSOP] DNSOP Call for Adoption: draft-kristoff-dnsop-dns-tcp-requirements

[John Kristoff]

On Thu, 11 May 2017 23:25:13 +
神明達哉  wrote:

> I've read draft-kristoff-dnsop-dns-tcp-requirements-02.

Thank you for taking the time to read, review, and comment on it!

> I think RFC7766 already pretty clearly states TCP is a MUST.

IETF RFC 7766 does very explicitly declare TCP is a MUST in the context
of DNS implementation.  It is also very explicit about not declaring
this to be so from an operational standpoint, although with a strong
warning about the consequences.  The last paragraph is Section 1 in that
document is the operative text.  It was that in addition to my own
operational and teaching experience I felt made this draft necessary. I
tried to make this case at the meeting in Chicago and elsewhere that
this is an important distinction that matters.  I can try to make this
case more compelling and convincing in the text.

>   I'm not sure if DDNS update bolsters the need for TCP.
[...]
>   And I don't see any new trend that changes this practice.

I see Tony has chimed on this so I'll simply add that the goal of
Section 2 was not necessarily intended to make or bolster the modern
argument for carrying DNS over TCP.  In fact, the purpose was to help
show how it is difficult to conclude one way or another whether carrying
DNS over TCP is an operational requirement or not. I can make this
objective more explicit at the beginning of that section.

>   The term "forwarder" can be ambiguous (see, e.g, RFC7766).  You
>   might want to use a different term to be clearer.

Thanks again, I can try to make the wording and meaning more precise.

John

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

Re: [DNSOP] Preliminary Agenda for

[John Kristoff]

On Thu, 9 Mar 2017 21:29:25 +
Tim Wicinski  wrote:

> * draft-kristoff-dnsop-dns-tcp-requirements
>  DNS Transport over TCP - Operational Requirements

Oh thanks Tim.  I wasn't sure if this was going to make it into the WG's
plans.  I had started a revised version of the draft, which I intend to
have updated and uploaded by the 13th for review.  The last -01 version
just expired a few days ago, but should be easily found if anyone wants
to take a look at it.

Here are the changes that I've made or may make for the next revision
based in part on some comments already given:

  * Some grammatical, spelling fixes.

  * At least a mention of IETF RFC 7858 (DNS over TLS)

  * Revamped Requirements section.

  * Possibly some operational guidance like that found in section 10 of
IETF RFC 7766 (DNS over TCP implementation requirements)

  * Possibly some history of TCP versus UDP implementation differences.

  * Possibly a summary of current DNS standards related to TCP.

More comments welcome of course.

John

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

[DNSOP] Soliciting feedback for draft-kristoff-dnsop-dns-tcp-requirements

[John Kristoff]

Friends,

If I could trouble you to consider reviewing this and provide any
comments you might have about it, that would be appreciated.  Thank you.

  DNS Transport over TCP - Operational Requirements
  

Abstract

   This document encourages the practice of permitting DNS messages to
   be carried over TCP on the Internet.  It also describes some of the
   consequences of this behavior and the potential operational issues
   that can arise when this best common practice is not applied.

John

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

Re: [DNSOP] DNS Delegation Requirements

[John Kristoff]

On Mon, 8 Feb 2016 09:57:15 +0100
Jakob Schlyter  wrote:

> At this point, we're seeking more public comments - on this mailing
> list (unless the chairs disapproves), on the our issue tracker [4] or
> via email to the authors.

Hello Jakob and Patrik.  Some comments as requested.

The introduction lists 8 areas of interest.  All, except "7. Name
Server" have their own section in the table of contents.  Oversight?

This sentence is awfully confusing:

  Many requirements in this document deal with the properties of a
  nameserver that is used as part of a delegation, therefore the
  wording mentioning the use of a name server as part of this is
  omitted.

First there is nameserver, then name server as two words.  Which is
it?  More importantly, I'm not quite sure what is being said here.  Can
you perhaps rewrite, elaborate or provide an example?

You may be interested to know that I recently submitted a draft on DNS
over TCP operational requirements.  If that work progresses as I hope,
it might help with section 4.2 of your draft.

The consistency requirements might be too strict, since it applies all
zone data.  While reasonable people might fret about inconsistency when
things like "views", "geo-location", client-subnet and so on are in
use, it might be best to limit consistency requirements to the
infrastructure records (e.g. SOA, NS).

Additionally, I could imagine an argument being made that all names
need not respond with the same NS RRset.  While generally this
delegation or authority list inconsistency is often indication of a
problem, it is feasible that it might be intentional and may even
provide some advantage.  The so-called "fast flux" invention by the
miscreants taught us that.

Suggesting that name servers be the same AS is often unnecessary.  More
important is diversity in the route announcements covering the name
server addresses.  Many might not even be able to easily satisfy this
requirement.

A few additional topics you may wish to consider:

  * delegated name server should be authoritative only (no rd service)
  * ptr names of NS addresses should match the associated A/ names
  * name server should run NTP or equivalent so time is accurate
  * DNS TTLs of the NS and A/ name servers MUST be consistent

John

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

Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

[John Kristoff]

On Thu, 12 Nov 2015 08:00:50 -0800
Nicholas Weaver  wrote:

> We've done some of this in Netalyzr.  Captive portals in particular
> are a problem, with about 1% of systems measured in Netalyzr unable
> to use EDNS0 to get DNSSEC information either from the recursive
> resolver OR directly from the roots.

After a DNS over TCP discussion a student of mine indicated that they
recently fixed a problem in their network where DNS messages over 512
bytes were not being relayed.  It appears the root cause has to do with
some defaults being set common gear that simply drops messages over 512
bytes.  For example:

  

  !-- Enable a maximum message length to help defeat DNS
  !-- amplification attacks. Note: This is the default
  !-- configuration and value based on RFC 1035.
  !
  message-length maximum 512

This contradicts what IETF RFC 6891 (EDNS0, April 2013) now says:

   6.2.6.  Support in Middleboxes
   [...]
   Conformant middleboxes MUST NOT limit DNS messages over UDP to 512
   bytes.

John

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

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

[John Kristoff]

On Wed, 18 Mar 2015 01:59:56 -0700
Paul Vixie p...@redbarn.org wrote:

 This document therefore updates the core DNS protocol
  specifications such that support for TCP is henceforth a REQUIRED
  part of a full DNS protocol implementation.

 this language is too strong, and breaks working configurations.

That is the exact same language used in IETF RFC 5966.  The original
document, along with this draft still says  it makes no specific
recommendations to operators of DNS servers.  It is written for
implementors.  This seems to be a common misunderstanding.

John

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

Re: [DNSOP] OpenSSH 6.8 will default UseDNS to no

[John Kristoff]

On Fri, 20 Feb 2015 14:12:50 -0500
Daniel Kahn Gillmor d...@fifthhorseman.net wrote:

 If there are other instances of popular software that does
 unreasonable or unsafe things with the DNS by default,

I think it is worth noting, again, all OpenSSH does when UseDNS is
enabled is a log a message when it detects a connecting client's
address and the associated name, if any, do not match.

The 'POSSIBLE BREAK-IN ATTEMPT!' string is still part of log message
generated in those mismatch cases when UseDNS is enabled (see
canohost.c).  So the on/off button was set to a different default, but
the spirit of your unreasonable and unsafe campaign missed affecting
change onto a key part of the code.  Perhaps you could follow up and
advocate a change for that as well?

 If there are other instances of popular software that does
 unreasonable or unsafe things with the DNS by default,

It may be reasonable to advocate that the OpenSSH UseDNS option be
disabled by default, but one might ask then, when is it reasonable and
safe to use PTR queries and in-addr.arpa/ip6.arpa.  Hello, rat hole.

John

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

Re: [DNSOP] Nudging some reviews

[John Kristoff]

On Tue, 16 Dec 2014 02:25:57 +0530
Mukund Sivaraman m...@isc.org wrote:

 As part of the DNS fragments drafting, I went through
 draft-eastlake-dnsext-cookies-05 yesterday, and want to send some
 comments. But it seems the above is a newer version of it, so I'll
 read it tomorrow and send the review.

It is literally the same document, only the file name has changed (see
below.  I provided some comments under the -05 name to this list,
hopefully those were received and helpful in some small way.

John

$ diff -u draft-eastlake-dnsext-cookies-05.txt draft-ietf-dnsop-cookies-00.txt 
--- draft-eastlake-dnsext-cookies-05.txt
+++ draft-ietf-dnsop-cookies-00.txt
@@ -1,13 +1,13 @@
-  
+
 INTERNET-DRAFT   Donald Eastlake
 Intended Status: Proposed StandardHuawei
 Mark Andrews
  ISC
-Expires: April 10, 2015 October 11, 2014
+Expires: May 29, 2015  November 30, 2014
 
 
 Domain Name System (DNS) Cookies
- draft-eastlake-dnsext-cookies-05.txt
+   draft-ietf-dnsop-cookies-00.txt

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

[DNSOP] Feedback: draft-eastlake-dnsext-cookies

[John Kristoff]

I remember a much older version of this mechanism, but I imagine many
are not.  It isn't until quite a bit into the document where the reader
is really given any idea about what DNS cookies are or how they work.
This might be annoying to the reader, because especially in section two
that describes various threats, there are numerous statements about how
DNS cookies might help mitigate these threats.  I'd suggest a succinct
summary of what DNS cookies are or do, more than they are a
transaction security mechanism in the introduction.

Section 2.1.2,, second to last sentence reads in part:

  The computational or communications burden caused by such requests
  may not dependent on a forged IP source address [...]

In the first part, I think there is a missing verb be between not
and dependent.

Section 2.1.2, last sentence reads in part:

  Use of DNS cookies should enables a server to reject forged queries
  from an off path attack with relative ease and before [...] 

Remove the word should.  I'd also recommend removing phrase with
relative ease and , since that is largely superfluous and subjective.

Something to consider mentioning in section 3 is TCP-AO.  I don't think
it has ever been widely deployed outside of BGP services, but TCP-AO
(IETF RFC 5925) is an option and might be perhaps worth mentioning that
is is, but only for TCP and has not seen deployment in the DNS, even on
a limited basis where TSIG has often been used for things like
AXFR/IXFR between slaves and masters.

The ASCII cookie option figures 1 and 2 look a little awkward with that
2 byte hole following the error code.  Maybe it would be better to draw
it as 16-bit aligned as IETF RFC 6891 does?

The statements at the end of sections 4.1 and 4.2 conclude similarly:

  A client MUST NOT use the same Client Cookie value for queries to
  all servers.

  A server MUST NOT use the same Server Cookie value for responses to
  all clients.

The obvious logical question would be, but it is OK to use the same
cookie for some of them?

The nomenclature of BADCOOKIE is misleading since a missing server
cookie for an initial request is in no way bad, but perfectly
legitimate.  This is minor, but it might be syntactically preferable to
use better descriptors.

Lastly, a couple of random thoughts... should cookies received be
available to logging systems or collected by passive DNS systems for
analysis and debugging?

As implicitly described in 5.2.3, there is a risk of making a DDoS
attack a little worse when cookies are implemented.  If cookies become
widely deployed, servers might want to return a TC=1 response if there
is a cookie OPT but no server cookie present for that bootstrapping
query.

John

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

Re: [DNSOP] Workshop on DNS Future Root Service Architecture, Hong Kong, December 8-9, 2014 (SAVE THE DATE)

[John Kristoff]

On Tue, 28 Oct 2014 01:07:40 -0700
Paul Vixie p...@redbarn.org wrote:

 This two day workshop will focus on the DNS root service architecture
 issues raised by two current Internet Drafts:
 
 1. http://tools.ietf.org/html/draft-wkumari-dnsop-root-loopback-00
Decreasing Access Time to Root Servers by Running One on Loopback
W. Kumari, Ed.; P. Hoffman
 
 2. http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00
How to scale the DNS root system?
Xiaodong Lee; Paul Vixie; Zhiwei Yan
 
 These two drafts take very different approaches to the problem of
 increasing root zone availability to recursive name servers.

I can't make the workshop, but wow, very different indeed.  I'm
surprised no one has commented on the second draft at all.  Folks,
there is more than scaling and availability going on here.

John

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

Re: [DNSOP] various approaches to dns channel secrecy

[John Kristoff]

On Fri, 04 Jul 2014 20:04:02 -0700
Paul Vixie p...@redbarn.org wrote:

 first, dns data itself is public -- the data is there for anybody to
 query for it, if you know what to query for. only the question,
 questioner, and time can be kept secret. answers are only worth
 keeping secret because they identify the question, questioner, and
 time.

Hi Paul,

This may traditionally be true and ideally in the coherent name space
world be true, but is not necessarily true.  Thanks to views and other
so-called DNS tricks, particularly those that in essence or a weak
form of authentication (or even stronger form such as when attaching
TSIG to them), answers that may never otherwise be seen by some subset
of clients, or perhaps more correctly synthesized for some clients, may
be candidates for enhanced secrecy.

I wouldn't necessarily optimize for or argue to support such uses, just
pointing out that they do exist in some corner cases.

 by implication, then, the remainder of possible problem statement
 material is hide question from on-wire surveillance, there being no
 way to hide the questioner or the time. to further narrow this, the
 prospective on-wire surveillance has to be from third parties who are
 not also operators of on-path dns protocol agents, because any second
 party could be using on-wire surveillance as part of their logging
 solution, and by (2) above there is no way to hide from them. so we're
 left with hide question from on-wire surveillance by third parties.

This sounds like DNSCurve's approach.

John

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

Re: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt

[John Kristoff]

On Fri, 2 Mar 2012 09:56:40 -0800
Eric Osterweil eosterw...@verisign.com wrote:

 We have resurrected our draft Improving DNS Service Availability by
 Using Long TTL Values, and added some new polish to it.  We've taken
 some feedback from various people and would love to hear any thoughts
 other people have.

Hi Eric,

I remember this draft from years ago so I'll resurrect and update my
comments on the subject as well.

I'm not convinced these long TTLs are for everyone , though of course
I'm not opposed to it, from an operational perspective I would need to
be convinced this is worthwhile.  I think ultimately it depends on
the operator.  There doesn't seem to be much critical analysis in why
this might not be desirable. I'll try to offer some.

Practically speaking, while caching to avoid transient issues may be
highly desirable, you may find that many operators would prefer to
build their network to get as many queries as possible even if that
leaves that part of the hierarchy at risk when transient issues arise.
Queries, even and often especially if unnecessary, have intrinsic
intelligence value.

In the Introduction there is this sentence:

   Furthermore, the use of shared unicast introduces one entry in the
   global BGP routing for every shared unicast enabled server.

This is misleading.  There may be many unique announcements from each
each anycast instance, but each router's global table will use only one
as long as the prefix is consistent.

Does the deployment of DNSSEC change any of the underlying assumptions?

The references used in section two are now quite old.  Updated
measurement results to ensure they support the recommendations would be
nice.

After reading section 3.3, I wrote to myself Such as?  What sorts of
changes are you alluding to?

This is designed specifically for the root and TLDs, yes?  It might be
helpful to make this stipulation more clear in the Recommendations
section.

It seems to me that this may be a useful document to help folks
design their own strategy for infrastructure RRs.  I would approach
it that way, as an informational guide demonstrating how to do it and
why you might want to.  I'm not convinced everyone should.  At least
you've not convinced me yet.  :-)

For background, this is related:

  https://lists.dns-oarc.net/pipermail/dns-operations/2006-April/000503.html

Note, the concern about uncooperative authoritative DNS servers.

Lixia sought comments from the DNS operations community on this topic in
2007 and I followed up offline.  I'll include that follow up here for
posterity and since it may never have made it to you since it includes
the concern mentioned above.

  Date: Thu, 22 Mar 2007 17:54:05 -0500
  From: John Kristoff j...@ultradns.net
  To: Lixia Zhang li...@cs.ucla.edu
  Cc: Daniel Massey mas...@cs.colostate.edu, Vasileios Pappas 
vpap...@us.ibm.com, Steve Crocker st...@shinkuro.com
  Subject: Re: [dns-operations] Seeking input regarding TTL value for 
infrastructure RRs

  On Wed, 21 Mar 2007 15:13:32 -0700
  Lixia Zhang li...@cs.ucla.edu wrote:

   Note that in this talk we separate out infrastructure RRs from all  
   other RRs.
   Some people  might argue that they dont want long TTL values because  
   their hosts move around a lot, but we have not directly heard from  
   anyone saying they moving their DNS servers around on a daily or even  
   weekly basis.

  And in fact that might be pretty hard to fully accomplish quickly anyway
  if there are glue records in some parent zone they don't control.

   But as Vasilis reasoned above, if child zone's response overwrites  
   whatever one learned from the parent zone, then what I said on  
   slide-9 still holds true, right?  i.e. a zone can choose to set long  
   TTL for its NS+A RRs to make itself more available.

  There is that damage problem, which I think is going to be a point of
  contention long term.  If a zone owner wants to move their zone and
  the zone server administrator decides to set a TTL really high, the
  server administrator can effectively hijack the domain for a long
  time.  This doesn't seem to happen in practice much today, but it
  could easily become a lock-in problem we'd want to avoid.

   What John meant here is to be able to move one's DNS servers around  
   quickly to get around the attack traffic.
   
   But wouldn't this also require that one have to update the parent  
   quickly?  Can people actually coordinate that well in short time scale?

  For some parents it should be do-able.

   (Vasilis also did a massive measurement on lame delegations, people  
   don't even seem to be able to fix long term inconsistencies between  
   parent and child zones :-)

  Oh yeah, that's a big problem too.  Here are a few other areas Of
  interest I've been looking at.  If you want to collaborate on some
  of this stuff, let me know, I'd love to:

open resolvers (fully open, caching only and auth only)
EDNS0 max size discrepancies
reserved