[DNSOP] Probably not a new thing (was Re: New agenda, and alt-tld draft at IETF 115)

. It is admittedly imperfect, but it is addressing an area where perfection is fundamentally impossible. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] root crud, Possible alt-tld last call?

in the document, but I do think it is necessary to remember that a resolver that doesn't claim to implement the resulting RFC will, quite predictably, not conform to the requirements of such an RFC. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com

Re: [DNSOP] [Ext] Possible alt-tld last call?

money to anyone for something that benefits others. So there's a reason instead that IANA should pay to maintain this registry without clear evidence that there is a benefit? Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP

Re: [DNSOP] [Ext] Possible alt-tld last call?

insisting that it's bound to happen anyway. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Possible alt-tld last call?

o my mind, creating a registry that won't have any real effect, that won't scale, that will almost certainly hold useless registrations, and that presents both political and legal risks for the Internet, is something a document shouldn't do. Best regards, A -- Andrew Su

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

I suspect the characters must all be alphabetic, though perhaps that rule has been superseded by IDNA. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] looking for reference for reverse maps do not work

the document wasn’t worth sending through publication. A — Andrew Sullivan Please excuse my clumbsy thums > On Apr 11, 2022, at 11:38, Michael Richardson wrote: > >  > Hi, in reviews of > > https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-04.htm

Re: [DNSOP] How Slack didn't turn on DNSSEC

in which the only way to start operating DNSSEC is already to have operated DNSSEC? Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

model components," the chances are good that an implementer will _not_ understand those interactions or even componets, and will mess up the implementation accordingly. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing

Re: [DNSOP] Question on interpretation of DO and CD

. This is laid out in some detail in Appendix B, but the result is still not that satisfying to someone who wants predictable behaviour our of the validated resolution system. Hope that's helpful, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP

Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld

as DNSGATE. But I, of course, don’t have much to contribute one way or the other. Best regards, A — Andrew Sullivan Please excuse my clumbsy thums > On Jul 31, 2021, at 11:48, Ray Bellis wrote: > >  > >> On 30/07/2021 19:29, Paul Wouters wrote: >> >>

Re: [DNSOP] NXDOMAIN and RFC 8020

a sentence? A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient...

for it. That is, by the way a good reason to suppose that bugs could be part of the problem! A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient...

to the delegation, but you could get the answer by asking for it. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME

Apologies, all, that was supposed to go off-list. I have an employer (ISOC), not speaking for it, A On Sat, Nov 16, 2019 at 11:33:50PM -0500, Andrew Sullivan wrote: > On Sat, Nov 16, 2019 at 10:41:51PM +0800, John Levine wrote: > > Remember that it's invalid for an NS or MX

Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME

-using resolution. To my knowledge there is no explicit prohibition, but if you asked in the right way (such as without DO set) you'd get a CNAME synthesized, which would mean that the thing would break sometimes and not other times. Seems even less good for that reason. Best regards, A --

Re: [DNSOP] Special-use TLDs in resolvers

t you should _never_ look up that name in the DNS. That's its whole function. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Brief addition to terminology-bis draft

t regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Global DNS architecture changes, "the camel", and so on

similar to those asked by John Klensin in a draft he put out some time ago, but that I think he has declined to discuss on this list. I am aware that perhaps I'm alone in my worries. If so, you can continue with your regularly scheduled programming :) Best regards, A -- Andrew Su

Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

ied upon for systems to work properly. This is true, but still broken. > This ambiguity in the current specifications What is the ambiguity? There is only an ambiguity if you think that people's expectation of something nobody ever promised them is part of the specification, and it isn'

Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

ways have the option of using an ORDER BY clause, which we don't have in the DNS.) Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] refer-down

their transfers were suddenly failing. Instead of fixing it or alerting anyone, they just kept restarting BIND to use the old zone. It took quite a lot of effort to sort that out, and determining how caches were getting so much bad data in them was a key to figuring it out.) Best re

Re: [DNSOP] refer-down

that would happen? Are we > doing anyone a real favor by returning anything other than REFUSED? You mean, when a server that is not authoritative for anything nevertheless gets a query with RD==0? I think that's fine. How else do you debug a ca

Re: [DNSOP] refer-down

Hi, On Mon, May 28, 2018 at 11:17:33PM +0530, Mukund Sivaraman wrote: > > RFC 1034 mentions how to handle upward referrals - ignore them. Ok, I'll just let this expire. Thanks, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailin

Re: [DNSOP] refer-down

