Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Christopher Morrow]

So, sorry I added an example set and we rat-holed on those.

My point is that the recursive reoslver has no idea why an authoritative
is unreachable and that doing anything like sending stale records is
going to cause unintended problems.

-chris


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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Christopher Morrow]

On Mon, Mar 4, 2019 at 11:00 PM Paul Wouters  wrote:

> On Tue, 5 Mar 2019, Mark Andrews wrote:
>
> >> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> >>> can I ask, what happens when a domain is intentionally down though? For
> >>> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> >>> master/shadow NS go down, hard. All public auth servers eventually (in
> a
> >>> day or so) went dark too.
>
> "If the recursive server is unable to contact the
>   authoritative servers for a query "
>
> So make the DNS server reachable, but return ServFail or NXDOMAIN. If
> the owner doesn't cooperate and there is legal standing, talk to the
> parent to do this for the delegation.
>
>
this wasn't, near as I could tell, an option for the ccTLD in question.
They lost their IP access, and were 'required' to disable their dns zone,
their master was down hard from the internet's perspective,
keeping anything else up wasn't really an option.

I don't know how long it takes to get ICANN to 'do something creative' for
the root zone, but I'm guessing this isn't always feasible in normal
timelines (hours to a day or so).


> I don't think this draft stops a domain from being brought down
> intentionally.
>
>
i think it prolongs the data being available in a bunch of the cases I can
imagine/have-seen.
I think there's at least one case where it's likely grave harm could have
come to the dns operator. :(

I think what the draft does is attempt to guess at WHY a thing is changed,
without an real data to back up the reasoning. this will mean the decision
is wrong more than a small percent of the time.


> >> i already raised that question, very far up-thread. got no answer.
> >>
> >>> If someone is 'ordered' to make a zone dark, there may be reasons for
> that
> >>> action, and real penalties if the request is not honored.
> >>> Is this draft suggesting that the DNS operations folk go against the
> wishes
> >>> of the domain owner by keeping a domain alive after the auth servers
> have
> >>> become unreachable? How would a recursive resolver know that the auth
> is
> >>> down: "By mistake" vs: "By design" ?
>
> The DNS resolvers who want to accomodate their governments need to
> manually override their resolvers anyway with new (forged) data. This
> draft does not change that.
>
> If the owner itself wants to bring the domain down, they just need to
> make its auth servers reachable.
>
>
sometimes that's not possible :( and the expectation is that 'when the
right ttl sets expire all of our records disappear as you requested"


> If the DNS hoster wants to bring it down, they just need to modify the
> data it serves resulting in NXDOMAIN, ServFail or 127.0.0.1 A records.
>

this is also not always possible :(


>
> I don't think the "4 years" is a realistic problem case.
>
>
is the '4 years' here in reference to the .eg problem?
in my example the '4 yrs' was: "when the incident happened" not "please
keep my dns alive for 4 yrs without talking to me"


> I can see how people want to get a few hours or a few days of usage
> beyond the TTL to accomodate for errors. Although, it is likely that
> moving up the error this way will also delay the error from being
> detected before the extra time has expired, and we are just moving
> the goal post with no effective gain. But in the case of a DDOS
> attack, the draft's feature is surely useful.
>
>
seems unlikely to be useful... even in the case of dos...really.
(to me anyway)

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Christopher Morrow]

On Mon, Mar 4, 2019 at 9:26 PM Paul Vixie  wrote:

> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
> > can I ask, what happens when a domain is intentionally down though? For
> > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
> > master/shadow NS go down, hard. All public auth servers eventually (in a
> > day or so) went dark too.
>
> i already raised that question, very far up-thread. got no answer.
>
>
apologies for repeat-asking :( whoops! It'd still be good to hear an answer.
I can think of simple product and not 'life safety' reasons that I might
darken a zone as well, so if you don't want to answer for an abundance of
caution for your fellow folken... think of the product marketing folk who
mistakenly launch a day early, or who would like to retire a service in a
clearly delineated manner.

:)

> If someone is 'ordered' to make a zone dark, there may be reasons for that
> > action, and real penalties if the request is not honored.
> > Is this draft suggesting that the DNS operations folk go against the
> wishes
> > of the domain owner by keeping a domain alive after the auth servers have
> > become unreachable? How would a recursive resolver know that the auth is
> > down: "By mistake" vs: "By design" ?
>
> this the essence of the argument against utility for this entire proposal.
> no
> data should be served beyond its TTL unless some new leasing protocol is
> first
> defined, to obtain permission and to provide a cache invalidation method.
>

this is what I was thinking as well. thanks for more clarity.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Christopher Morrow]

