Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
The current draft is hand-wavy when it comes to which transports DSO can run on. Section 2 says "such as": The term "connection" means a bidirectional byte stream of reliable, in-order messages, such as provided by using DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. Section 4.1 says "are suitable": Standard DNS over TCP [RFC1035][RFC7766], and DNS over TLS [RFC7858] are suitable protocols. The document should explicitly list which protocols are currently acceptable, and say that the list can change in the future based on standards-track documents. Proposed wording for both of these above are: Section 2: The term "connection" means a bidirectional byte stream of reliable, in-order messages. Section 4.1 says "are suitable": DSO MUST be run as standard DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. This list might expand in the future, such an expansion MUST be in standards-track RFCs. Having developers know exactly which protocols can be used is important so that they do not use protocols that they accidentally think are reliable and in-order. For example, the DOH WG is working on a protocol that might initially seem attractive, but it does *not* qualify for DSO. --Paul Hoffman ___ 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
The problem is that search lists are being applied when “localhost” is being entered into name lookup APIs and is being matched against localhost.example which isn’t expected to to a address on the current machine and that the search list may be auto constructed or come from a untrusted source. There is also a small risk that hotspots will return something other than a local address if a address lookup for .localhost is made. This is all in the context of processing urls. Localhost is the last remanent of the pre hierarchical host scheme. The risks are eliminated if the name APIs use local lookup sources in those contexts. Then you have legacy clients. As long as the servers for the namespace on the public Internet don’t return A or records for localhost the issue is addressed there. You then have the recursive server where you would like it, by default, return a answer without contacting the root servers. The only safe way to do that is to have it serve a empty zone for localhost. As this zone isn’t linked into the global DNSSEC chain of trust the root zone needed a insecure delegation for localhost. -- Mark Andrews > On 3 Feb 2018, at 05:25, Bob Harold wrote: > > >> On Thu, Feb 1, 2018 at 4:26 PM, Ted Lemon wrote: >> On Feb 1, 2018, at 2:48 PM, Andrew Sullivan 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) >> >> Yes, I will admit I was a bit surprised that you put it that way, although >> as you say, your position is more clear in your formal review of the >> document. >> >> 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. You are a much more experienced DNS expert than I am, so for me >> to argue you away from those opinions is a tall order—I don't think you've >> really expressed the underlying belief that is the keystone to the whole >> edifice. >> >> 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. We've had that >> discussion before. We even published a document about it, which hasn't >> quite made its way out of the RFC editor queue yet. It seems to me that it >> is demonstrably the case that these two sets are disjoint. >> >> 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. So if we were to >> succeed in understanding why we disagree on this point, it would be >> necessary to dig down into that. >> >> Having seen you give keynotes at the plenary, I know that you are deeply >> concerned about computer security. The reason that I am in favor of the >> behavior I'm propounding is that I think it closes a small security gap >> through which a truck might some day be driven, to our woe. So to me, the >> need to leave that gap, which I admit is small, open, seems inconsistent >> with what I know of you. >> >> So clearly you value this idea that localhost is a name that exists in the >> DNS, even though it doesn't exist in the DNS. It might be fruitful to >> explore that further. It might also be a waste of time. I don't honestly >> know. But that is, I think, the key to our disagreement. > > > Could someone explain the security problem? If it really is bigger than the > problems that will be caused by changing resolvers to answer with NXDOMAIN, > then you might convince me. > > -- > Bob Harold > > ___ > 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] the ??-- thing (was Re: I-D Action: draft-huston-kskroll-sentinel-04.txt)
On Thu, Feb 1, 2018 at 4:37 PM, Paul Hoffman wrote: > On 1 Feb 2018, at 13:20, Andrew Sullivan wrote: > > 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? >> > > > > As a note, this is related to but different from < > https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf>, which has been > expired for four months but is still a WG document. > > > I will review. -- Bob Harold ___ 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 1, 2018 at 4:26 PM, Ted Lemon wrote: > On Feb 1, 2018, at 2:48 PM, Andrew Sullivan > 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) > > > Yes, I will admit I was a bit surprised that you put it that way, although > as you say, your position is more clear in your formal review of the > document. > > 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. You are a much more experienced DNS expert than I > am, so for me to argue you away from those opinions is a tall order—I don't > think you've really expressed the underlying belief that is the keystone to > the whole edifice. > > 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. We've had that > discussion before. We even published a document about it, which hasn't > quite made its way out of the RFC editor queue yet. It seems to me that > it is demonstrably the case that these two sets are disjoint. > > 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. So if we were > to succeed in understanding why we disagree on this point, it would be > necessary to dig down into that. > > Having seen you give keynotes at the plenary, I know that you are deeply > concerned about computer security. The reason that I am in favor of the > behavior I'm propounding is that I think it closes a small security gap > through which a truck might some day be driven, to our woe. So to me, the > need to leave that gap, which I admit is small, open, seems inconsistent > with what I know of you. > > So clearly you value this idea that localhost is a name that exists in the > DNS, even though it doesn't exist in the DNS. It might be fruitful to > explore that further. It might also be a waste of time. I don't > honestly know. But that is, I think, the key to our disagreement. > Could someone explain the security problem? If it really is bigger than the problems that will be caused by changing resolvers to answer with NXDOMAIN, then you might convince me. -- Bob Harold ___ 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
[DNSOP] WGLC session-state-signal comments
(Due to weirdness with email, the WGLC announcement for me came on DNSSD and
not DNSOP. Shoulder shrug - something to debug for later.)
I was told of this last call:
referring to the document at
https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-05
Overall - the approach looks promising. I would want to see this run through
workshops to see how well it is compatible with the installed base before too
much is built on top of it. The idea of state-per-channel has long been a
taboo subject, one that I think should be broken, nevertheless, we have to
understand this change in thinking. "Corner cases" are always a concern.
Section 2, terminology
# The unqualified term "session" in the context of this document means
#the exchange of DNS messages over a connection where:
#
#o The connection between client and server is persistent and
# relatively long-lived (i.e., minutes or hours, rather than
# seconds).
#
#o Either end of the connection may initiate messages to the other.
I fear that this may cause confusion down the line, given the history of
how terms have been used in previous RFC documents.
A session to those who recall the 7-layer OSI model conjures up ideas of
end-to-end associations that make use of one or more transport"s", or
connections. I.e., a session might use multiple, parallel in time, transport
channels or may use successive in time transport channels.
In this use, the DSO session refers to the management of the transport
connection between two intermediate elements of the DNS.
# A "DSO Session" is established between two endpoints
The endpoints - is that the stub resolver and authoritative server (on in
DNSSEC terms) the signer and the validator? I believe here it is the
client-server actors for the channel.
# A "DSO Session" is terminated when the underlying connection is
# closed.
This is in conflict with the older notion of a session persisting across
transports.
To support that notion, using (for convenience):
https://en.wikipedia.org/wiki/Session_layer, this is stated
"If a connection is not used for a long period, the session-layer
protocol may close it and re-open it."
Note - this is terminology, not conceptual. However, I've seen terminology
become a greater problem "down the road" as new people come into the field.
As a suggestion I'd work in that this is "DNS channel management". It
sounds like the document is defining a DNS channel management protocol.
Or perhaps DNS transport management protocol.
Section 4.1
This section intermingles text on whether or not each DSO request elicits
a response or not and the process of DSO "session" establishment. With proper
editing, these should be separated to lessen confusion.
Section 4.1.1
Requirements (first MUST) and recommendations to operate in a certain way
tend to become dated quickly. Instead of placing requirements on clients
to act good, let the server refuse workload. I am thinking of the issue
surrounding the iterations in NSEC3 and recent surveys of operators. Despite
the documents saying a low value is better, operators use high values.
With that in mind, I'd not have "clients MUST take care". If not for the
reasoning above, then "how does one test whether a client has taken care"?
Instead, reinforce the notion that a server has the right to deny opening a
connection on its own grounds (local policy), including load considerations.
Section 4.1.3
This section reinforces the notion that this is "transport channel management"
and not "session management in the OSI layer 5 sense."
Section 4.2.1
This phrase is confusing and unnecessary "this is a fatal error". The logic
to that point is clear that the situation doesn't happen and the
prescribed behavior ("close the connection") makes sense.
This is clumsy, when describing the RCODE: "generally set to zero on
transmission, and silently ignored on reception, except". I'd suggest
saying ... well reading it again, I don't understand what the paragragh
is saying. It starts out with RCODE being 0 on send, then except when
it conveys the reason for termination...which I'd expect to be in a response.
However, it might be better to say that the RCODE value may be set according
to the definition of the request, but in most cases, will be 0. Maybe?
Section 4.2.2
" Unacknowledged
request messages are only appropriate in cases where the sender
already knows that the receiver supports and wishes to receive these
messages."
This passage causes concern in me. The entire notion of unacknowledged
requests trouble me as a protocol designer. There are three outcomes of
sending a request over a reliable transport - the receiver doesn't understand
it, the receiver acts accordingly, or the receiver misinterprets the request.
The latter includes software bugs (or other unintended consequences) and
could cover outright refusal to perform. It's not that an acknowledgement
is needed, the question is how the se
Re: [DNSOP] A conversational description of sentinel.
On Fri, Feb 2, 2018 at 4:41 AM, Petr Špaček wrote: > On 2.2.2018 09:32, Mark Andrews wrote: >> This isn’t about whether name servers load A records with non LDH names >> as they all can. >> >> The real question is do the name lookup api’s in the web browsers barf >> on non IDN, non LDH names since that is the mechanism being proposed >> for people to test this. > > Sure. Given that MS AD users underscore A records in its integrated DNS > server (at least in older versions), it is going to work with DNS > resolver distributed with Windows. This covers 99 % of clients which can > potentially be target of potential ad campaign. > > So, now, we need to test browsers... > For those who would like to test this, while not having to get their hands quite as dirty, I've added: _www IN CNAME ron.kumari.net xm--www IN A 204.194.23.4 to ksk-test.net, and have updated the JavaScript to test these as well. On Chome and Safari on both OS X and IOS I get: These below 2 tests are just for debugging / to understand browser behavior. You: were able to fetch the "underscore" record were able to fetch the "dashdash" record Surprisingly, on Chrome on Android and Samsung Internet (the browser on Samsung Galaxy Note devices) I get: These below 2 tests are just for debugging / to understand browser behavior. You: were **NOT** able to fetch the "underscore" record were able to fetch the "dashdash" record I must admit that I was not expecting this - can others please also test this? I personally don't really care what the labels are -- we could make it I-Heart-KennyG-is-ta-[foo] for all I care[0]. W [0]: Note: anyone who suggests a: an emoticon or b: some cute unicode hack is dead to me. > > Talk is cheap, let's get hands dirty! > > I just tested Firefox 58.0.1 on Fedora 27 > URL http://_test.example > > Result: The Firefox under test issued DNS queries > _test.example. A > _test.example. > just fine. > > nsswitch.conf: > hosts: files mdns4_minimal [NOTFOUND=return] dns myhostnam > > I do not have other desktop system at hand, so I will defer other > experiments to others. > > Please do experiments and report your results. > Petr Špaček @ CZ.NIC > >> Mark >> >>> On 2 Feb 2018, at 6:50 pm, Petr Špaček wrote: >>> >>> On 2.2.2018 07:55, A. Schulze wrote> Paul Hoffman: > My preference is #1 because, in general, a label starting with _ has > been meant for infrastructure, and that's what these labels are. > Others might like #2 so they don't have to add configuration to BIND > (and maybe other authoritative servers). just checked, my NSD and POWERDNS serve A record for _foo.examle. without noise... so: #1 >>> >>> For the record, I also like more the underscore variant (#1 above). >>> >>> BIND spits a warning about it and I like it. After all, this whole KSK >>> sentinel bussiness is quite specialized thing to do and should be done >>> only by people who know what they are doing, so warning is appropriate. >>> >>> After all, what is your guess about number of zones containing such >>> names? 10? 20 zones globally? I cannot see more, and most likely vast >>> majority of people who would like to create such zones is following this >>> dicussion. >>> >>> Please do not overcomplicate things. The technology seems okay to me. >>> (I've implemented it including tests, see Knot Resolver 2.0.0.) >>> Could we polish the text and publish it, pretty please? >>> >>> >>> (BTW I have seen underscore names with A records in Microsoft Active >>> Direcotry DNS years ago, so this is not the first time _ A is used.) >>> >>> -- >>> Petr Špaček @ CZ.NIC > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A conversational description of sentinel.
On 2.2.2018 09:32, Mark Andrews wrote: > This isn’t about whether name servers load A records with non LDH names > as they all can. > > The real question is do the name lookup api’s in the web browsers barf > on non IDN, non LDH names since that is the mechanism being proposed > for people to test this. Sure. Given that MS AD users underscore A records in its integrated DNS server (at least in older versions), it is going to work with DNS resolver distributed with Windows. This covers 99 % of clients which can potentially be target of potential ad campaign. So, now, we need to test browsers... Talk is cheap, let's get hands dirty! I just tested Firefox 58.0.1 on Fedora 27 URL http://_test.example Result: The Firefox under test issued DNS queries _test.example. A _test.example. just fine. nsswitch.conf: hosts: files mdns4_minimal [NOTFOUND=return] dns myhostnam I do not have other desktop system at hand, so I will defer other experiments to others. Please do experiments and report your results. Petr Špaček @ CZ.NIC > Mark > >> On 2 Feb 2018, at 6:50 pm, Petr Špaček wrote: >> >> On 2.2.2018 07:55, A. Schulze wrote> Paul Hoffman: My preference is #1 because, in general, a label starting with _ has been meant for infrastructure, and that's what these labels are. Others might like #2 so they don't have to add configuration to BIND (and maybe other authoritative servers). >>> >>> just checked, my NSD and POWERDNS serve A record for _foo.examle. >>> without noise... >>> so: #1 >> >> For the record, I also like more the underscore variant (#1 above). >> >> BIND spits a warning about it and I like it. After all, this whole KSK >> sentinel bussiness is quite specialized thing to do and should be done >> only by people who know what they are doing, so warning is appropriate. >> >> After all, what is your guess about number of zones containing such >> names? 10? 20 zones globally? I cannot see more, and most likely vast >> majority of people who would like to create such zones is following this >> dicussion. >> >> Please do not overcomplicate things. The technology seems okay to me. >> (I've implemented it including tests, see Knot Resolver 2.0.0.) >> Could we polish the text and publish it, pretty please? >> >> >> (BTW I have seen underscore names with A records in Microsoft Active >> Direcotry DNS years ago, so this is not the first time _ A is used.) >> >> -- >> Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A conversational description of sentinel.
On 02/02/2018 08:32, Mark Andrews wrote: > The real question is do the name lookup api’s in the web browsers barf > on non IDN, non LDH names since that is the mechanism being proposed > for people to test this. +1 - that's my concern too. The browsers that refuse to accept an underscore label might only be a small portion of the possible clients in Geoff's experiments, but it's an outcome that should be allowed for so as to prevent false readings. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A conversational description of sentinel.
This isn’t about whether name servers load A records with non LDH names as they all can. The real question is do the name lookup api’s in the web browsers barf on non IDN, non LDH names since that is the mechanism being proposed for people to test this. Mark > On 2 Feb 2018, at 6:50 pm, Petr Špaček wrote: > > On 2.2.2018 07:55, A. Schulze wrote> Paul Hoffman: >>> My preference is #1 because, in general, a label starting with _ has >>> been meant for infrastructure, and that's what these labels are. >>> Others might like #2 so they don't have to add configuration to BIND >>> (and maybe other authoritative servers). >> >> just checked, my NSD and POWERDNS serve A record for _foo.examle. >> without noise... >> so: #1 > > For the record, I also like more the underscore variant (#1 above). > > BIND spits a warning about it and I like it. After all, this whole KSK > sentinel bussiness is quite specialized thing to do and should be done > only by people who know what they are doing, so warning is appropriate. > > After all, what is your guess about number of zones containing such > names? 10? 20 zones globally? I cannot see more, and most likely vast > majority of people who would like to create such zones is following this > dicussion. > > Please do not overcomplicate things. The technology seems okay to me. > (I've implemented it including tests, see Knot Resolver 2.0.0.) > Could we polish the text and publish it, pretty please? > > > (BTW I have seen underscore names with A records in Microsoft Active > Direcotry DNS years ago, so this is not the first time _ A is used.) > > -- > Petr Špaček @ CZ.NIC > > ___ > 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
