[DNSOP] Fwd: I-D Action: draft-song-dns-wireformat-http-02.txt

[Davey Song]

We have updated the draft as follows:

* fixed typos
* made "transport:" always required
* mentioned the possibility to use DNS over HTTP in a browser, if you
really want to
* made the language stronger when talking about the 2-byte length label in
TCP
* expanded the security considerations. We go through RFC 3552, but do not
find it applies much since we're basically just layering on HTTP.
* give a explanation why using POST and try to answer the questions from
the mailing list.
* call for a Well-Know URI like /.well-known/dns-over-http. But I think It
is still open for future edition.
* add a co-author who contributed the first implementation and details of
this protocol.

Thanks to Bob Harold and Paul Hoffman for review. I'm sorry for wrongly
using dismissive words and may offending many people in the discussions.
Thanks for reminding me this as well.

Best regards,
Davey

-- Forwarded message --
From: 
Date: Mon, Mar 21, 2016 at 6:07 PM
Subject: I-D Action: draft-song-dns-wireformat-http-02.txt
To: i-d-annou...@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title   : DNS wire-format over HTTP
Authors : Linjian Song
  Paul Vixie
  Shane Kerr
  Runxia Wan
Filename: draft-song-dns-wireformat-http-02.txt
Pages   : 9
Date: 2016-03-21

Abstract:
   This memo introduces a way to tunnel DNS data over HTTP.  This may be
   useful in any situation where DNS is not working properly, such as
   when there is middlebox misbehavior.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-song-dns-wireformat-http-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

Title   : Client Subnet in DNS Queries
Authors : Carlo Contavalli
  Wilmer van der Gaast
  David C Lawrence
  Warren Kumari
Filename: draft-ietf-dnsop-edns-client-subnet-07.txt
Pages   : 32
Date: 2016-03-21

Abstract:
   This document describes an EDNS0 extension that is in active use to
   carry information about the network that originated a DNS query, and
   the network for which the subsequent response can be cached.  Since
   it has some known operational and privacy shortcomings, a revision
   will be worked through the IETF for improvement.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-client-subnet-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[DNSOP] Stephen Farrell's No Objection on draft-ietf-dnsop-edns-client-subnet-07: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-client-subnet-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/



--
COMMENT:
--


Thanks for handling my discuss point and the comments
below (which I didn't check in detail, but am happy to
chat about it you want).

Cheers,
S.


- abstract: I think it'd be good if the abstract noted that this
was documenting a deployed option and not necessarily
recommending this as the best thing ever. There's text in the
write-up and intro that does that nicely that could work if
reduced to one sentence, e.g. maybe something like: "This
documents an EDNS0 option that is in active use on the Internet
today that is intended to be revised in the near future to
improve it's security and privacy features."  

- Thanks for section 2.

- 7.2.2 says "Because a client that did not use an ECS option
might not be able to understand it, the server MUST NOT provide
one in its response." That seems like a bit of a pity - one
comment I was going to make was that it might be good to include
this (or something) in a response so that a client that didn't
ask for ECS could be informed that some DNS server is doing ECS.
Would that actually break things? 

- section 10 has RFC1918 as a SHOULD but doesn't refer to e.g.
RFC6598 at all.  RFC6890 has a MAY associated with it, but does
refer to 6598. And what about stuff like RFC7534, which isn't
mentioned? Is that all correct and up to date? 

- 11.1, 4th para: "Users" isn't really right. People don't know
about any of this stuff really. "Clients" would be more accurate


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

[Mukund Sivaraman]

Hi all

On Mon, Mar 21, 2016 at 06:08:39AM -0700, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
> Title   : Client Subnet in DNS Queries
> Authors : Carlo Contavalli
>   Wilmer van der Gaast
>   David C Lawrence
>   Warren Kumari
>   Filename: draft-ietf-dnsop-edns-client-subnet-07.txt
>   Pages   : 32
>   Date: 2016-03-21
> 
> Abstract:
>This document describes an EDNS0 extension that is in active use to
>carry information about the network that originated a DNS query, and
>the network for which the subsequent response can be cached.  Since
>it has some known operational and privacy shortcomings, a revision
>will be worked through the IETF for improvement.

This revision is a welcome improvement on the previous revision of the
draft.

There are still some minor topics that need consideration (after
off-list discussions among people on the dnsop list). These have been
sent to the author. I'm listing them here for completeness:

(1) Section 7.2.1.  Authoritative Nameserver:

> When deaggregating to correct the overlap, prefix lengths should be
> optimized to use the minimum necessary to cover the address space, in
> order to reduce the overhead that results from having multipe copies
> of the same answer.  As a trivial example, if the Tailored Response
> for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then
> the Authoritative Nameserver would need to provide Tailored Responses
> for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and
> 1.2.3/24 to B.

This is a greatly improved description. It would be good to add here
that the authoritative server would also have to provide the following
*exact-match* tailored responses in ADDRESS/SOURCE/SCOPE syntax (for
corresponding ADDRESS/SOURCE queries):

1.2.2/23/24 pointing to A
1.2.0/22/24 pointing to A
1.2.0/21/24 pointing to A
1.2.0/20/24 pointing to A

which should be cached to exactly match the SOURCE prefix length.

(2) Section 7.3.2.  Answering from Cache:

> o  If there was an ECS option specifying SOURCE PREFIX-LENGTH but no
>ADDRESS, the client's address is used but SOURCE PREFIX-LENGTH is
>initially ignored. 

Wouldn't this be a FORMERR according to section 6 (option format)?

(3)

An authoritative server replies with SCOPE > SOURCE in some cases. This
is now described in detail in the -07 revision of the draft.

Let's assume a local resolver as SOURCE=16 configured as policy.  A
client 10.0.0.1 queries the resolver and the resolver's cache is
empty. The resolver queries a remote nameserver with 10.0.0.0/16 and the
auth server responds with 10.0.0.0/16/24.  It means that the answer is
strictly valid for 10.0.0.0/16 only, because it has a more specific /24
answer for some subnet under 10.0.0.0/16.

In this case, the resolver caches the answer at 10.0.0.0/16 with an
exact-match flag set to true.

Now assume that the same client 10.0.0.1 sends a second query to the
resolver for the same question. Now, these two cases can happen:

(a) the resolver looks in cache for 10.0.0.0/16 for a previously cached
answer because SOURCE=16 and finds the exactly matching answer.

(b) the resolver looks in cache for 10.0.0.1/32 and does not find the
previously cached answer.

It seems that (a) is the correct or desirable behavior. However, the
draft seems to suggest (b) which is not optimal. See section 7.3.2
(Answering from Cache):

> Cache lookups are first done as usual for a DNS query, using the
> query tuple of .  Then the appropriate RRset MUST
> be chosen based on longest prefix matching.  The client address to
> use for comparison will depend on whether the Intermediate Nameserver
> received an ECS option in its client query.
>
> o  If no ECS option was provided, the client's address is used.