can I ask, what happens when a domain is intentionally down though? For
instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
master/shadow NS go down, hard. All public auth servers eventually (in a
day or so) went dark too.

If someone is 'ordered' to make a zone dark, there may be reasons for that
action, and real penalties if the request is not honored.
Is this draft suggesting that the DNS operations folk go against the wishes
of the domain owner by keeping a domain alive after the auth servers have
become unreachable? How would a recursive resolver know that the auth is
down: "By mistake" vs: "By design" ?

-chris


On Mon, Mar 4, 2019 at 6:25 PM Puneet Sood  wrote:

> Tim, Paul,
>
> Thanks for the feedback. Working on clarifying the recommendations.
>
> -Puneet
>
> On Sun, Mar 3, 2019 at 8:34 PM Tim Wicinski  wrote:
>
>> "Proposal: Put all recommendations in Section 4, and talk about them
>> (instead of introducing them) in the other sections. That way, a lazy
>> developer who only reads Section 4 will know all the recommendations."
>>
>> I totally agree here.  It also makes it easier if the document passed
>> WGLC and moves along the standards process train.
>>
>
>> Tim
>>
>>
>> On Fri, Mar 1, 2019 at 2:51 PM Paul Hoffman 
>> wrote:
>>
>>> Following up on my previous message:
>>>
>>> The document is actively confusing about recommendations.
>>>
>>> - Section 4 has the actual update to the RFC 1035, and that update
>>> contains MAY and SHOULD statements.
>>>
>>> - Section 5 is called "Example Method" but also contains recommendations.
>>>
>>> - Section 6, "Implementation Caveats" also has recommendations. A
>>> subsection, "6.1. Implementation Considerations" has more recommendations.
>>>
>>> Proposal: Put all recommendations in Section 4, and talk about them
>>> (instead of introducing them) in the other sections. That way, a lazy
>>> developer who only reads Section 4 will know all the recommendations.
>>>
>>> --Paul Hoffman
>>> ___
>>> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] EDNS0 clientID is a wider-internet question

[Christopher Morrow]

darn, I keep reading 'client-id' as 'client subnet' :( back in my hole I go.

On Tue, Jul 25, 2017 at 9:53 AM, Christopher Morrow <morrowc.li...@gmail.com
> wrote:

>
>
> On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon <mel...@fugue.com> wrote:
>
>> On Jul 24, 2017, at 8:59 PM, Christopher Morrow <morrowc.li...@gmail.com>
>> wrote:
>>
>> and at the cache->auth layer it's potentially the case that the provider
>> can say: "use precision of /24" or "use precision of /17" ? So, there's
>> really not much "pii" that can be worried over at the
>> provider-cache-resolver (they already know who you are...) and they
>> (provider) can decide how much granularity is "important" to release to the
>> upstream authoritative cache.
>>
>>
>> There is no such thing as an upstream authoritative cache.   The
>> filtering is being
>>
>
> apologies, 'upstream (from the cache resolver's perspective) authoritative
> SERVER'.
>
>
>> done at the cache.   This is not client subnet: this is client ID.   So
>> the cache, which is not authoritative, is receiving PII about a specific
>> client machine.   Being able to
>>
>
> I agree with this, the cache resolver sees the client's IP address.
>
>
>> filter the PII at the CPE would indeed improve privacy in this case; the
>> problem is that the CPE has to have a UI or API that allows that to happen,
>> and they don't.
>>
>>
> I don't think the CPE is the answer, the cache-resolver CAN decide to send
> along in it's edns0 option: "1.2.128.0/17" instead of "1.2.3.0/24". Or it
> seems to me that this is a fine knob to add to resolver software... granted
> you'd need some extra config about your client subnets in use.
>
>
>> The reason DNS filtering is useful is not that it is forced upon the end
>> user, but that it allows devices that use the default cache to get
>> filtering in a way that does not
>>
>
> I don't believe the goal of the draft is to enable filtering.
> Certainly for a nation-state actor you could see: "Oh, now I know what
> subnets use the resolver over there, so I can limit useful replies, or
> steer requestors toward 'better/approved' content'
>
>
>> depend on the software installed on them.   So e.g. your IoT device can
>> be infected by a worm but not actually exfiltrate any private information
>> to the attacker, because the attacker's DNS is blocked.
>>
>>
> you seem to be conflating a few things here... or using 'content
> filtering' in a different way here than before in this response.
>
>
>> Being able to know that a particular device is a particular device is
>> actually quite useful in this context; unfortunately, there is no way to
>> distinguish "useful" and "personally-identifying".   Even if you only
>> identify the IoT devices in your home, by doing so you reduce the search
>> space for identifying the other devices.
>>
>>
> I don't think the draft is aiming at 'device' as much as 'region of the
> network'. The cache resovler COULD choose to send /32 (or /128) level data
> in the edns0 option, but that seems counterproductive, and a bit invasive.
>
> -chris
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] EDNS0 clientID is a wider-internet question