the WG isn't going to do much review of it, which makes me think the effort would be rewarded with more effort and then no document coming out :) A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/m

[DNSOP] refer-down

But it's about to expire, and if nobody else thinks it's worth the wasted electrons I don't feel strongly enough about it to have the fight. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://ww

Re: [DNSOP] raising the bar: requiring implementations

s" a DNS implementation is wise, however. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Current DNS standards, drafts & charter

fit of the model to the world strikes again! Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [art] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

ed a registry to begin with. > A good way to rationalize them would be to document the the rules in > one place with pointers to the relevant registries. I would be willing to review additional proposals (including that one) for how to make this whole thing less of a disaster, yes. A -- Andrew Sull

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

document, but I think it is making a bigger change than it seems to understand. And anyway, I don't understand how the original 6761 text is the wrong approach: given that it isn't even being followed on the Internet today, there's no reason to suppose that this alternative approach is going to make thin

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

stake on my part.) As Mark says elsewhere in this thread, localhost is not a protocol switch. It's a name in the context of the global, Internet DNS; respoding authoritatively with NXDOMAIN is therefore wrong. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

zone beneath local. I hope that at least explains what I'm worried about. I do think that keeping the distinction between "domains in the DNS" and "domains" is useful. I think we may disagree about the boundary. A -- Andrew Sullivan a...@anvilwalrusden.com _

[DNSOP] the ??-- thing (was Re: I-D Action: draft-huston-kskroll-sentinel-04.txt)

ing that it must update RFC 5891 to be useful? Thanks, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

ing. […] > On Wed, Jan 31, 2018 at 4:51 AM, Andrew Sullivan <a...@anvilwalrusden.com> > wrote: > > On Tue, Jan 30, 2018 at 10:42:15AM -0500, Joe Abley wrote: > > > >> I probably missed some. Anyway, I think when people are saying "address > >>

Re: [DNSOP] A conversational description of sentinel.

osed. Just noting that it's work that would be needed. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

more detail in a different message (one to which you did not respond) where I reviewed the draft at greater length. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

d consensus on in recent months, yes. I think I missed that consensus. I was under the impression that there was still disagreement about it, but that in any case the answer should definitely not be RCODE 3. Best regards, A -- Andrew Sullivan

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

'd be better. It has the notable advantage that it's what the RFC says to do. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

t instead does not. Such resolvers are broken under 6761 anyway, and shouldn't be making such a request. But lying about the answer is not in keeping with 6761. There remains some controversy about what the right answer would be, given some interpretations of REFUSED. A -- Andrew

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

ntroversial because the answer is static. My preference, however, would be for the root servers to REFUSE to answer such queries. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

ean "IP address record". > We should probably say that, then, and also of course we should fix the poor text in the teminology document to point this out. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ie

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

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 define it. Should we define it more

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

- the BSD approach would be as good as any other). Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

es. But the complexities of resolution are such that any application in the future that is supposed to do its own resolution might just wire up a shortcut to a loopback addresses, thereby enshrining the very "hard coding" into protocol-specified behaviour for applications. I am sorry that ca