This should be updated to say something like "If no ECS option was
provided, the client's address and the value of its maximum cacheable
prefix length are used to construct an address prefix to search in the
cache".

(4)

This observation is from Stephen Morris:

From section 7.3.1 (Caching the Response):

> If SOURCE PREFIX-LENGTH is shorter than the configured maximum and
> SCOPE PREFiX-LENGTH is longer than SOURCE PREFIX-LENGTH, store SOURCE
> PREFIX-LENGTH bits of ADDRESS and mark the response as only valid to
> answer client queries that specify exactly the same SOURCE PREFIX-
> LENGTH in their own ECS option.
   
When there are overlapping answers, and SCOPE > SOURCE is returned, if
the SOURCE PREFIX-LENGTH that is returned by the authoritative server is
the *shortest* prefix length of a more specific answer that the
authoritative server has under /SOURCE, the answer would be valid
not ju

Re: [DNSOP] Introducing draft-wouters-sury-dnsop-algorithm-update

[Rose, Scott]

This draft should also serve to obsolete RFC 6944.

Scott


On 19 Mar 2016, at 15:43, Paul Wouters wrote:

> Hi,
>
> there was an interest in deprecating some DNSSEC related algorithms.
> Ondrey and I wrote a draft that tries to introduce and depricate
> DNSSEC algorithms similar to how it has been done for IKE in RFC4307
> and 4307bis:
>
> Comments, feedback would be great :)
>
> https://tools.ietf.org/html/draft-wouters-sury-dnsop-algorithm-update
>
> Paul
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


==
Scott Rose, NIST
sco...@nist.gov
ph: +1-301-975-8439
Google Voice: +1-571-249-3671

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-priming-07.txt

[Bob Harold]

On Sat, Mar 19, 2016 at 10:57 AM, Paul Hoffman 
wrote:

> On 19 Mar 2016, at 10:51, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations of the
>> IETF.
>>
>> Title   : Initializing a DNS Resolver with Priming Queries
>> Authors : Peter Koch
>>   Matt Larson
>>   Paul Hoffman
>> Filename: draft-ietf-dnsop-resolver-priming-07.txt
>> Pages   : 6
>> Date: 2016-03-19
>>
>
>
> Thank you to the WG for the editorial changes in this draft. There are
> still a few outstanding issues:
>
> The WG discussed the sentence:
>The RD bit MAY be set to 0 or 1, although the meaning of it being set
> to 1 is
>undefined for priming queries.
> However, there were widely-varying opinions and no consensus about change.
>
> With respect to the DO bit, there was a suggestion:
>   Resolvers SHOULD send DO, and should try validate (if it gets signed
> responses).
>   This is pointless at the moment, but if / when we end up with signed
> root-servers.net
>   (or foo.bar) it would be nice if the right things were already being
> done.
> There was some agreement on this, but then it was pointed out that the
> response might be
> larger than the typical size set in EDNS(0) requests. And then the
> discussion got lost.
>
> It would be grand to resolve these (and any other issues folks have) on
> the list before the Buenos Aires meeting so that the face-to-face
> discussion is more valuable.
>
> --Paul Hoffman
>
>
Minor question:
"if the recursive resolver did not announce a reassembly size larger than
512 octets"

Does that mean 513 is enough?   I would prefer wording like "at least xxx"
rather that "larger than xxx"
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

Title   : The ALT Special Use Top Level Domain
Authors : Warren Kumari
  Andrew Sullivan
Filename: draft-ietf-dnsop-alt-tld-04.txt
Pages   : 10
Date: 2016-03-21

Abstract:
   This document reserves a string (ALT) to be used as a TLD label in
   non-DNS contexts or for names that have no meaning in a global
   context.  It also provides advice and guidance to developers
   developing alternate namespaces.

   [ Ed note: This document lives in GitHub at:
   https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and
   pull requests happily accepted. ]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-04.txt

[Warren Kumari]

Nothing to see here, move along.

(this is just a version bump to keep it alive - sorry)
W
On Mon, Mar 21, 2016 at 10:31 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
> Title   : The ALT Special Use Top Level Domain
> Authors : Warren Kumari
>   Andrew Sullivan
> Filename: draft-ietf-dnsop-alt-tld-04.txt
> Pages   : 10
> Date: 2016-03-21
>
> Abstract:
>This document reserves a string (ALT) to be used as a TLD label in
>non-DNS contexts or for names that have no meaning in a global
>context.  It also provides advice and guidance to developers
>developing alternate namespaces.
>
>[ Ed note: This document lives in GitHub at:
>https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and
>pull requests happily accepted. ]
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] I-D Action: draft-ietf-dnsop-alt-tld-04.txt

[Shane Kerr]

Warren,

So, um... what's the status here? Is this basically just on hold
waiting for RFC 6761 movement? Or...?

Cheers,

--
Shane

At 2016-03-21 14:35:08 +
Warren Kumari  wrote:

> Nothing to see here, move along.
> 
> (this is just a version bump to keep it alive - sorry)
> W
> On Mon, Mar 21, 2016 at 10:31 AM  wrote:
> 
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Domain Name System Operations of the IETF.
> >
> > Title   : The ALT Special Use Top Level Domain
> > Authors : Warren Kumari
> >   Andrew Sullivan
> > Filename: draft-ietf-dnsop-alt-tld-04.txt
> > Pages   : 10
> > Date: 2016-03-21
> >
> > Abstract:
> >This document reserves a string (ALT) to be used as a TLD label in
> >non-DNS contexts or for names that have no meaning in a global
> >context.  It also provides advice and guidance to developers
> >developing alternate namespaces.
> >
> >[ Ed note: This document lives in GitHub at:
> >https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and
> >pull requests happily accepted. ]
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-04
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-04
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >  


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-04.txt

[Suzanne Woolf]

Shane,

Yes. The chairs fondly hope that the WG will be able to adopt a problem 
statement in the near future, which will in turn make it a bit easier to 
explain what problem alt-tld is solving when we look for WG and IETF 
consensus on it.



Suzanne

On 3/21/16 11:05 AM, Shane Kerr wrote:

Warren,

So, um... what's the status here? Is this basically just on hold
waiting for RFC 6761 movement? Or...?

Cheers,

--
Shane

At 2016-03-21 14:35:08 +
Warren Kumari  wrote:


Nothing to see here, move along.

(this is just a version bump to keep it alive - sorry)
W
On Mon, Mar 21, 2016 at 10:31 AM  wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations of the IETF.

 Title   : The ALT Special Use Top Level Domain
 Authors : Warren Kumari
   Andrew Sullivan
 Filename: draft-ietf-dnsop-alt-tld-04.txt
 Pages   : 10
 Date: 2016-03-21

Abstract:
This document reserves a string (ALT) to be used as a TLD label in
non-DNS contexts or for names that have no meaning in a global
context.  It also provides advice and guidance to developers
developing alternate namespaces.

[ Ed note: This document lives in GitHub at:
https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and
pull requests happily accepted. ]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-04


Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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


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