[Christopher Morrow]

On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon <mel...@fugue.com> wrote:

> On Jul 24, 2017, at 8:59 PM, Christopher Morrow <morrowc.li...@gmail.com>
> wrote:
>
> and at the cache->auth layer it's potentially the case that the provider
> can say: "use precision of /24" or "use precision of /17" ? So, there's
> really not much "pii" that can be worried over at the
> provider-cache-resolver (they already know who you are...) and they
> (provider) can decide how much granularity is "important" to release to the
> upstream authoritative cache.
>
>
> There is no such thing as an upstream authoritative cache.   The filtering
> is being
>

apologies, 'upstream (from the cache resolver's perspective) authoritative
SERVER'.


> done at the cache.   This is not client subnet: this is client ID.   So
> the cache, which is not authoritative, is receiving PII about a specific
> client machine.   Being able to
>

I agree with this, the cache resolver sees the client's IP address.


> filter the PII at the CPE would indeed improve privacy in this case; the
> problem is that the CPE has to have a UI or API that allows that to happen,
> and they don't.
>
>
I don't think the CPE is the answer, the cache-resolver CAN decide to send
along in it's edns0 option: "1.2.128.0/17" instead of "1.2.3.0/24". Or it
seems to me that this is a fine knob to add to resolver software... granted
you'd need some extra config about your client subnets in use.


> The reason DNS filtering is useful is not that it is forced upon the end
> user, but that it allows devices that use the default cache to get
> filtering in a way that does not
>

I don't believe the goal of the draft is to enable filtering.
Certainly for a nation-state actor you could see: "Oh, now I know what
subnets use the resolver over there, so I can limit useful replies, or
steer requestors toward 'better/approved' content'


> depend on the software installed on them.   So e.g. your IoT device can be
> infected by a worm but not actually exfiltrate any private information to
> the attacker, because the attacker's DNS is blocked.
>
>
you seem to be conflating a few things here... or using 'content filtering'
in a different way here than before in this response.


> Being able to know that a particular device is a particular device is
> actually quite useful in this context; unfortunately, there is no way to
> distinguish "useful" and "personally-identifying".   Even if you only
> identify the IoT devices in your home, by doing so you reduce the search
> space for identifying the other devices.
>
>
I don't think the draft is aiming at 'device' as much as 'region of the
network'. The cache resovler COULD choose to send /32 (or /128) level data
in the edns0 option, but that seems counterproductive, and a bit invasive.

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

Re: [DNSOP] EDNS0 clientID is a wider-internet question

[Christopher Morrow]

On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon  wrote:

> It would be nice if there were an RFC to point to that used a method that
> didn't include PII.   For the use cases of which I am ware, there is no
> need to identify individual devices: only policies.   What's lacking is a
> way to do this in the home router, so the PII winds up getting exported to
> the cloud not because that's necessary to accomplish the filtering but
> because it's the only available place where the translation from
> PII->policy can be done in practice.   Unfortunately, solving _that_
> problem is definitely out of scope for DNSOP.
>
> isn't the query path here: (largely)
  client  -> cpe-router -> provider-cache-resolver -> auth-dns

and at the cache->auth layer it's potentially the case that the provider
can say: "use precision of /24" or "use precision of /17" ? So, there's
really not much "pii" that can be worried over at the
provider-cache-resolver (they already know who you are...) and they
(provider) can decide how much granularity is "important" to release to the
upstream authoritative cache.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses

[Christopher Morrow]

On Jul 19, 2016 8:36 AM, "Ralf Weber"  wrote:
>
>
> Except that if you have a decent size and hot Cache with refreshing
> these records will be in there anyway. IMHO you gained nothing, but I
> agree with Jim Reid that it would be good to have data on this.

Nothing except some DNS round trips.
How could that matter though?
___
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)

[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] Followup Discussion on TCP keepalive proposals

[Christopher Morrow]

On Wed, Jan 21, 2015 at 4:53 PM, John Heidemann jo...@isi.edu wrote:
 I don't see how DoS is an argument against TCP for DNS.  (Unless one
 assumes hardware and software at the servers is fixed to something like
 2004 standards.)  What am I missing?

What's the average client load expected (number of unique clients in
the timeout of the tcp connection expected) for an authoritative
server today? (say an enterprise hosted server, and then someone that
is a large domain aggregator)

What is the same curve for a recursive server? (again, a small
isp/enterprise vs a large provider)

What impact will changing to longer lived persistent tcp connections
have on hardware and network capacity planning?

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

Re: [DNSOP] [dns-operations] hong kong workshop, day 2, live link

[Christopher Morrow]

On Tue, Dec 9, 2014 at 12:12 PM, Randy Bush ra...@psg.com wrote:

 this is an amusing list.  i can understand EXAMPLE, LOCALHOST, and TEST.
 maybe even WHOIS and WWW.  but the rest sure look as if lawyers wanted
 and got what is in effect a super trademark.

I am shocked that there are lawyers in the naming business. When did
this happen? Who let them in the door/process?

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

Re: [DNSOP] call to work on edns-client-subnet

[Christopher Morrow]

#1 - support doing the work to finalize the edns-client-subnet standard.

now... (I hope my inline response is accepted by the readers of this
wg's list, I would note that someone's quoting is all jacked up... oh
well)

pull up waders

On Thu, May 8, 2014 at 12:17 PM, Paul Vixie p...@redbarn.org wrote:


 Ralf Weber wrote:

 ...

 There is madness, but the madness is in mixing authoritative and recursive
 functions in one server and not in using DNS to direct traffic.


It seems, to me at least, that a bunch of the problems with dns
'tricks' which are more than: Oh good, my zone loads! Lookey, I have
an A record! what is an A record again?

are that folk should not play with sharp knives if they aren't
prepared to get cut occasionally. Ideally you understand the
implications of tricks like:
  bind views
  dns anycast
  edns-client-subnet
  etc

before you deploy them... That's all beside the point of good
documentation being available to support inter-operability between
vendor code for these features though. Should the IETF mint a standard
for 'feature-X' in the software system that makes up the DNS? Where's
the bar used to measure whether or not a feature has critical enough
mass/interest to be written up? Should all feature ideas get adopted
and then those which prove to wither be permitted to die out before
WGLC?


 while i'm on record has holding that view, it turns out that RFC 1035 does
 describe recursion and authority as co-residing in a server. so while this
 is in my view a dangerous practice and a bad idea, it's well supported by
 the scriptures.


 After all that's what all lookups do, give you an IP address you connect to.


 i don't think so. dns lookups have many purposes unrelated to returning IP
 addresses. i'd like to see 100 more things like SSHFP this decade.

ah, so you seem to be in the camp of 'let a thousand flowers bloom' or
whatever... that seems like fun as well. Back on topic though, should
the edns-client-subnet work get attention and potentially move forward
in this WG?

-chris

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

Re: [DNSOP] key lengths for DNSSEC

