[DNSOP] Probably not a new thing (was Re: New agenda, and alt-tld draft at IETF 115)
Dear colleagues, [I'm employed by the Internet Society, and not speaking for them.] On Wed, Nov 02, 2022 at 09:27:33PM +, Suzanne Woolf wrote: The chairs set out some comments on the -17 version, which appear to have been addressed in the -18 version. We agree with the editors that there are a couple of issues that may need further discussion. The time set aside for alt-tld in our meeting next week is intended to let us we find out how far we might be from consensus on the current draft and whether people still feel there are new things to say. In the interests of not taking up meeting time, I thought I'd send a note here to say that I think the current draft addresses such concerns as I had. There are several things it does _not_ do that I think are important. It does not specify anything about the wire or presentation format of possible names in this space. It does not constrain the names in any way with rules about DNS or its restrictions or so on. And it does not create any registry and just accepts that those wishing to use this unmanaged namespace are on their own and had better be prepared to deal with that. The reason I think all of that important, in case it wasn't clear in previous stuff I said, is that I conceive of this space as entirely dedicated to the idea that there are other potential naming systems that are quite purposely trying to address limitations in DNS. They will therefore, of necessity, possibly be incompatible with any DNS limitation. If this namepsace is constrained by DNS limitations, that will encourage people to avoid this namespace, and so the goal of its creation would be undermined. The reason I think the lack of a registry to be good is that it makes quite clear that nobody can rely on a registry as somehow authoritative for this namespace. The danger with a registry is that people treat it as authoritative and therefore attempt to legislate deference to the registry. But we know that at least some experiments in naming are explicitly disdainful of the idea of authoritative registries. Such efforts almost certainly will not register their presence, and so every protocol will need to cope with collisions anyway. If that is true, then a registry has minimal technical value and has a potential technical harm. I therefore support proceeding with draft-ietf-dnsop-alt-tld-18. 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?
Dear colleagues, [ObDisclaimer: I work for the Internet Society but I'm not speaking for them.] On Wed, Oct 26, 2022 at 05:23:42PM +, Paul Hoffman wrote: Thus, we have a standards-track document that requires that every resolver on the planet is supposed to have special rules for this particular name. It is completely clear that, seven years later, many resolvers don't follow that SHOULD NOT rule. In fact, at at least one root server, .onion queries appear more often than many gTLDs and ccTLDs. Sure. RFC 7686 didn't update STD 13, and so it's not surprosing that lots of resolvers don't implement RFC 7686 and therefore send such queries along to the DNS. This was not only predictable, but IIRC actually predicted when RFC 7686 was being discussed. I have no opinion about whether there should be a MUST NOT lookup in the DNS associated with the alt label 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Hi, [ObDisclaimer] On Thu, Oct 20, 2022 at 09:40:01PM +0200, Eliot Lear wrote: They're asking for the registry. Who is asking for it? And more importantly, what will a registry do? As I pointed out already in this thread, the registry won't be complete, it won't be accurate, and it won't solve in any way the problem of collision. So what does the registry do such that anyone cares about it? Normally, a registry is created when it will help the operation of the protocol. The problem here is that there's an _anti_-protocol, and therefore it's mystifying to me how a registry helps anything, since there is no way to know whether a registry will actually help or in some cases even hurt. which is whether there should be a protocol switch inside .ALT. There will be, almost by definition, exactly as many protocol switches as anyone wants inside alt. What alt does is itself a protocol switch. I think that imagining that such a protocol switch will then proceed in an orderly, hierarchical way flies in the teeth of the evidence. I fully expect more than one use to attempt to colonize the entire alt space, and to do exactly no registration in any registry as a matter of principle. Do you have some reason to suppose otherwise? I don't think the registry follows the Internet-cops approach, but it sure sounds like a registry as Internet hall monitor. I think the reasons to create alt give us every reason to suppose that appointing such a hall monitor is a mistake, and I strongly oppose the creation of such a registry. As ever, I think it's possible I'm in the rough. But I also don't think you or other proponents of a registry have offered anything like good reasons why this registry is a good idea. reason for these people to continuously pay 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Hi Eliot, Still employed and still not speaking for them, I have a question: On Thu, Oct 20, 2022 at 10:15:22AM +0200, Eliot Lear wrote: As a matter of practicality, a registry surely will be form. What evidence do you have for this assertion? As a practical matter, after all, if a registry function were wanted there _already is one_ in the form of any trivial name you can think of in the DNS (I think Joe Abley has made this point rather well on the list already). So, if you want to give IANA or anyone else a new duty, you are going to need a better argument for it than 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?
Dear colleagues, I work for the Internet Society but this is emphatically not the position of the Internet Society. On Sun, Oct 16, 2022 at 03:03:10PM +, Suzanne Woolf wrote: 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the basis that having the IETF “recognize” (if only by recording) such pseudo-delegations may serve to attract unwanted attention to the IETF’s supposed recognition of alternate (non-DNS) namespaces as reservations of the namespace from the shared, common DNS root. We’re still being denounced in certain corners for .onion. It might be good to have a paragraph calling out specifically why .alt is not a delegation of a TLD from the DNS root by the IETF, even though it looks like one. (We didn’t invent this problem, because we didn’t make the decision that top-level domain labels should be used by other protocols in a way that led to confusion. But let’s not propagate it.) I think I might not entirely agree with the reasoning above, but I very strongly agree that it would be a bad idea to create a registry for this innovation with any change control either held or delegated by the IETF. The point of the alt namespace, if it has any point at all, is to create a protocol-switch in the DNS using in-band signalling via a label. That protocol switch is there to say, "You are now outside the DNS." It is a mechanism by which someone could in principle put these alternative identifiers into what may be thought of as "domain name slots" and hope that somehow there is the appropriate handler for such identifiers to work. Attempting to police or advise about such a chaotic namespace is a doomed venture. There is little reason to suppose it won't be polluted with entries that do not work or that cease to work over time. There is little reason to suppose that any exclusivity rule could be enforced, so any protocol wishing to use one of these identifiers needs to be prepared to deal with another, conflicting use of the same name anyway. (To show why this is true, consider the use of labels like .home and .lan that were not registered in the DNS but that were in wide use by various independent operators in not-very-consistent ways. At least in that case, they all used the DNS wire format.) And, since alt is explicitly saying, "You're not in the DNS," there's not even a single protocol that will want these kinds of identifiers. Anyone who has been through a corporate renumbering that resulted from corporate merger and the discovery of awkward RFC 1918 number collisions knows that there are basically two kinds of registries for identifiers on the Internet: globally-unique registries, and everything else. There is no way to make this a globally unique registry, and yet someone will surely think that by getting their label in it they have some claim on that label. This puts whoever is maintaining the registry squarely in the crosshairs of litigious people for whom technical reality is no barrier to argument. Finally, it seems to me that the creation of such a registry presents a serious problem for IANA. IANA, recall, is in part subject to a Customer Standing Committee with representation from three operational communities. If I came from the names operational community and saw IANA setting up a registry for something that at first glance will look like an end run around names community processes (however justified such processes might be), I would ask some pretty pointed questions about what IANA is doing. So, to 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 Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld
Disclaimer: I work for the Internet Society but I am not speaking for them. On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote: recommends that the ICANN board to pick a string that will never be put into the DNS root, and thus is usable for systems like GNS. This was, of course, the whole point of the .alt draft in the first place, at least when I was involved in preparing it. I don't think any of us involved then cared whether it was alt or one of thousands of other strings that it could have been. The main point was to come up with something that would not pad total length too much and that could be a clear "protocol switch". The registration in the IANA sutld registry was suppossed to ensure the same outcome as what is going through SSAC, but it makes no difference to me what the characters are. Note that because of the old-timey restriction, 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
I tried to document this ages ago in https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-considerations/, and got so many contradictory edits (see the history) that the final version ended up saying “A or maybe not-A, or maybe both, your choice,” so the then-chairs decided 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.html > > I was asked to expand upon why the reverse map can not be intelligently used > for MUD ACLs. (section 3, XXX stuff) > (MUD controllers, upon being presented with ACLs made up of > names need to do forward lookups of the names and build ACLs based upon the > IP addresses.) > > There are two aspects of this: > 1) even in an ideal situation, it takes too long on the first packet to > extract a name from an IP address. Yes, that could be aggresively cached. > > 2) forward:reverse maps are N:M mappings, often with unidirectional parts, > and often > broken or not delegated. > > Further, there is no authorization of the mappings, so an attacker who > wants to be able to reach IP address 2001:db8::abcd, can insert a > reverse name of their choice, including updates.example.com, which is > permitted by the MUD ACL. > > While I can write the above paragraph, I don't feel that it's detailed enough > for what is needed, and I feel that we (the IETF) must have documented the > security issues with reverse/forward mismatched at least twice over the past > 40 years. > > I'm looking for a good well reviewed reference to use rather than repeating > this again. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > ___ > 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 Slack didn't turn on DNSSEC
ObDisclaimer: work for Internet Society, speaking for me. On Wed, Dec 01, 2021 at 01:39:19AM -0500, Viktor Dukhovni wrote: The main advice that comes to mind is to use a DNS hosting provider with a proven (multi-year) record of doing DNSSEC reliably. Wouldn't that create a vicious circle 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
Still speaking only for myself :) On Thu, Oct 07, 2021 at 02:49:53PM +1000, George Michaelson wrote: if there's ever been explicit protocol requirement of this, I have forgotten it. Sorry, but I think this is just an over-reach. There is no necessary reason for a single information model to break. And this, of course, is why there isn't such an explicit protocol requirement (and also why we weren't able to get to consensus on MUST set CD on queries): these things represented protocol changes, however trivial, and people didn't accept they were absolutely necessary so the answer was no. From the point of view of an implementer coming along later, however, it sure seems like a gap in the protocol (particularly if you want to maximize interoperability). After all, while we might say, "It's one information model and you need to understand the interactions of the 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 list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question on interpretation of DO and CD
Hi, Disclaimer: I work for the Internet Society but am speaking for myself. On Wed, Oct 06, 2021 at 04:47:32PM -0700, Eric Rescorla wrote: Sorry if these are dumb questions. They are not dumb questions, unfortunately. Looking at things from the stub resolver's perspective, if the zone is signed, then the stub resolver must receive the necessary RRsets or fail the resolution. So, there needs to be an unambiguous way for the stub to tell the recursive to deliver them. Am I right so far? You are right. The problem is that the protocol is exactly ambiguous enough, in my reading, that there isn't a way to ensure that happens. RFC 6840 attempted to clarify a number of things, but there are IMO two gaps in it. First of all, it is apparent that if a resolver maintains a unified cache in which it has DNSSEC-aware and DNSSEC-oblivious data, things will definitely break. The general wisdom appears to be that you need to maintain two caches, and only answer DO-set queries with DO-set cache (or go fetch); but if there's ever been explicit protocol requirement of this, I have forgotten it. The upshot is that it is entirely possible for a cache to have some but not all the DNSSEC data to answer a query, and to respond with what it has, and I know I have seen this in the wild. Much worse is the continued confusion around CD, which 6840 tried pretty hard to sort out but that seems to remain a dark corner of the protocol. The reality is that the SHOULD about setting CD in 6840 probably has to be a MUST or else stuff will almost certainly break. For some reason I now don't recall, some people wanted to be able to select a policy in which they didn't set CD even though it was the only way the validating stub would actually get everything it needed. 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld
Hi, [Employed by ISOC, speaking for self] Speaking as usual only for myself, it seems to me that if there were actual demand for a WG that would actually W as a G on actual extensions, it would be pretty trivial to charter it. What would be bad IMO is a “working group” that functioned instead 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: >> >> We are seeing the WG dropping actual protocol work because of these >> discussions. > If only we had a working group for discussing DNS Extensions... > > Ray > > ___ > 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] NXDOMAIN and RFC 8020
On Tue, Apr 06, 2021 at 05:41:10PM -0400, John Levine wrote: In a somewhat different world where we used RRTYPEs rather than _tag names, we could do tree walks a lot more efficiently. I guess we're now in the world-record running for "somewhat" doing the most amount of work in 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...
[ObDisclaimer: I work for ISOC, but don't speak for them.] On Fri, May 22, 2020 at 09:24:51AM -0400, John R Levine wrote: I believe that the policy is to remove orphan glue, and the glue in the Afilias zones is due to software bugs. It's not just .org, it's also ..info and .mobi and other zones they manage directly. There were historical reasons why glue was not removed on various occasions, on purpose. So I doubt it's just bugs. I know there was a policy decision sometime around 05 or 06 that caused orphan glue to be removed, because I wrote the database code 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...
[ObDisclaim: I work for the Internet Society, but I'm not speaking for them.] On Thu, May 21, 2020 at 05:51:37PM -0400, Warren Kumari wrote: These IPs are only in the ADDITIONAL section - they should not be used as answers. Are you quite sure they're not getting used as answers though? Are you sure query minimization is on for all cases? If not, you'll ask the parent-side server for the A record and may get an answer, though non-authoritative. The _reason_ you'll get an answer is because of the need for the glue -- it could be that you're asking the question because you didn't have the glue because of TC or something, and so you're coming back and asking explicitly. I know that at least one system that I worked on would definitely respond this way, because under some circumstances it was certainly necessary to be able to give such an answer. The AA bit wasn't set due 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 to point to a CNAME so I assume > > it's equally invalid for them to point to a DNAME. > > They couldn't point to a DNAME, but they could point to a target that > would resolve through a 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 > > -- > Andrew Sullivan > a...@anvilwalrusden.com > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
On Sat, Nov 16, 2019 at 10:41:51PM +0800, John Levine wrote: > Remember that it's invalid for an NS or MX to point to a CNAME so I assume > it's equally invalid for them to point to a DNAME. They couldn't point to a DNAME, but they could point to a target that would resolve through a 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 -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Special-use TLDs in resolvers
As I often note, I work for ISOC but I'm not speaking for it. On Fri, Aug 16, 2019 at 11:30:06AM +0200, Vladimír Čunát wrote: > I've been wondering what's best to do around these TLDs: invalid, local, > onion, test. The RFCs say that resolvers SHOULD recognize them as > special and answer NXDOMAIN without any interaction with nameservers (by > default). What do you think about NOT following this "advice", subject > to some conditions that I explain below? I think it's less than ideal, because the point of resolvers immediately answering NXDOMAIN is that these are not and never will be names in the global DNS. That is, they really are special-use, and part of that specialness is that they're part of the domain name space but not part of the global DNS name space. This is particularly true of onion, which is a protocol switch. It's intended to signal that 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
Dear colleagues, On Tue, Sep 04, 2018 at 12:29:30AM -0400, StJohns, Michael wrote: > Actually, 5.2 suggests that a master file (not zone) should contain a > single class and single SOA record. That’s not the same thing as limiting > a zone to a single class AFAICT. I believe it is the same thing, because classes divide the database which means that they are a division point among zones. I will note that I attempted a little while ago to explore this space more completely, but nobody liked my idea of effectively closing the class registry. See https://tools.ietf.org/html/draft-sullivan-dns-class-useless-03. If someone wanted to pick up that document, I wouldn't discourage them (but I don't think I have time any more to work on it). I agree with Paul Vixie that classes were never defined well enough to be made to work properly, at least at Internet scale. Best 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
Dear colleagues, Several meetings ago, I was at the mic complaining about various incremental changes to the DNS architecture and how we didn't seem to be thinking holistically about the matter. I think it was in response to something Ray Bellis said, and Ray quite correctly challenged me to put up or shut up. But as too often has been the case in recent years, I never managed to write down in a coherent form what I was talking about, and was left to splutter incoherently. This message is an attempt to lay out some of the questions that are nagging me, in the hope that someone else will find them interesting, since it seems pretty unlikely I'm going to get to put this together more coherently. This message is inspired in part by watching the exchange between Paul Hoffman and Stewart Bryant over the DoH I-D progress. What struck me there was Stewart's model of how things work: he was wondering how a client that had a host name was going to resolve anything, if that host name was its "DNS provider". I suspect that is actually the mental model an _awful lot_ of people have: a given host on the network has a source for resolution service, and that source provides all the answers. We (here) all know this is wrong, and has been essentially forever. But if large numbers of people continue to hold this assumption about the basic resolution path, I am prepared to believe that many things will continue to be built with that assumption built in. This means that we need to make the notion of "resolution context" a first-class notion, so that people understand that (e.g.) the link-local, homenet, split-brain, stub-to-full-service-resolution, and DoH contexts are all potential issues to build into one's assumptions. Indeed, even as that is going on, the IESG is considering draft-ietf-ipsecme-split-dns-12.txt. This follows from the MIF work some years ago that kind of but not really addressed split DNS and how it ought to work. We've also introduced mechanisms for signalling sessions (an idea for which I was an early proponent, I should note), altered the kind of queries people make by encouraging minimal queries (this has interesting consequences for strategies where parent and child zones are hosted on the same servers), and so on. This is all part of the complexity that I think Bert was talking about in his Camel talk. But I would say that the complexity _might_ be a requirement, and I think the problem is that we can't tell because we no longer (if we ever did) have a common and crisp description of what problems we are trying to solve and how the parts are supposed to fit together. (There is another claim about the camel -- that it is a horse designed by a committee.) I guess, therefore, I want to ask whether long-standing assumptions about the DNS are still true: • Is the stub::full-service resolver::auth server model just over? • Do we think resolution context needs signal? If so, how? • Is the age of the stub coming to an end? • Do we need something like "submission port for DNS", so that large concentrated systems can protect themselves and still provide service to important resolvers? • Does TCP need to become the norm (particularly for the above use case)? • How can we explain these changes to others working on network systems? • Do we have an appropriate venue to discuss these issues, on the presumption that they're not really operations issues? I really don't know the answer to much of this. I will note that some of these are questions 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 Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
On Fri, Jun 15, 2018 at 04:17:00PM -0400, Erik Nygren wrote: > We have many years of software that relies on emergent behaviors from the > current default. Well, I think more accurately we have years of software that relies on emergent behaviours of the prior default of certain implemnetations. > While pedantically it may be true that these should be treated as unordered > sets I don't think that's being pedantic. That's literally the definition of an RRset, and (as I guess has been shown by others in this thread) relying on an existing order behaviour to which one has become accustomed is going to be a problem even if people just switch out their software or change the configuration of their systems. This is a bug in the relying software, because the network _never_ made the promise that software was relying upon. > Software should have safe defaults that matches common expectations. I think this is true only if the common expectations are reasonable ones, and given what RRsets are the expectation in this case is not a reasonable one. What you're really saying is that, if there was ever one dominant system on the Internet (in this case, BIND), then the standards all need to be rewritten to conform not only to what that software implemented (a position with which I have some sympathy) but also to conform with the default settings of that software (a position I think needs rather more support than you've offered). > is that the order of results is NOT consistent. Sure. "Unordered sets." > In many environments, this > lack > of consistency is relied upon for systems to work properly. To me, this is like saying that, in many environments, the order of TCP packets (which very frequently do come in order) is relied 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't. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote: > A number of folks have been bitten by a bug in bind 9..12 where it silently > changes the default sorting of rrsets to always be sorted (even if the > authoritative response wasn't sorted). I believe that RRsets are unordered sets by definition. So I supect that if people are relying on the order in which they come off the wire, they're making a mistake. This is a common mistake with unordered data sets; it results in lots of complaints about SQL data responses, too, for instance. (Of course, in that case you always 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
On Tue, May 29, 2018 at 11:52:23AM -0400, John Levine wrote: > >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 cache? > > I'm guessing that it's intended to mean return the answer if you > already have it. If so, we should document that. I see that unbound > makes it an option but normally refuses any RD=0 queries. When you're doing support and someone is having a problem, one good thing to do is dig @targetresolver +norec to see what it gives you, yes. A difference between that and what you get at the authoritative server is often the explanation for the trouble. (One fun example: an ISP on the wrong end of a slow pipe in a certain country was doing unauthorized zone transfers for a TLD's zone. When TSIG became required for the zone transfers, 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 regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] refer-down
On Mon, May 28, 2018 at 09:34:06PM -0400, John Levine wrote: > > Also, you're the only person who's commented directly and that makes > > me think the WG isn't going to do much review of it > > Sheesh, it's a national holiday in the US and UK today. Some of us > were out having picnics. My apologies for being unclear. My point was rather that the draft is about to expire, and Joe and I created it entirely to draw away the debate of how referrals _should_ happen from the terminology document. Tht was what I meant by "the only person". As someone who can barely manage to cope with emails at a 1 week interval any more, I'm hardly likely to complain people don't get back the same day; but I do apologise that wasn't clear. > I like it because I like anything that makes the DNS simpler. I'd > make the advice clearer, authoritative servers that want to > interoperate MUST refuse out of zone requests. This is an interesting suggestion. > I'd also like to consider offering clearer advice on what do do when a > recursive server gets an authoritative query. Is there any situation > other than misconfiguration or testing when 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 cache? A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] refer-down
On Tue, May 29, 2018 at 12:08:36AM +0530, Mukund Sivaraman wrote: > good to have. You seem to have put a lot of effort into it; perhaps you > can update it as a clarification that provides more detail. It was just ancillary effort needed to make the terminology-bis discussion work, so it wasn't really much effort. Maybe it's useful text to have around if we ever get around to fixing up STD13 to be a modern document, but perhaps not that useful just now, since most people are unlikely to read it anyway. Also, you're the only person who's commented directly and that makes me think 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/mailman/listinfo/dnsop
[DNSOP] refer-down
Dear colleagues, As a consequence of some of the discussion about clarifying the term "referrals" in terminology-bis, it became clear that we didn't really have a place that said not to do upward referrals. So, Joe Abley and I put this little draft together: https://tools.ietf.org/html/draft-sullivan-dnsop-refer-down-00 I _think_ it is useful, but it didn't get much comment when we put it out because everyone was paying attention to the terminology document. Does anyone else think it's useful? If so, and some people are prepared to do some reviews, I'm prepared to work on it. 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://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] raising the bar: requiring implementations
On Wed, Mar 28, 2018 at 05:24:33PM +0200, bert hubert wrote: > allow the one remaining closed source DNS implementation Really? I'm so pleased we have not only candidate censors of what is going to be published by the WG but also census-takers who have determined then number and types of DNS implemntations in the universe. In case it isn't clear from the above, I am deeply uncomfortable with the entire DNS-police-cum-government latent in this thread. I think interoperability is important and valuable. I do not think that creating a clubhouse of kool kids who decide what "is" 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
Hi, On Mon, Mar 26, 2018 at 05:46:45PM +0200, bert hubert wrote: > So my first suggested action is: could we write a document that has a core > introduction of DNS and then provides a recommended (not) reading list. Maybe we could, but we failed at that once before. After the DNSSEC work wound down, around IETF 68, DNSEXT went "dormant". But it was apparent that the DNS protocol was complicated and difficult to understand, so the WG was rechartered partly to try to get some clarity to the standards. The document the WG hung its efforts on was https://tools.ietf.org/html/draft-ietf-dnsext-dns-protocol-profile-01. The problem, of course, was that nobody had the time required to complete this. I have no idea how the SMTP crowd at the IETF manged to get the cycles to update 821/822 several times, but we were unable to get this energy. The last update to that draft came in January 2008, and by IETF 72 (in July of '08) Olafur and I concluded that, if we couldn't get any activity, then we'd try to focus the WG on places where it could make progress. We took that decision in the fall of 2008. Now, I don't think that the work was bad or wrong, and I think that draft remains a useful place to start if people want to pick up that work again. But I'm not super convinced that this or any other WG really will have the desire to undertake it. Maintenance is no fun, and inventing new stuff is more entertaining. But, by all means, if people want to revisit that effort, I think it would be a fine thing. I think, however, that someone should contact a friendly neighbourhood AD to try to determine where the work should be chartered. I do _not_ think it is operations and management work. One thing that would be interesting to explore in taking that effort up is whether DNS should really be considered INT or ART. DNS lives squarely in the application layer and isn't really like the other things that fit in INT. OTOH, it's more a service to other parts of the network than it is an application the way ordinary application layer things are. The misfit 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
On Fri, Mar 23, 2018 at 06:02:47PM +, John Levine wrote: > > I see a message on dnsop from you proposing a bunch of things > including "rationalizing" names, and comments from Andrew and Peter > saying they like that approach. I think, to be clear, what I was saying I liked was the document splitting. This is because I sent Dave feedback on his original approach back a decade or so ago, worried about how the registry won't really be possible because of the multiple levels and so on. The basic problem is that underscore labels are a mess and needed 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 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
Hi, On Tue, Feb 06, 2018 at 12:50:18AM -0500, Ted Lemon wrote: > That's pretty clear. This document is not forbidding the appearance of such > names in the DNS, nor the resolution of such names. > Instead, it is wanting to have its cake and eat it too. Because… > >Note, however, that the admonition against searchlist usage could >affect their resolution in practice, as discussed in Section 3 …of the "admonition" (or whatever you want to call it). In effect, the document requires special-casing of "localhost" as a label in every searchlist context. If the goal is to say, "The search list is evil, and should not be used," then say that. Otherwise, what this document is _really_ doing is altering STD13's search list processing, to include special-casing of down-tree names. I think that is the case despite this bit: >Application software MUST NOT use a searchlist to resolve a >localhost name. That is, even if DHCP's domain search option >[RFC3397 <https://tools.ietf.org/html/rfc3397>] is used to >specify a searchlist of "example.com" for a given network, >the name "localhost" will not be resolved as >"localhost.example.com." but as "localhost.", and >"subdomain.localhost" will not be resolved as >"subdomain.localhost.example.com." but as >"subdomain.localhost.". The reason I think that is because of the earlier part: 2. Application software MAY recognize localhost names as special, or MAY pass them to name resolution APIs as they would for other domain names. If you can just pass this to a resolution API, then it's actually the resolution API that needs to know to handle the search list rules according to this new specification (this part of the specification does not say that you can only use the API if you can tell the API not to use search lists, ). I really do sympathise with the goal of the 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 things any better. 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
On Thu, Feb 01, 2018 at 08:46:01PM -0500, Joe Abley wrote: > > Can we take a brief pause to acknowledge that "the DNS" as a phrase is highly > ambiguous Yes. > and think about whether we mean the protocol, I mean this and > any particular installation or the namespace (and if so, which one, since > there are many, even if our context is a single Root Server System serving a > single Root Zone, note capitals, which I think it should be). this but > any particular implementation, > not this. That is, I think that localhost is a DNS name in the context of the Internet DNS root zone. I think that because RFC 2606 and RFC 6761 say so, and because I was under the impression that the Internet root zone operated by IANA still conforms to RFCs. It's apparent now to me, however, that the Internet root does not actually answer for localhost. I find this surprising and wrong. It is also possibly part of the reason for the complaint that people can't rely on the name "localhost", since a query to the root for that name will get a cacheable response saying authoritatively that the name does not exist. I don't know whether that _is_ part of the problem, of course. I note that SAC045 observes that localhost was in the top 10 "invalid TLDs" queried between 2006 and 2009. (I realise now that when that came out I didn't check to see whether the root was responding as RFC 6761 said it should. This was plainly a mistake 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 ___ 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
Hi, On Thu, Feb 01, 2018 at 03:26:40PM -0600, Ted Lemon wrote: > > As for why I responded to this and not to the formal review, the answer is > that the formal review was a bit overwhelming. You made a lot of assertions > of fact that didn't sound like fact to me—they sounded like strongly-held > opinion. Hmm. I should do better. I apologise. > The problem I have is that to me it's dead obvious that the name hierarchy > and the set of names in the DNS are not the same thing. Me too. Hence the distinction with local and invalid compared to localhost. > But you explain your reasoning on the basis that clearly they are the same > set, and that they are the same set is left unexamined. No, I'm arguing that the _existing behaviour_ according to RFCs and long-standing practice (including that of the BSD resolver) is that the distinction between the global DNS zones and the handling of localhost is not observed in the way that it most certainly (by documentation) should be for local. I don't think it's ok to try to legislate by RFC, and 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. Every root server on the planet, _for its own purposes_, ought to be authoritative for localhost. There is no reason therefore that it should present a lie (NXDOMAIN) when asked by someone else. That's different from local, where in fact in the DNS there _is_ no 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] the ??-- thing (was Re: I-D Action: draft-huston-kskroll-sentinel-04.txt)
Hi, Please note that this is not about the document that started this thread. It's a rathole, but in a different field. On Tue, Jan 30, 2018 at 04:58:01PM -0800, Paul Hoffman wrote: > Please, no. As the originator of the original > hack, I think this is the wrong thing to do > for many reasons. The biggest one is, sadly, the fact that some software now > has as reserved even though it should not. I am not convince that "it should not" is true, and having thought about this a little more it seems to me that an IANA registry should have been created in the first place for this sort of miserable in-label hack. If it had been, we could have done something useful here. And if we don't do so now, in short order we're going to be into the multi-level underscore-label hell that underscore labels are. RFC 5891 explicitly says that any IDNA-handling software can't accept a string with two hyphens in the third and fourth character positions (that is, in a crappy regex, can't take ^..\-\-.*) as a candidate Unicode string to be a label (see 4.2.3.1). This causes upset in section 5.4 of the same document, which is I suspect how Paul's "sad" software came to be. It seems plain therefore that a registry of in-band in-label prefixes ought to be created, so that instead of heuristics in IDNA2008 we could tell people to use a real rule. Before I go to the bother of writing this up, are there at least five people who would review it, noting 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
To be clear, I agree that it's a small point, and I was mostly interested for other reasons having to do with another draft (the one I mentioned). I didn't think this was a blocking question. On Wed, Jan 31, 2018 at 09:44:10AM +1000, George Michaelson wrote: > I think we're rat holing. […] > 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 > >> record" here they actually mean "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. -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A conversational description of sentinel.
On Fri, Feb 02, 2018 at 07:20:45AM +1100, Geoff Huston wrote: > What about if the sentinel spec proposes to use a left-most label of the > form(s): > > xm—-is-ta-[key] > > and > >xm—-not-ta-[key] > > > would this form of hostname be a reasonable way forward? Only if you want to create an IANA registry of labels with two ASCII-letter-range octets followed by two hyphen-minus characters. One of the IDNA documents reserves everything of that form, alas. This registry business might be a good tidying effort anyway, though, so I'm not opposed. 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
On Thu, Feb 01, 2018 at 11:45:26AM -0600, Ted Lemon wrote: > > As a general principle, when what the RFC says to do is not the right thing > to do, the solution is to update the RFC, not to ignore the problem. I strongly agree with this (as I think or anyway hope you know), and if my response seemed to be an appeal to the mythical authority of the RFC series then I apologise. My intent was to point out, instead, that RFC 6761 has a position about this, and it is quite clear and also contrary to the behaviour of the root servers. Since RFC 6761 has IETF consensus, I am not convinced that the response from the roots is right. Since an NXDOMAIN response causes the _very problem_ that the draft this thread is about is attempting to fix -- literally by making the effect in question more ubiquitous -- it seems to me that the burden of proof lies upon others. > Your and Paul's responses to this seem to take the position that what matters > is consistency. We should not return NXDOMAIN, because localhost has > meaning, and NXDOMAIN doesn't. But this misunderstands what NXDOMAIN means. > What NXDOMAIN means is "there is no such name in the DNS." It doesn't > mean "there is no such name." > But of course, there _is_ a name "localhost" in the DNS. It's already defined, in the RFCs, to this effect. RFC 6761 defines special-purpose domain names, not domain names that are outside the DNS. It so happens that this domain name _is_ in the DNS, precisely because RFC 6761 recommends that it be so (unlike, for example, what it says for .invalid or what RFC 6762 says for .local). The point is rather that localhost is a universal reference to the loopback address. Since it is a universal truth, it is true in the IN class, and that means that any server on the Internet ought to know this. > Returning REFUSED makes things worse. Returning NXDOMAIN does not. The goal in the draft is to make things break for the host making the request, even though it should not have made that request. Returning REFUSED and returning NXDOMAIN both have that effect. But returning NXDOMAIN also breaks the semantics of DNS, which I think it worse. > Second, there's no trust model for such a response. The trust model for > NXDOMAIN is clear, and we know how to do it. The trust model for e.g. > REFUSED is nonexistent. > Nonsense. The trust model for refused is, "You asked and were denied." Signable denial of service strikes me as possibly the most abusable service on the Internet :) > Whether we should place special requirements on recursive resolvers is > certainly something that is up for debate. RFC 6761 _already_ places such requirements, it seems to me. > If you believe that the right response is not NXDOMAIN, your reason needs to > be something more than "that's what the RFC says to do." > I believe I offered such reasons in rather 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
On Thu, Feb 01, 2018 at 09:11:37AM -0800, Paul Vixie wrote: > > That's not entirely true - if you are asking an authoritative-only server > > then you get REFUSED or not depending on whether the QNAME is in an > > authoritative zone. > > that's what this group has reached 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 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
On Wed, Jan 31, 2018 at 04:15:07PM +, Viktor Dukhovni wrote: > return NXDomain is likely the best option for now. The other > alternative is to actually serve the expected data: > > localhost. IN A 127.0.0.1 > localhost. IN ::1 > > but I don't think that'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
On Wed, Jan 31, 2018 at 10:04:03AM +, Ray Bellis wrote: > > Won't that cause the resolver to cycle through every root server letter > hoping for one that doesn't give that answer? It might, yes. But that's a poor reason to give an authoritative answer that a name which does exist 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 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
On Tue, Jan 30, 2018 at 11:39:31AM -0600, Ted Lemon wrote: > > It is possible to produce a signed answer, because the domain doesn't exist I think I was arguing yesterday that that is in fact not true. The domain (name) does exist, and it is defined in RFC 6761 precisely to be special. In addition, > > cavall% dig @a.root-servers.net localhost > > ; <<>> DiG 9.10.1b1 <<>> @a.root-servers.net localhost > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19121 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available That answer from the root is contrary to RFC 6761 section 6.3 item 5 and maybe 6. Because of that same section, also, signing the answer should also not be controversial 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
On Tue, Jan 30, 2018 at 10:42:15AM -0500, Joe Abley wrote: > > I realise that the following is not what anybody means in this thread Hmm. Actually, I wasn't sure :-) > I probably missed some. Anyway, I think when people are saying "address > record" here they actually mean "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@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 formally? 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
On Fri, Jan 26, 2018 at 05:32:33PM +0100, Petr Špaček wrote: > I personally agree with the doc, it makes sense to me, and I do not > believe that its wording prevent anyone from adding knobs they want. > Software in the end will do whatever its developers wanted, which might > include knob to override any part of spec. The purpose of RFC 2119 language is not to make people feel better or to provide the imaginary benefit of a stick with which to beat people for non-conformance. The purpose is to maximise reliable interoperation, where "reliable" is interpreted generously to include concern for security and privacy, and "interoperation" is interpreted generously to include avoidance of anti-patterns in design and deployment choices. So the problem here is that, if people start adding local configurations to override the proposed update to "MUST", the goals of the document won't be realised anyway. If on the other hand we understand 2119 language correctly and apply it rigorously, the failure to capture localhost at the local boundary will already be understood as a problem (regardless of what the mechanism is by which one gets there -- 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
Dear colleagues, On Mon, Jan 22, 2018 at 11:18:08AM -0500, Suzanne Woolf wrote: > Hi all, > > This is the opening of the Working Group Last Call for "Let 'localhost' be > localhost” > (https://www.ietf.org/id/draft-ietf-dnsop-let-localhost-be-localhost-02.txt). > I have read this document. Let me begin by saying that I am sympathetic to what the document wants to do and why it wants to do it. I nevertheless think the proposal here is incorrect, and that it has bad consequences for the DNS and for the RFC 6761 special-use registries. I am at least a little troubled by the assertion, early in the document, that RFC 6761 empowers anything to send queries anywhere. This is the text in RFC 6761: 3. Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s). That does not sound to me like "empowering" clients to send queries to a resolver. It sounds to me like something being advised against, and strongly. In RFC 2119, "SHOULD" does not mean, "This is mostly preferable." It means you ought to do it unless there "exist valid reasons in particular circumstances to ignore" that constraint. Nevertheless, people sometimes misread the SHOULD. Perhaps the section of RFC 6761 dealing with localhost could use the following clarification: 3. Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s). The only exception to this stricture is in the case where a node is known not to have a loopback interface configured and the local network is known to provide some replacement service. For practical purposes, libraries will never use such functionality, and resolution API and library programmers are encouraged to treat these requirements and mandatory behaviour. I'd even be prepared to countenance an argument that the SHOULDs really ought to be MUSTs in this item. I am really very troubled by the idea that any DNS server should return RCODE 3 to a query for "localhost". (This is items 4 and 5 in section 3.) This is not even wrong: the name _does_ exist, and indeed any server on the Internet would know that (since it would itself serve the answer _to_ itself of what localhost means; whether it should serve it to anyone else might be a different question, but it certainly should not respond with RCODE 3). The draft's IANA considerations are wrong, I think, because it does not make clear that this reservation is of the label "localhost" anywhere in the DNS at all. That is the consequence of item 2 under section 3: since the bare label localhost, which is a relative name, is treated as root-relative under all circumstances. I am pretty sure this is an update to STD13: I can't think of any case where relative qualification is treated so strangely (if example.com does not get resolution as example.com., then the fallback to the search list happens, but not before). This seems to be in tension with section 5.2. I understand the goal, but I don't think it is possible to achieve it in the DNS. The advocacy in section 5.1, that applications should do the work themselves, seems to me to be leading in the opposite direction to an ostensible goal of the document. In section 1 we see a note that applications have hard-coded loopback addresses. 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 cannot support advancing the draft in its current state. 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)
Hi all, Some of you will perhaps recall that previous efforts at text on referrals were unsuccessful. I've had another go. I _think_ it addresses all the comments so far, without actually causing the terminology draft to drift into prescribing protocol. It is unfortunately quite a bit longer, but that seems to be the cost of making all the points from the discussion. Thoughts are solicited: Referral: A type of response in which a server, signalling that it is not (completely) authoritative for an answer, provides the querying resolver with an alternative place to send its query. Referrals can be combined with partial answers. A referral arises when a server is not performing recursive service while answering a query. It appears in step 3(b) of the algorithm in [RFC1034], Section 4.3.2. There are two types of referral response. The first is a downward referral (sometimes described as "delegation response"), where the server is authoritative for some portion of the QNAME. The authority section RRset's RDATA contains the name servers specified at the referred-to zone cut. In normal DNS operation, this kind of response is required in order to find names beneath a delegation. The bare use of "referral" means this kind of referral, and many people believe that this is the only legitimate kind of referral in the DNS. The second is an upward referral (sometimes described as "root referral"), where the server is not authoritative for any portion of the QNAME. When this happens, the referred-to zone in the authority section is usually the root zone (.). In normal DNS operation, this kind of response is not required for resolution or for correctly answering any query. There is no requirement that servers send them. Some people regard upward referrals as a sign of a misconfiguration or error. A response that has only a referral contains an empty answer section. It contains the NS RRset for the referred-to zone in the authority section. It may contain RRs that provide addresses in the additional section. The AA bit is clear. In the case where the query matches an alias, and the server is not authoritative for the target of the alias but it is authoritative for some name above the target of the alias, the resolution algorithm will produce a response that contains both the authoritative answer for the alias, and also a referral. Such a partial answer and referral response has data in the answer section. It has the NS RRset for the referred-to zone in the authority section. It may contain RRs that provide addresses in the additional section. The AA bit is set, because the first name in the answer section matches the QNAME and the server is authoritative for that answer (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
Hi, On Mon, Dec 18, 2017 at 02:52:11PM +0100, Stephane Bortzmeyer wrote: > I think that it would be better to remove "global DNS". It is not a > technical definition and it assumes things like the mythical "names > operational community". I don't believe the "names operational community" is mythical, since it specifies behaviour through a formal mechanism for something that goes in an IANA registry. But the discussion of Global DNS is imperfect, I agree. > This draft is about DNS terminology. From the > point of view of the DNS, ICANN and OpenNIC are the same (same > protocols, same concepts, same names) even if their registration > (i.e. non-DNS) policies are different. I think that description is, however, inaccurate. One of those DNS operations is the public Internet name system -- the one with the root published by IANA -- and the other one is not. This is not different from the distinction between split-horizon names, where some of them can get answers from the public Internet and others cannot. It is also the way we can reasonably make the distinction between something like local., which is a domain name that is not part of the DNS; home., which is not delegated in the "global DNS" but might be in use in the DNS in some locations; and com., which is delgated in the "global DNS". I think this is an important notion that impinges on the DNS, and I think we need to be able to define a term 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
On Sat, Dec 02, 2017 at 08:09:25PM +0530, Mukund Sivaraman wrote: > I don't agree a downstream cache has authoritiative say about extending > TTLs (except exceptional circumstances where the authority is > unreachable ~serve-stale). I will note that this WG spent a fair amount of effort 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 list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 11:34:12PM +, Tony Finch wrote: > > Normal (downward) referrals come from authoritative data, and indicate the > server is saying to the client, you need to ask here next; on the other hand > these special kinds of referrals come from the cache. An implicit referral > comes in a full-fat RD=1 RA=1 answer, and indicates the server is telling the > client where the answer came from; if RD=0 or RA=0 you can get an upward > referral, which indicates the server is telling the client where the server > would ask next in order to fill its cache. > I think that's correct. But what is not plain to me in my reading, insistent noises on the list notwithstanding, is whether the second ¶ in step 3.b of the algorithm in section 4.3.2 of RFC 1034 is still part of what "a referral" means. The ordinary English meaning, as far as I can tell, of that 3.b subsection is that everything one does as part of step 3.b is a referral response. The problem is that "Go to step 4" is part of that last ¶, not a new ¶, and so what I think is obscure in the algorithm text is whether the stuff you're copying into the response in step 4. I tend to agree that the other parts of STD 13 argues in favour of at least "upward referrals are a degenerate case" and maybe even "upward referrals are _not_ referrals in the bare word sense." But while I find that reading persuasive, there are two important facts to consider: for a long time, that was not actually the reading people adhered to, and there does not seem to have been a lot of complaining about it (indeed, even djb's remarks about DNS barely suggest this is a fault of the server, and AFAICT he thought that BIND was responsible for bubonic plague when he wrote those notes). Second, we should not expect, in fairness, an earnest reader to do the same synoptic reading that others have done, or to reach the same conclusion. It's at least as likely that such a reader will conclude that RFCs 1034 and 1035 are written with a certain lack of terminological rigour -- which is perhaps borne out by the effort we apparently need to make to clarify a term as fundamental as "referral". I don't think anyone in this discussion disagrees about how things _ought_ to operate. But in the terminology document, I think we have tried to preserve the meanings that persist on the Internet. I find it very hard to convince myself either that upward referrals are dead, or even that lots of people don't use "referral response" to mean "referral to the root". I encounter both of these ways of speaking with some regularity. Maybe my sample is really skewed; but I think it is at least as plausible that people who are clued into the DNS think that upward referrals are bad and that therefore all referrals must be down. > implicit referrals and upward referrals are supposed to be cache-filling > gossip (in 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)
On Wed, Nov 29, 2017 at 09:18:39PM +, Dick Franks wrote: > > And said referral could be to an arbitrary node in the DNS tree, i.e. > possibly "upward"? > > Or am I missing something? That depends on whether you believe the later part of the algorithm in RFC 1034 (where it says to do things from the cache) is part of the "referral" part, particularly in a mixed-mode server where it has received a query with RD=0. The list appears to have strong feelings about that. It's why Joe and I wrote draft-sullivan-dnsop-refer-down. As I've said many times, 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)
On Wed, Nov 29, 2017 at 01:55:29PM +, P Vix wrote: > Please do not write anything that blurs or softens the clear language of > downwards-ness in 1034. If you can't keep the clear spirit and intent of the > existing document then please write nothing at all. > I don't believe 1034 is anywhere near as clear as you are insisting it is; and the empirical evidence of that lack of clarity is the very thing you feel the need to recant. If the WG believes otherwise, then I think it is free to write the definition as it wishes, but only if it removes me as an editor of the terminology document. I do wish to make the definition clear, and I have no complaint where the definition might note that not every operator agrees about providing upward referrals (the text proffered already says that, I think). But I shall not include a change to the definition of referrals such 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@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 12:23:36PM +, P Vix wrote: > 1034 cannot be reasonably read that way. Sure it can. See the discussion in draft-sullivan-dnsop-refer-down and on the list not two weeks ago for how. I think it should _not_ be read that way, but an honest reader could read it that 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.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 02:37:20AM +, Evan Hunt wrote: > > I think the phrasing is unclear because "this response is not required to > work" is ambiguous. The response *itself* doesn't have to work? Or the > resolver can get along without this response? I took it to mean the > latter, but I see how it could be confusing. Yep, got it. > I'd suggest something like "this response is not strictly speaking > necessary, as it provides no information the resolver didn't already > have; resolution can succeed without it." How about, "This 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote: > that's fatally unclear. So I gather :) > then the thing to say would be "a referral should always be downward, and if > a non-downward referral is received, it should be treated as a network data > configuration error". No, that is attempting to define away other kinds of referrals, which is precisely the discussion we were previously having (and why Joe and I wrote that other draft). The terminology draft should not, in my opinion, attempt to change any RFC; and, IMO, 1034 defines referrals in such a way 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 01:14:13PM +1100, Mark Andrews wrote: > When the CNAME refers to a name that is out of zone and the target zone is > below > a zone that the server serves you will have CNAME (DNAME) + referral. > > 4.3.2 loops. This part I got. > pass 1 -> 3a (adds CNAME, AA is set as it matches the question > section, QNAME is updated). This is the CNAME response, yes, ok. > pass 2 -> 3b (we have a partial match with a bottom of zone cut which > adds the referral). > Right, and the authoritative server can't proceed, 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...@anvilwalrusden.com> wrote: > > > > Hi Mark, > > > > On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote: > >> You can answer only responses, you can have referral only responses, > >> you can partial answer + referral responses. > > > > Where in the algorithm in section 4.3.2 of 1034 (or other, derived > > cases like DNAME) is this "partial answer + referral responses" > > described? If this is well-defined somewhere, I want to refer to it. > > If it is not, I wish to describe it clearly, because it seems pretty > > obvious given the amount of discussion we've had on this topic that > > the notion of referral is nowhere near as clear 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 > > > -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
Hi, On Wed, Nov 29, 2017 at 11:16:28AM +, Tony Finch wrote: > > Regarding the definition of referrals from older RFCs, see my > terminology review from May 2015: > https://www.ietf.org/mail-archive/web/dnsop/current/msg14243.html Yes, it's your review that has caused this issue :) > I think that quote implies that other less formal uses of "closer" > specifically mean downward in the DNS tree. That's plausible. > So I think unqualified "referral" means "downward referral" (from > authoritative data) I'm not totally convinced, but I can certainly see the argument. If we added to the text I proposed something like, "Many people use the unqualified term 'referral' to mean only a downward referral," would that help? > answer the query. I have also seen the term "implicit referral" meaning > the authority section from a recursive response, since the idea was that a > downstream cache might use those records to answer future queries more > efficiently (though doing that is no longer considered safe). Hmm. It seems like we ought to add that point about implicit referral. I wonder 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)
Hi Mark, On Wed, Nov 29, 2017 at 12:57:26PM +1100, Mark Andrews wrote: > You can answer only responses, you can have referral only responses, > you can partial answer + referral responses. Where in the algorithm in section 4.3.2 of 1034 (or other, derived cases like DNAME) is this "partial answer + referral responses" described? If this is well-defined somewhere, I want to refer to it. If it is not, I wish to describe it clearly, because it seems pretty obvious given the amount of discussion we've had on this topic that the notion of referral is nowhere near as clear 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 -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
Yes, what I just sent. So how does one end up in 3.b with the AA bit and still have a "referral" according to 1034, section 4.3.2? A On Wed, Nov 29, 2017 at 12:49:48PM +1100, Mark Andrews wrote: > AA Authoritative Answer - this bit is valid in responses, > and specifies that the responding name server is an > authority for the domain name in question section. > > Note that the contents of the answer section may have > multiple owner names because of aliases. The AA bit > 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:44 pm, Andrew Sullivan <a...@anvilwalrusden.com> > >> wrote: > >> > >> Hi, > >> > >> On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote: > >>> The AA bit may or may not be set depending upon whether the response > >>> contains > >>> a CNAME/DNAME or not. > >>> > >> > >> I replied with an enthusiastic "thanks" because this struck me as > >> obviously correct, but then I though I'd better look at the algorithm > >> again. And now I have a problem. > >> > >> 3.a is the CNAME case, but it's not a referral in the 1035 sense. > >> > >> 3.b takes us out of the authoritative data, so AA should not be set. > >> > >> Now, in RFC 6672 the DNAME processing happens at step 3.C, which > >> undertakes the DNAME processing. The resulting answer goes into the > >> answer section and processing continues. > >> > >> None of these steps seems to provide the case where a referral happens > >> but the AA bit is set. So, while I feel like I agree that in some > >> cases the AA bit should be set and not clear in case the response > >> contains a 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 6:50 am, Andrew Sullivan <a...@anvilwalrusden.com> > >>>> wrote: > >>>> > >>>> Dear colleagues, > >>>> > >>>> Joe Abley and I have just submitted a draft > >>>> (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) > >>>> that is intended to capture the discussion here about referrals and > >>>> how to describe them. It is intended for BCP, and it discourages > >>>> upward referrals by authoritative servers. > >>>> > >>>> That leaves the task of the referrals definition. I have some new > >>>> text below: > >>>> > >>>> ---%<---cut here--- > >>>> > >>>> Referral: A type of response in which a server, signalling that it is > >>>> not authoritative for an answer, provides the querying resolver with > >>>> an alternative place to send its query. A referral contains an empty > >>>> answer section. It contains the NS RRset for the referred-to zone in > >>>> the authority section. It may contain RRs that provide addresses in > >>>> the additional section. The AA bit is clear. > >>>> > >>>> There are two types of referral response. The first is a downward > >>>> referral (sometimes described as "delegation response"), where the > >>>> server is authoritative for some portion of the QNAME. The Authority > >>>> section RRset's RDATA contains the name servers specified at the > >>>> referred-to zone cut. In normal DNS operation, this kind of response > >>>> is required in order to find names beneath a delegation. > >>>> > >>>> The second is an upward referral (sometimes described as "root > >>>> referral" or just "referral response", as distinct from the delegation > >>>> response above), where the server is not authoritative for any portion > >>>> of the QNAME. When this happens, the referred-to zone in the > >>>> Authority section is usually the root zone (.). In normal DNS > >>>> operation, this kind of response is not strictly speaking required to > >>>> work, and in practice some authoritative server operators will not > >>>> return referral responses beyond those required for delegation. > >>>> > >>>> [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. We'll > >>>> only include this reference if the other draft reaches WG consensus > >>>> before terminology-bis] > >>>> > >>>> ---cut here--->%--- > >>>> > >>>> Comments, please. Also, Joe and I solicit comments on the referrals > >>>> draft proper, but it would be nice to put that in a different thread. > >>>> > >>>> 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)
On Wed, Nov 29, 2017 at 12:46:07PM +1100, Mark Andrews wrote: > GO READ STD13! I thought I had, and I thought indeed that I was quoting it to you (or at least making references). I _suspect_ that you're referring to 4.1.1 in 1035 which describes AA. But that says that it "that the responding name server is an authority for the domain name in question section." This does not seem to me to line up clearly with the cases called a "referral" in 1034. I'm not trying to be religious about this or claim that I have the right answer. I'm just trying to write down 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)
On Tue, Nov 28, 2017 at 03:18:57PM -0800, Paul Vixie wrote: > what would "to work" mean in the above text? "Not strictly speaking required to work" was intended to observe that, if you didn't get a referral under this condition, nothing ought to break (or, if it did, it was already broken). The point is in contrast to the downward referrals case, which _must_ work or delegation doesn't. I'm nervous about someone running off saying, "IETF says referrals don't work," which is clearly not the point. > that an upward referral could "work" in the above-reference sense seems to > imply that the authority server you've queried, knows more about where the > zone really is, than you could learn by walking down from the root. that's a > walking talking nonsequitur. could you tell me what you really mean by "to > work" since 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)
Hi, On Wed, Nov 29, 2017 at 07:39:42AM +1100, Mark Andrews wrote: > The AA bit may or may not be set depending upon whether the response contains > a CNAME/DNAME or not. > I replied with an enthusiastic "thanks" because this struck me as obviously correct, but then I though I'd better look at the algorithm again. And now I have a problem. 3.a is the CNAME case, but it's not a referral in the 1035 sense. 3.b takes us out of the authoritative data, so AA should not be set. Now, in RFC 6672 the DNAME processing happens at step 3.C, which undertakes the DNAME processing. The resulting answer goes into the answer section and processing continues. None of these steps seems to provide the case where a referral happens but the AA bit is set. So, while I feel like I agree that in some cases the AA bit should be set and not clear in case the response contains a 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 6:50 am, Andrew Sullivan <a...@anvilwalrusden.com> wrote: > > > > Dear colleagues, > > > > Joe Abley and I have just submitted a draft > > (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) > > that is intended to capture the discussion here about referrals and > > how to describe them. It is intended for BCP, and it discourages > > upward referrals by authoritative servers. > > > > That leaves the task of the referrals definition. I have some new > > text below: > > > > ---%<---cut here--- > > > > Referral: A type of response in which a server, signalling that it is > > not authoritative for an answer, provides the querying resolver with > > an alternative place to send its query. A referral contains an empty > > answer section. It contains the NS RRset for the referred-to zone in > > the authority section. It may contain RRs that provide addresses in > > the additional section. The AA bit is clear. > > > > There are two types of referral response. The first is a downward > > referral (sometimes described as "delegation response"), where the > > server is authoritative for some portion of the QNAME. The Authority > > section RRset's RDATA contains the name servers specified at the > > referred-to zone cut. In normal DNS operation, this kind of response > > is required in order to find names beneath a delegation. > > > > The second is an upward referral (sometimes described as "root > > referral" or just "referral response", as distinct from the delegation > > response above), where the server is not authoritative for any portion > > of the QNAME. When this happens, the referred-to zone in the > > Authority section is usually the root zone (.). In normal DNS > > operation, this kind of response is not strictly speaking required to > > work, and in practice some authoritative server operators will not > > return referral responses beyond those required for delegation. > > > > [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. We'll > > only include this reference if the other draft reaches WG consensus > > before terminology-bis] > > > > ---cut here--->%--- > > > > Comments, please. Also, Joe and I solicit comments on the referrals > > draft proper, but it would be nice to put that in a different thread. > > > > 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)
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 Sullivan <a...@anvilwalrusden.com> wrote: Dear colleagues, Joe Abley and I have just submitted a draft (https://datatracker.ietf.org/doc/draft-sullivan-dnsop-refer-down/) that is intended to capture the discussion here about referrals and how to describe them. It is intended for BCP, and it discourages upward referrals by authoritative servers. That leaves the task of the referrals definition. I have some new text below: ---%<---cut here--- Referral: A type of response in which a server, signalling that it is not authoritative for an answer, provides the querying resolver with an alternative place to send its query. A referral contains an empty answer section. It contains the NS RRset for the referred-to zone in the authority section. It may contain RRs that provide addresses in the additional section. The AA bit is clear. There are two types of referral response. The first is a downward referral (sometimes described as "delegation response"), where the server is authoritative for some portion of the QNAME. The Authority section RRset's RDATA contains the name servers specified at the referred-to zone cut. In normal DNS operation, this kind of response is required in order to find names beneath a delegation. The second is an upward referral (sometimes described as "root referral" or just "referral response", as distinct from the delegation response above), where the server is not authoritative for any portion of the QNAME. When this happens, the referred-to zone in the Authority section is usually the root zone (.). In normal DNS operation, this kind of response is not strictly speaking required to work, and in practice some authoritative server operators will not return referral responses beyond those required for delegation. [optional: see draft-sullivan-dnsop-refer-down-00 or whatever. We'll only include this reference if the other draft reaches WG consensus before terminology-bis] ---cut here--->%--- Comments, please. Also, Joe and I solicit comments on the referrals draft proper, but it would be nice to put that in a different thread. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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] Clarifying referrals (#35)
_ one. > as witnessed in discussions of the u.s. constitutions and the christian > bible, arguments about the literal intent of the authors are interesting > mostly to scholars, whereas our concern should be with the actions taken by > the far end given the data pattern we transmit and the circumstances as we > know them. Well, I want to be neither talmudic nor supreme. I don't think I disagree with your view (though FWIW I find your tone a little patronizing), but I think we are doing two things in this discussion: 1. Providing fodder for a draft I've already started writing that provides guidance not to return upward referrals. 2. Providing the necessary information for the terminology document so that we have written down our current best understanding of terms as people use them. I do not believe that (2) ought to include an effort to define terms to exclude operations we (for some value of we) think are a bad idea. IMO, the goal of 7719bis is not to define problems out of existence but to give us a clear and common set of terms to talk about all of this, _so that_ we can specify improvements to what the traditional specifications say. > while specific guidance was not given as to resolver action in response to > each possible authority RCODE, i have both witnessed and implemented full > resolvers which treated REFUSED as a permanent failure whereas SERVFAIL was > a temporary failure. And that "permanent failure" marks the server dead, not the server-qname or even server-zone combination dead, I guess. 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 so that we can maximise interoperation, not specify what is Correct. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07
Hi, Speaking only for myself and not the other editors: On Tue, Nov 14, 2017 at 03:09:39PM +0800, Mukund Sivaraman wrote: > The terminology document seems to contain both easy and > hard-to-come-by definitions. Without knowing what to filter, I keep > getting a large vocabulary of DNS phrases to propose but I don't > know if they belong in this terminology document. Is any DNS phrase > acceptable? Maybe :) The editors will of course do whatever the WG consensus is. Still, the point is not, IMO, to cover every term that has to do with the DNS in any context, and if a term is not used except in a given context I'd expect familiarity with that part of the protocol to be enough unless the terms are otherwise poorly defined. The genesis of the document was in part, at least for me, irritant terms: 1. There were terms that I would trip across even though they were well-documented (nobody would bother to look them up), and I wanted an easy thing to point to. Usually these were terms that were used badly or carelessly (sometimes by people who were obviously pretending to know what they were talking about). 2. There were terms that got thrown around all the time, and when someone would ask me the meaning I found I didn't have a good reference, but I knew perfectly well that everyone knew what was meant. 3. There were terms that I was afraid were being used ambiguously or even equivocally. Some of these haven't made the cut yet :) I don't know whether Paul's and Kazunori's inspirations were the same. I think in general though the WG has attempted to include terms that are in wide enough use and sufficiently DNS-specific so as to be appropriate for processing through the DNSOP WG. > * DNS indirection (a phrase also used in the infamous iDNS > attack.. lookup of name leads to lookup of nameserver's address > nsname1/A, which leads to lookup of another nameserver's address > nsname2/A), etc. I am not sure I have ever heard this term, so I can't tell whether it ought to be included. > > * Cache (explanation of what a cache is, what it contains, how long the > cache may be expected to store data, whether it is strongly coupled to > authoritative data, etc.) Probably the general term cache doesn't need explaining, but it's true that 7719 has a lot of mentions of caches without saying what they ought to have, and I'm not sure the older RFCs are too clear about this. > * Chain-of-trust (in DNSSEC) Is this a DNS-specific term? I think it's pretty common in PK crypto, no? > * Owner name (of RRs) Already there ;-) > * Truncated message (I feel it's important to describe it and what > happens due to it, as it's a commonly seen occurrence) If you have proposed text, I can maybe see a spot for this. > * DNS continuation (e.g., the sequence of AXFR messages) There is a pretty exhaustive AXFR document, and this only comes up in that context, right? […] > * DNS class (what is it good for? :) Absolutely nothing, say it again. I offered a draft about this a while ago and got enough push back that I gave up. I am not convinced that a terminology draft could tackle the definition of class in STD 13 without attempting to alter the meaning, myself. > > * Negative response - shouldn't this also include "name doesn't exist" > NXDOMAIN?) It does, no? We don't reproduce the stuff to which we refer: you're supposed to follow those referrals, just like a resolver ;-) > * Reverse lookup - is it worth mentioning PTR here? Text? > * Occluded name - This is not limited to DNS UPDATE and introduction of > DNAME. It _can_ also occur via regular zone loading process, if the > parser allows non-address "glue" (the wider use). I think it isn't > strictly specified that 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)
Hi, On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote: > > If I ask the authoritative server for example.com about a name > > label.example.net, in a graph-theoretic sense the NS RRset for the > > root zone is clearly closer to label.example.net than anything else I > > can give. > > dns is not that kind of graph. > > if the qname is acetes.pa.dec.com and the query is being processed by the > dec.com authority server who knows that pa.dec.com is a delegation, then > pa.dec.com is closer to acetes.pa.dec.com than the root would be. Obviously. But your example is still on the current tree, just not immediately below. The example I gave is in a completely different section of the tree, and my point is that none of the text you quoted shows why "." isn't the "closer server" that an authoritative server somewhere beneath com. can give in response to a qname that is somewhere beneath net. We might think today that is a misfeature in STD13, but I don't think it's a misinterpretation of what STD13 says. I don't know what kind of graph would make that false. > as i wrote during the SOPA wars, REFUSED has been widely used as an > administrative denial, and repurposing it would not be effective at this > late date. This, too, seems to be a claim that is at best poorly justified. It might be that it is how BIND interprets the RCODE, but it's not what it is defined to be. I'm anyway not sure 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 perform upward referrals is also a policy, no? Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[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 new draft), > > I'd suggest a new draft be produced with which discussion could ensue. Given the discussion that ensued only here, it's pretty clear that some new text is needed. If nobody else writes one before I get the round tuit, I will, and will update the text about referrals also. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
Hi, This is quite a helpful response, thanks. I wonder whether more of it ought to go in discussion (or a new draft), however. For I'm struck by this: On Sun, Nov 12, 2017 at 06:42:18PM -0800, Paul Vixie wrote: > > always be generated using only local data, and either contains the > > answer to the question or a referral to other name servers "closer" to > > the desired information. > > the operative phrase is '"closer" to'. this is repeated in 4.3.1: If I ask the authoritative server for example.com about a name label.example.net, in a graph-theoretic sense the NS RRset for the root zone is clearly closer to label.example.net than anything else I can give. So the upward referral doesn't seem prohibited by this at all; on the contrary, it seems like a requirement. Maybe I need to read this again with better glasses. The current approaches 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
Hi, On Sun, Nov 12, 2017 at 06:04:06PM -0800, Paul Vixie wrote: > > they must be ignored, because they could constitute part of a referral loop. > valid referrals are to descendants not ancestors or cousins. […] > we should note that an upward or sideways or other non-downward referral is > a sign of misconfiguration and must be treated as SERVFAIL. I am a little uncomfortable with using this document to specify protocol behaviour as opposed to specifying protocol behaviour already specified elsewhere. I may have missed them, but I am not sure either of these requirements (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)
On Sun, Nov 12, 2017 at 09:18:31PM +0800, Stephane Bortzmeyer wrote: > This is an upward referral and I tought it was frowned upon since the > ISPrime attack (MUST NOT? SHOULD NOT?) > <https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful> I tend to agree, but 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Clarifying referrals (#35)
Dear colleagues, In github tracker issue #35 (https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/35), we have an item about the way Referral is defined in RFC 7719. The issue mostly comes from the (as usual incisive) observations of Tony Finch. I think he's right. I think a change is in order, but I'm not fully convinced of the following text, so that's why I'm putting it here for discussion. My co-editors do not deserve the brickbats, so fling them at me. There are questions at the end of this proposed text, because there are two issues about which I am very much in doubt and I'm too lazy to convince myself of the right answer when I can just ask everyone. ---%<---cut here--- Referral: A type of response in which a server, signalling that it is not authoritative for an answer, provides the querying resolver with an alternative place to send its query. All referral responses follow the same form. The response has the AA bit cleared. It has an empty Answer section. It has an Authority section containing an RRset in which the owner name is the referred-to zone, the class is the queried class, the type is NS, and the RDATA holds the nameservers for the referred-to owner name as known by the responding server. The response might also have an Additonal section containing glue records. There are two types of referral response. The first is a delegation referral (sometimes described as "delegation response"), where the server is authoritative for some portion of the QNAME. The Authority section RRset's RDATA contains the name servers specified at the zone cut. In normal DNS operation, this kind of response is required in order to find names beneath a delegation. The second is a non-delegation referral (sometimes described as "referral response", as distinct from the delegation response above), where the server is not authoritative for any portion of the QNAME. In this case, the referred-to zone in the Authority section is usually[1] the root zone (.). In normal DNS operation, this kind of response is not strictly speaking required to work, and in practice some authoritative server operators will not return referral responses beyond those required for delegation. ---cut here--->%--- First, on [1], it seems to me that in principle it ought to be possible for this sort of referral to refer to something other than . , but I can't come up with an example where it happens or really ought to happen. Is this case actually necessarily a referral to the root? (In that case, also, the name of this type should be "root referral", I guess?) Second, is there any circumstance in which glue in a non-delegation referral ought not to be treated as possible poison, and just thrown away? It seems to me that a root referral ought automatically to cause the resolver to go to the results of a priming query and follow that chain. No? Also, maybe that's not a terminological issue, and so it ought to 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
On Thu, Sep 21, 2017 at 07:31:29PM -0700, Paul Vixie wrote: > we can, if we wish, continue to standardize one protocol, watch as the world > deploys a different one, and still pretent that our effort was worthwhile. > however, this would fit the technical definition of "insanity", and i urge > that we avoid this course of action. […] > we need a kernel option for various open source operating systems which > causes all UDP to be fragmented at 512 octets of payload. If working on a protocol that merely depends on certain middleboxes eventually die is "insanity", 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
Hi, On Wed, Sep 20, 2017 at 09:50:24PM -0700, Paul Vixie wrote: > > what we have to do is arrange to fragment, using the > ipv6 extension header, all ipv6 udp, for a period of not less than five > years. noone who blocks ipv6 extension headers should be able to get > reliable ipv6 udp services. we have to make this problem felt where it is > made. we must NOT work around it to insulate the makers of the problem from > the costs of their actions. I think that the above suggestion needs to define carefully who "we" is in each sentence. Because I am very far from convinced that the "we" in each case is the same people, and also very far from convinced that we are going to be able to "make" this happen, given our lack of protocol police. Operators have one incentive, which is to make their customers stop calling; if our plan 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
Hi, The conversation on QNAME went quiet some time ago, so I thought it might be a good time to send a proposal about what to say about this term. I haven't passed this by my co-editors, since it seems like we're going all to need to discuss anyway. Here's the old text: QNAME The most commonly-used definition is that the QNAME is a field in the Question section of a query. "A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match." (Quoted from [RFC1034], Section 3.7.1.) [RFC2308], however, has an alternate definition that puts the QNAME in the answer (or series of answers) instead of the query. It defines QNAME as: "...the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME. The last CNAME in this sense is that which contains a value which does not resolve to another CNAME." Here's a proposal to replace it: QNAME The most commonly-used rough definition is that the QNAME is a field in the Question section of a query. "A standard query specifies a target domain name (QNAME), query type (QTYPE), and query class (QCLASS) and asks for RRs which match." (Quoted from [RFC1034], Section 3.7.1.). Strictly speaking, the definition comes from [RFC1035], Section 4.1.2, where the QNAME is defined in respect of the Question Section. This definition appears to be applied consistently: the discussion of inverse queries in section 6.4 refers to the "owner name of the query RR and its TTL", because inverse queries populate the Answer Section and leave the Question Section empty. (Inverse queries are deprecated in [RFC3425], and so relevant definitions do not appear in this memo.) [RFC2308], however, has an alternate definition that puts the QNAME in the answer (or series of answers) instead of the query. It defines QNAME as: "...the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME. The last CNAME in this sense is that which contains a value which does not resolve to another CNAME." This definition has a certain internal logic, because of the way CNAME substitution works and the definition of CNAME. If a name server does not find an RRset that matches a query, but it finds the same name in the same class with a CNAME record, then the name server "includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record." ([RFC1034] Section 3.6.2). This is made explicit in the resolution algorithm outlined in Section 4.3.2, which says to "change QNAME to the canonical name in the CNAME RR, and go back to step 1" in the case of a CNAME RR. Since a CNAME record explicitly declares that the owner name is canonically named what is in the RDATA, then there is a way to view the new name (i.e. the name that was in the RDATA of the CNAME RR) as also being the QNAME. This creates a kind of confusion, however, because the answer to a query that results in CNAME processing contains in the echoed Question Section one QNAME (the name in the original query), and a second QNAME that is in the data field of the last CNAME. The confusion comes from the iterative/recursive mode of resolution, which finally returns an answer that need not actually have the same owner name as the QNAME contained in the original query. To address this potential confusion, it is helpful to distinguish between two meanings: QNAME (original) The name actually sent in the Question Section in the orignal query, which is always echoed in the (final) reply in the Question Section when the QR bit is set to 1. QNAME (effective) The name actually resolved, 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS names for local networks - not only home residental networks ...
Hi, On Fri, Sep 01, 2017 at 10:01:38PM +0200, Walter H. wrote: > > Internal networks should either use a subdomain of the > > company's public domain, or register a second domain for internal use. > > > such a registry where you can register domains for internal use doesn't > exist ... > not one registry is willing to give me a domain - even when I pay for this - > which I only use in a LAN, > and the authoritativ DNS servers would then just be 127.0.0.1 or ::1 I respectfully disagree. You could register any domain you like today and fence it off just 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 companies! Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf
Hi, On Thu, Aug 03, 2017 at 03:36:24PM -0700, Dave Crocker wrote: > deal with that fully, in a single spec produced an especially confused > draft, roughly 10 years ago. I _think_ I may be one of the people who complained at the time, and if I recall correctly what Dave and I agreed about (maybe the only thing) was that this was all a terrible mess that needed repair. At the time, I was still too much in thrall to data-theoretic approaches to give in on Dave's pragmatic answer. And I now see that Dave has actually described better than I was ever able my objection: > I've come to the conclusion that "accommodating" the established > registration practices is a fundamentally wrong path. The only way to solve > a problem of multiple registration authorities is to create a single > registration authority. Yes. >1. Have this document define the simple, sole, authoritative mechanism > for registering "top-level" (global scope) underscore names. > >2. Create a separate document that specifies modifications to the SRV and > URI documents, rationalizing the use of underscore names, through the > mechanism defined 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
On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote: > > But it's certainly another step along the way to DNSbis by accident. > > Would it be useful to make it not "by accident"? Yes. That was basically the point I was trying to make at the beginning of today's 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 fruit? 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
On Thu, Jul 20, 2017 at 06:45:25PM +0200, Ondřej Surý wrote: > Is this useful for DNS at all, or is this targeted at DNS-SD only? I can think of at least one way it would be useful. Large authoritatives often have a clear population of query sources that ask a lot -- the "top talkers". It would be excellent if those clients stood up TCP connections and kept them in place because then (1) the server could treat their TCP connections as long-lived and (2) the server could treat new UDP packets from those IPs as suspect. The current TCP handling makes this mostly suck, and 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)
Dear colleagues, On Mon, Jul 10, 2017 at 06:16:53PM -0400, Shumon Huque wrote: > negotiation from the beginning, fail open would not have been necessary. > This fail open behavior frequently takes people not in the DNSSEC club by > complete surprise. I've lost track of how many "WTF" moments I've had to > explain to other people about this behavior. DNSSEC is mostly like that. I think it is because most people used to security extensions are used to them in end to end protocols, and used to failing when the arrangement is not end-to-end. For instance, people also express astonishment that DNSKEYs don't expire. Everyone always has to be reminded that signatures expire, and if you want to expire keys you take them out of the zone. This is not to say, "Stupid users," but instead to say that at least _part_ of the reason DNSSEC violates a lot of expectations is because DNS does. People continue to believe, for example, that there's always one authoritative server, one recursive, and one stub. We all know that's _also_ a bad model, but it's mostly good enough except when it isn't. So, I think one can sympathise completely with the "WTF" 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"
On Thu, Jul 20, 2017 at 02:34:48PM +0100, Tony Finch wrote: > This basically means that BULK is a master-only feature, which implies > that there's no need for BULK to work across zone transfers, which implies > the need to standardize it for interop is almost nonexistent. I don't think that follows. The DNS market is, like the mail market did some while ago, undergoing a period of consolidation in which a fairly small number of people have a very large number of dependent customers. Unfortuantely, whereas mail is asynchronous, DNS is effectively synchronous: if the provder has a bad day and you can't get an answer the site is down. This means that customers want to have multiple different vendors as their master, and they want the secondaries of those sources to offer as much as possible the same features, even when various DNS Tricks are in use; and they want the downstreams to be using standard protocols. The more we can make interoperate to support that, the better off those users are. It is possible this is not a case that will work for that (see John L's note), but I think the argument that master-only features don't need to surive zone transfers is mistaken. 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
Hi, On Tue, Jul 18, 2017 at 05:09:00PM +0100, Tony Finch wrote: > In my view an authoritative server which does online signing and on-demand > record synthesis is a master server. You can make all your public > authoritative servers into masters if you like, but it must not be > required. > > If (like me) you have a more traditional setup then ANAME is an > instruction to the master server about zone maintenance, saying that it > needs to periodically update the sibling A and records, similar to > periodic re-signing, or as if some script were periodically `nsupdate`ing > the records. The secondary servers can continue to work the same as they > do now, but they'll work better if they know about some helpful additional > section rules for ANAME. I think I (at least mostly) agree. One possible way to sort out these bits of potential confusion is to break the problem up into conceptual parts, so that one can see the way that they work together. One part is, "How do you give this instruction to the master server(s)?" It covers representation in the master file format, what a master is supposed to do on input, how to refresh the data, and so on. A second part is, "How do you give this instruction to a slave?". This covers transferring zones, the trade-offs in handing the slaves the ANAME vs the "resolved" records, refresh timers and so on. DNSSEC considerations at least are split between these, which suggests to me that these topics could be covered by one document in two parts; but these are nevertheless separate and separable functional questions. A third part has to do with downstream resolvers and caches and so on. This is really a separate problem: how to handle ANAME-aware vs ANAME-unaware systems, the consequences of an ANAME-unaware cache ending up with an ANAME in the cache, the effects of having an A and not in cache,A fourth part, which might be yet a separate problem or might be the same document, is what this all looks like from a stub and what happens when there are chains of forwarders and caches and so on with a mix of ANAME-awareness and -obliviousness. I still think that in addition a clear description of why this is hard would be helpful. The troublesome thing about Stupid DNS Tricks is that they're always >80% there, and all the really hard parts are in that last <20%, and the difficulties in those <20% cases are manifold and completely unexpected when you think in the abstract cases. The people who worked through all the gnarly problems of caches and the interaction with DNSSEC already went through this once (I came in at the tail end and mercifully missed most of that), but we're about to revisit those problems for a different set of questions. I think we need to understand why this is more complicated than it looks, and I think any future implementer will need a clear guide to that also. ### WARNING: IETF ADMINISTRATIVE WRANGLING AHEAD ### Since there's been talk about an interim, it strikes me that the current issue is the sort of specific topic that deserves one. But I also wonder whether this isn't bumping up pretty hard against the DNSOP charter, and whether this mightn't be a case where we put together a tightly focussed statement of work that gets chartered as a WG, with a plan never to meet (or to meet only as "part of" a DNSOP meeting or something like that), if only to avoid pain and misery when the documents describing all this go to IETF LC. I am not interested even a little 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
On Mon, Jul 10, 2017 at 11:14:26AM +1000, Mark Andrews wrote: > b) For DNS tools to add support for allocated data types within X >months of them being assigned by IANA. Allocated types are >supposed to have stable wire and presentation formats. > > for a reasonable value of X (<= 12?). With all due respect, that sounds like you want to make some sort of expectation of people on the Internet -- one requiring that they spend time or money or both to solve a problem that they apparently don't have. If they _did_ have it, they would already be solving it. For instance, infrastructure operation on the Internet provides thin profit margins. If a customer requires a lot of attention or hand-holding then the profit margin on that customer can disappear pretty quickly. Therefore, it is of critical importance to have a lot of automated checking in place that ensures that the customer's expectations are met. Tools to smooth the rough edges need to be foolproof -- customers don't want to do "rocket science" or even "appliance science". The tools must not only to handle a user's input, but to be able to be pretty confident that it is going to do something like what they wanted it to do (or else give them a hint). Otherwise, the angry customer contacts support and wipes out the profit on them. The natural consequence of that is just that the more obscure RRs are just not going to be supported in those kinds of tools. The risk to companies' reputations and customer satisfaction is too great for the meagre reward. Is this bad for the Internet? Yes. But that's what you get in a system that depends on voluntary participation: sometimes other people don't want to play your game, and unless it seems like it will be rewarding enough most of them aren't even going to bother asking what the rules are. And that's just for RRTYPEs. There is no evidence whatever that a new CLASS is of any utility at all to anyone except maybe DNS nerds. It is ridiculous to claim that everyone else on the Internet is wrong and, if they would just do what we say, everything would be good. The Internet did not eat every other communication technology because people found it hard to follow the Official Rules Made Up By Netgods. It took over because it worked well enough for most people most of the time without too much effort. Everything 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)
Hi Mark, On Wed, Jul 05, 2017 at 09:33:15AM +1000, Mark Andrews wrote: > > draft-sullivan-dns-class-useless has lots provably invalid assumptions > in it that it is worthless in determining if new classes could be > deployed. What are the "lots of provably invalid assumptions in it"? As far as I know, I incorporated changes that were an attempt to address comments you sent me; perhaps I didn't understand you at the time. But this is the first time I've ever heard about provably invalid assumptions. Anyway, I abandoned the effort because it became clear to me that there wasn't going to be any consensus around this: there were too many people too wedded to keeping classes around despite the obvious problem that they haven't actually been used when the obvious opportunities arose. I cheerfully predict that the DNS will be replaced before we ever have a 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 list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt
On Wed, May 31, 2017 at 07:44:46PM +, Edward Lewis wrote: > I ask because of the issues raised in the thread regarding the number of keys > assumed in the operation. Automated Updates apparently (to me) was defined > with more than one active secure entry point in mind, but in practice, the > only operating example I've witnessed of Automated Updates relies on a single > active secure entry point. > Remember that when DNSEXT selected the TA rollover mechanism, many of us believed that signing the root was a pipe dream akin to the single trust anchor for the RPKI. 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
On Tue, May 02, 2017 at 03:03:15PM -0400, Lee Howard wrote: > >Do you have a reference for the following statement > >Serving ads: "This host is probably in town.province." An ISP that does > >not > >provide PTR records might affect somebody else's geolocation. > > No. Given the privacy considerations, I¹ve changed the example from > ³x.town.province² to ³string.region² and added privacy considerations. So > I need to fix this text anyway. > > > > > >Extracting geo information from reverse DNS is very hard. As far as I > >know, > >geo location services for IPv4 mostly rely on other sources. > > That¹s probably true. Given that I need to update it to match what it says > in the Privacy Considerations section and the examples, should I just > remove mention of geolocation? Or should I tweak 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 how they use this, but I can testify that it is in fact used that way. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Digest, Vol 125, Issue 31
On Thu, Apr 13, 2017 at 02:41:20PM -0400, Viktor Dukhovni wrote: > What I should have said is that the variant with the upper case > first letter is invalid (as opposed to being "different") in > IDNA2008. This is IMHO a poor user interface, so running code > will generally go with UTS#46 (increasingly non-transitional) > mappings. Yes, everyone _knew_ it was troublesome. But you can do that case folding operation without embracing all of UTS#46 and getting some of the problems, too. The basic problem with UTS#46 is that it contains a number of quite good ideas and some things that are harmful. Worse, the embrace of something like it by WHATWG has caused even more trouble, because the answer that one gets from WHATWG any time one raises any of the issues with their stance is that "nobody uses" the problematic cases, and so they don't count. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Status of IDNA
On Thu, Apr 13, 2017 at 02:39:36AM +, Viktor Dukhovni wrote: > > Well, IIRC they sensibly converged on a case-folded normal form > that ensures that https://Духовный.org maps to the same underlying > wire-form domain as https://духовный.org, i.e. both result in > queries for xn--b1adqpd3ao5c.org. AFAIK, those would generally be > different domains under IDNA2008. They would be different domains because the first of them is DISALLOWED. But everyone knew, when making IDNA2008, that removing the case mapping from the protocol meant that clients needed to do it before starting. That's what https://tools.ietf.org/html/rfc5895 was all about (a document that could have moved faster if some participants had collaborated more enthusiastically instead of, well, going away and making their own protocol). One of the problems we had with IDNA2003 was that the protocol did the caseFold operation. The difficulty there was that there was no way to pay attention to locale or other information that might tell you the right thing to do, because caseFold is not nearly as simple as ASCII always pretended it was. IDNA2008's answer was to kick this problem out of the protocol and into user agents, which were supposed to do this in a sensible way. If UTS#46 had restricted itself to that kind of job, it could well have been an enormous contribution to the practical use of IDNs. Unfortunately, it didn't do just that. > While is true that UTS#46 maps <U+1F4A9>.org to xn--ls8h.org, (see In the way I'm using the term, that's not mapping, that's re-encoding. The idea of "mapping" is to substitute in some more or less predictable way some set of Unicode code points for some other set of Unicode code points. Then you can run the resulting final string through the IDNA2008 algorithm. The problem with treaing U+1F4A9 as an acceptable character for an identifier is not in itself -- maybe it is fine on its own -- but that it is part of a class of characters that do not have normalizations and are not letters or digits. The IETF took seriously the advice from UTC that we should use the stable categories that UTC had invented, and derive our properties from those. We did so, and no emojis are in the categories that we used for the derivation. It is therefore more than a little frustrating to see the same UTC now recommending that such characters be used in identifiers on the network. Such use is particularly bad with emojis because they have no normalization either, and they interact in some ways with ZWNJ. They provide a completely new playground for attackers to use in phishing and so on, and we already have _enough_ trouble with that without inventing new ways to cause ourselves grief. Anyway, I doubt very much that DNSOP is the list where this ought to be discussed (idna-update is still an open list, as is the IAB's i18n-discuss list even though the program is closed, and precis is still an active WG last 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
On Wed, Apr 12, 2017 at 03:47:14PM +, Viktor Dukhovni wrote: > Just move on to non-transitional UTS#46. Given that its mappings include many emojis, which aren't allowed under either IDNA2003 or IDNA2008, I think there is an apparent problem with UTS#46 too. One might be forgiven 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
Accidentally sent this just to Florian. Fixing that. On Wed, Apr 12, 2017 at 01:36:49PM +0200, Florian Weimer wrote: > What's the current standardization status of IDNA? It's complicated. > As far as I can tell, a lot of vendors are still stuck with the original > IDNA standard (IDNA2003). Well, not exactly. IDNA 2003 is defined only for Unicode 3.2, which nobody has used for a long time. So strictly speaking, what most of those vendors are doing is undefined, since there's no way to know what version of Unicode you have installed. Bur practically, of course, this is what's happening. > There are three or more competing successors, > IDNA2008 as standardized by the IETF (without any tweaks), the Unicode IDNA > standard TS46 (<http://www.unicode.org/reports/tr46/>, which is configurable > and allegedly compatible with IETF IDNA2008, but is not because it yields > different results than IETF IDNA2008), and the Mozilla/DENIC IDNA > implementation in Firefox/Thunderbird > (<https://bugzilla.mozilla.org/show_bug.cgi?id=479520> and other sources). UTS#46 is allegedly a transitional technology that is supposed to do mapping so that things that did work in IDNA2003 but that won't under IDNA2008 will continue to work. As a practical matter, it does not appear to have a mechanism by which the transition can be brought to an end, so it's hard to see it as an actual transition mechanism. It's also hard to understand why it has so many characters marked as "valid" that are not valid under any version of IDNA, including many emojis. > These aren't compatible. You can see this by visiting > <https://www.buße.de/> in different browsers. Yes. > Is there an ongoing effort to reconcile application behavior? Different > TLDs appear to expect different IDNA implementations. ICANN's rules require IDNA2008. There is a new version of the guidelines out -- I can't recall whether the public comment is closed. Many ccTLDs voluntarily conform to the guidelines also, but ICANN can't compel it. And of course ICANN has no control of other things down the tree. Part of the trouble comes because the WHATWG is apparently opposed to IDNA2008, partly on the grounds that it makes some domain names that were valid under 2003 invalid. > One practical problem with IDNA2003 is that it prevents having Hebrew domain > names containing ASCII digits. Any of the IDNA2008 variants mentioned above > will fix that, I think, but it's difficult to pick a variant to implement. > And I certainly don't want to implement per-TLD policies. Another practical problem with IDNA2003 is that it loses information round trip: Unicode can be sent into the algorithm, turned into Punycode, and when it is turned back into Unicode the result is not the same. ß is mapped, for instance, so you get back "ss" whatever you put in. This issue is one of the main things that IDNA2008 fixes, in my opinion: 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 on a draft to try to fix that. 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-alt-tld
Hi, Thanks for the review. On Sat, Apr 01, 2017 at 03:17:27PM -0500, Stephane Bortzmeyer wrote: > Editorial : > > Section 1: > > "and that should not be resolved" I cannot parse it. Missing "it"? Yes. > > Section 5 : > > After "and anyone 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 just an example. Yeah, we should move it. Thanks. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] algrithm-update table
Hi, Further to the comments I made at the mic today, I didn't dig into the history on this, but the syntactic agreement that we finally came up with when we had this bunfight years ago was is in RFC 6944. The idea a the time was that we'd product updates of that. The publication date claims 2013, but I recall the fight happening in 2012. The datatracker might say more -- Pete Resnick held the discuss on this for a long time. The table there is on p 3. If you update that document, it will avoid the table fight. I personally like the table format better too, but it was painful to go 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
Hi, On Thu, Mar 23, 2017 at 08:34:14AM -0400, Ted Lemon wrote: > > The working group is aware of the "wait many years" part of this approach, > and is willing to try and see. If the working group sees no progress over > the course of the next few years, we may shift to the latter approach. > As a comment on the document, then (that is what we're discussing, right?), I'd note that the plan for allocation of a special-use name contained in the draft does not state clearly (at least in my reading) whether it is conditional on receiving the relevant unsigned delegation. 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 Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
On Wed, Mar 22, 2017 at 02:00:08AM +1100, Mark Andrews wrote: > > What is the point of having a MoU that names may need to be assigned > in the root namespace if there cannot be a entry added to the root > namespace if there is a technical need to it? You are conflating "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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] .arpa
Hi, On Wed, Mar 22, 2017 at 09:19:24AM -0700, Ray Bellis wrote: > Arguably I'm not "typical", but IMHO we shouldn't be designing for the > lowest common denominator. That argument is absurd on the face of it, because anyone sufficiently clueful about systems to be using ssh or hand-entering domain names is also sufficiently clueful to recognize that maybe they should use the google search result that pertains to networking rather than the US DoD. (Presumably these are the same people who have figured out that iab.org and iab.com are not the same organizations.) Therefore, homenet.arpa would work just fine for such people, there'd be no design for LCD, and also we'd get something that would work and wouldn't involve a constitutional crisis for IANA. > Either way, the Homenet WG has reached its consensus decision to request > ".homenet" rather than ".homenet.arpa". Since the point of this discussion is to inform IETF consensus, HOMENET's consensus is not the only thing that counts. It is entirely possible that HOMENET's consensus will not be the IETF consensus. > To those that say "no insecure delegations in the root zone" because > "DNSSEC is good" I don't think anyone is saying anything about that. The point is that _someone else_ gets to decide. The IETF has literally no say in the decision about what goes in the root zone itself, and hasn't since the IETF signed its MoU with ICANN. (Some argue that for this reason the IETF must never allocate a top-level label. I do not agree with them, but there is absolutely no question about whether we are in a position to decide actual registrations in the root zone.) The plain fact is that the IETF IANA considerations in draft-ietf-homenet-dot-03 makes a request of IANA that the IETF has no business making, because we are requesting an entry in a registry whose policy is controlled by someone else. It's clear that the weasel words "arrange for" are there to pretend we're not making such a request it, but the MUST NOT be 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 lifetime. Best regards, A (speaking, of course, for myself) -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
Hi, On Mon, Mar 20, 2017 at 01:14:25PM -0400, Ralph Droms wrote: > Russ - In my opinion, the special-use domain registry is not being > used to put the name in the root zone. The observation is that the > special-use definition of this TLD requires both an entry in the > special-use domain name registry, and an entry in the root zone I am having a hard time making the above two sentences consistent. This special-use case requires an entry in the root zone, and so by definition the entry into one (the special-use registry) with processing rules that require normal DNS processing, 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...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
On Mon, Mar 20, 2017 at 06:19:45PM -0400, Paul Wouters wrote: > I am assuming that if stubs are validating, then they must also support > excluding special queries from validation, such as mDNS, .onion and > .homenet. > What possible basis do you have for this? This is in effect a requirement that every validating stub (or resolver? I dunno) be upgraded to support homenet. That _might_ be ok, but it's not in the design parameters of the original work AFAICT. > The .homenet queries should never reach real DNS servers But they're going to. We've had local since at least the neolithic age, in Internet terms, and yet the global DNS still sees those queries. > not think an insecure delegation in the root is required. If the DNS > resolver doesn't know how to handle .homenet, it is already as wrong > as it can be, regardless of the type of answer. 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 a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
Hi, On Sun, Mar 12, 2017 at 10:35:19PM -0700, william manning wrote: > Joel, > > I'd be happy to see the document proceed under two conditions: 1) it > becomes a WG document, subject to IETF change control Without my IAB hat on, I should think that is self-evident. If a WG adopts a document, it's a WG product and the WG (and thereby IETF) gets change control of the document. This is why the WG editors (called "authors") of the document can be replaced at the pleasure of the WG chairs. > enclave that is NOT part of the open Internet. Adoption and acceptance of > this draft is an acknowledgement that the IETF, the IAB and ISOC reject the With my IAB hat on, this WG is not in a position to make any claims about what the IAB does or does not reject. IAB positions are not subject to IETF consensus; the IETF is able to remove IAB members if it wishes using the recall procedures, but it cannot decide what the IAB is or is not going to say. (I suspect the IETF is not in a position to make claims about ISOC's views, either, but I will allow ISOC to speak for itself.) Therefore, even if I supported the disclaimer, which I do not, the WG could not add 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.
On Tue, Feb 07, 2017 at 10:01:23AM -0500, Bob Harold wrote: > What I envision for the future is an insecure delegation of .alt, and an > option in future cable modems to enable a local "homenet.alt" domain, which > would just work, even if some stub resolvers in the house are validating. > The cable modem is already a recursive resolver or forwarder, and dhcp > server, so it seems a logical place for the local domain. No, it won't just work if a stub is validating, because the validating stub will want to validate the delegation from the parent, and that will be a proof of non-existence. Provable non-existence prevents you from being poisoned through typosquatting, but it means you can't inject things in the tree without co-operation from the parent. This is part of why I don't want to extend alt this way, and the more I think about it the less desirable it seems to me. We have a particular problem: non-DNS-protocol switching for applications that want to use a DNS-compatible domain name slot (see RFC 5890). This is problems like onion, local, and so on. We propose a solution in which we steal four of the available 255 octets to create a "safe" space from DNS delegation. Now anyone can use that space for their non-DNS protocol, and every resolver library in the world knows that if it runs into a name in the alt tree it shouldn't need to look it up in DNS. If the query leaks to the root and gets a proof of non-existence, it doesn't matter because it was supposed to be a different protocol. Non-existence in the DNS is analytically true. If a validating resolver gets an answer back from another resolver that provides NXDOMAIN without the proof of non-existence and treats the result as bogus instead, who cares? It was never supposed 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ALT-TLD and (insecure) delgations.
On Wed, Feb 08, 2017 at 12:36:23PM -0800, Brian Dickson wrote: > So, while technically the instruction (SHOULD NOT) applies to full .onion > names, > it is a SHOULD NOT, not a MUST NOT. Note also that the original request was that it be a MUST NOT, and some of us tried to explain that RFCs do not actually determine what people may do and it's the Internet, and so you couldn't make a requirement in one RFC that would be guaranteed to be implemented by those who don't implement that RFC. Which means that the restricton is a stupid one. The result was a compromise in which it says "SHOULD NOT". In this case, the pretty good reason not to implement the restriction is that the Internet doesn't work the way the people who wanted onion to work thought it did. Any name under alt -- which is, rememeber, _supposed_ to be the protocol switch in the way Warren and I originally were thinking -- should never get looked up in the global DNS. If it does, that's because someone is trying to use a name that contains right in itself an indication that it needs an alternative resolution context, and not having that resolution context available. It might be that 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.
On Sun, Feb 05, 2017 at 12:26:08AM +1100, Mark Andrews wrote: > > Given there are no rules for this type of namespace Which "type of namespace" do you mean? I think there are three possible namespaces you're talking about: 1. Domain names. There are rules for these, though they're possibly underspecified. The IETF now has change control over the namespace definition documents (though the creation of said namespace predates the IETF). For this reason, the IETF was in a position to create the 6761 registry and thereby establish that there are some domain names that are treated specially. 2. Domain names that are candidates for some DNS zone. There is a policy authority for these, and it's the operator of the zone in question. Its rules for that zone apply. In the case of the DNS root zone, the policy authority for that zone is the names community as expressed through ICANN. (Similarly, I am the policy authority for the crankycanuck.ca zone, and if you want a delegation in there you can talk to me.) 3. Domain names that are _not_ for use in the DNS. This is one of the purposes of 6761, though perhaps not the only one. So far, the rules for these have been mostly underspecified, though I think 6761 gives pretty compelling reasons why it's a good idea at least to register the use there. The trouble we seem to be having is that we want something that is in (2) but with no single policy authority for the zone. It is not clear that we have a way to do that if we start from the root. We _might_ have a way to do it if we start from arpa, since the IAB is in charge of arpa and doesn't have the policy problems that ICANN does. The alt draft that Warren and I worked on was 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...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ALT-TLD and (insecure) delgations.
On Fri, Feb 03, 2017 at 08:58:43PM -0500, George Michaelson wrote: > sorry to be thick, but.. can we have both on a case-by-case basis somehow? Well, if the stub that is going to query in this namespace _knows_ that it's special, then it also knows not to validate it too. So that's not a problematic case, and the provable denial of existence from the root isn't an issue. So the only question is whether this has to work properly for any random resolver doing normal operations -- is this like RFC 1918 for the DNS? If we want that (and for homenet, for instance, that's basically the 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/mailman/listinfo/dnsop