Re: [DNSOP] Introducing draft-wouters-sury-dnsop-algorithm-update

[Paul Wouters]

On Mon, 21 Mar 2016, Rose, Scott wrote:


This draft should also serve to obsolete RFC 6944.


Just submitted -01 which does that, and also adjusts the levels for GOST
and ECDSAP384SHA384.

https://tools.ietf.org/rfcdiff?url2=draft-wouters-sury-dnsop-algorithm-update-01.txt

https://tools.ietf.org/html/draft-wouters-sury-dnsop-algorithm-update-01

Paul

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

Re: [DNSOP] Fwd: I-D Action: draft-song-dns-wireformat-http-02.txt

[Shane Kerr]

Davey,

Thanks! Some expanded comments from me, inline below...

At 2016-03-21 18:43:02 +0800
Davey Song  wrote:

> We have updated the draft as follows:
> 
> * fixed typos
> * made "transport:" always required

We had it implicitly optional if a client was using the protocol
directly (rather than converting a stub resolver DNS packet). However
this was quite correctly pointed out to be silly, so now we are always
explicit about it.

> * mentioned the possibility to use DNS over HTTP in a browser, if you
> really want to

It really doesn't make sense to use this technology in a browser, but I
grudgingly admit that it is *possible*, for someone very determined.

> * made the language stronger when talking about the 2-byte length label in
> TCP

I've tried 2x to make this clearer now. If this one is still confusing
then I either need to ask someone else to write this or I'll delete
this completely, do some tequila shots, and then try from scratch in a
new state of mind. ;)

> * expanded the security considerations. We go through RFC 3552, but do not
> find it applies much since we're basically just layering on HTTP.

If anyone has recommendations for a document that we can refer to which
covers security problems with DNS, HTTP, or TLS, that would be great.
Right now I resorted to saying "yeah, any problems in DNS, HTTP, or TLS
can be a problem here too" without references, because they do not
appear to exist.

> * give a explanation why using POST and try to answer the questions from
> the mailing list.
> * call for a Well-Know URI like /.well-known/dns-over-http. But I think It
> is still open for future edition.

Yes, I was unsure whether this makes sense. To be clear, I am not
opposed to the "/.well-known" approach, I'm just curious if it is
actually widely used.

> * add a co-author who contributed the first implementation and details of
> this protocol.

An international man of mystery. ;)
 
> Thanks to Bob Harold and Paul Hoffman for review. 

Yes, thank you!

I also note that someone pointed out that DNS over HTTP requires more
data, which can be a problem on slow links. I honestly hadn't really
considered this because the main concern when we were testing this was
extra RTT and the related latency. I admit this could be an issue for
some use cases. Is this important enough to merit some discussion in
the document?

Cheers,

--
Shane


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

[神明達哉]

At Mon, 21 Mar 2016 19:21:59 +0530,
Mukund Sivaraman  wrote:

> (1) Section 7.2.1.  Authoritative Nameserver:
>
> > When deaggregating to correct the overlap, prefix lengths should be
> > optimized to use the minimum necessary to cover the address space, in
> > order to reduce the overhead that results from having multipe copies
> > of the same answer.  As a trivial example, if the Tailored Response
> > for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then
> > the Authoritative Nameserver would need to provide Tailored Responses
> > for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and
> > 1.2.3/24 to B.

I'm confused about the revised Section 7.2.1 regarding overlapping
prefixes.  The 07 version of the draft now states:

   [...]  Because it can't be guaranteed that queries for all
   longer prefix lengths would arrive before one that would be answered
   by the shorter prefix length, an Authoritative Nameserver MUST NOT
   overlap prefixes.

But the above "trivial example" seems to talk about what an
authoritative nameserver would do if it overlaps prefix...doesn't it
simply break the MUST NOT in the first place?

Also (ignoring the MUST NOT), what if a query is sent with a source
prefix 1.2.1/24?  The best matching prefix is 1.2.0/20, so isn't the
tailored response A with the scope prefix length of 20?  I mean,
shouldn't the above deaggregated prefixes be incomplete?

--
JINMEI, Tatuya

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

[DNSOP] New I-D on DNSSEC crypto algorithm agility - Fwd: New Version Notification for draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt

[Dan York]

DNSOP members,

Today a group of us submitted a draft starting to document the operational 
steps (and issues) around deploying new crypto algorithms within DNSSEC.  This 
builds off of a couple of sessions we've had at DNSSEC Workshops at ICANN 
meetings as well as various mailing list discussion.  This overall discussion 
about deploying new DNSSEC crypto algorithms will continue with a session 
organized by Ondrej Sury at DNS-OARC on April 1 in Buenos Aires and then 
another one at RIPE in Copenhagen.

The goal right now is to document the deployment steps so that there is a 
common understanding and operational guidance can be provided. Ideally in the 
process we may also highlight opportunities for improvement of operational 
processes.

Comments and feedback are definitely welcome.

Thanks,
Dan

Begin forwarded message:

From: mailto:internet-dra...@ietf.org>>
Subject: New Version Notification for 
draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt
Date: March 21, 2016 at 2:29:57 PM EDT
To: "y...@isoc.org" 
mailto:y...@isoc.org>>, Ondrej Sury 
mailto:ondrej.s...@nic.cz>>, "Olafur Gudmundsson" 
mailto:olafur+i...@cloudflare.com>>, Dan York 
mailto:y...@isoc.org>>, "Paul Wouters" 
mailto:pwout...@redhat.com>>


A new version of I-D, draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt
has been successfully submitted by Dan York and posted to the
IETF repository.

Name: draft-york-dnsop-deploying-dnssec-crypto-algs
Revision: 00
Title: Observations on Deploying New DNSSEC Cryptographic Algorithms
Document date: 2016-03-21
Group: Individual Submission
Pages: 9
URL:
https://www.ietf.org/internet-drafts/draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
Htmlized:   
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-00


Abstract:
  As new cryptographic algorithms are developed for use in DNSSEC
  signing and validation, this document captures the steps needed for
  new algorithms to be deployed and enter general usage.  The intent is
  to ensure a common understanding of the typical deployment process
  and potentially identify opportunities for improvement of operations.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org.

The IETF Secretariat


--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/




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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

[Mukund Sivaraman]

Hi Jinmei

On Mon, Mar 21, 2016 at 11:38:35AM -0700, 神明達哉 wrote:
> At Mon, 21 Mar 2016 19:21:59 +0530,
> Mukund Sivaraman  wrote:
> 
> > (1) Section 7.2.1.  Authoritative Nameserver:
> >
> > > When deaggregating to correct the overlap, prefix lengths should be
> > > optimized to use the minimum necessary to cover the address space, in
> > > order to reduce the overhead that results from having multipe copies
> > > of the same answer.  As a trivial example, if the Tailored Response
> > > for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then
> > > the Authoritative Nameserver would need to provide Tailored Responses
> > > for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and
> > > 1.2.3/24 to B.
> 
> I'm confused about the revised Section 7.2.1 regarding overlapping
> prefixes.  The 07 version of the draft now states:
> 
>[...]  Because it can't be guaranteed that queries for all
>longer prefix lengths would arrive before one that would be answered
>by the shorter prefix length, an Authoritative Nameserver MUST NOT
>overlap prefixes.
> 
> But the above "trivial example" seems to talk about what an
> authoritative nameserver would do if it overlaps prefix...doesn't it
> simply break the MUST NOT in the first place?