[Christopher Morrow]

On Wed, Apr 2, 2014 at 11:19 AM,  Roy Arends r...@dnss.ec wrote:

 Just a thought that occured to me. Crypto-maffia folk are looking for a 
 minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk 
 are looking for a maximum (i.e. at most soo many bits otherwise 
 fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum 
 might actually be larger than the DNS-maffia’s maximum.

 As an example (dns-op perspective).

 Average case: 2 keys (KSK/ZSK) + 1 sig (by KSK) with 2048 bit keys is at 
 least 768 bytes (and then some).
 Roll case: 3 keys(2 KSK/1 ZSK) + 2 sig (by KSK) with 2048 bit keys is at 
 least 1280 bytes (and then some).


Part of jim's query is of interest:
  Where are the requirements? (boiled down some to that I think)

There's also a point I asked about previously in jim's note:
  Where's the POC at?

I don't think anyone's going to change anything without your referred
to 2008-like incident... and without some requirements at least as a
swag, right?

I'd expect the key length discussion relates pretty closely to:
  If I can factor the key in less time than you will rotate keys...

So, how often to the keys rotate? at least every 30 days? So you have
to be able to be 'secure' longer than 30 days of compute resources
time, right?

 Then there is this section in SAC63: Interaction of Response Size and IPv6 
 Fragmentation”

 Which relates to response sizes larger than 1280 and IPv6 and blackhole 
 effects.

 https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf

good times :(

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

Re: [DNSOP] key lengths for DNSSEC

[Christopher Morrow]

On Wed, Apr 2, 2014 at 11:31 AM, Christopher Morrow
morrowc.li...@gmail.com wrote:
 On Wed, Apr 2, 2014 at 11:19 AM,  Roy Arends r...@dnss.ec wrote:

 Just a thought that occured to me. Crypto-maffia folk are looking for a 
 minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk 
 are looking for a maximum (i.e. at most soo many bits otherwise 
 fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum 
 might actually be larger than the DNS-maffia’s maximum.

 As an example (dns-op perspective).

 Average case: 2 keys (KSK/ZSK) + 1 sig (by KSK) with 2048 bit keys is at 
 least 768 bytes (and then some).
 Roll case: 3 keys(2 KSK/1 ZSK) + 2 sig (by KSK) with 2048 bit keys is at 
 least 1280 bytes (and then some).


 Part of jim's query is of interest:
   Where are the requirements? (boiled down some to that I think)

 There's also a point I asked about previously in jim's note:
   Where's the POC at?

 I don't think anyone's going to change anything without your referred
 to 2008-like incident... and without some requirements at least as a
 swag, right?

oops, apologies, phil's 2008 reference.


 I'd expect the key length discussion relates pretty closely to:
   If I can factor the key in less time than you will rotate keys...

 So, how often to the keys rotate? at least every 30 days? So you have
 to be able to be 'secure' longer than 30 days of compute resources
 time, right?

 Then there is this section in SAC63: Interaction of Response Size and IPv6 
 Fragmentation”

 Which relates to response sizes larger than 1280 and IPv6 and blackhole 
 effects.

 https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf

 good times :(

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

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

[Christopher Morrow]

On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
 Yes. If doing it for the DNS root key is too politically challenging, maybe 
 do it for one of the 1024-bit trust anchors in the browser root pile.

why would this be politically sensitive?

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

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

[Christopher Morrow]

On Thu, Mar 27, 2014 at 2:39 PM, Nicholas Weaver
nwea...@icsi.berkeley.edu wrote:

 On Mar 27, 2014, at 11:18 AM, Christopher Morrow 
 christopher.mor...@gmail.com wrote:

 On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
 Yes. If doing it for the DNS root key is too politically challenging, maybe 
 do it for one of the 1024-bit trust anchors in the browser root pile.

 why would this be politically sensitive?

 Because the browsers have already decided killing of 1024b CAs is a good 
 idea, and they could revoke just those CAs once someone breaks a 1024b 
 example, since the browser vendors have good experience in revoking bad CAs 
 already (queue DigiNotar...)


 In contrast, DNSSEC seems mired in a 1024b swamp at the root, and when you 
 can use an old key (which you can for the root, since you can fake everything 
 up below that dynamically and fake NTP so that your bad key is still kosher), 
 breaking a root key really would be breaking DNSSEC.


that didn't answer the question really? Do you mean: NTIA/ICANN (pick
your place depending on day and worldview) would be upset that someone
proved there are no pants on the emperor.

I'm not sure that matters though? Just because you did it and
published the result/example doesn't mean that this isn't already
happening all over the net, right? I don't know that there's a reason
to NOT do the experiment and publish, without some impetus, what's
going to drive the change? given other priorities that exist and
already have leadership attention...

Why don't you just go do the experiment nick and let us know how it goes?

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

Re: [DNSOP] port 0 requests leading to errors

[Christopher Morrow]

If I have a patch which makes no sense, will you also add it?
On Mar 22, 2014 1:25 PM, Paul Vixie p...@redbarn.org wrote:



 bert hubert wrote:
  ...
 
  43.504115 IP x.y.117.10.0  192.175.48.6.53: 6365+ SOA?
 168.192.in-addr.arpa. (38)
  45.504152 IP x.y.117.10.0  192.175.48.6.53: 6365+ SOA?
 168.192.in-addr.arpa. (38)
  49.505124 IP x.y.117.10.0  192.175.48.6.53: 6365+ SOA?
 168.192.in-addr.arpa. (38)
 
  PowerDNS now refuses to attempt to answer such packets, which silences
 the
  error messages.

 mark andrews sent me a similar patch to bind 4.9 back in 1992, which
 made no sense to me but i put it in anyway. thanks for explaining.

 ___
 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] BIG RRSETS EDNS0 and ipv6 framentation.

[Christopher Morrow]

On Mon, Jun 17, 2013 at 10:19 PM, Mark Andrews ma...@isc.org wrote:

 In message 
 cal9jlabek2eh2jejmm2rjrugj6ctqtfzojyhkrp7hzjtefq...@mail.gmail.com, 
 Christopher Morrow writes:
 On Mon, Jun 17, 2013 at 8:49 PM, Mark Andrews ma...@isc.org wrote:
  Unfortunately the former are far too prevalent.  It's undoubtedly too
  late, but unfortunately it might have been better to do the
  fragmentation within the UDP payload (i.e. inside DNS) somehow (c.f.
  http://tools.ietf.org/html/rfc5405#section-3.2).
 
  It is *never* too late.  For IPv6 we are still in the very
  early days.

 but, what about the 'vast install base'  ?

 There isn't a vast install base of firewalls (border routers).
 If there was we would have 99% IPv6 traffic instead of 1.6% IPv6
 traffic.

I forgot my :) in my comment.
anyways...

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

Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?

[Christopher Morrow]

On Fri, Feb 15, 2013 at 5:05 PM, Paul Ebersman list-dn...@dragon.net wrote:

 nick I like this and think it should be adopted as a WG doc.  Am not
 nick going to volunteer for formal document review, but would be happy
 nick to run + provide feedback for this sort of code in a live
 nick environment.

 I also support this being adopted as a WG document.

aolme too!/aol

seems like a great start.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains

[Christopher Morrow]

On Tue, Oct 9, 2012 at 11:13 AM, Antoin Verschuren
antoin.verschu...@sidn.nl wrote:

 So enough prior art.
 Question is more if we need action and if so what.
 I don't have any knowledge about the US patent system, or any patent
 system as a matter of fact.

perhaps the questions to ask are:
 1) does it hurt the filing entity to file a claim? (verisign in this case)
 2) does it hurt people using the 'prior art' today? (ietf users of
the technology I suppose)
 3) what remediation is verisign expecting today (or ever)?
 4) what's the cost to fight the claim?

