On 3 Mar 2014, at 9:51, joel jaeggli wrote:
> On 3/3/14, 9:25 AM, Norbert Bollow wrote:
>> Warren makes a strong argument in favor of .alt I think.
>
> yeah... anything that has the potential to result in additional leakage
> seems like a recipe for additional pain.
Well, except that the curre
On 2 Mar 2014, at 23:02, Stephane Bortzmeyer wrote:
> On Sat, Mar 01, 2014 at 10:13:23PM -0500,
> Joe Abley wrote
> a message of 93 lines which said:
>
>> It's hard to see a better option than today than anchoring your new
>> namespace to a domain that you re
On 3 Mar 2014, at 13:12, Ted Lemon wrote:
> On Mar 3, 2014, at 1:09 PM, Joe Abley wrote:
>> I suggest that it's entirely plausible for someone to choose a DNS-namespace
>> anchor for their non-DNS namespace that is as stable as they want, depending
>> on their needs
On 3 Mar 2014, at 13:17, Ted Lemon wrote:
> On Mar 3, 2014, at 1:07 PM, Joe Abley wrote:
>> If we assume that leaks will happen, then they will hit the root servers and
>> there's no opportunity to sink the queries anywhere else.
>
> This will happen whether the s
On 3 Mar 2014, at 14:19, Warren Kumari wrote:
> 3. The root zone nameservers should either return NXDOMAIN
> responses, or the ALT TLD should be delegated to "new style"
> AS112 nameservers. (TODO(WK): WK, JA, BD to revive AS112 /
> AS112-bis).
New-style AS112 proposes red
On 3 Mar 2014, at 18:46, Paul Vixie wrote:
> i know of code that's in widespread use which assumes that TC=1 means that
> the last non-empty section was damaged but that it is safe to cache anything
> found in earlier sections. this code is clearly wrong-headed, but as i said,
> is in wide-sp
I have not reviewed all these drafts thoroughly, since I am a slacker, and so
what follows is mainly a reaction to presentations and not a detailed reading
of the text. So, in no particular order (hence numbering):
8. draft-hzhwm-start-tls-for-dns-00, TO not protected
It seems like a potential
On 4 Mar 2014, at 15:17, Warren Kumari wrote:
> Let's figure out what the right answers are, and then figure out how
> (and if) we get there from here.
I realise I have my broken record hat on, but the only problem that reserving
ALT solves is avoiding collision with an ALT TLD in the DNS.
Th
, Roy Arends ,
> "Joe Abley"
>
>
> A new version of I-D, draft-jabley-dnsop-dns-onion-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
>
> Name: draft-jabley-dnsop-dns-onion
> Revision: 00
> Title:
On 7 Mar 2014, at 10:05, Mark Andrews wrote:
> What do we expect CPE devices to implement to update parent
> zones. 100 different things to cover all the update methods
> registrar's come up with. Or do we say do exactly one
> method that works in all situations?
>
>
On 7 Mar 2014, at 10:49, Tony Finch wrote:
> Joe Abley wrote:
>
>> https://xkcd.com/927/
>
> So from the standards development point of view, I think what this is
> saying is that success is more likely to come from building on what people
> are already doing and nu
On 27 Mar 2014, at 22:56, Nicholas Weaver wrote:
> Bits are not precious: Until a DNS reply hits the fragmentation limit of
> ~1500B, size-matters-not (tm, Yoda Inc).
>
> So why are both root and com and org and, well, just about everyone else
> using 1024b keys for the actual signing?
Th
On 27 Mar 2014, at 10:05, Nicholas Weaver wrote:
> On Mar 27, 2014, at 7:22 AM, Joe Abley wrote:
>
>> On 27 Mar 2014, at 22:56, Nicholas Weaver wrote:
>>
>>> Bits are not precious: Until a DNS reply hits the fragmentation limit of
>>> ~1500B, size-matte
On 27 Mar 2014, at 17:47, Joe Abley wrote:
> There was a plan underway to roll the KSK. I was at ICANN briefly when that
> started (I spoke publicly, albeit briefly about it in the dnsop meeting in
> Berlin). I'm no longer at ICANN and hence no longer have anything
> aut
On 28 Mar 2014, at 9:06, Phillip Hallam-Baker wrote:
> Therefore ICANN needs to sign the root zone with 2048 before we consider it
> signed. End of story.
Small point of clarity: the only key that ICANN maintains is the 2048 bit KSK,
and the only signatures ICANN makes with it are over the DN
On 28 Mar 2014, at 10:26, Phillip Hallam-Baker wrote:
> VeriSign is acting on ICANN's instructions.
I think actually that Verisign is acting on NTIA's instructions under the
cooperative agreement. But my experience while I was there was that the three
organisations work in concert on this kin
On 2 Apr 2014, at 10:26, Ted Lemon wrote:
> The problem with the way you've phrased this question is that there does not
> seem to be agreement amongst the parties to this discussion whether old keys
> matter. If you think they do, you need longer keys. If you think they
> don't, you need
On 8 Apr 2014, at 9:54, Petr Spacek wrote:
> On 8.4.2014 15:20, Edward Lewis wrote:
>> From the linked message:
>
> Let me quote very first part of the message to put it into context:
> People start to disagree when it comes to questions like "Is it
> feasible to
> rely
On 8 Apr 2014, at 10:27, Petr Spacek wrote:
> I would rather see RFC 4025, RFC 4255, draft-wouters-dane-openpgp and
> draft-wouters-dane-openpgpkey-usage to be practically implemented and widely
> used sooner than later.
I would like to see those things too. But they're a bit useless without
On 8 Apr 2014, at 11:01, Edward Lewis wrote:
> But isn’t that example (below) a new API? ;)
I wasn't reacting to the newness of the API, but rather the dual approaches of
(a) provide a new DNS API for applications, or (b) leave applications using the
existing/archaic API for name resolution,
On 16 Apr 2014, at 8:02, Warren Kumari wrote:
> I think I made it even clearer:
> The first time a DNS operator signs a zone, they need to communicate
> the keying material to their parent through some out-of-band method to
> complete the chain of trust. Depending on the desires of the parent,
>
On 23 Apr 2014, at 18:32, Phillip Hallam-Baker wrote:
> We can't run over port 53 (trust me, I tried).
You have doubts about the approach described in
draft-hzhwm-start-tls-for-dns-00? Those would be interesting to hear; I find
that draft (and the accompanying t-dns technical report) to be qu
On 24 Apr 2014, at 10:53, Phillip Hallam-Baker wrote:
> If you want to use TLS with DNS then use port 443. One of the effects
> of firewalls is that we now only have three ports for all protocols:
>
> Port 80/UDP: Non SSL traffic
> Port 443/TCP: SSL traffic
> Port 53/UDP: DNS
I think it's impo
On 25 Apr 2014, at 11:14, Phillip Hallam-Baker wrote:
> The existing DNS works as far as the people running their firewalls
> are concerned. The failure of TCP fallback in practice has been an
> understood problem for 20+ years.
Understood, perhaps; measured and understood, not so much.
What i
On 28 Apr 2014, at 9:04, Edward Lewis wrote:
> (I’m not saying “use my wording” I am saying that parental agent is not a
> term of art in practice. A term used in practice would be better. I used
> parent provisioning system but there may be another term.)
I think there's quite probably no
Hi Stephane,
On 5 May 2014, at 16:13, Stephane Bortzmeyer wrote:
> On Sun, May 04, 2014 at 01:42:51PM -0400,
> Tim Wicinski wrote
> a message of 33 lines which said:
>
>> Since this has been discussed several times and voted on during the
>> meetings, please *only* state if you think these ar
Hi all,
I'm seeing increasing discussion about edns-client-subnet (most recently
documented, I think, in the expired document
draft-vandergaast-edns-client-subnet-02), both in commercial and open source
venues (there's an active thread on the unbound-users mailing list right now,
for example).
On 6 May 2014, at 13:27, Doug Barton wrote:
> On 05/06/2014 10:18 AM, Joe Abley wrote:
>> I think not picking up this work will result in implementation and
>> operational problems.
>
> Those of us who still have the vomity taste would like the problems with
> inter
On 6 May 2014, at 22:34, Doug Barton wrote:
> You could say that I'm arguing 'ad absurdum' here, but I'm not. There really
> are such things as bad ideas, and it's perfectly reasonable for the IETF to
> decide that something is a bad idea, and shouldn't be done. Or at least,
> shouldn't be ma
On 7 May 2014, at 13:12, P Vixie wrote:
> Ouch. Well so if a large body of ietf participators think wide area rdns is a
> bad idea and that this option should never be recommended then we would
> presumably have to say so in the document which standardized the option.
> Strange.
I think docu
On 17 May 2014, at 7:51, Ted Lemon wrote:
> On May 17, 2014, at 3:12 AM, Mark Andrews wrote:
>>> Or are there other uses for ENAME beyond what the HTTP/CDN crowd do
>>> with CNAMEs today?
>>
>> I would encourage both. ENAME is just service agnostic.
>
> It might be worth actively pushing the
Hi all,
We have two documents proceeding (in wglc) together, both relating to AS112
service:
draft-ietf-dnsop-rfc6304bis
draft-ietf-dnsop-as112-dname
The 6304bis document updates the advice to people running AS112 nodes to
incorporate the new scheme described in the as112-dname document, w
On 22 May 2014, at 12:19, Chris Thompson wrote:
> On May 22 2014, Joe Abley wrote:
>
> [...]
>> William has reminded me that there has been some work done amongst current
>> AS112 operators to add an IPv6 prefix to the current scheme, and that some
>> AS112 operators
Hi all, again :-)
RFC 7249, fresh off the presses, instantiates an IANA registry for
"Special-Purpose AS Numbers".
The initial registry contents are:
AS Numbers Reason for Reservation
- ---
0
On 23 May 2014, at 11:47, Ted Lemon wrote:
> On May 23, 2014, at 4:30 AM, Ray Bellis wrote:
>> Given that the CNAME at the Apex problem appears to be mostly (entirely?) an
>> HTTP-related problem, it seems to me we ought to be engaging more with
>> HTTPbis to help them come up with a solution
On 28 May 2014, at 15:23, Ted Lemon wrote:
> So not to put too fine a point on it, but where is the use case for this
> proposal? It seems like something that is more of someone's cool hack than
> a standard people ought to implement. What am I missing?
Is the use case perhaps the ability
On 28 May 2014, at 16:33, Ted Lemon wrote:
> On May 28, 2014, at 9:25 AM, Joe Abley wrote:
>> Is the use case perhaps the ability to attack comment-like metadata
>
> Definitely a possibility. :)
Sorry, I've been teaching people at AfNOG about DNS and reflection attac
On 22 Jun 2014, at 11:54, John Levine wrote:
>>> As I understand it, this changes DNS caches so that for the root zone
>>> its behavior is somewhere between a cache and a secondary master.
>>
>> The cache remains precisely a cache.
>
> I understand that it's still a cache in the DNS hierarch
Hi Paul, Warren,
On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote:
> Greetings. Warren and I have done a major revision on this draft, narrowing
> the design
> goals, and presenting more concrete proposals for how the mechanism would
> work. We welcome
> more feedback,
Hi Roy!
On 8 July 2014 at 7:40:22, 🔒 Roy Arends (r...@dnss.ec) wrote:
> I really like this idea. Many ISPs already do this, (including some high
> profile public
> recursives, like Google and OpenDNS), because it simply makes sense: It
> reduces latency
> for the end user, reduces outbound
Hi Hosnieh, Stéphane,
On 16 July 2014 at 11:21:34, Hosnieh Rafiee (hosnieh.raf...@huawei.com) wrote:
> For DNS in general, I saw some terminologies in different RFCs. In other
> words, they are
> distributed in different RFCs. But probably it is a good idea to gather all
> in one RFC like
>
On 6 August 2014 at 8:10:25, Patrick W. Gilmore (patr...@ianai.net) wrote:
> Composed on a virtual keyboard, please forgive typos.
>
> On Aug 6, 2014, at 7:47, Toerless Eckert wrote:
> >
> > Sorry, haven't been following this group for a long time, so
> > please excuse if answers to these questi
On 13 Aug 2014, at 20:16, Mark Andrews wrote:
> Can we please move on this.
>
> The reverse address are not yet insecurely delegated as
> would be required for RFC 6598 compliance. This is starting
> to cause operational problems for ISP's that validate DNS
> resp
On 14 Aug 2014, at 12:04, Mark Andrews wrote:
> The assignements go:
>
> 0.0.0.0/0 IANA (IN-ADDR.ARPA)
> 100.0.0.0/8 ARIN(100.IN-ADDR.ARPA)
> 100.64.0.0/10 IANA (64.100.IN-ADDR.ARPA through
>127.100.IN-ADDR.ARPA)
>
> The 1
Hi Chris,
I went quiet on this thread because I was going to try this out in a lab before
commenting further, but since I haven't done that and you had something to
say...
On 20 Aug 2014, at 12:50, Chris Thompson wrote:
> On Aug 14 2014, Joe Abley wrote:
>
> [...]
>> It
On 20 Aug 2014, at 17:48, Mark Andrews wrote:
> You will give answers that validate as bogus in the stub resolver.
This seems to be the crux of our differing world views.
> A validating stub resolver
Validating stub resolvers?
In my own personal taxonomy a stub resolver doesn't validate. Val
On 3 Sep 2014, at 13:21, joel jaeggli wrote:
> On 9/3/14 10:01 AM, David Conrad wrote:
>
>> On Sep 3, 2014, at 8:42 AM, Guangqing Deng
>> wrote:
>>> From RFC1034 section 4.1, it seems that the way used for improving
>>> the redundancy and resilience of DNS system is to increase DNS
>>> servers
Hi all,
ICANN will facilitate an open, technical workshop to discuss operational plans
for a future root zone KSK rollover, during the upcoming ICANN 51 meeting to be
held in Los Angeles in October 2014.
The workshop is intended for participants who have a technical, operational
perspective an
Hi Dave,
On 26 Nov 2014, at 10:37, Dave Thaler wrote:
> [note: I am not on the dnsop mailing list, so keep me on any replies]
>
> One issue I have is with the first paragraph of the Introduction:
>
>> Many sites connected to the Internet make use of IPv4 addresses that
>> are not globally uni
On 26 Nov 2014, at 15:42, Paul Hoffman wrote:
> Greetings. Warren and I updated the draft a bit to reflect input from the WG,
> and to add another configuration example (for Windows Server).
I think the general problem space of how we distribute authoritative data to
caches is well worth thou
> On 9 Dec 2014, at 12:42, Randy Bush 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.
>>
>> Its also missing one thats actually reall
On 7 Oct 2014, at 00:04, Tim Wicinski wrote:
> Dear DNSOP WG,
>
> After discussions about the landing spot of this document, DNSOP vs the newer
> DNS Privacy WG, it was realized the updated DNSOP charter specifically had
> work like this in mind.
>
> This starts a Call for Adoption for draft
On 10 Dec 2014, at 11:41, Joe Abley wrote:
> On 7 Oct 2014, at 00:04, Tim Wicinski wrote:
>
>> Dear DNSOP WG,
>>
>> After discussions about the landing spot of this document, DNSOP vs the
>> newer DNS Privacy WG, it was realized the updated DNSOP charter speci
On 20 May 2015, at 13:12, Tim Wicinski wrote:
The draft can be found here:
https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/
https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01
Please review the draft and offer relevant comments.
I have read this document. I suppo
Hi Tim,
On 20 May 2015, at 22:13, Tim Wicinski wrote:
From the discussion on the mailing list, this draft appears to have
support in the working group. The authors have requested a Call for
Adoption. The chairs want to move forward with this draft if it has
consensus support.
This starts a
Hi Bob,
On 21 May 2015, at 12:55, Bob Harold wrote:
The "onion.eff.org" idea only solves half of the problems - it would
prevent others from using the domain for something else, but it fails
to
provide the required privacy - part of the requirement is that the
onion
names NOT be sent to DNS
On 3 Jun 2015, at 17:17, Shane Kerr wrote:
On Wed, 03 Jun 2015 13:57:39 +0100
Ray Bellis wrote:
Whilst discussing 5966-bis with my co-authors connection-close with
the
co-authors, we were reminded of this point I made in
draft-bellis-dnsop-connection-close in relation to §7 of RFC 6891:
"
On 9 Jun 2015, at 8:58, The IESG wrote:
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document:
> - 'Definition and Use of DNSSEC Negative Trust Anchors'
> as Informational RFC
I have read this document. The topic under discussion
Hi Ed,
On 9 Jun 2015, at 7:49, Edward Lewis wrote:
> On 6/9/15, 6:51, "John Levine" wrote:
>
>>> In a side conversation about "preventing" badness it was suggested to
>>> turn
>>> the conversation towards "accommodating correct behavior." What would it
>>> take for someone to pick an identifier
Hi all!
On 26 May 2015, at 11:31, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations Working
Group of the IETF.
Title : DNS Terminology
Authors
Hi Paul,
On 15 Jun 2015, at 14:49, Paul Hoffman wrote:
This message, and some of the earlier in this discussion, says in
essence "RFC Foo says the definition of X is Y, but that's wrong". At
the beginning of this process, we decided that we should use
definitions from the RFCs where possible
On 1 Jul 2015, at 10:08, Suzanne Woolf wrote:
First-- apologies for the misunderstanding.
It seems appropriate for someone at this point to make a joke about
onion leaving a bad taste in the mouth. But not me. I'm not that guy.
Joe
___
DNSOP mai
On Oct 6, 2024, at 08:58, Ralf Weber wrote:
> DNS wise this is totally fine. You can always have multiple resource
> records of the same type for a name node.
Except when you can't, like when the type is SOA or CNAME or DNAME. But SVCB
and HTTPS were not defined to have those kinds of restricti
Hi Shane!
On 5 Nov 2024, at 13:13, Shane Kerr wrote:
> I wrote a quick draft to specify that answers returned should be returned in
> a random order:
>
> https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
I think that you might need to nail down what "random" means. I presume y
Hi Shane!
On 5 Nov 2024, at 14:08, Shane Kerr wrote:
> In the security section I do mention that you don't need
> cryptographically-secure random numbers. I could expand that a bit, if it is
> useful.
Every time I mention "random" within earshot of Lucas Pardue it invites hard
stares, I thin
On 5 Nov 2024, at 14:48, Joe Abley wrote:
> The idea of making a protocol change in the DNS to work around behaviour that
> might be fixable in one point release of Android and iOS
... seems less than ideal, I meant to say. Sorry, clicked send a bit early.
Perhaps both those thing
On 18 Sep 2024, at 08:51, Shay C wrote:
> Forgive me, but I'm not clear if the WALLET RRtype is a proposal or if it has
> been ratified. I see references to it in the IANA registry so I'm assuming
> it has been assigned and is currently usable?
RRTypes are assigned by expert review and no spe
On 18 Sep 2024, at 17:44, Dave Lawrence wrote:
> You don't have an opinion on using TXT?
>
> I'm somewhat surprised by this.
TXT clearly works for some applications. Others weigh the pros and cons and
choose differently. Having an opinion without the benefit of knowing anything
about the appl
Hey,
On 18 Sep 2024, at 09:35, Shay C wrote:
> The draft currently overloads the TXT record RRtype. WALLET record type
> would be appropriate but does have the issue that adoption isn't complete yet.
I don't know exactly what you mean by "adoption". The code-point is assigned.
If you mean it
On 6 Nov 2024, at 13:44, Otto Moerbeek wrote:
> Updating 3484 might be possible. Something like: pick a random one if
> some of the addreses turn out to be equivalent?
Yeah, that's the kind of thing that sprang to my mind.
Joe
___
DNSOP mailing lis
On 6 Nov 2024, at 10:17, Otto Moerbeek wrote:
> I would guess there are many, many cases of applications using glib's
> getaddrinfo and some other implementations of getaddrinfo sort as
> well.
If we imagine that the vast majority of cases where people care about any of
this are, collectively,
On 6 Nov 2024, at 08:18, Otto Moerbeek wrote:
> Two cases against mandatory ordering:
>
> - glibc's getaddrinfo orders the list received, so any ordering done
> *by servers* is going to be undone anyway.
This seems pertinent if glibc is involved in mediating a DNS response on its
way to an app
On 7 Nov 2024, at 15:11, Ben Schwartz wrote:
> Each registry entry implicitly normalizes this filtering rationale as a
> behavior deemed acceptable by the IETF.
The point of these code points is to provide an opportunity to describe things
that happen in the real world to the benefit of end us
On 7 Jan 2025, at 21:18, Shane Kerr wrote:
> This is a good point! I guess it depends on whether you really, REALLY care
> if the answer is made from a wildcard. Otherwise if the RDATA is the same you
> can safely assume that it was - or might as well be.
I don't think you can even say that th
On 5 Feb 2025, at 02:05, Paul Hoffman wrote:
> On Feb 4, 2025, at 13:49, Kim Davies wrote:
>
>> We have published a new version of the draft intended to document the
>> .internal top-level domain.
>> (https://datatracker.ietf.org/doc/draft-davies-internal-tld/)
>> When we presented this work
Hi Geoff,
On 5 Feb 2025, at 02:43, Geoff Huston wrote:
>> On 4 Feb 2025, at 4:49 pm, Kim Davies wrote:
>>
>> Hi folks,
>>
>> We have published a new version of the draft intended to document the
>> .internal top-level domain.
>> (https://datatracker.ietf.org/doc/draft-davies-internal-tld/)
Hi all,
The thread about Kim's .INTERNAL draft reminded me of a different draft I wrote
a while back.
In draft-jabley-sink-arpa I proposed that SINK.ARPA be reserved by the IETF as
never existing because I thought there were protocol reasons to have a name
that reliably didn't exist. For examp
Hi Geoff,On 5 Feb 2025, at 12:34, Geoff Huston wrote:By my reading, RFC 6761 and the registry it created are all about how a domain name should be used, not its provenance. There's no special handling required by clients, stub resolvers, recursive resolvers, forwarders or authoritative servers for
On 5 Feb 2025, at 15:39, Wessels, Duane
wrote:
> I think .internal definitely should be a special use domain name, just like
> .invalid, .test, and others. The text for RFC 6761 consideration 4 should be
> similar to those others, e.g.:
>4. Caching DNS servers SHOULD, by default, recogni
Hi Donald,
On 5 Feb 2025, at 22:10, Donald Eastlake wrote:
> Maybe I'm confused but what is wrong with any domain name ending in the TLD
> "invalid." if you want a domain name that is guaranteed not to exist? (RFC
> 2606/6761)
I guess that also works. I think it's semantically ugly and I thin
Hi Geoff,
On 5 Feb 2025, at 13:16, Geoff Huston wrote:
> Obviously, the text in the draft in section 5.1 differs here from your
> assertion about "nothing special" in a number of points, but It would be
> kinda pointless here for me to cut and paste, as its already in the draft.
> The draft a
On 9 Jan 2025, at 01:02, Paul Vixie wrote:
> On Wednesday, January 8, 2025 11:52:03 PM UTC Watson Ladd wrote:
> >
> > What would the benefit of this signalling be on the Internet? And how
> > would it avoid being overinclusive when some names change?
>
> synthetic data would be explicitly known
Hi Peter,
> On 2 Mar 2025, at 13:10, Peter Thomassen
> wrote:
>
> On 2/21/25 01:44, Tony Li via Datatracker wrote:
>>
>> Reviewer: Tony Li
>> Review result: Has Nits
>> OPSDIR review of draft-ietf-dnsop-generalized-notify-06
>> Reviewer: Tony Li
>> Disclaimer: I am not a DNS expert and I do n
Hi Victor,
On 7 Mar 2025, at 00:10, Victor Zhou wrote:
> Our intention was not to claim it's hard to add a new RR type. it is not hard
> to "add" it. It's hard to gain consensus without showing adoption first.
What consensus do you mean?
New RRTypes are assigned based on expert review. Consen
801 - 884 of 884 matches
Mail list logo