When overlapped address prefixes occur in zone data (the configuration
provided by an administrator to the authoritative nameserver), the
authoritative server should resolve the overlap by deaggregating
prefixes such that the prefixes in the Authoritative Nameserver's reply
messages do not overlap.

The "Authoritative Nameserver MUST NOT overlap prefixes" requirement is
in the reply messages that it generates. But it can accept overlapping
prefixes as configuration and deaggregate to non-overlapping prefixes.

> Also (ignoring the MUST NOT), what if a query is sent with a source
> prefix 1.2.1/24?  The best matching prefix is 1.2.0/20, so isn't the
> tailored response A with the scope prefix length of 20?  I mean,
> shouldn't the above deaggregated prefixes be incomplete?

The 1.2.1/24 case would be covered by 1.2.0/23 listed in the example.
So a query with 1.2.1/24/0 would be replied to with 1.2.1/24/23.

If the auth had responded instead with 1.2.1/24/20, that would be cached
at address prefix 1.2.0/20 in the resolver's cache and a future query
for 1.2.3/24 would match it.

Mukund


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

[DNSOP] Deprecating classes

[Andrew Sullivan]

Dear colleagues,

Thanks for the many helpful comments.  I've updated the DNS Is Not
Classy I-D to close the registry.  The new draft is at
https://datatracker.ietf.org/doc/draft-sullivan-dns-class-useless/.

Best regards,

A

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

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

[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

Title   : DNSSEC Roadblock Avoidance
Authors : Wes Hardaker
  Olafur Gudmundsson
  Suresh Krishnaswamy
Filename: draft-ietf-dnsop-dnssec-roadblock-avoidance-03.txt
Pages   : 18
Date: 2016-03-21

Abstract:
   This document describes problems that a DNSSEC aware resolver/
   application might run into within a non-compliant infrastructure.  It
   outline potential detection and mitigation techniques.  The scope of
   the document is to create a shared approache to detect and overcome
   network issues that a DNSSEC software/system may face.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Hi,

there was an interest in reducing latency for address record lookups.
Me and Olafur wrote a draft on adding  records to A answers and
treating them as authoritative. This fixes latency issues with NS
A/ discovery in resolvers and improves caching for clients (
already cached by the time client comes asking for it).

Comments, feedback and snarky remarks would be great!
https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Mark Andrews]

Well we really want to get rid of A lookups.   Why don't we just
recommend that we publish mapped A records in  RRsets and have
master servers update  RRsets if they are inconsitent with the
A RRsets.

We also need a way to signal that there are no A records in the
 RRset.  :::255.255.255.255 or :::0.0.0.0 would be
sensible records to indicate this.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Vixie]

Marek Vavruša wrote:

...

https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/


+1. we ought to have done this from the get-go.

--
P Vixie

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Wouters]

On Mon, 21 Mar 2016, Marek Vavruša wrote:


there was an interest in reducing latency for address record lookups. Me and 
Olafur wrote a draft on adding  records to A answers and treating them as 
authoritati
ve. This fixes latency issues with NS A/ discovery in resolvers and 
improves caching for clients ( already cached by the time client comes 
asking for it).

Comments, feedback and snarky remarks would be great!

https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/


I think this draft is a good idea. It does need some more writing out of
the use case and the possible interaction with some of the answer
sections. And some additional guidance with CNAME's with and without
DNSSEC.

Some comments/questions:


What happens with the Answer Count for QTYPE=A when there are no A
records and only  records? And can the examples also clarify this?

What is the logic behind:

   However, if there is a direct answer to the original question, but no
   records for other address protocols, the authoritative DNS server
   SHOULD NOT prove their non-existence.  In this respect, they are
   treated as additional data.

Are you just afraid of packet size to include the proofs? Because now
a client cannot distinguish between an old auth server not supporting
this draft and a new server supporting this draft (when no additional
A/ exist to add). So if it wants to know about the other QTYPE,
it will need to make another query, even for auth servers implementing
this draft. Which is exactly what this draft is trying to prevent.

What is SNAME? Did you mean QNAME?

I'm also a little confused that section 3 auth servers only talks about A
and section 4 recursive servers only talks about . I like short
documents but I think you need to write this out a bit more :)


   and it MUST reject any such records if the validation
   fails, and the zone is not provably secure.

That's awkwardly written. If the zone is not provably secure (which is a
term you should not use, and instead use Bogus, Indeterminate. Insecure
or Secure) then there is nothing to validate - if you meant Insecure. If
you meant Indeterminate or Bogus, other text is warranted.

I think you mean to say if the zone _is_ secure, then any records in it
must be proven secure too.


   other IP address records

You mean other QTYPE's for IP addresses :P


I don't think the Security Considerations use case mentioned is worth
mentioning. What is worth mentioning is if this involves CNAMEs,
because that leads to out of bailiwick data. And complications with
DNSSEC (chains to other zones?) and without (free Kaminsky attack)

Paul

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Wouters]

On Tue, 22 Mar 2016, Mark Andrews wrote:


Well we really want to get rid of A lookups.   Why don't we just
recommend that we publish mapped A records in  RRsets and have
master servers update  RRsets if they are inconsitent with the
A RRsets.

We also need a way to signal that there are no A records in the
 RRset.  :::255.255.255.255 or :::0.0.0.0 would be
sensible records to indicate this.


That's a terrible hack and error prone to implement.

Paul

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

Who wants to get rid of A lookups? "A" is going to be here for a while and
using it as a generic mean to get all addresses of given protocol
(regardless of version) gives servers a way to smoothly transition over
versions.
If the A was updated to have a variable address length, then it could be
used to hand out any address with different RDLEN instead of making new
type. I'm dreading of a day when somebody implements A,, and 
lookup in glibc stub in parallel.

On Mon, Mar 21, 2016 at 4:58 PM, Mark Andrews  wrote:

>
> Well we really want to get rid of A lookups.   Why don't we just
> recommend that we publish mapped A records in  RRsets and have
> master servers update  RRsets if they are inconsitent with the
> A RRsets.
>
> We also need a way to signal that there are no A records in the
>  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> sensible records to indicate this.


Do we need that? I'd be happy if clients use just A for IP lookups, and
then use
 if only  falls out of cache. Can't think of a good use case.


>
> Mark
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Mark Andrews]

Or we could defined the "aaa" (A and ) {E}DNS bit where the
server guarantees that the response contains both the A and 
answers for A or  queries if aaa=1 in the response.

