[DNSOP] Question regarding draft-ietf-dnsop-svcb-https-10 sections 4.1 and 6
Hi all, I have a small question in respect to section 4.1 (DNS Server Behavior /Authoritative servers) and section 6 (SVCB-compatible). I have to admit that I do not yet fully understand the current draft (having neglected following the discussion on the draft in the past). So please forgive me if the answer is actually obvious. So my question is which concrete record types (besides A and ) should be returned in the Additional Section (if they exist) by an authoritative name server? * only the SVCB record type, but no SVCB compatible record? * only the same record type the from which the target is originating? * SVCB record type and any known compatible record type (as far as the type is known to the name server implementation)? Thanks in advance, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
On 21.02.20 14:44, Vladimír Čunát wrote: On 2/21/20 2:23 PM, Klaus Malorny wrote: My understanding of the plan is that for fallbacks we'll have what people are using now, e.g. that http redirect. Perhaps you can elaborate on why that doesn't seem sufficient. Hi Vladimir, simply that I want to get rid of it. IMHO one aim of a new technology should be to make old technology obsolete, esp. such workarounds. If I have to keep them (forever?), where is the benefit (for me as a company)? Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
On 21.02.20 13:19, Dan York wrote: If HTTPSVC can do that, and browser vendors will implement it [1], then that use case can be satisfied. Dan Hi all, I have to admit that I haven't worked through the HTTPSSVC/SVCB draft in detail, but while it seems to provide much more functionality than the ANAME (as it addresses other problems, too), I see a major drawback in comparison to the ANAME draft, namely that there seems to be no fallback for old browsers (and robot software accessing websites) being defined. Of course, authoritative name servers could implement a similar mechanism as specified in the ANAME draft. The question would be whether it needs to be addressed in the HTTPSSVC/SVCB specification in an appropriate manner. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
On 21.02.20 10:08, Benno Overeinder wrote: I am interested to learn what the problem is that the customer wants to solve. Quoting from the email from Evan Hunt in this thread: "CNAME at the apex wasn't really the problem. Getting browsers to display content from the right CDN server was the problem." If there is a specific use case for CNAME in the APEX (ANAME), I am really interested to learn from this. Thanks, -- Benno Hi Benno, according to my colleagues, who are in contact with the customers, the use case is mostly in the context of CDNs. Some of them maintain a larger set of domains with alternate spellings of their product names, with different ccTLDs, some for promotions etc. The content for these domains are hosted by CDNs and not by us (we are not in that business right now). They want their domains to work also without a "www." prefix, and for now we use a web redirection service. This has some disadvantages, e.g. a "heavy" extra roundtrip to an HTTP server and in respect with HTTPS support. So our problem is exactly the "CNAME in the apex" problem. HTH. Regard, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
Hi, thanks all for responding, this was very informative for me. The lack of interest for the ANAME draft is a bit pity. We have some customer requests in this direction and I was hoping to be able to offer them a standards compliant solution. So now I have to rethink our strategy. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] status of the aname and svcb/httpsvc drafts
Hi all, I asked myself about the status of the two drafts. I got the impression a little bit that the svcb/httpsvc draft successfully killed the aname draft, but is now dying slowly itself. It would be great if somebody could give me some insight whether the one or the other has still a measurable heartbeat, to stay with the allegories ;-) Thanks & greetings, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] question regarding draft-ietf-dnsop-aname: aname section & truncation
Hi all, thanks for answering my recent questions so far, but I have to bother you with another (maybe stupid?) issue. I saw that for regular address queries, you moved the ANAME record from the "answer" section to the "additional" section in the -02 draft. I tried to figure out why, but did not find an answer in the document itself or in the github issues. This might by a problem, at least theoretically. RFC 2181, section 9, says that records may be removed from the additional section without setting the TC bit if the message would get too large otherwise. So the ANAME record could get lost in some circumstances. I have not checked whether this could occur in real, with very long query names, a lot of address records, authority records and maybe with signatures (which would allow larger responses due to the DNSSEC requirements on the other hand). Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/proof of non-existence of the ANAME record
Hi all, while still struggling with the basic ANAME processing (as described in my other mail), I wondered whether with DNSSEC, an authoritative name server MAY, SHOULD or MUST prove the non-existence of an ANAME record when it receives an A or query and no sibling ANAME record exists for the delivered address records. My personal opinion is that there is no big harm if a man-in-the-middle silently removes the ANAME record from the response, as the returned address records should still point to some valid hosts, so I would not include it. In the case that there are neither address records nor an ANAME, the NSEC/NSEC3 record which covers the non-existing address record would also cover the ANAME, so this case is not a problem at all. Nevertheless, I wanted to bring this to your attention just in case that you haven't considered that already (it is not clear from the spec that you did). Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response
On 28.05.19 21:14, Matthijs Mekking wrote: Hi Klaus, Hi Matthijs, I provided responses inline. I too. On 5/28/19 5:49 PM, Klaus Malorny wrote: Hi all, [...] For authoritative servers that receive A or requests, the address records shall appear only once: in the answer section. It is correct that those address records have the owner name and TTL adjusted (to the owner name of the ANAME record and the minimum of the encountered TTLs). There is nothing in the additional section, except for the ANAME record, as described in Section 6.1.1: When a server receives an address query for a name that has an ANAME record, the response's Additional section MUST contain the ANAME record. The ANAME record indicates to a client that it might wish to resolve the target address records itself. Note that there is separate additional processing for authoritative servers and resolvers. For resolvers there is a requirement of having target address records in the additional section. [...] I am not sure what text in Section 3 you are referring to, can you quote the specific text? > > AFAICS there is nothing that says the visited ANAMEs and CNAMEs needs to > be set in the Additional section. Visited ANAME and CNAME records are > used to adjust the owner name and the TTL. Well, just the two sentences just below the headline of section 3: The requirements in this section apply to both recursive and authoritative servers. ^ An ANAME target MAY resolve to address records via a chain of CNAME and/or ANAME records; any CNAME/ANAME chain MUST be included when ^^^ adding target address records to a response's Additional section. Along with the following requirement of 3.1: o MAY contain the target address records that match the query type (or the corresponding proof of nonexistence), if they are available and the target address RDATA fields differ from the sibling address RRset. So, I can choose to add the target addresses to the additional section, but then I have to add the full path of ANAME/CNAME/DNAME(?) also. This is my interpretation. - if the name server chooses to cache the target address records (and the intermediate xNAME records), shall the answer reflect the age of the cache entries in the TTLs (i.e. be subtracted) of the records in the answer and/or additional section? There is some guidance in appendix C on this: - In principle you should use a fixed TTL (no decremented TTLs) to avoid query bunching (C.1). - If the ANAME target lookup is done inside the name server, and implements a cache, may use a decremented TTL in the response to the client rather than using the original target address records' TTL, but not a near zero TTL (C.4). Hope this helps. Ah, ok. This is helpful. Thanks for answering. Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response
Hi all, I am working on an experimental implementation of ANAMEs in our authoritative name server software, which shall perform its own ANAME lookup. I am a bit puzzled what is really expected to be returned for regular address (A/) queries. - Is it right that the determined target address records shall appear twice, first in the answer section, with the query name as the owner and the TTL adjusted (based on the involved records), second in the original form in the additional section? - It is not yet quite clear to me what the purpose of recording the visited ANAMEs and CNAMEs beyond the very first ANAME in the additional section, as described in the section 3. Is it of any use for an aware resolver? Shall it validate the path to the target addresses in order to recognize them as such? And what about DNAMEs? I constructed a nice example, despite not knowing whether such a situation would ever occur in real life: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3 ;; flags: qr aa ; qd: 1 an: 1 au: 0 ad: 5 ;; QUESTIONS: ;; multi.example., type = , class = IN ;; ANSWERS: multi.example. 2 IN fe:dc:ba:98:76:54:32:10 ;; AUTHORITY RECORDS: ;; ADDITIONAL RECORDS: multi.example. 86400 IN ANAME redir1.target. redir1.target. 2 IN CNAME redir2.sub.target. sub.target. 86400 IN DNAME base.target. redir2.base.target. 86400 IN ANAME redir3.target. redir3.target. 3 IN fe:dc:ba:98:76:54:32:10 ;; Message size: 223 bytes - if the name server chooses to cache the target address records (and the intermediate xNAME records), shall the answer reflect the age of the cache entries in the TTLs (i.e. be subtracted) of the records in the answer and/or additional section? Sorry in case that the questions do not make sense. I have to admit that I have not yet fully understood the document in all aspects. But that's why I am asking. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multiplexing DNS & HTTP over TLS
On 14.02.19 11:03, Shane Kerr wrote: Stephane, Is there a write-up on this? Thinking about it naively, a demultiplexer really only needs to say "is there a non-ASCII character in the first 2 or 3 bytes of a TLS session?". Hi, please think of HTTP/2, which is a binary protocol (although I don't know what the first bytes are). But I guess ALPN (RFC 7301) would do the trick. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] TSIG - BADKEY error handling appears to be underspecified.
On 17.09.18 02:27, Mark Andrews wrote: Actually having the clients time and fudge in those fields for BADKEY provides spoofing protection for the unsigned responses. This is especially important with opportunistic TSIG,which is what TSIG with a WKK will be, as there is no longer the presumption that server is configured for the key that there was when TSIG was originally drafted. It’s all about getting answers through acceptance filters. Hi Mark, thanks for the explanation, this sounds reasonable, I will fix our software in the next release. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] TSIG - BADKEY error handling appears to be underspecified.
On 14.09.18 00:55, Mark Andrews wrote: I was testing TSIG with a well known key against TLD servers and got the following response. Once you get past the bad class field (reported to the operator) there were a number of other items: * the tsig name does not match the request. * the algorithm doesn’t match the algorithm in the request. * time signed is not set. * the fudge value is zero. Should these match the request / be set for BADKEY? Mark Hi Mark, thanks for bringing this to our attention. I have fixed the DNS class, the key and algorithm name. For the latter two, it makes some sense to return the values from the request. Regarding the time and fudge, I have currently left it to zero, as IMHO they have no meaning without having a signature. But I am open to conviction... By the way, the parsing error of DiG seemed to be solely caused by the wrong class; after changing it to ANY, the RDATA was parsed and displayed correctly. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On 22.05.2014 03:18, Masataka Ohta wrote: Klaus Malorny wrote: Sure, but I am talking of about 5-20 variants per name, not all that are combinatorially possible. The idea is that the registrant simply decides which of the variants he wants to have included with his original name. Those would be added to the zone via redirection resource records, whatever available. When he reaches a registry given limit, he has to make a trade-off, which of the possible variants he regards as most valuable for his purpose. From my perspective, this is an acceptable compromise. OK. If it is acceptable for you, allow 1 variant per name and we are done. That people around you are happy with at most 5 or 20 variants does not mean other people needing more variants may suffer from the trade-off. A better solution is never use IDN. That, even within European (French) context, capital form of 'y' with diaeresis can be 'Y' or 'Y' with diaeresis is already bad enough for case insensitive DNS. What's the purpose of this comment? Are you saying that you don't care about real world problems? Get rid of IDNs? Learn English or die? Internet back to its roots as an academic, non-commerical network? This all would be fine to me, but unfortunately not to many people out there. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On 21.05.2014 08:09, Mark Andrews wrote: What's wrong with: _http._tcp.example.net. SRV ... www.example.net. Nothing. Hi, please take into account that a CNAME + DNAME, the previously discussed BNAME or the now discussed ENAME solution is still interesting for domain name registries that have to deal with (maybe lots of) IDN variants. I don't think that SRV records are a viable solution for their use case. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On 21.05.2014 11:52, Ralf Weber wrote: Moin! Hi Ralf, Oh and then came DNAME for redirecting whole domain trees and that might have been a nice idea if I have a couple of domains and want them all to have the same data. But I do not know of Registries/Registrars that picked that up. Or is there widespread deployment? To my knowledge, the .gr TLD registry uses DNAME besides puntCAT (.cat), in whose operation I am involved. From a technical perspective, we have not encountered problems with DNAMEs so far, but, of course, the registrants would prefer to be able to use the variant name without a subdomain prefix as well. With the new gTLDs, those customers of us who intend to offer variants preferred not to use DNAME variants, not only because of the risk of getting special attention from ICANN (extended validation), but also because of the redirection problem of the variant name itself. As the alternatives also have operational deficits as well, I do not regard it as impossible that future gTLDs would use a fully working DNS redirection or that even existing gTLDs/ccTLDs would move to that once available. But this is, of course, my humble opinion, not based on any inquiry. Now having an ENAME that initially will break all existing DNSSEC resolvers (Who can't validate any longer, because they don't support the algorithm yet) is IMHO not the right message when we want people to deploy DNSSEC and especially do validation. Well, I do not regard myself as an expert in DNS matters and cannot really estimate the impact of protocol changes, since I lack the global view to some extend (so I would have introduced IDNs as UTF-8 labels instead of the tricky, but still inconvenient Punycode, but that's another story). So my point of view is more that of a DNS user than of a protocol guru. Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On 21.05.2014 12:08, Masataka Ohta wrote: Klaus Malorny wrote: please take into account that a CNAME + DNAME, the previously discussed BNAME or the now discussed ENAME solution is still interesting for domain name registries that have to deal with (maybe lots of) IDN variants. Scalability of IDN labels of equivalent characters is exponential. Sure, but I am talking of about 5-20 variants per name, not all that are combinatorially possible. Thus, the only solution against it is to give it up. Not yet ;-) Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
On 21.05.2014 13:30, Masataka Ohta wrote: Klaus Malorny wrote: Sure, but I am talking of about 5-20 variants per name, not all that are combinatorially possible. I'm afraid you don't distinguish name and label. Anyway, what if you encounter a label with 21 variants? Are you saying registries MUST reject registrations requests for domain names, if the numbeer of variants exceed 20? Note that a single Chinese character frequently used in Japan have, at least as I quickly checked, 6 variants, which means your limit can easily and naturally be exceeded. Or, how many variants, do you think, a '-' character, which is a legal ASCII character for hostnames, have? The idea is that the registrant simply decides which of the variants he wants to have included with his original name. Those would be added to the zone via redirection resource records, whatever available. When he reaches a registry given limit, he has to make a trade-off, which of the possible variants he regards as most valuable for his purpose. From my perspective, this is an acceptable compromise. Otherwise, the only solution to cope with the exponential number of variants would be to add logic about human languages and scripts directly into the name servers that serve the respective TLD. They would have to identify the base name, and synthesize and sign respective answers on the fly. Besides the technical challenge, I am sure ICANN would not be pleased about this (thinking of zone file access, escrow and the explicit ban of redirecting unregistered names as Verisign once did, which resembles this approach). Regards, Klaus ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