I think for 1 there's very little cost (none maybe), so the rest don't
really matter... file all the patent applications!! (there's a meme
about this...)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] FYI: DNSOPS presentation

[Christopher Morrow]

On Wed, Mar 31, 2010 at 1:55 PM, Dan Wing dw...@cisco.com wrote:

 But Remi's point is that those same systems (running Windows XP
 and IE6) using 6rd will be denied the ability to access content
 via IPv6.  Which removes an incentive for ISPs to add 6rd (and
 offload the NAT44 they may soon have to install).

I'm not sure this is true:
o the end-station sends a dns query to the ISP recursive resolver
o the recursive resolver uses whichever protocol is 'best' for the
lookup (assuming something like BIND's NS RTT caching happens in the
majority of cases)
o if the query goes over ipv6, is for a , a  response could be returned
o if the query goes over ipv4, is for a , no response is returned
and presumably a follow-up A query happens.

Igor/Yahoo are proposing that recursive resolvers which have v6
transport use it and be rewarded for doing so... if they have a
longer/worse path over ipv6 there's a good chance the user experience
will also suffer, so the users should use v4.

-chris

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

Re: [DNSOP] Ugly DNS ack

[Christopher Morrow]

On Wed, Mar 31, 2010 at 10:41 PM, Patrick W. Gilmore patr...@ianai.net wrote:
 On Apr 1, 2010, at 12:29 AM, John Jason Brzozowski wrote:

 Not necessarily, if a dual stack hosts communicates with a recursive name
 server over both IPv4 and IPv6 and other conditions are met then I believe
 it would be fine based on what was presented.

 What other conditions need to be met?

 I did not think there was any way for a host to signal a recursive NS to use 
 v6 or v4 transport.