Recursive servers would lookup A/ records if cache is missing
them before returning a response.

If the A /  does not fit into the additional section then TC=1
is set.

NOERROR NODATA is valid for both types if aaa=1 in the response.

This way you could signal that you want both A and  records and
if you don't want both then the response does not have the other
type added.

Yes, we would have to nuke the stupid servers that reflect back
{E}DNS flags.  We would also have nuke the stupid firewalls that
block {E}DNS queries with a unknown flag bit set.

Mark

Mark Andrews writes:
> 
> Well we really want to get rid of A lookups.   Why don't we just
> recommend that we publish mapped A records in  RRsets and have
> master servers update  RRsets if they are inconsitent with the
> A RRsets.
> 
> We also need a way to signal that there are no A records in the
>  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> sensible records to indicate this.
> 
> Mark
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

On Mon, Mar 21, 2016 at 5:14 PM, Paul Wouters  wrote:

> On Mon, 21 Mar 2016, Marek Vavruša wrote:
>
> there was an interest in reducing latency for address record lookups. Me
>> and Olafur wrote a draft on adding  records to A answers and treating
>> them as authoritati
>> ve. This fixes latency issues with NS A/ discovery in resolvers and
>> improves caching for clients ( already cached by the time client comes
>> asking for it).
>>
>> Comments, feedback and snarky remarks would be great!
>>
>> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>>
>
> I think this draft is a good idea. It does need some more writing out of
> the use case and the possible interaction with some of the answer
> sections. And some additional guidance with CNAME's with and without
> DNSSEC.
>

Agreed, thanks for taking time commenting.


> Some comments/questions:
>
>
> What happens with the Answer Count for QTYPE=A when there are no A
> records and only  records? And can the examples also clarify this?
>
>
That's an example 5.3


> What is the logic behind:
>
>However, if there is a direct answer to the original question, but no
>records for other address protocols, the authoritative DNS server
>SHOULD NOT prove their non-existence.  In this respect, they are
>treated as additional data.
>
> Are you just afraid of packet size to include the proofs? Because now
> a client cannot distinguish between an old auth server not supporting
> this draft and a new server supporting this draft (when no additional
> A/ exist to add). So if it wants to know about the other QTYPE,
> it will need to make another query, even for auth servers implementing
> this draft. Which is exactly what this draft is trying to prevent.
>

The proposal is opt-in, if the authoritative decides to throw in 
addresses
then client should accept them. If it doesn't then it should requery. This
is of course
going to reduce the effectiveness in the transition period for names that
have A, but don't have 
which is something I expect to change.

The rationale is not to carry unnecessary payload when most authoritatives
support it, but you make a good point
that it might be better to mandate denial of non-existence proof now, and
amend the draft later.


> What is SNAME? Did you mean QNAME?
>

SNAME as in RFC1034, either QNAME or CNAME chain terminal name.

I'm also a little confused that section 3 auth servers only talks about A
> and section 4 recursive servers only talks about . I like short
> documents but I think you need to write this out a bit more :)
>
>
>and it MUST reject any such records if the validation
>fails, and the zone is not provably secure.
>
> That's awkwardly written. If the zone is not provably secure (which is a
> term you should not use, and instead use Bogus, Indeterminate. Insecure
> or Secure) then there is nothing to validate - if you meant Insecure. If
> you meant Indeterminate or Bogus, other text is warranted.
>
> I think you mean to say if the zone _is_ secure, then any records in it
> must be proven secure too.
>

Fair enough!

   other IP address records
>
> You mean other QTYPE's for IP addresses :P
>
>
> I don't think the Security Considerations use case mentioned is worth
> mentioning. What is worth mentioning is if this involves CNAMEs,
> because that leads to out of bailiwick data. And complications with
> DNSSEC (chains to other zones?) and without (free Kaminsky attack)
>
> Paul
>

The CNAMEs should be covered by the SNAME part, owner has to either match
QNAME or terminal of CNAME chain just as a direct answer would. Maybe it
needs a clarification.

Thanks!

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Marek Vavruša]

I see the point but I don't really want to go down the EDNS route.
So presuming that this draft catches on and Alexa 1M NSs publish at least
one  record,
there would be no need for two queries in most cases and no need for
additional signalisation.
If they don't publish  records, then the resolver will still have to do
the same thing as today,
however that also means that IPv6 adoption is stalled and possibly
irrelevant.

TL;DR the draft optimises first case, if the second case proves to be valid
then we can always amend the draft but I don't want to overengineer it from
the start and it's always much easier to add than to remove.

Marek


On Mon, Mar 21, 2016 at 5:26 PM, Mark Andrews  wrote:

>
> Or we could defined the "aaa" (A and ) {E}DNS bit where the
> server guarantees that the response contains both the A and 
> answers for A or  queries if aaa=1 in the response.
>
> Recursive servers would lookup A/ records if cache is missing
> them before returning a response.
>
> If the A /  does not fit into the additional section then TC=1
> is set.
>
> NOERROR NODATA is valid for both types if aaa=1 in the response.
>
> This way you could signal that you want both A and  records and
> if you don't want both then the response does not have the other
> type added.
>
> Yes, we would have to nuke the stupid servers that reflect back
> {E}DNS flags.  We would also have nuke the stupid firewalls that
> block {E}DNS queries with a unknown flag bit set.
>
> Mark
>
> Mark Andrews writes:
> >
> > Well we really want to get rid of A lookups.   Why don't we just
> > recommend that we publish mapped A records in  RRsets and have
> > master servers update  RRsets if they are inconsitent with the
> > A RRsets.
> >
> > We also need a way to signal that there are no A records in the
> >  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> > sensible records to indicate this.
> >
> > Mark
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Mark Andrews]

In message 
, 
=?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
> 
> I see the point but I don't really want to go down the EDNS route.

Why not?  It is cleaner as it deals with A-only, A and , and
-only sites without a second lookup once support is deployed.
It is supportable on a hop by hop basis.

Just adding records w/o signalling is a waste of effort and bandwidth
if the server does not support the extra records.

https://ednscomp.isc.org/compliance/summary.html show current unknown
EDNS flags behaviour.  It also shows that you can change behaviour
with a little education.

Signaling also allows you to put both answers in the answer section.

> So presuming that this draft catches on and Alexa 1M NSs publish at least
> one  record,  there would be no need for two queries in most cases
> and no need for additional signalisation. If they don't publish 
> records, then the resolver will still have to do the same thing as today,
> however that also means that IPv6 adoption is stalled and possibly
> irrelevant.

IPv6 is here to stay.  IPv4 is very much in its death throws at the moment.
 
> TL;DR the draft optimises first case, if the second case proves to be
> valid then we can always amend the draft but I don't want to overengineer
> it from the start and it's always much easier to add than to remove.

You can also under engineer.  There is no way to measure client
support as it currently is.  A flag provides you with the ability
to measure client support.

