Jiankang Yao | 3 May 08:21 2016
Picon

Re: Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt

 
From: Ray Bellis
Date: 2016-04-29 17:38
CC: dnsop
Subject: Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt
 
 
> I am unconvinced that the ability to specify multiple QNAMEs offers any
> benefits and can't think of any good use cases where the client knows a
> priori what the other QNAMEs might be.   [ I don't consider looking up
> example.com and www.example.com at the same time to be 'good' ].
>
 
when receiving an email from abc <at> example.com, I often would like to visit the website of www.example.com too when I reply the email.
 
another examples are :
1, when querying DNSSEC records for www.example.com, it normally needs querying example.com too for DNSSEC verification.
 
2, DKIM exmaple in Appendix A of rfc5617
 
Appendix A.  Lookup Examples

   aaa.example                  A     192.0.2.1        (1)
   _adsp._domainkey.aaa.example TXT   "dkim=all"       (2)

   bbb.example                  MX 10 mail.bbb.example (3)
   mail.bbb.example             A     192.0.2.2        (4)
3, DMARC example
when you query for example.com, you might look up for  _dmarc.example.com
 
 
 
> The examples given all appear to show a recursor -> authority query, but
> I see no hint in the draft about whether it's only for that path or also
> for stub -> recursor.
>
 
I think that it works for both.
 
The hint is the name "responder", "initiator"
 
section  4.  Responder Processing  . . . . . . . . . . . . . . . . . . . .   5
section   5.  Initiator Processing  . . . . . . . . . . . . . . . . . . . .   6
Inititator can be stub or recursor
Responder can be authority server or recursor
 
 
 
 
Best regards.
 
Jiankang Yao
 
> Ray
>
 
> p.s. I noticed a dangling reference to RFC1321 (MD5) ?
>
typos. will remove it. thanks for catching it.
 
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Davey Song | 3 May 06:01 2016
Picon

Re: draft-song-dns-wireformat-http

Hi guys, 

Thanks for the comments and discussion. I catch up them after holidays :) 

I reply in line and cc Paul's comments to  DNSOP WG mailing list, so that we can continue to comment follow the same context in this mailing list.

Best regards,
Davey.

On 30 April 2016 at 06:23, Paul Vixie <paul <at> redbarn.org> wrote:


Shane Kerr wrote:
    specific semantics, such as the HTTP request method, specific
    request-target, HTTP-version, and HTTP header field, all of which
    have impact on interoperability as well as performance.

    In HTTP 1.1 specification section 3 in RFC 7230 [RFC7230], an HTTP
    message consists of three parts: start-line, header fields, and
    message body with an empty line between header fields and message
    body.  The DNS over HTTP message also contains these parts.
Otherwise, it wouldn't be HTTP/1.1, right. FWIW, if you make this
requirement here, you wouldn't be able to use HTTP/2.

