Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

[Terry Manderson]

Hi Spencer,

On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF"
 wrote:
>
>Terry, I like where you're headed, but just to ask the obvious question,
>are you thinking the draft would, or would not, also contain something
>like "at the time this document was approved, a domain used for this test
>was $someactualworkingdomain.com "?

Sorry I didn't make it obvious, yes I would like to see text like this,
and I think it makes an easy path for the less adventurous in addition to
supplying more in depth guidance.

Cheers
Terry


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

Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

This is Not My Yes, but ...

On Wed, Jul 13, 2016 at 12:28 AM, Terry Manderson  wrote:

> Hi Wes,
>
> Thanks for responding.
>
> I'll trim to only the the remaining items needing a response, and express
> my appreciation at the clarified items.
>
> On 9/07/2016, 9:53 AM, "iesg on behalf of Wes Hardaker"
>  wrote:
>
> >"Terry Manderson"  writes:
> >
> >
> >> s1.2 is https://github.com/ogud/DNSSEC_ALG_Check going to be a fully
> >> stable URL?
> >
> >Per discussion in another thread: probably.  Olafur certainly won't
> >delete it as the owner, and I doubt github will die anytime soon.
> >
> >The only other choice is to remove the helpful reference.
>
> Thanks.
>
> >
> >I've changed it to "validating resolver daemon" instead.  Make more sense?
>
> It does.
>
>
> >
> >> s3.1.1, please use the example domain for such examples, ie example.com
> ,
> >> and once you have used it do you really need to repeat it for each
> >> 'existing' text until you get to the non-existent tests and so on up to
> >> 3.1.14.
> >
> >Well, here's the deal: example.com won't work and the domain in question
> >actually does work.  Some of them can probably be replaced with the root
> >server, but many others require somewhat specialized tests pointing to a
> >special domain.  That one is known to be the only one that likely will
> >work for some tests at this point.  The question is, what to do about
> >that?  Can we list a known one?  Must we list a useless one instead?
> >Should we pre-declare the problem?  I've been waiting for this to come
> >up :-)
>
> Personally, my advice would be to pre-decalre the issue, and why it's an
> issue and why some special domain is needed and describe the semantics of
> the FQDNs needed for the appropriate tests (including an appendix zone
> file?), and then use example.com as the label which needs to be
> substituted by the person constructing the tests/zone. The benefit here is
> that some folks might like to replicate such a construct in their own
> infrastructure, and this document might give them that guidance.
>
> Does that make sense?


Terry, I like where you're headed, but just to ask the obvious question,
are you thinking the draft would, or would not, also contain something like
"at the time this document was approved, a domain used for this test was $
someactualworkingdomain.com"?

I didn't mention the domains mentioned in this draft in my ballot, but I
was watching when you brought it up ... so I'm still curious.

Thanks,

Spencer


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

Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)

[John Levine]

>> why all that complexity? if some remote device (iot thingy) wants 'dns over
>>> http' why would it not (as a first order answer) just ask
>>> /cgi-bin/dnslookup for 'srv:foo.com' ? (returned answer in txt, json,
>>> etc...)

>> Security in IoT is close to an oxymoron, but my device would like to check
>> the signature before trusting what your proxy says.
>>
>ok, I'm sure your device has some agreement with the cooperating http(s)
>server though, right? it can get the text / bas64 rrsig content just as
>easily as if it were doing udp/dns. (it should probably also check ssl
>certificates/etc to make sure traffic did not get wonked in flight)

I don't understand what problem this solves.  If you're going to
provide all of the DNS results in a gooped up form, why not just
provide them in a native form and let the client deal with it?

R's,
John

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

Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)

[Christopher Morrow]

On Wed, Jul 13, 2016 at 3:42 PM, John R Levine  wrote:

> why all that complexity? if some remote device (iot thingy) wants 'dns over
>> http' why would it not (as a first order answer) just ask
>> /cgi-bin/dnslookup for 'srv:foo.com' ? (returned answer in txt, json,
>> etc...)
>>
>> why bother with a bunch of javascript tomfoolery?
>>
>
> Security in IoT is close to an oxymoron, but my device would like to check
> the signature before trusting what your proxy says.
>
>
ok, I'm sure your device has some agreement with the cooperating http(s)
server though, right? it can get the text / bas64 rrsig content just as
easily as if it were doing udp/dns. (it should probably also check ssl
certificates/etc to make sure traffic did not get wonked in flight)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)

[John R Levine]

why all that complexity? if some remote device (iot thingy) wants 'dns over
http' why would it not (as a first order answer) just ask
/cgi-bin/dnslookup for 'srv:foo.com' ? (returned answer in txt, json,
etc...)

why bother with a bunch of javascript tomfoolery?


Security in IoT is close to an oxymoron, but my device would like to check 
the signature before trusting what your proxy says.


Also, as I mentioned in another message, unless you plan to carefully 
maintain your proxy to handle and translate every rrtype, we're going to 
want to use rr's that it doesn't handle.  I suppose it might return a json 
blob of TYPE1234, but you might as well just send the binary stuff at that 
point.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

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

Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)

[Christopher Morrow]

On Wed, Jul 13, 2016 at 10:59 AM, Tony Finch  wrote:

> Shane Kerr  wrote:
> >
> > OTOH, I am (obviously) not a web developer, so perhaps I overestimate
> > the difficulty in working with DNS binary-format. Maybe it's a
> > relatively compact set of JavaScript functions that can be used?
>
> It wouldn't be completely horrible to parse DNS packets using JavaScript
> typed arrays.
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays
>
>
why all that complexity? if some remote device (iot thingy) wants 'dns over
http' why would it not (as a first order answer) just ask
/cgi-bin/dnslookup for 'srv:foo.com' ? (returned answer in txt, json,
etc...)

why bother with a bunch of javascript tomfoolery?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)

[Tony Finch]

Shane Kerr  wrote:
>
> OTOH, I am (obviously) not a web developer, so perhaps I overestimate
> the difficulty in working with DNS binary-format. Maybe it's a
> relatively compact set of JavaScript functions that can be used?

It wouldn't be completely horrible to parse DNS packets using JavaScript
typed arrays.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames: Variable mainly northwesterly 3 or 4, increasing 5 at times.
Slight, occasionally moderate. Showers. Good.

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