> Marek
> 
> 
> On Mon, Mar 21, 2016 at 5:26 PM, Mark Andrews  wrote:
> 
> >
> > Or we could defined the "aaa" (A and ) {E}DNS bit where the
> > server guarantees that the response contains both the A and 
> > answers for A or  queries if aaa=1 in the response.
> >
> > Recursive servers would lookup A/ records if cache is missing
> > them before returning a response.
> >
> > If the A /  does not fit into the additional section then TC=1
> > is set.
> >
> > NOERROR NODATA is valid for both types if aaa=1 in the response.
> >
> > This way you could signal that you want both A and  records and
> > if you don't want both then the response does not have the other
> > type added.
> >
> > Yes, we would have to nuke the stupid servers that reflect back
> > {E}DNS flags.  We would also have nuke the stupid firewalls that
> > block {E}DNS queries with a unknown flag bit set.
> >
> > Mark
> >
> > Mark Andrews writes:
> > >
> > > Well we really want to get rid of A lookups.   Why don't we just
> > > recommend that we publish mapped A records in  RRsets and have
> > > master servers update  RRsets if they are inconsitent with the
> > > A RRsets.
> > >
> > > We also need a way to signal that there are no A records in the
> > >  RRset.  :::255.255.255.255 or :::0.0.0.0 would be
> > > sensible records to indicate this.
> > >
> > > Mark
> > >
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
> 
> --001a11432b86aea53d052e98798d
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> I see the point but I don't really want to go down the=
>  EDNS route.So presuming that this draft catches on and Alexa 1M NSs p=
> ublish at least one  record,there would be no need for two q=
> ueries in most cases and no need for additional signalisation.If=
>  they don't publish  records, then the resolver will still have to =
> do the same thing as today,however that also means that IPv6 ado=
> ption is stalled and possibly irrelevant.TL;DR th=
> e draft optimises first case, if the second case proves to be valid then we=
>  can always amend the draft but I don't want to overengineer it from th=
> e start and it's always much easier to add than to remove. r>Marek >On Mon, Mar 21, 2016 at 5:26 PM, Mark Andrews <=
> span dir=3D"ltr">mar=
> k...@isc.org> wrote: =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Or we could defined the "aaa" (A and ) {E}DNS bit where the r>
> server guarantees that the response contains both the A and 
> answers for A or  queries if aaa=3D1 in the response.
> 
> Recursive servers would lookup A/ records if cache is missing
> them before returning a response.
> 
> If the A /  does not fit into the additional section then TC=3D1
> is set.
> 
> NOERROR NODATA is valid for both types if aaa=3D1 in the response.
> 
> This way you could signal that you want both A and  records and
> if you don't want both then the response does not have the other
> type added.
> 
> Yes, we would have to nuke the stupid servers that reflect back
> {E}DNS flags.=C2=A0 We would also have nuke the stupid firewalls that
> block {E}DNS queries with a 

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Wouters]

On Mon, 21 Mar 2016, Marek Vavruša wrote:


  What happens with the Answer Count for QTYPE=A when there are no A
  records and only  records? And can the examples also clarify this?

That's an example 5.3


The use case is, but I still have no idea what the ANCOUNT should
be. Neither the text nor the example list the ANCOUNT. I can only assume
based on the fact that the  is placed in the answer section, that
you would have ANCOUNT=1. I think that is wrong. I think ANCOUNT should
be 0, and the  record should be in the additional section.


The proposal is opt-in, if the authoritative decides to throw in  addresses
then client should accept them. If it doesn't then it should requery. This is 
of course
going to reduce the effectiveness in the transition period for names that have 
A, but don't have 
which is something I expect to change.


And I would assume QTYPE= with additional A records would become the
more common query. At least I hope we are still trying to transition to
IPv6 :)


The rationale is not to carry unnecessary payload when most authoritatives 
support it, but you make a good point
that it might be better to mandate denial of non-existence proof now, and amend 
the draft later.


If you want to do it your way, you need to add some signalling so the
client knows what happened and it can decide whether or not to query
again. I think it is important for the client to know whether the
answer that came back came from a server supporting this document,
as opposed to a server not supporting this document.


  What is SNAME? Did you mean QNAME?
 
SNAME as in RFC1034, either QNAME or CNAME chain terminal name.


Oh thanks. a quick google didnt give me much :)

Paul

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-client-subnet-07.txt

[神明達哉]

At Tue, 22 Mar 2016 01:15:48 +0530,
Mukund Sivaraman  wrote:

> > > (1) Section 7.2.1.  Authoritative Nameserver:

> > I'm confused about the revised Section 7.2.1 regarding overlapping
> > prefixes.  The 07 version of the draft now states:
> >
> >[...]  Because it can't be guaranteed that queries for all
> >longer prefix lengths would arrive before one that would be answered
> >by the shorter prefix length, an Authoritative Nameserver MUST NOT
> >overlap prefixes.
> >
> > But the above "trivial example" seems to talk about what an
> > authoritative nameserver would do if it overlaps prefix...doesn't it
> > simply break the MUST NOT in the first place?
>
> When overlapped address prefixes occur in zone data (the configuration
> provided by an administrator to the authoritative nameserver), the
> authoritative server should resolve the overlap by deaggregating
> prefixes such that the prefixes in the Authoritative Nameserver's reply
> messages do not overlap.

At least to me, "MUST NOT overlap" can't obviously read that way.  I
think some more wording clarification is needed.  Also, what about
the "warn and continue" behavior of this one?

   2.  Alert the operator that the order of queries will determine which
   answers get cached, and either warn and continue or treat this as
   an error and refuse to load the configuration.

If it's not considered a violation of the MUST NOT, I think we need
more explanation here, too.

> The "Authoritative Nameserver MUST NOT overlap prefixes" requirement is
> in the reply messages that it generates. But it can accept overlapping
> prefixes as configuration and deaggregate to non-overlapping prefixes.
>
> > Also (ignoring the MUST NOT), what if a query is sent with a source
> > prefix 1.2.1/24?  The best matching prefix is 1.2.0/20, so isn't the
> > tailored response A with the scope prefix length of 20?  I mean,
> > shouldn't the above deaggregated prefixes be incomplete?
>
> The 1.2.1/24 case would be covered by 1.2.0/23 listed in the example.
> So a query with 1.2.1/24/0 would be replied to with 1.2.1/24/23.

Ah, right, I should have had another cup of coffee before asking it:-)

--
JINMEI, Tatuya

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Vixie]

Mark Andrews wrote:

In message, 
=?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:

I see the point but I don't really want to go down the EDNS route.


Why not?  It is cleaner as it deals with A-only, A and , and
-only sites without a second lookup once support is deployed.
It is supportable on a hop by hop basis.


i think we have to start planning for a world in which EDNS0 never 
reaches 75% penetration due to middleboxes having the high ground.


i think putting  in the additional section and specifying that the 
AA bit covers all rr's matching qname or effective-qname, is likely to 
penetrate better than rrtype!=qtype in the answer section, though.