Re: [DNSOP] Clarifying referrals (#35)

(see [RFC1035], section 4.1.1). -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Please review in terminology-bis: Global DNS and Private DNS

to cover it, but if people hate "global DNS" maybe we need a different term? Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Measuring DNS TTL Violations in the wild

rt on RFC 7583. That text is actually bad advice if you are supposed to expect resolvers to extend the TTL on RRsets, because the Ready state depends on caches expiring. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing l

Re: [DNSOP] Clarifying referrals (#35)

the distributed systems sense of gossip protocols). > I like this observation. Thanks. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

imes, I don't believe that settling that question is appropriate for the terminology document. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

that upward referrals are defined away. They exist, today, all over the Internet, and it would be extremely foolish lexicography to attempt to hide that. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ie

Re: [DNSOP] Clarifying referrals (#35)

way, and the terminology document is not the place to rule on the way people should read a text. We're supposed to be doing description, not prescription. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.

Re: [DNSOP] Clarifying referrals (#35)

s kind of response is not required for resolution or for correctly answering any query, and in practice some authoritative server operators will not return referral responses beyond those required for delegation"? Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com __

Re: [DNSOP] Clarifying referrals (#35)

y that someone _could_ think that upward referrals are sometimes a normal part of operation. If we want to change the advice of what to do there, I think a different document is needed. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DN

Re: [DNSOP] Clarifying referrals (#35)

but the referral is necessary. Good, this is helpful, thanks. This also means, of course, that in such a response the answer section isn't empty. Is this why you call it a "partial referral"? Best regards, A > > On 29 Nov 2017, at 1:03 pm, Andrew Sullivan <a...@anvilwalrusde

Re: [DNSOP] Clarifying referrals (#35)

der how this is related to the "partial referral" Mark is talking about (see elsewhere in this thread). Thanks, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

r as people seem to think it is. I'm not sure I understand your cryptic remark above, but I am certain I can't make it more comprehensible to others without you telling me that I'm wrong and need to do it over. So I'm appealing to you to try to make your view as clear as possible. Best regards, A --

Re: [DNSOP] Clarifying referrals (#35)

corresponds to the name which matches the query name, or > the first owner name in the answer section. > > > On 29 Nov 2017, at 12:46 pm, Mark Andrews <ma...@isc.org> wrote: > > > > GO READ STD13! > > > >> On 29 Nov 2017, at 12

Re: [DNSOP] Clarifying referrals (#35)

the historical lore, so that future people don't have to be this bored again. Thanks, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

nce it can't possibly be that? Indeed, it is not that. Suggestions on how to make this clearer are welcome. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

CNAME or DNAME, I'm trying to figure out whether such responses are really referrals or else just intermediate steps. RFC 6672 doesn't call them referrals. Maybe this is a bit of informal jargon that needs clarifying? Thanks for the contribution, and best regards, A > > On 29 Nov 2017, at

Re: [DNSOP] Clarifying referrals (#35)

Excellent point! Thanks. -- Please excuse my clumbsy thums -- On November 28, 2017 15:40:14 Mark Andrews <ma...@isc.org> wrote: The AA bit may or may not be set depending upon whether the response contains a CNAME/DNAME or not. On 29 Nov 2017, at 6:50 am, Andrew Su

Re: [DNSOP] Clarifying referrals (#35)

. I think I have seen this too. That seems like another thing that ought to be documented, however, as a possible issue: at least one full service resolver interprets an RCODE somewhat more liberally than the specification does under some (other) plausible reading. I'm here to document things

Re: [DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07

hat such occluded records should be rejected > during zone load. This sounds like a somewhat wider definition. I'd like to see text and strong WG support before it gets included. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

e your description in the circleid piece (or elsewhere) is inconsistent with the RFC 1035 definition of RCODE 5: "The name server refuses to perform the specified operation for policy reasons." Refusing to respond to this or that IP address is a policy, and refusing to perf

[DNSOP] another draft (was Re: Clarifying referrals (#35) )

On Mon, Nov 13, 2017 at 08:52:35AM -0600, John Kristoff wrote: > On Mon, 13 Nov 2017 03:26:41 + > Andrew Sullivan <a...@anvilwalrusden.com> wrote: > > > This is quite a helpful response, thanks. I wonder whether more of it > > ought to go in discussion (or a n

Re: [DNSOP] Clarifying referrals (#35)

roaches that people have for this are either NODATA responses and REFUSED. Only the latter seems obviously consistent with the text, though I'm aware that there's controversy over using REFUSED here. A -- Andrew Sullivan a...@anvilwalrusden.com ___

Re: [DNSOP] Clarifying referrals (#35)

irements (musts) are stated so baldly in any RFC. Have I missed something? A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Clarifying referrals (#35)

it's certainly something that's around. Should we note that clients sometimes ignore such references? Should we note that servers often do not return these, though they used to commonly? A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mai

[DNSOP] Clarifying referrals (#35)

o be left out of the document anyway. In any case, I seek guidance from the WG. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] 答复: 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

nsanity", what do we call it when people work on a protocol that depends on UDP fragments working everywhere? Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

is to make IPv6 even less reliable than it has been historically, I think the operators are going to point us to the nearest short pier and tell us to take a long walk. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

d, which is either the name actually queried or else the last name in a CNAME chain as defined in [RFC2308]. I'm certainly not wedded to these two names. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS names for local networks - not only home residental networks ...

On Wed, Sep 06, 2017 at 10:39:47AM -0700, Paul Vixie wrote: > right. but this is why we fail, and can't be used as a reason we won't change. Oh, yes, we are in complete agreement there. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mail

Re: [DNSOP] DNS names for local networks - not only home residental networks ...

as effectively as you might wish. Please provide an example where you cannot. > there is a security reason why companies often use .local for this case ..., Any company that uses .local for any security reasons is one that I want as my competitor. I'd love to know the names of such com

Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf

ined in -attrleaf-. I like this approach. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

session, about overall analysis. > b) make this draft DNS-SD only, so it can fast forward... > I'm not keen on this. > c) use the changed paradigm to work on DNSbis without the accident part? I'm starting to wonder whether a bof is needed. Maybe the IAB's workshop will produce some

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

d the session-signalling approach makes it suck less. But it's certainly another step along the way to DNSbis by accident. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)

uot; moments, but still think the response is, "Yep, this thing violates all your assumptions. Sorry." Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

en. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

bit in making more administrative overhead, but I'm very much interested in avoiding a "this is off charter" discussion during IETF LC should we get there. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] new DNS classes

hing actually deployed on the Internet scratches someone's itch. Adding support for stuff to the DNS is a hair shirt. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] draft-sullivan-dns-class-useless (was Re: new DNS classes)

significant deployment of a class that even remotely rivals the deployment of IN. But I'm not going to waste a lot of effort trying to forge a consensus about that. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing lis

Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt

PKI. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

weak it to match the rest, and > add text saying, ³But reverse DNS is not a great source for geolocation > information²? For whatever it's worth, I know of one geolocation effort that uses the names in the reverse as clues about geolocation improvement. I am not able to state who it is or

Re: [DNSOP] DNSOP Digest, Vol 125, Issue 31

ount. At least UTS#46 doesn't take that stance about (say) ZWJ and ZWNJ, but I'm entirely sympathetic with Florian's original complaint upthread that the whole situation is a mess because of too many options. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com _

Re: [DNSOP] Status of IDNA

t I checked). But any sentence about internationalization that involves the concept "just do _x_" is, I think, already too naïve. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Status of IDNA

ven for wondering why the UTC decided that it knew something about domain names and the history of how they are used. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Status of IDNA

nion: every valid A-label matches exactly one valid U-label, and anything that does not have this property is not a valid A- or U-label. There are problems with IDNA that have prevented it being updated for recent versions of Unicode. Asmus Freytag, John Klensin, and I are working o

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

ne watching queries along the path", add a reference to > RFC 7626? A good idea. Thanks. > Normative references: > > Why is RFC 6303 a normative reference? It is no longer used. Should be removed. Thanks. > Why is RFC 7686 a normative reference? It is jus

[DNSOP] algrithm-update table

through LC last time. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

elegation. If it _is_ so dependent, then that would be important to know. If it is _not_ so dependent, then probably some additional text is needed (maybe in the security considerations) about the likely failure of DNSSEC or resolution in such a context. I hope that's helpful, A -- Andrew Sulliva

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

ot;root namespace" and "root zone of the DNS". We have in fact created the former. But this draft asks for the latter, which is different. We have an MoU, and it says that we won't meddle in that zone. Best regrds, A -- Andrew Sullivan a...@anvilwalrusden.com _

Re: [DNSOP] .arpa

signed is an attempt to specify protocol operation in a registry where we have no business working. If this proceeds as IETF consensus, it will be apparent that it is the IETF, not ICANN, that threatens the stability of the IANA arrangements. I hope we do not have to explore that rathole in my life

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

ng, combined with the request for a provably-insecure delegation, is either incoherent or else links the two registries. I don't know which it is, but I see no way it can be other than one of them. Best regards, A -- Andrew Sullivan a...@anvilw

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

er. This doesn't follow. If the resolver gets it wrong in the case of a provably-unsigned answer, it can just continue its resolution as it ever wanted. It won't be able to validate, since it does not have a local trust anchor. But it'll work. A -- Andrew Sullivan

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

dd it to the document. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ALT-TLD and (insecure) delgations.

pposed to resolve in the DNS anyway. The homenet case is different, because it _is_ supposed to work with DNS. In that case, the missing proofs are a problem for validating end points. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com __

Re: [DNSOP] ALT-TLD and (insecure) delgations.

hat such a computer will erroneously fall back on the global DNS. That's not a reason for us to do contortions in the specification. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] ALT-TLD and (insecure) delgations.

really intended to carve out a place for (3). > respect the reasons for the other rules which I did but you choose > to completely cut out of the reply. I cut them out because I don't believe the IETF is the unambiguous source of those reasons. Best regards, A -- Andrew Sullivan a

Re: [DNSOP] ALT-TLD and (insecure) delgations.

use case) then we have a problem. But if we don't think that's necessary -- and I'm not sure it is -- then we don't have to care about this. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mail

  1   2   3   4   >