It seems to me that you'll need to: (at least)
1) ask for a  from the client - recursive resolver
2) dual-stack the recursive resolver
3) provide 's with 'better' latency/response than the A records
associated with the NS's for your domain (the domian being looked up)
4) decide to answer  queries over ipv6 transport from these NS hosts.
5) also reply with A (and other normal records) when asked for them
over either transport

Just because 'if the  query comes over ipv6, auto-whitelist +
answer' there's nothing stopping the server from responding to A
queries over ipv6 with ipv4 addresses. The NS here has no real idea
about the original requestor, only what the recursive resolver decides
to use for a transport.

you can suppose that if a recursive resolver has 'better' ipv6
transport it should be used 'more', and that potentially the
AS/customer-set represented by it will have 'better' (or at least
'good enough') ipv6 transport, but that's not guaranteed.

All that said, I think I like Igor's idea, I'm not sure I'd implement
it without some research first... the same issues that keep
large-content-providers from adding blanket  records would likely
also affect DNS queries over ipv6 transport.

-Chris



 On 3/31/10 5:12 PM, John Payne j...@sackheads.org wrote:



 On Mar 31, 2010, at 3:19 PM, Dan Wing wrote:

 Any host that sends its  queries over IPv4 would lose
 IPv6 connectivity.


 Isn't this a misdirection?

 I suspect it's more like: any (address family agnostic) clients of a dual
 stacked nameserver will (non?) deterministically lose IPv6 connectivity to
 DNS-determined destinations.

 ie, even if I only send DNS over IPv6 to my recursive nameserver, if it is
 dual stacked (often beyond my control), and for this specific query it 
 prefers
 IPv4, then I will not get an answer for my  under this proposal.



 =
 John Jason Brzozowski
 Comcast Cable
 e) mailto:john_brzozow...@cable.comcast.com
 o) 609-377-6594
 m) 484-962-0060
 w) http://www.comcast6.net
 =

 ___
 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] how DNS redirect works with empty response

[Christopher Morrow]

2009/8/3 Florian Weimer f...@deneb.enyo.de:
 * JINMEI Tatuya / 神明達哉:

 What does a recursive server that implements the DNS redirect service
 do in this case?

 Empty responses are typically rewritten.  NXDOMAIN redirect is a
 misnomer.

 then I guess authoritative server implementors who don't like
 NXDOMAIN redirect could introduce a auto-site-finder option,
 defaulting to yes, which automatically adds a wildcard name (of some
 meaningless RR type) at the apex of each authoritative zone:-)

 I don't think this trick will work.

with the unspoken reason of: Because the redirctor has full control
over the dns reponse path and can 'at will' replace any response with
one of it's choosing.

For instance replacing all instances of: isc.org with
dns-assist.com because of either mal-intent or misconfiguration on
the part of the redirector service owner.

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