Of all your observations, this one is the trickiest. :(

Right now the protocol is clearly based on HTTP/1.1, although we have
an implementation that works fine with HTTP/2 since the Go HTTP library
supports it (basically) transparently.

Let me talk with my co-authors and see what they think!

as a named co-author, i think the http version number is irrelevant, and that we should not describe http/1.1 in our spec. that is, we should not mention headers, lines, or bodies. those are syntactic elements meant to be parsed to find semantic elements: request action, request headers, and request body. (or similar.) how those elements are encoded is not important to proxy-dns, nor to any other web-carried app.

we should restate our specification in terms that are portable to http/2 and every http protocol thereafter. the encoding of our blobs into http, and the decoding of an http message into the blobgs we need, is an implementation detail.

The HTTP version is mentioned because the difference of http/1.1 and http/2 is relevant to DNS performance, if http is used as an alternative transport protocol. It is worthwhile to encourage people to use modern HTTP protocol. 
  
    - Note that choosing POST (not GET) as the request method for DNS
    wire-format over HTTP is mainly based on two reasons.  One is that
    the protocol is designed using HTTP as a tunnel-like technology
    carrying data from one side to another, not a web service with
    RESTful framework.  Another is that from the view of implementation
    some servers may ignore undefined entity-body if using GET; and HTTP
    libs vary on supporting GET with payload.
GET with payload would indeed be a bad idea. However you could use the
request URI for the payload; was this discussed?

So you mean encoding the entire DNS query packet as a long URL?

That was *not* discussed, and is actually quite a clever idea. :-D

it was discussed. it was dismissed.

a text/dns format should be defined, likely being json, that can carry a dns message. a dns-request URI format should be defined, so that we can send a normal GET, subject to HTTP caching and proxying.

but this is not that. those things should be defined -- elsewhere, by someone who has a lot more appetite for work than we do. that other specification can peacefully co-exist with this one -- and will be widely intercepted by middleboxes, just as udp/53 and tcp/53 are today. the use case for that specification is completely different from the use case for this specification.

please do not lose focus on the purpose of this specification, for which POST was chosen deliberately, and for which POST is correct, and ideal.

...
Let me discuss it with my co-authors and/or the dnsop working group and
we'll see what we think.

please pass the above comments on to anyone else, and any other forum, where you have opened this discussion. it is vital that we not turn this proxy-dns spec into a general-dns-over-http spec.

    RFC 5785 [RFC5785], it begins with the characters "/.well-known/" and
    the name "dns-wireformat".  So the request-target for DNS wire-format
    over HTTP SHOULD be '/.well-known/dns-wireformat'.
No reason for a "SHOULD" here. Just define the well-known URI.

I'm not sure how this works. Clearly developers and operators don't
need to use the well-known port, but we think that they should unless
they have a good reason not to. Is this not the use case for the
"SHOULD" key word?

his comment was editorial. don't say SHOULD BE. say IS.

    Proxy-DNS-Transport: xyz

    Where xyz is either UDP or TCP, which is the client's indication of
    how it received the underlying DNS query, and which the server will
    use when sending the query to the far-end DNS server.  This means if
    a stub DNS client asks for TCP, then that's what the far-end DNS
    server will see, and likewise for UDP.  This header field is used for
    both request and response, for all DNS over HTTP message.

    Exposing the transport protocol of the query allows the HTTP server
    proxy to send DNS queries to the recursive resolver that look like
    those that the DNS client is sending to the client proxy.  If the
    stub resolver sent a UDP packet, then this allows the recursive
    resolver to implement the logic of truncating the packet properly,
    instead of requiring that the HTTP client proxy somehow manage that
    functionality.

    For a stub resolver that connect directly via HTTP to the HTTP server
    proxy then this flag should be set to TCP, as the entire response can
    always be delivered so truncation is never required.

    The client MUST include this option.  If it is missing then it is an
    error and the server should respond with HTTP code 400 (bad request).
I'm not sure why it's needed, but if it's needed it would be simpler to
just define two well-known URIs.

that feels like a layering violation to me.

--
P Vixie

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Vixie | 30 Apr 04:27 2016

Re: Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt


> Bob Harold <mailto:rharolde <at> umich.edu>
> Friday, April 29, 2016 06:44
>
>
>
>     On 29/04/2016 02:01, Jiankang Yao wrote:
>     > Dear all,
>     >
>     >       We submit a draft about "A DNS Query including A Main Question
>     > with Accompanying Questions".
>     >
>     >        Any comments are welcome.
>
>     I am unconvinced that the ability to specify multiple QNAMEs
>     offers any
>     benefits and can't think of any good use cases where the client
>     knows a
>     priori what the other QNAMEs might be.   [ I don't consider looking up
>     example.com <http://example.com> and www.example.com
>     <http://www.example.com> at the same time to be 'good' ].
>
>     The examples given all appear to show a recursor -> authority
>     query, but
>     I see no hint in the draft about whether it's only for that path
>     or also
>     for stub -> recursor.
>
>     My own draft in this area (draft-bellis-dnsext-multi-qtypes) where
>     only
>     a single QNAME is supported and a single RCODE is returned has
>     IMHO far
>     clearer semantics.  It's also appropriate both for stub ->
>     recursor and
>     for recursor -> authority.
>
>     Ray
>
>
> I am assuming that the benefits here are:
> - reduced number of packets
> - reduced total bytes
> - possibly reduced round trips

yes to that last.

specifically, if one wanted to ask about a SRV RR and an A RR and an 
AAAA RR, that's two different QNAMEs, which would otherwise require 
multiple transactions.

note that the transactions can be sent in parallel, but it's currently a 
2-packet microburst without any congestion control, which is dangerous. 
once we have negotiated TCP stayopen, we can pump the queries in as fast 
as the initiator would like, and in that event, the bellis model will be 
superior by its simplicity, even if it uses more wire-octets due to the 
extra DNS header.
>
> Would it be possible to get most of these benefits with a combination of:
> - tcp + pipeline - pipeline multiple queries with less packets
> - tcp-fast-open - avoid extra round trip

as to whether we should punt on all the multi-question drafts and say 
"wait for negotiable TCP keepopen, and use that", i don't know. i think 
probably so, since every code point we allocate will vastly increase the 
amount of testing implementors have to do on every new release.

by the way TFO's payload size is limited, since there's no TCP window 
yet. so, the negotiated TCP/53 keepopen signaling is likely to offer a 
greater benefit, simply by allowing long-lived TCP sessions between DNS 
initiators and DNS responders.
>
> If cookies are longer-lived than tcp sessions, could we use 
> tcp-fast-open with cookies to avoid spoofed source addresses?

if anybody in the TFO world cared about spoofed-source addresses, they 
would have supported RFC 6013 rather than inventing their own thing. so, 
no. (if i sound bitter, you'll see my name in the Usenix ;login: article 
which preceded RFC 6013, so, yes, i am a small bit bitter.)

https://www.usenix.org/publications/login/december-2009-volume-34-number-6/improving-tcp-security-robust-cookies
>
> If all of that would work together, it would be more flexible than 
> either of the above drafts.  But I am probably missing something.

i think you're mostly right-headed on this. the smallest number of 
changes that covers the largest number of use cases is probably our best 
answer.

vixie

--

-- 
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Edward Lewis | 29 Apr 21:08 2016
Picon

Re: NXDOMAIN synthesis for NSEC3 (was call for adoption for draft-fujiwara-dnsop-nsec-aggressiveuse)

On 4/28/16, 18:05, "DNSOP on behalf of Matthew Pounsett" <dnsop-bounces <at> ietf.org on behalf of matt <at> conundrum.com> wrote:

On 28 April 2016 at 06:37, Edward Lewis <edward.lewis <at> icann.org> wrote:

Not sure if that answers the question fully.  Hope it helps.

It helps, for sure.  So if I understand you correctly, at the TLD level it's 4:1 in favour of NSEC3, and all of those are opt-out.
I imagine that will change as the number of DS records rise, but it gives us an idea of the scale of the issue.

I do know of one operator whose told me that the are considering swapping NSEC for NSEC3 as the zone size is putting pressure on the infrastructure.

I see other trends that say operator behavior is unpredictable.  Operators are still debuting zones with RSA-SHA1, for instance, despite educational efforts to go to something newer.  So, while there's a little bit of pent up energy to go from NSEC3 to NSEC, there's no telling whether future debuts will feature one or the other.

So back to Shane's question which I was responding to ...
We can't say that most zones are NSEC or NSEC3, but we can say there are an awful lot of TLDs that are NSEC3 opt-out.  

Yep - the question is, if we don't know, can we just go forward with the uncertainty?

If someone can get me a relatively current, and relatively complete, set of TLD zones, I could volunteer to check the next level down.  I don't think I have time to go through the process of signing and faxing all those zone file access agreements though.

If I had time, I've done studies along the lines you are thinking of.  Last year I studied the selections of DNSSEC security algorithms and lengths but didn't include NSEC in the work then.  Between the time I did the work and got around to talking about it (at CENTR Jamboree 2015) a higher priority work item overcame events.  The data I have access to is pretty much not-the-ccTLDs.  File this under best laid plans...I do need to fix my set up last year after changing hardware.
Attachment (smime.p7s): application/pkcs7-signature, 6226 bytes
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
神明達哉 | 29 Apr 19:12 2016
Picon

Re: Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

At Fri, 29 Apr 2016 10:09:30 +0200,
Matthijs Mekking <matthijs <at> pletterpet.nl> wrote:

> >> - I don't see why setting the CD bit is an indication that NSEC(3)
> >> aggressive usage should not be used. Could you elaborate on that?
>
> I am still hoping that someone could response to this :)

Specifically where in draft-fujiwara-dnsop-nsec-aggressiveuse-03 are
you referring to?

--
JINMEI, Tatuya

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

John Levine | 29 Apr 18:56 2016

Re: Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

>So, ISPs not doing reverse DNS for IPv6, like my current ISP, are making it
>impossible to use your own mail server to deliver mail over IPv6. I think
>they are doing a serious disservice to the open internet.

Aw, c'mon. This argument was over a decade ago.

If your ISP is like most other ISPs, retail connections have port 25
blocked, the IP ranges are listed in the MAPS DUL and Spamhaus PBL,
and the IPv4 addresses have rDNS with names that say don't connect to
me.  (The patterns that Richard derides work surprisingly well in
practice.)  The reason, as we all know, is that about 99% of mail from
retail connections is botnet spam, and it's sheer self defense.  You
don't have to like it, but it's not going to change, and it's a waste
of time to argue about it.

There are plenty of hosting providers that will rent you a VPS
for $5/mo with static v4 and v6 addresses and rDNS that matches
whatever forward DNS you point at it.  If it's not worth $5/mo,
well, OK.

R's,
John

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

John Levine | 29 Apr 18:28 2016

Re: Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

>Disclaimer: Personally I think that the whole notion of reverse IP is
>ridiculous, especially in IPv6. I proposed that we skip the whole
>notion in IPv6, possibly providing some alternate, non-DNS, method to
>get hostname from IPv6 addresses for the rare case where that is useful.

My problem with the draft is that it doesn't distinguish between hosts
with static addresses (configured manually or by DHCP) and hosts with
dynamic addresses.  rDNS for static addresses is easy, and these days
a lot of people use the existence of rDNS as a hint that an IPv6 host
has a static address and is intended to be a server.

The discussions of all the ways to kludge rDNS for dynamic hosts is
fine, perhaps with a clearer note at the beginning that you probably
don't want to bother.

R's,
John

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Bob Harold | 29 Apr 18:20 2016
Picon

Re: draft-song-dns-wireformat-http

Responding to only one part:

> >    - Note that choosing POST (not GET) as the request method for DNS
> >    wire-format over HTTP is mainly based on two reasons.  One is that
> >    the protocol is designed using HTTP as a tunnel-like technology
> >    carrying data from one side to another, not a web service with
> >    RESTful framework.  Another is that from the view of implementation
> >    some servers may ignore undefined entity-body if using GET; and HTTP
> >    libs vary on supporting GET with payload.
>
> GET with payload would indeed be a bad idea. However you could use the
> request URI for the payload; was this discussed?
So you mean encoding the entire DNS query packet as a long URL?
That was *not* discussed, and is actually quite a clever idea. :-D
A typical DNS query is less than 100 bytes, which means even
hex-encoded would be only a 200-byte URI. That would have the nice
effect of giving a URL that can be cut & paste for debugging and so on.
(We could also use base64 or base32, but I find that hex-encoding is
relatively easy to work with for humans should that ever be necessary.)
Anyway, it *is* more bytes, but I'm not sure it would result in more
packets which is probably more important. (This depends on HTTP
pipelining and the like.)
Let me discuss it with my co-authors and/or the dnsop working group and
we'll see what we think.

I had to search to be sure that the GET URL is encrypted, and found that there might be additional concerns if the user is using this with https for privacy.
1. The URL would get logged in the web server logs.  Including the DNS query.
2. If using a browser, the URL is saved in the browser history
3. If used in a web page, URLs are passed in Referrer headers
I don't think #2 and #3 apply to DNS over HTTPS, but #1 might be a concern.  However, the server is already getting the DNS query and might be logging queries at the DNS level, so maybe this is just an issue to mention to the server admin.

-- 
Bob Harold





_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Davey Song | 27 Apr 10:43 2016
Picon

Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

Hi Colleagues, 

We have update the dns-wireformat draft according to the advice we gained from last IETF meeting, changing the well-known URI from dns-over-http to dns-wireformat according to Paul Hoffman's suggestion. Any further comments ? I would like to ask for WG to adopt it this time.

Best regards,
Davey

---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: 27 April 2016 at 16:03
Subject: New Version Notification for draft-song-dns-wireformat-http-03.txt
To: "Paul A. Vixie" <vixie <at> tisf.net>, Shane Kerr <shane <at> biigroup.cn>, Runxia Wan <rxwan <at> biigroup.cn>, Linjian Song <songlinjian <at> gmail.com>



A new version of I-D, draft-song-dns-wireformat-http-03.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:           draft-song-dns-wireformat-http
Revision:       03
Title:          DNS wire-format over HTTP
Document date:  2016-04-27
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-03.txt
Status:         https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
Htmlized:       https://tools.ietf.org/html/draft-song-dns-wireformat-http-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-03

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.




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


_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Picon

dnsop - New Meeting Session Request for IETF 96


A new meeting session request has just been submitted by Tim Wicinski, a Chair of the dnsop working group.

---------------------------------------------------------
Working Group Name: Domain Name System Operations
Area Name: Operations and Management Area
Session Requester: Tim Wicinski

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 140
Conflicts to Avoid: 
 First Priority: dprive dnssd homenet appsawg apparea dhc dane dbound
 Second Priority: trans intarea mif v6ops
 Third Priority: sidr saag pcp opsawg opsarea grow 6man

Special Requests:

---------------------------------------------------------

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Tim Wicinski | 25 Apr 22:50 2016
Picon

Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

This starts a Working Group Last Call  for draft-ietf-dnsop-isp-ip6rdns

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

There was a large amount of feedback on the draft prior to it being 
adopted, and we feel the author addressed all the outstanding issues.
Please let us know if this is not the case.

This starts a two week Working Group Last Call process, and ends on
9 May 2016.

thanks
tim

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Gmane