--
P Vixie

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[George Michaelson]

I'm confused. DO bit implies EDNS0, and we think DO bit in the field
is north of 75%.

What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.

-George

On Tue, Mar 22, 2016 at 11:55 AM, Paul Vixie  wrote:
>
>
> Mark Andrews wrote:
>>
>> In
>> message,
>> =?UTF-8?Q?Marek_Vavru=C5=A1a?= writes:
>>>
>>> I see the point but I don't really want to go down the EDNS route.
>>
>>
>> Why not?  It is cleaner as it deals with A-only, A and , and
>> -only sites without a second lookup once support is deployed.
>> It is supportable on a hop by hop basis.
>
>
> i think we have to start planning for a world in which EDNS0 never reaches
> 75% penetration due to middleboxes having the high ground.
>
> i think putting  in the additional section and specifying that the AA
> bit covers all rr's matching qname or effective-qname, is likely to
> penetrate better than rrtype!=qtype in the answer section, though.
>
> --
> P Vixie
>
>
> ___
> 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] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Vixie]

George Michaelson wrote:

I'm confused. DO bit implies EDNS0, and we think DO bit in the field
is north of 75%.

What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.


by query volume, or by rdns ip?

--
P Vixie

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[George Michaelson]

On Tue, Mar 22, 2016 at 12:07 PM, Paul Vixie  wrote:
>
>
> George Michaelson wrote:
>>
>> I'm confused. DO bit implies EDNS0, and we think DO bit in the field
>> is north of 75%.
>>
>> What did I mis-understand? The APNIC 1x1 is a random sample over
>> users, and it sees significantly more than 75% EDNS0. More like 93%.
>
>
> by query volume, or by rdns ip?

By query volume. And, we're at authority where I suspect you see the edge.

Once the query is covered by a modern competent resolver, and gets
passed, it acquires. EDNS0

-George

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

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Paul Vixie]

George Michaelson wrote:

What did I mis-understand? The APNIC 1x1 is a random sample over
users, and it sees significantly more than 75% EDNS0. More like 93%.


by query volume, or by rdns ip?


By query volume. And, we're at authority where I suspect you see the edge.

Once the query is covered by a modern competent resolver, and gets
passed, it acquires. EDNS0


most middleboxes who think they know what a dns packet has to look like 
and willfully intercept or rewrite or drop them, are between the stub 
and the (desired) rdns. i am not sanguine about getting edns0-carried 
data to a stub often enough during my lifetime to say, let's solve the 
a-vs- problem using another protocol extension.


if the internet is a territory, then the dns, like bgp, is the map of 
that territory. since many commercial and government actors want to 
control access to the internet, they mostly do it by controlling access 
to the dns. and their incentives are misaligned such that they do not 
care what they break or what upgrade paths they deny.


note that solving a+ with an edns0 extension may be good enough, if 
we think that getting the  rrsets cached more often will mean that 
the stub's  query will less often lead to a cache miss, as long as 
the largest share of RTT for a stub query that leads to a cache miss is 
still on the rdns-to-auth path and not the stub-to-rdns path.


--
P Vixie

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

[DNSOP] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications

[Stuart Cheshire]

Dear Keepalive authors,

Draft-ietf-dnssd-push-06 (see below) references 
draft-ietf-dnsop-edns-tcp-keepalive.

However, at present, a more accurate title might be 
“draft-ietf-dnsop-edns-tcp-idle-timeout” instead of 
“draft-ietf-dnsop-edns-tcp-keepalive”, because while it tells the client how to 
learn what the idle timeout is, it doesn’t say anything about what the client 
does to actually keep a connection alive.

Draft-ietf-dnssd-push-06 currently has the text included below.

1. It states what actions reset the idle timer.

2. It states that the client should send keepalive traffic before the idle 
timeout expires, but the server should not kill a connection until 1.5x the 
idle timeout, to allow for clock rate differences and propagation delays.

3. Particularly note the final paragraph, which calls for suggestions for a 
specified keepalive action.

   At both servers and clients, the generation or reception of any
   request, response, update, or keepalive message resets the keepalive
   timer for that connection.

   In the absence of any requests, responses, or update messages on a
   connection, a client MUST generate keepalive traffic before the idle
   timeout expires, or the server is entitled to close the connection.

   If a client disconnects from the network abruptly, without closing
   its connection, the server learns of this after failing to receive
   further traffic from that client.  If no requests, responses, update
   messages or keepalive traffic occurs on a connection for 1.5 times
   the idle timeout, then this indicates that the client is probably no
   longer on the network, and the server SHOULD abort the connection
   with a TCP RST.

   [We need to discuss the nature of "the required keepalives".  Are
   they TCP-layer keepalives?  DNS-layer keepalives?  There is currently
   no DNS-layer keepalive or 'no-op' operation defined.  What would that
   operation be?  A DNS QUERY containing zero questions?  A DNS
   SUBSCRIBE containing zero questions?  An "empty" DNS message over the
   TCP connection (just a pair of zero bytes, signifying a zero-length
   message)?  One benefit of TCP-layer keepalives is that they transmit
   fewer bytes, and involve less software overhead for processing those
   bytes.  Another benefit is that it is more feasible to implement
   these in networking offload hardware, which can allow devices to meet
   their TCP keepalive obligations while sleeping.  This is particularly
   important for battery-powered devices like mobile phones and tablets.
   On the other hand, using TCP-layer keepalives requires an API for a
   client to tell the networking stack at what frequency to perform TCP-
   layer keepalives, and an API for a server to request the networking
   stack to inform it when TCP-layer keepalives are not received by the
   required deadline.  TCP-layer keepalives also only verify liveness of
   the remote networking stack, whereas DNS-layer keepalives provide
   higher assurance of liveness of the remote server application
   software -- though this a limited benefit, since there is no reason
   to expect that DNS Push Notification server software will routinely
   become wedged and unresponsive.]

I could define this specified keepalive action in the DNS Push document, but I 
think it would be better to have that specification in the keepalive document.

Thoughts?

Stuart Cheshire

Begin forwarded message:

> From: internet-dra...@ietf.org
> Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt
> Date: 21 March 2016 at 16:58:41 Pacific Daylight Time
> To: i-d-annou...@ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Extensions for Scalable DNS Service 
> Discovery  of the IETF.
> 
>Title   : DNS Push Notifications
>Authors : Tom Pusateri
>  Stuart Cheshire
>   Filename: draft-ietf-dnssd-push-06.txt
>   Pages   : 31
>   Date: 2016-03-21
> 
> Abstract:
>  The Domain Name System (DNS) was designed to return matching records
>  efficiently for queries for data that is relatively static.  When
>  those records change frequently, DNS is still efficient at returning
>  the updated results when polled.  But there exists no mechanism for a
>  client to be asynchronously notified when these changes occur.  This
>  document defines a mechanism for a client to be notified of such
>  changes to DNS records, called DNS Push Notifications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnssd-push-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmliz

Re: [DNSOP] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications

[Paul Wouters]

Our document is in AUTH48 already, so making those kind of changed there might 
be very difficult.

Also, if you are so idle that you might run into tcp issues timing out, you 
probably should be nice to the other end and close your tcp session.

Sent from my iPhone

> On Mar 21, 2016, at 22:54, Stuart Cheshire  wrote:
> 
> Dear Keepalive authors,
> 
> Draft-ietf-dnssd-push-06 (see below) references 
> draft-ietf-dnsop-edns-tcp-keepalive.
> 
> However, at present, a more accurate title might be 
> “draft-ietf-dnsop-edns-tcp-idle-timeout” instead of 
> “draft-ietf-dnsop-edns-tcp-keepalive”, because while it tells the client how 
> to learn what the idle timeout is, it doesn’t say anything about what the 
> client does to actually keep a connection alive.
> 
> Draft-ietf-dnssd-push-06 currently has the text included below.
> 
> 1. It states what actions reset the idle timer.
> 
> 2. It states that the client should send keepalive traffic before the idle 
> timeout expires, but the server should not kill a connection until 1.5x the 
> idle timeout, to allow for clock rate differences and propagation delays.
> 
> 3. Particularly note the final paragraph, which calls for suggestions for a 
> specified keepalive action.
> 
>   At both servers and clients, the generation or reception of any
>   request, response, update, or keepalive message resets the keepalive
>   timer for that connection.
> 
>   In the absence of any requests, responses, or update messages on a
>   connection, a client MUST generate keepalive traffic before the idle
>   timeout expires, or the server is entitled to close the connection.
> 
>   If a client disconnects from the network abruptly, without closing
>   its connection, the server learns of this after failing to receive
>   further traffic from that client.  If no requests, responses, update
>   messages or keepalive traffic occurs on a connection for 1.5 times
>   the idle timeout, then this indicates that the client is probably no
>   longer on the network, and the server SHOULD abort the connection
>   with a TCP RST.
> 
>   [We need to discuss the nature of "the required keepalives".  Are
>   they TCP-layer keepalives?  DNS-layer keepalives?  There is currently
>   no DNS-layer keepalive or 'no-op' operation defined.  What would that
>   operation be?  A DNS QUERY containing zero questions?  A DNS
>   SUBSCRIBE containing zero questions?  An "empty" DNS message over the
>   TCP connection (just a pair of zero bytes, signifying a zero-length
>   message)?  One benefit of TCP-layer keepalives is that they transmit
>   fewer bytes, and involve less software overhead for processing those
>   bytes.  Another benefit is that it is more feasible to implement
>   these in networking offload hardware, which can allow devices to meet
>   their TCP keepalive obligations while sleeping.  This is particularly
>   important for battery-powered devices like mobile phones and tablets.
>   On the other hand, using TCP-layer keepalives requires an API for a
>   client to tell the networking stack at what frequency to perform TCP-
>   layer keepalives, and an API for a server to request the networking
>   stack to inform it when TCP-layer keepalives are not received by the
>   required deadline.  TCP-layer keepalives also only verify liveness of
>   the remote networking stack, whereas DNS-layer keepalives provide
>   higher assurance of liveness of the remote server application
>   software -- though this a limited benefit, since there is no reason
>   to expect that DNS Push Notification server software will routinely
>   become wedged and unresponsive.]
> 
> I could define this specified keepalive action in the DNS Push document, but 
> I think it would be better to have that specification in the keepalive 
> document.
> 
> Thoughts?
> 
> Stuart Cheshire
> 
> Begin forwarded message:
> 
>> From: internet-dra...@ietf.org
>> Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-06.txt
>> Date: 21 March 2016 at 16:58:41 Pacific Daylight Time
>> To: i-d-annou...@ietf.org
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Extensions for Scalable DNS Service 
>> Discovery  of the IETF.
>> 
>>   Title   : DNS Push Notifications
>>   Authors : Tom Pusateri
>> Stuart Cheshire
>>Filename: draft-ietf-dnssd-push-06.txt
>>Pages   : 31
>>Date: 2016-03-21
>> 
>> Abstract:
>> The Domain Name System (DNS) was designed to return matching records
>> efficiently for queries for data that is relatively static.  When
>> those records change frequently, DNS is still efficient at returning
>> the updated results when polled.  But there exists no mechanism for a
>> client to be asynchronously notified when these changes occur.  This
>> document defines a mechanism for a client to be notified of such
>> changes to DNS records, called DNS Push Notifications.
>> 
>

Re: [DNSOP] [dnssd] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications

[Stuart Cheshire]

On 21 Mar 2016, at 20:02, Paul Wouters  wrote:

> Our document is in AUTH48 already, so making those kind of changed there 
> might be very difficult.

I didn’t realise that. I agree, it’s too late to make substantive changes at 
this point.

> Also, if you are so idle that you might run into tcp issues timing out, you 
> probably should be nice to the other end and close your tcp session.

The idea of DNS Push Notifications is for moderately long-standing queries (on 
the order of 5-10 minutes) waiting to be notified of some change.

For example, you go to print, but the printer is turned off. You walk down the 
hall and turn the printer on, and when you get back to your office your 
computer has been notified that a new printer has become available (without you 
having to repeatedly cancel and try again until the printer shows up).

It’s not something that would be useful for all DNS servers. Think of it as a 
different protocol, that happens to leverage existing DNS protocols and message 
formats instead of inventing new protocols and message formats.

The draft explains it in more detail.

DNSOP feedback on the draft would be appreciated.

Stuart Cheshire

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

Re: [DNSOP] [dnssd] Draft-ietf-dnsop-edns-tcp-keepalive and DNS Push Notifications

[Paul Wouters]

Sent from my iPhone

> On Mar 22, 2016, at 00:16, Stuart Cheshire  wrote:
> 
>> On 21 Mar 2016, at 20:02, Paul Wouters  wrote:
>> 
>> Our document is in AUTH48 already, so making those kind of changed there 
>> might be very difficult.
> 
> I didn’t realise that. I agree, it’s too late to make substantive changes at 
> this point.
> 
>> Also, if you are so idle that you might run into tcp issues timing out, you 
>> probably should be nice to the other end and close your tcp session.
> 
> The idea of DNS Push Notifications is for moderately long-standing queries 
> (on the order of 5-10 minutes) waiting to be notified of some change.
> 
> For example, you go to print, but the printer is turned off. You walk down 
> the hall and turn the printer on, and when you get back to your office your 
> computer has been notified that a new printer has become available (without 
> you having to repeatedly cancel and try again until the printer shows up).
> 

Sound more like a match for xmpp than DNS?

Paul


> It’s not something that would be useful for all DNS servers. Think of it as a 
> different protocol, that happens to leverage existing DNS protocols and 
> message formats instead of inventing new protocols and message formats.
> 
> The draft explains it in more detail.
> 
> DNSOP feedback on the draft would be appreciated.
> 
> Stuart Cheshire
> 
> ___
> 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