Hi Shane,
On Jul 29, 2017, at 09:05, Shane Kerr wrote:
> I guess that I understand your concern, but we don't have any way to
> authenticate servers in DNS today and we already send error messages back.
>
> I'm happy with error codes that are informational, but don't change client
> behavior
Hi Mike,
On Aug 2, 2017, at 09:54, Mike West wrote:
> What would you like to see in the document in order to address this concern?
> A requirement that a `localhost` zone be created and delegated as an insecure
> delegation, using some of the language from the draft above (e.g. "This
> delega
Wow. That was horribly-formatted. Apologies for the iPad MIME-crime.
> On Aug 2, 2017, at 14:34, Joe Abley wrote:
>
> Hi Mike,
>
> On Aug 2, 2017, at 09:54, Mike West wrote:
>
> What would you like to see in the document in order to address this concern?
> A requi
On 7 Sep 2017, at 11:42, Stephane Bortzmeyer wrote:
> On Tue, Sep 05, 2017 at 03:25:39PM -0400,
> tjw ietf wrote
> a message of 77 lines which said:
>
>> This starts a formal Call for Adoption for draft-tale-dnsop-serve-stale
>>
>> The draft is available here:
>> https://datatracker.ietf.org
Apologies in advance for iPad MIME-crime. See below for crimes committed by
workman rather than tools.
> On Sep 7, 2017, at 21:37, Paul Vixie wrote:
>
> note, there's a proposal contained here.
>
> Jared Mauch wrote:
>>> On Thu, Sep 07, 2017 at 01:29:47PM -0700, Paul Vixie wrote:
>>> if the dr
> On Sep 8, 2017, at 01:28, Paul Vixie wrote:
>
> if they really need this, they should provide a method by which i can specify
> both a TTL and an Expiry, and i will consider publishing both values, and if
> i
> do, then they can use them the way i intend them. because as i said,
> autonomy
On 12 Sep 2017, at 13:11, John R Levine wrote:
>> https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00#section-4.1
>>
>> When something shouldn't work, it shouldn't work.
>
> I agree but this is a tangent. The draft is about localhost. or maybe
> .localhost. It's not about localhos
On Oct 31, 2017, at 07:27, Ray Bellis wrote:
>> On 30/10/2017 17:40, Evan Hunt wrote:
>>
>> IIRC we discussed it, and were concerned that _ta. could be cached as
>> nonexistent by servers implementing QNAME minimization.
>
> How would that happen, at least so long as _ta responds like any other
On 31 Oct 2017, at 11:01, Ray Bellis wrote:
> On 31/10/2017 14:56, Joe Abley wrote:
>
>> Perhaps I missed something, but how do you ensure that _ta is an
>> empty non-terminal?
>
> By having that be part of the required server logic to implement the
> sentinel mecha
On 2 Nov 2017, at 11:04, Bob Harold wrote:
> I generally agree with you, but wonder if there is a performance penalty to
> searching every possible path before failing. Is that a reasonable concern?
I think there's a much bigger performance penalty from returning an error to an
application an
On Nov 12, 2017, at 10:51, Kim Davies wrote:
We haven't studied what would be involved, but I feel confident in
predicting the whole exercise would be non-trivial.
It seems to me that you could implement this using lawyers as easily as you
could using developers; it is after all arguably a sta
An unbounded number of AS112 operators, not an inbound number.
I apologise to all present for sending mail to dnsop from a phone without
taking more time to check for autocorrect lunacy.
On Nov 12, 2017, at 11:26, Joe Abley wrote:
On Nov 12, 2017, at 10:51, Kim Davies wrote:
We haven&#
Hi Geoff,
I think the number 4 on the slide was different from the one in the mail.
The option on the slide that I mentioned I liked the most was the one that
didn't copy the RCODE value from the header, but in effect provided a
16/32/whatever-bit sub-code for whatever the RCODE happened to be.
On Nov 14, 2017, at 09:37, George Michaelson wrote:
> Stephane, I don't entirely understand your response. old systems can
> never understand new code point assignments, or know what to do with
> it, no proposed change can alter this. Middleboxes dropping unexpected
> things will hit almost any p
On Nov 14, 2017, at 16:47, Viktor Dukhovni wrote:
Well, once we're in the "lying with DNS" business, we hardly need
to restrict extended diagnostics to errors, we can equally contemplate
them for policy-based answers that don't reflect the authoritative
zone content... :-8
You make it sound li
Hi Bob,
On Nov 15, 2017, at 00:23, Bob Harold wrote:
If I have to add those entries to each zone, I worry that the automated DNS
appliance that I use might not be able to create the broken records
required.
Since the implementation of the mechanism requires special handling of
queries whose QNA
I support adoption and am willing to contribute and review.
> On Nov 16, 2017, at 16:23, tjw ietf wrote:
>
> All
>
> The author has rolled out a new version addressing comments from the meeting
> on Monday, and we feel it’s ready to move this along.
>
> This starts a Call for Adoption for dra
On Nov 23, 2017, at 06:19, Havard Eidnes wrote:
> Secondly: can someone please explain to me why the idea of a
> "primary master" where the zone data originates from and where
> updates are performed is considered archaic?
I think the only in-protocol use of the MNAME field is to specify the nam
Hi Håvard,
On Nov 23, 2017, at 11:36, Havard Eidnes wrote:
>>> Secondly: can someone please explain to me why the idea of a
>>> "primary master" where the zone data originates from and where
>>> updates are performed is considered archaic?
>>
>> I think the only in-protocol use of the MNAME fie
On Nov 23, 2017, at 12:44, Tony Finch wrote:
Joe Abley wrote:
In that sense the idea of using a single master (which I think is
implied by "primary master" and a name published in a single MNAME
field) is defensibly archaic.
It's quite difficult to have multiple masters
Hi Paul,
On 23 Nov 2017, at 13:48, Paul Vixie wrote:
> Joe Abley wrote:
>> ...
>>
>> Feeding a large array of slaves (eg hundreds, including individual
>> members if clusters) with large numbers of zones from a single master
>> doesn't scale very well.
>
Hi Fred,
[I haven't read Jordi's draft; I'm just responding to what I've read in this
thread.]
On Nov 25, 2017, at 14:00, Fred Baker wrote:
> One thing you might want to think about: the root servers are all
> IPv6-capable today and serve requests using IPv6, and the 1541 TLDs are all
> requ
Hi Tony,
On Nov 27, 2017, at 08:22, Tony Finch wrote:
> Joe Abley wrote:
>>> On Nov 23, 2017, at 12:44, Tony Finch wrote:
>>>
>>> It's quite difficult to have multiple masters and DNSSEC and coherent
>>> copies of the zone from all masters
As I imagine you've heard, part of the problem with resolver-authoritative
telemetry interfaces is that the deployed infrastructure is not so simple; it
also includes forwarders, changed resolvers, caches, middleware that interferes
with the query path and/or drops queries that don't look normal
On 27 Nov 2017, at 14:47, Richard Barnes wrote:
> As tempting as it may be to do the easy thing, it's not always the best use
> of resources. Looking at the closest tree might be easy for one observer,
> but when you try to do it with enough observers to have a result that's
> useful for the
On Dec 5, 2017, at 23:04, Lanlan Pan wrote:
> Some authorititatives set the NS RR TTL<60s, they don't follow the best
> practice guide.
The trouble here is understanding the motivations of any particular parameter,
and doing so at scale.
You could assume as a resolver operator that a zone man
Hi Stéphane,
On 11 Dec 2017, at 04:18, Stephane Bortzmeyer wrote:
> On Mon, Dec 11, 2017 at 01:10:20AM -0800,
> Paul Vixie wrote
> a message of 31 lines which said:
>
>> we have no way to assure that they hear a request that they add more
>> secondary DNS zones to such servers. so if we deleg
On 11 Dec 2017, at 19:50, Ted Lemon wrote:
> On Dec 11, 2017, at 11:17 AM, Joe Abley wrote:
>> Note though that the homenet document specifically requests a delegation.
>
> Please do not read more into the document than was intended. What Mark is
> saying looks to m
Hi Ted,
> On Dec 13, 2017, at 17:14, Ted Lemon wrote:
>
> Can you point to the actual ambiguity? The reason we said "one or more
> black hole servers" was to leave it up to the operator of .arpa to decide
> which black hole servers and how many of them. That was a deliberate
> choice, not
Hi Mark,
> On Dec 13, 2017, at 17:09, Mark Andrews wrote:
>
> Section 7 says:
Yes, I know. I read it.
> RFC 6303 has similar requirements and IANA was able to co-ordinate those
> delegation.
Apart from the zones originally delegated to the AS112 project, I couldn't find
a zone specified in
Hi Mark,
[I'm typing this on a phone. It's going to look horrible in a real
mail client. Sorry about that.]
On Dec 13, 2017, at 20:19, Mark Andrews wrote:
> Looks like we need to open a ticket for those. But the ones people actually
> have internal zones in are correct. Check the RFC 1918 de
On 15 Dec 2017, at 10:31, Paul Hoffman wrote:
> On 14 Dec 2017, at 21:45, Geoff Huston wrote:
>
>> I agree the mechanics of the change in the text, and even in the code for
>> support this are pretty minor, but I am slightly worried about the intended
>> generality of the proposed change being
On 15 Dec 2017, at 11:24, Matt Larson wrote:
>> On Dec 15, 2017, at 10:37 AM, Joe Abley wrote:
>>
>> In practical terms anybody who has a non-root trust anchor installed has a
>> bidirectional operational relationship with the people who publish it.
>> Synchro
Hi Warren,
On 14 Jan 2018, at 20:51, Warren Kumari wrote:
> I had a conversation with a friend earlier today, who had carefully read the
> document
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/), but
> had not managed to understand it at all. Since this friend is
On 15 Jan 2018, at 07:22, KenM wrote:
> I think its a bit sad that for the DNS to work, one now needs to run http[s]
> and JS. So much for stand alone protocols. Now if you could show how this
> works without JS or HTTP, then we might be getting somewhere.
We could write the client test cod
Hey Paul,
(with the usual apologies for the MIME-crime that follows)
> On Jan 24, 2018, at 20:50, Paul Vixie wrote:
>
> Mark Andrews wrote:
>>> On 25 Jan 2018, at 8:38 am, Paul Vixie wrote:
>>>
>>> viktor, i don't disagree with your goals, but i have a proposal as to
>>> method.
>>>
>>> no
Hey,
> On Jan 30, 2018, at 10:24, Andrew Sullivan wrote:
>
>> On Mon, Jan 29, 2018 at 11:37:55PM +0100, Martin Hoffmann wrote:
>> Perhaps define a term for "A or " such as "address record"?
>
> I went and looked at terminology-bis and noted that we use "address
> record" and parenthetically
Hi George,
On Jan 30, 2018, at 21:49, George Michaelson wrote:
>> The problem you hit was in BIND. To get around it, you simply add
>> "check-names master warn;" to the options.
>
> And with this.. he was good again. So, modulo the implementation
> cost/consequence, I'm good here.
>
> But, if
> On Feb 1, 2018, at 20:27, Ted Lemon wrote:
>
>> On Feb 1, 2018, at 3:41 PM, Andrew Sullivan wrote:
>> I think that this is an example of attempting to
>> do so: to make a name that already appears today in the DNS
>> (localhost) go away.
>
> Okay, but this simply isn't true. I think you act
> On Feb 1, 2018, at 21:03, Ted Lemon wrote:
>
>> On Feb 1, 2018, at 7:46 PM, Joe Abley wrote:
>> Can we take a brief pause to acknowledge that "the DNS" as a phrase is
>> highly ambiguous and think about whether we mean the protocol, any
>> p
On 6 Feb 2018, at 11:04, Petr Špaček wrote:
> On 6.2.2018 13:22, Tony Finch wrote:
>> A. Schulze wrote:
>>
>>> Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
>>> I also prefer that longer variant.
>>
>> Yes, more friendly for web searches if someone is wondering about wei
Hi Paul,
> On Feb 7, 2018, at 10:43, Paul Wouters wrote:
>
>
> I think it is useful to know how long the DNS resolver process has been
> up, and/or how long the server running the DNS resolver has been up,
> when it is sending the sentinel queries.
>
> That would allow us to detect if we are l
Hi Paul,
(with apologies for breakfast/iPad MIME crime that surely follows)
> On Feb 8, 2018, at 01:02, Paul Wouters wrote:
>
>> On Wed, 7 Feb 2018, Robert Story wrote:
>>
>>> On Wed 2018-02-07 10:43:16-0500 Paul wrote:
>>> How about using this query to also encode an
>>> uptime-processstarted
> On 8 Feb 2018, at 09:24, sth...@nethelp.no wrote:
>
>> If just to spread rumors, I heard the following as early as November, 2016.
>> One of the issues is that operators update code without updating
>> configuration files. I.e., a BIND upgraded today might be using a
>> configuration file
On 8 Feb 2018, at 13:52, Paul Wouters wrote:
> On Thu, 8 Feb 2018, Joe Abley wrote:
>
>> I don't disagree with the need for more data, but I think the hole you
>> mention is not so giant. As far as I can tell it's a result of:
>
> How do you know without the
Hi Paul,
This draft is waiting for me to commit changes to and submit a revised draft.
My co-author and our esteemed chairs have been badgering me with full
efficiency, and the delay is all my fault. I have some time this weekend so
long as I don't have to deal with another metre of snow, and I
Hi Warren,
I think the advice is good, but I wonder what the practical effect of writing
it down would be. I doubt it would change any of the entrenched habits in
enterprise systems and networking in our remaining lifetimes, for example, but
perhaps I'm just being overly grumpy and am ignorant
On Feb 10, 2018, at 16:27, Ted Lemon wrote:
> Well, for example, when the DHC working group was considering the search list
> option for DHCPv6, I argued that there should be no such option because
> search lists are bad. My argument was rejected. Had the IETF officially
> deprecated searc
On 12 Feb 2018, at 06:30, Tony Finch wrote:
> Paul Wouters wrote:
>>> On Feb 9, 2018, at 20:22, Joe Abley wrote:
>>>
>>> I aim to get it done before next week.
>>
>> Awesome! Thanks!
>
> And from me too - I was wondering about this draft the o
On 13 Feb 2018, at 12:10, Bob Harold wrote:
> Thanks, the explanation helped. I finally realized that it only works if all
> (or most) validating resolvers are updated to support this new feature,
> otherwise we have a bunch of responses that are uncertain.
Based on numbers of queries arrivin
On Feb 21, 2018, at 14:43, Bob Harold wrote:
> Prefer numeric, since RFC4034 specifies that for display, and everywhere I
> see key tags in a google search they are always that way. "dig" shows them
> that way.
Me too, same reasons.
Why did 8145 specify hex? I don't remember the discussion.
Hi Petr,
> On Feb 22, 2018, at 04:03, Petr Špaček wrote:
>
> I would prefer decimal for user-friendliness, and zero padding to make
> implementation easier and faster.
A few people now have mentioned that they like zero padding. What is
it about zero padding or fixed-size labels that makes imple
On 22 Feb 2018, at 06:20, Petr Špaček wrote:
> On 22.2.2018 11:38, Joe Abley wrote:
>
>> A few people now have mentioned that they like zero padding. What is
>> it about zero padding or fixed-size labels that makes implementation
>> easier than specifying no zero paddi
fication for draft-ietf-dnsop-refuse-any-05.txt
> Date: 5 March 2018 at 14:17:50 EST
> To: "Joe Abley" , "Marek Majkowski"
> , "Olafur Gudmundsson"
>
>
> A new version of I-D, draft-ietf-dnsop-refuse-any-05.txt
> has been successfully submit
ouple of weeks.
Begin forwarded message:
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-dnsop-refuse-any-06.txt
> Date: 5 March 2018 at 16:44:49 EST
> To: "Joe Abley" , "Marek Majkowski"
> , "Olafur Gudmundsson"
>
On 12 Mar 2018, at 11:09, Paul Hoffman wrote:
> Can these be improved on? This is one of the core ideas in the DNS protocol
> and it seems a bit weird that we don't have a crisp set of definitions. If
> there is more text from RFCs to quote, that would possibly be a big help.
One detail that c
On 12 Mar 2018, at 11:58, Roland Bracewell Shoemaker
wrote:
> After a number of discussions I’m interested in returning to the original
> concept as it simplifies a number of use cases that this document is intended
> to support but am still not sure whether or not this would be widely
> cons
On 13 Mar 2018, at 11:22, Ted Lemon wrote:
> On Mar 13, 2018, at 11:16 AM, Joe Abley
> wrote:
>
>> I think that if Tony can be d...@dotat.at, surely I can be
>> jab...@90.212.199.in-addr.arpa.
>>
>> A zone is a zone. ARPA is only special by conv
On 13 Mar 2018, at 10:55, Tony Finch wrote:
> From the operational point of view, you're going to bump into a lot of
> annoying road blocks: undelegated reverse DNS, provisioning systems that
> only allow for PTR, etc.
Data point: Google's MXes evidently have no interest accepting mail from me
lines is necessary and that the
working group should take this on.
Joe
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for
> draft-jabley-dnsop-bootstrap-validator-00.txt
> Date: 19 March 2018 at 14:59:53 GMT
> To: "
On Mar 24, 2018, at 13:49, Jared Mauch wrote:
>isc/bind can and perhaps should implement logging for these
> rrtypes that say they may be going away so folks can see the impact.
I'm actually surprised to see that support for rarely-used RRTypes is
really upsetting the camel.
A combinatorial
On Apr 3, 2018, at 21:32, Frederico A C Neves wrote:
>> On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:
>> Hi Frederico,
>>
>>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
>>> I was looking at our server to evaluate the MIXFR implementation and
>>> it seams to me that th
On Apr 6, 2018, at 09:45, Job Snijders wrote:
> While you are right that it is useful to define what is required for
> what sort of document, but I'd like to observe that at this moment, we
> are looking at a draft with 0 (zero, null, nada) implementations*, and
> also no implementation report dr
On Apr 6, 2018, at 14:43, 神明達哉 wrote:
> At Thu, 05 Apr 2018 17:15:47 +,
> Job Snijders wrote:
>
>> While the chair notes awareness of the point I raised, I’d like the be
>> explicit to avoid any confusion.
>>
>> This document is *not* ready for publication. There is no implementation
>> repo
Hi Bob,
On Apr 11, 2018, at 08:50, Bob Harold wrote:
> In various places, like 4.3. TSIG Record Format, "resolver and server" is
> used which seems a little vague to me, since I use TSIG between master and
> slave authoritative servers, neither of which is a resolver. Would it make
> sense
Following on from my previous comment in a will surely make no sense in the
archives unless you're ordering by date instead of by thread,
On 4 May 2018, at 08:37, Edward Lewis wrote:
> This isn't about terminology but the once-again debate about a registry's
> responsibility here.
>
> It's si
On 4 May 2018, at 10:26, Joe Abley wrote:
> Following on from my previous comment
Arrgh, which I sent from the wrong mailbox, and which consequently was held for
moderation.
Apparently I am not ready to use the Internet today.
Joe
signature.asc
Description: Message signed with Open
On 4 May 2018, at 05:59, Shane Kerr wrote:
> I think that there may be something useful in creating a term when a
> delegation only points to lame servers, thus cannot be resolved at all.
> Perhaps "broken delegation"?
One thing that I think has been missing from much of this conversation (but n
On 4 May 2018, at 05:59, Shane Kerr wrote:
> I think that there may be something useful in creating a term when a
> delegation only points to lame servers, thus cannot be resolved at all.
> Perhaps "broken delegation"?
One thing that I think has been missing from much of this conversation (but n
Hi Benno,
On 9 May 2018, at 09:12, Benno Overeinder wrote:
> There are now 2 implementations of kskroll-sentinel:
> 1) peer-reviewed and merged in the BIND master branch;
> 2) released with Unbound 1.7.1 last week.
>
> (And the draft mentions the implemention early versions of this
> technique
On Jun 19, 2018, at 10:20, Tony Finch wrote:
> Petr Špaček wrote:
>>
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
>
> The feature I would like is CNAME and other data (typically CNAME + MX +
> TXT), because I have a lot of deep
> On 19 Jun 2018, at 15:02, John Levine wrote:
>
> In article
> you
> write:
>> This sounds like a lot of work and likely to cause camel indigestion.
>
> Agreed but it doesn't seem all that much less work than a well
> specified version of ANAME, and it avoids the ANAME ugliness of making
>
On Jun 20, 2018, at 19:07, Warren Kumari wrote:
... what I'd alway wanted[0] was to be able to setup my own recursive name
server somewhere on the Internet, and then only allow myself (and a few of
my closest friends) to be able to query it.
For this particular use-case, why is SIG(0) better th
On Jun 20, 2018, at 21:05, Shumon Huque wrote:
On Wed, Jun 20, 2018 at 7:30 PM Joe Abley wrote:
> On Jun 20, 2018, at 19:07, Warren Kumari wrote:
>
> ... what I'd alway wanted[0] was to be able to setup my own recursive
> name server somewhere on the Internet, and then
On 19 Jun 2018, at 17:03, Ray Bellis wrote:
> On 19/06/2018 17:44, Tony Finch wrote:
>
>> SRV should have been part of the fix (and it was invented early
>> enough to be!) but it wasn't a complete fix without support from the
>> application protocols.
>
> AIUI, a large part of the supposed issu
Hi Benno,
On 22 Jun 2018, at 11:04, Benno Overeinder wrote:
> This starts a *one* week Working Group Last Call process, and ends on:
> 23:59 29 June 2018.
Which timezone? Seems odd to specify a timestamp with minute-accuracy without
specifying the hour :-)
=== General
I have read draft-ietf-
Hi Victor,
On Jun 23, 2018, at 17:04, Viktor Dukhovni wrote:
> [...]
> Yes, but if they have the NSEC bitmap, they can follow the XNAME
> without asking again.
> [...]
> That's already handled by NSEC/NSEC3.
I think a pragmatic solution needs to work in unsigned zones.
The demand for this kind
On Jun 23, 2018, at 22:45, Paul Vixie wrote:
> Joe Abley wrote:
>> I think a pragmatic solution needs to work in unsigned zones.
>>
>> ...
>
> can someone ask the IAB to rule on whether any new internet technology
> standard should address unsigned DNS zones, or
On 3 Jul 2018, at 09:11, Matthew Pounsett wrote:
> This is not a complete review of the latest revision.. I'm hoping to get to
> that in a day or two. But I've got a question about whether something
> should be added to the document..
>
> A question came up in conversation recently about the
On Jul 5, 2018, at 19:38, George Michaelson wrote:
> Only the zone authority can publish a DNSSEC signed zone.
I don't know what this means exactly, but I think it's wrong. I will
illustrate my thinking by using some of these words (like "publish")
in the way that I understand them, to see if t
On Jul 9, 2018, at 02:02, George Michaelson wrote:
> wow. Firstly, I thought canonicalization was a given: we have
> definitions of canonical zone order for other reasons (NSEC*) don't
> we?
NSEC is concerned with the ordering of owner names.
RRSIG is concerned with the ordering of individual R
On Jul 10, 2018, at 16:09, Adam Roach wrote:
> [as an individual]
>
>> On 7/10/18 9:59 AM, Paul Wouters wrote:
>> It seems more like an extension of the Public Suffix. Which domains can
>> make claims about other domains.
>
> Based on the conversation that took place in DoH in Singapore, I thi
On Jul 10, 2018, at 16:09, Paul Wouters wrote:
> On Fri, 6 Jul 2018, Tim Wicinski wrote:
>
>> This starts a Call for Adoption for: draft-huque-dnsop-multi-provider-dnssec
>> The draft is available here:
>> https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/
>
> I've revi
On Jul 10, 2018, at 17:22, Adam Roach wrote:
> Basically, you're describing a solution space that could be realized as
> something like:
>
> https://example.com/img/f.jpg"; ip="192.0.2.1">
Ok, interesting. I would suggest considering a richer scheme that
accommodates address families and multip
On Jul 10, 2018, at 17:41, Ted Lemon wrote:
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote:
> > But this is really equivalent in just about every important way to
> sending the normal https://example.com/img/f.jpg";> along with a
> pushed DNS record that indicat
On Jul 10, 2018, at 18:02, Adam Roach wrote:
> In large part because DNS provides "a richer scheme that accommodates address
> families and multiple addresses with priorities".
*cups hand to ear*
Was that the sound of a distant desire to specify use of SRV for HTTP?
Joe
Hi Andreas,
One problem with using non-unique namesapaces is that if you ever find yourself
needing to join your infrastructure to someone else's you run the risk of
collisions.
[This is an analogue to the problem at the IP layer with using RFC 1918
addresses -- if I'm already using 192.168.1
On 25 Jul 2018, at 12:30, Warren Kumari wrote:
> One of the original promises of DNSSEC is that I'd be able to find a
> zonefile written on a napkin on a bar floor, and trust it -- currently
> I cannot do this.
I don't think this is correct.
The main thrust of DNSSEC (as finally standardised) w
On Jul 29, 2018, at 12:19, Steve Crocker wrote:
> It feels like this discussion is based on some peculiar and likely incorrect
> assumptions about the evolution of root service. Progression toward hyper
> local distribution of the root zone seems like a useful and natural sequence.
> However
Hi Steve,
On Jul 29, 2018, at 15:09, Steve Crocker wrote:
> As an individuals, you, I, or anyone else, can do whatever we like, of
> course. On the other hand, as system designers we presumably look at the
> overall system and try to put in place an operational structure that
> anticipates a
service, I'm not
> in agreement that we should be entangling it with the much larger
> architectural issues you're raising.
>
> Steve
>
>
>> On Sun, Jul 29, 2018 at 12:44 PM, Joe Abley wrote:
>> Hi Steve,
>>
>> On Jul 29, 2018, at 15:09, S
On Jul 29, 2018, at 17:13, Florian Weimer wrote:
> * Tim Wicinski:
>
>> For the ZONEMD RR Type, where in the registry do the authors think it
>> should go? While some of that falls on the Expert Review process, I think
>> the document authors should capture their rationale in the document. If
Hi Philip,
Are you suggesting that web servers can't be massively scaleable? I'm not sure
I understand your examples.
You cite overprovisionoing in the root server system as a reason not to try and
supplement it, but I think it makes sense to look at it the other way round --
if there were way
Hi Paul,
I agree that it would be foolish to change 4034/4035 without understanding the
implications of doing so (e.g. breaking validators).
However, it's possible that it would be a fairly minor semantic change, e.g. if
signing records with an owner name below a zone cut was optional and if
v
Hi Richard,
I'd suggest that the unqualified nouns "question" and "answer" are sufficiently
ambiguous as to be dead to us at this point.
I agree with the idea that a "response" is a DNS message generated in response
to a query. Both "query" and "response" can be defined as DNS messages with
pa
Paul, you seem suspicious that there is some underhand camel attack
being planned, here, and that the forces of good must assemble to
reveal the ugly truth and save the caravan.
I think being able to verify the integrity of a zone as a complete
data structure is useful.
I think interop is useful.
have QTYPE=ANY
>Authors : Joe Abley
> Olafur Gudmundsson
> Marek Majkowski
> Evan Hunt
> Filename: draft-ietf-dnsop-refuse-any-07.txt
> Pages : 12
>
On Aug 20, 2018, at 07:48, Vittorio Bertola
wrote:
>> Il 19 agosto 2018 alle 19.02 Doug Barton ha scritto:
>> And Jason, you missed a threat model, which is users who want to bypass
>> their ISP's resolver.
>
> I think that there should be a lot more attention to this "use case" in this
> di
On Aug 20, 2018, at 11:49, Paul Vixie wrote:
> Joe Abley wrote:
> ...
>>
>> These are the same use-case, just viewed with different bias.
>>
>
> so, DoH's use cases all involve either violating the law, or violating the
> network operator's securi
Hi Tom,
> On Aug 24, 2018, at 09:52, Tom Pusateri wrote:
>
>> If a zone is signed, are the TIMEOUT records signed?
>
> No. The draft says they are skipped.
New RRTypes are supposed to be handled by old software that pre-dates them
because they can be treated as opaque types. That's not the ca
301 - 400 of 884 matches
Mail list logo
