Re: [DNSOP] RFC2317 Question: Resolving cname delegation
On 8/30/2017 3:53 PM, Tony Finch wrote: Hector Santos <hsan...@isdg.net> wrote: Not expecting this in my DNS resolver code, I modified the resolver to take the CNAMEs into account and return the host names instead. Was this the correct thing to do, thus providing the same results regardless of the query location? Yes. You should also make sure your response parser isn't tripped up by DNAME records (you can safely skip them). Ok, I'm going to explore DNAME types (at least it to my resolver). See also https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis which sadly ran out of steam and stalled... Interesting. Thanks for the note. -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC2317 Question: Resolving cname delegation
On 8/24/2017 12:06 PM, Vladimír Čunát wrote: Hello. On 08/24/2017 05:46 PM, Hector Santos wrote: [...] Not expecting this in my DNS resolver code, I modified the resolver to take the CNAMEs into account and return the host names instead. Was this the correct thing to do, thus providing the same results regardless of the query location? [...] I can't see any hint in RFC2317 that resolvers should/could change the data they obtain from upstream, even if just "expand CNAMEs" (and it's only BCP RFC anyway). In particular, if the particular zone is covered by DNSSEC, you may trigger validation errors by that. You're right. But I believe it does allude to potential problems and confusion. As I study this more, the issue is this old RFC promoted unexpected cname for the qname in PTR results. My ISP is using it for delegating our new /27 segment of ips. The direct DNS server authoritive response is: qname qtype data d.c.b.a.in-addr.arpa PTR host1 d.c.b.a.in-addr.arpa PTR host2 .. d.c.b.a.in-addr.arpa PTR hostN The non-authoritive response is: qname qtype data d.c.b.a.in-addr.arpa CNAME d.X.c.b.a.in-addr.arpa d.X.c.b.a.in-addr.arpa PTR host1 d.X.c.b.a.in-addr.arpa PTR host2 .. d.X.c.b.a.in-addr.arpa PTR hostN Where X is the the first IP in the delegated IP range. Although my resolver will only return the requested PTR records, the record.name field will contain the cname. I am still studying the impact. The exploratory change in the resolver was to basically compare the name field with the qname, and set it to the qname if different. That way the clients will get the same expected results. I don't think its any different when A->CNAME->A operations is done and cached. It does not seem its going to be a impact on my SMTP clients/senders that could be setup to dynamically obtain the EHLO/HELO hostname by extracting the first record in a PTR lookup. But it could be an impact on incoming SMTP filter scripts that could be setting a PTR requirement. Not sure. It does seem safe, for our system compatibility, to make it consistent. In my opinion, the delegation CNAME is meta-data and it should be passive in the query results. Thanks for the heads up. -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC2317 Question: Resolving cname delegation
On 8/24/2017 1:31 PM, Grant Taylor wrote: Before I release my updates, I wonder if this was the right thing to do. I prefer to use a different method to do classless in-addr.arpa delegation. Specifically, I ask ISPs to put an NS record for the IP(s) in question pointing to my own DNS server. Then I configure zone(s) that match the full in-addr.arpa name with the PTR in the zone apex. You can have a separate zone (d.c.b.a.in-addr.arpa.) for each IP (a.b.c.d) -or- you can have a single parent zone (c.b.a.in-addr.arpa.) with individual PTR records, much like the ISP normally does. If you do the second method (parent c.b.a.in-addr.arpa. zone) I'd recommend that you have NS records for the other 224 IPs that point to your ISP's name server that is authoritative for the zone. In effect, you are actually delegating the IPs an additional level. This was done, at least the first part of providing the ISP the two NS servers required. They used RFC2317 to setup the cname delegation. On my servers, I had done what you suggestion with the second method using a parent c.b.a.in-addr.arpa zone. It all seems to work, except for the unexpected cname+ptr records with non-authoritive results. Still studying the impact. I was trying to prevent some consistency in the results in the resolver. In the same way, that its done for A->CNAME->A results. Thanks -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC2317 Question: Resolving cname delegation
I have a question related to RFC2317 "Classless IN-ADDR.ARPA delegation." Earlier this year, I switched from a class C bank of 256 addresses to a reduced set of 32 ips (/27). To get PTR queries to work, RFC2317 was referred by my ISP to prepare the delegation. Having implemented RFC2317, I noticed with PTR lookups directly against my own DNS server, it returns the proper host names, no cnames. When the query is done against other DNS servers, it returns the CNAME which points to the expected host name(s). This I understand is the expected RFC2317 method setup by the ISP. Not expecting this in my DNS resolver code, I modified the resolver to take the CNAMEs into account and return the host names instead. Was this the correct thing to do, thus providing the same results regardless of the query location? Reading RFC2317, section 5.1 and section 5.3, it sounds what I did was ok.' I have various PTR lookup scripts that did not expect the CNAME in the PTR query as RFC2317 indicates may happen, thus possibly failing a PTR requirement, i.e. SMTP receiver connection, etc. Before I release my updates, I wonder if this was the right thing to do. Thanks -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
On 7/25/2014 6:41 PM, Mark Andrews wrote: In message 53d2dbec.6060...@isdg.net, Hector Santos writes: We will need to tweak the code or the retry frequency table for this particular socket error, in this case 10061. To optimize, we will need to specifically look for three conditions: MX.Count == 1 and MX[0].Preference == 0 and MX[0].Exchange == . to trump, preempt any call attempt. Nuke the preference check. Count and exchange is enough. Hi Mark, Sure, but its not the true spec condition. As stated in section 3, anything else but the three conditions could be programmatically extracted to be an error some where; an exception, indeterminate condition, possible corruption, not the spec condition, a how can this happen situation. What does an diligent, high QA conscious coder do? Being Specific Is Terrific! If the preference can technically be any non-zero value for a No Mail Service MX record, then the spec should probably make note of that in section 3, otherwise a coder may wonder and add an exception. 3. MX Resource Records Specifying Null MX To indicate that a domain does not accept email, it advertises a single MX RR (see [RFC1035], section 3.3.9) with an RDATA section consisting of a zero length label, written in master files as ., as the exchange domain, to denote that there exists no mail exchanger for a domain. The Preference SHOULD be set to zero, but implementators SHOULD NOT depend on it being zero for the NULL MX to be defined. Additional comments/nits about the draft: o Preference vs Priority An implementation note could be added: Implementation note: Some DNS record UI managers use the term Priority instead of Preference. MX expansion requires a sorted mail host order by increasing preference. The mail host with lower preferences are tried first. A Higher priority value in these UIs does not mean they are tried first. The DNS management tools I just recently used (Microsoft DNS v5 Windows GUI manager and Godaddy's web-based DNS manager) to quickly explore this used, the term Priority instead of the IETF spec defined Preference term for this MX field name. The draft has no reference to the term priority and/or the possible market, administration and technical terminology discrepancies. o No Permanent Blocks Semantics I think the draft should make a note that permanent blocks should not be extracted from an NULL MX records or the final resolution of attempts. The NULL MX condition can quickly change at any time. It is merely (to me, as I can see) an optimizer to short circuit an outbound attempt and also test an incoming message return path domain readiness for bounces/DSN which is a SMTP required mode of operation. o Security overstatement I think the security section does not need to be talking about SMTP being 'inherently insecure. Whether a site does dynamic checking or not of the SMTP session return path is the main thing here. This draft isn't removing any insecurity other than suggesting it is one way to detect the mail hosting service availability of an email domain without the need to actually try/test it. An optimizer. In fact, I think its possible that the attempt to define a NULL MX can actually nullify and learned behaver for a Implicit MX logic where there is no record at all. NULL MX is a real record and that can trigger different logic than an real NO MX record condition. For example, some MTA may have an option: [X] NO MX, Try A record ONCE TIME That was the case for our older version of MTA. The rule was relaxed (default OFF) due to the false positives. So for the modern versions, it doesn't matter anymore -- retries are based on the last SOCKET or SMTP error condition. -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-appsawg-nullmx-05.txt (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
On 7/25/2014 1:18 PM, Kevin Darcy wrote: I remain skeptical that the methodology in the draft, as written, requires no code changes, since I just performed a private experiment with a recent version of sendmail, and delivery failed in a spectacularly ugly way that made it appear much more like a bad .cf than no mail accepted for this domain. But, I'll spare everyone the gory details of that experiment, and its aftermath, if someone can give me an example (send privately if you wish) of a domain on the Internet with this null MX setup, and I'll talk to our gateway folks to see if it fails in similarly ugly ways, at recent or latest code versions of our gateway software. (Yes, I know it was said earlier in the message thread that there have been no negative consequences of this null MX methodology after years of deployment, but I'm going to be from Missouri here -- show me). I agree with you that code changes are needed, at least for our package. A published NULL MX does not reduced the number of MTA retries in our implementation and thats because there are high false positives so the full attempts are tried until exhausted. We will need to tweak the code or the retry frequency table for this particular socket error, in this case 10061. To optimize, we will need to specifically look for three conditions: MX.Count == 1 and MX[0].Preference == 0 and MX[0].Exchange == . to trump, preempt any call attempt. -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
On 7/23/2014 7:57 AM, Masataka Ohta wrote: David Conrad wrote: Since I mentioned it and some folks said where is it?: http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03 In what context, did you mention it? Masataka Ohta I'm interested to know. Maybe a coincidence. The NULL MX specifications defines a NULL MX record setup: Exchange : . (root) Preference: 0 What has been crossing my mind regarding this NULL MX setup, was the possible privacy issue with NULL MX root domain Traceability aspect with legacy MTAs performing SMTP Implicit MX (No MX record, Fallback to A record) logic. What will the A query IP resolved to when the exchange points to the root? (Pete, Dave, this is my only question/concern, if real, about the NULL MX proposal) -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] beta release of getdns stub resolver
I should note that we invested heavy in DNS API development that allowed for single sourcing and caching across many applications (DNS clients users of the API). If *local* caching is not part of it, it would not help in its consideration (for us). -- HLS On 2/26/2014 5:05 PM, Glen Wiley wrote: Not yet, but that us on the hit list for us. On Wednesday, February 26, 2014, Hector Santos hsan...@isdg.net wrote: Is there is a plug and play 32 bit and/or 64 bit Windows version? On 2/26/2014 1:46 PM, Wiley, Glen wrote: Verisign and NLnet Labs are pleased to announce the first beta release (0.1.0) of an open source implementation of the getdns API specification. The project's home page is at http://getdnsapi.nethttp://getdnsapi.net/ . getdns is a modern asynchronous DNS API. It implements DNS entry points from a design developed and vetted by application developers, in the specification at http://www.vpnc.org/getdns-api/ edited by Paul Hoffman. With the development of this API, we intend to offer application developers a modernized and flexible way to access DNS security (DNSSEC) and other powerful new DNS features; a particular hope is to inspire application developers towards innovative security solutions in their applications. We invite everyone to take a look at the project and to provide feedback to us and even contribute back to the project! We expect to have successive releases over the next few months that move us toward a more complete implementation and includes ports to even more platforms. Signed�the getdns core team: Craig Despeaux, Verisign, Inc. Neel Goyal, Verisign, Inc. Olaf Kolkman, NLnet Labs Allison Mankin, Verisign Labs. Melinda Shore, No Mountain Software LLC Willem Toorop, NLnet Labs Wouter Wijngaards, NLnet Labs Glen Wiley, Verisign, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- HLS ___ 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 -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
well, for a moment, I did have to think about this draft being a joke or not. But the acronym was perfect. :) On 7/3/2013 1:30 PM, Warren Kumari wrote: On Jul 2, 2013, at 1:58 AM, Matthijs Mekking matth...@nlnetlabs.nl wrote: This sounds a lot like prefetch in unbound, and the configuration option gives some analysis on increased traffic. prefetch: yes or no If yes, message cache elements are prefetched before they expire to keep the cache up to date. Default is no. Turning it on gives about 10 percent more traffic and load on the machine, but popular items do not expire from the cache. Doh, sorry, I was not aware that Unbound did this. I'd like to recognize this in the draft, any idea who actually suggested it / added it to the code? Also, if the original TTL of the RR is less than STOP * HAMMER_TIME then the cache entry, it cannot be used anymore and the resolver should Break it down. I got a few off-list questions asking about the odd naming (and I also remember the IETF Diversity thread on Discuss). For folk who have no idea what the hell we are on about: http://www.youtube.com/watch?v=GbKAaSf6e10 http://www.youtube.com/watch?v=otCpCn0l4Wo Best regards, Matthijs On 07/02/2013 03:44 AM, John Levine wrote: We would like to draw your attention to a new draft. It looks like it should work, assuming that your cache uses the existing logic to remember queries in progress so it doesn't hammer a record that's already in the process of being refetched. Hmm. Probably worth mentioning. My main observation is that I have no idea what the tradeoffs are between the increased DNS traffic and faster responses to clients. Have you done simulations or live experiments? Nope. This doesn't really change the average very much, but it should help decrease the jitter / spikes for the unlucky few who hit the resolver just as the cache entry expires. The draft specified HAMMER_TIME as a time, not a percentage because: A: I wanted to use the phrase HAMMER_TIME (and STOP HAMMER_TIME!) :-P B: The main issue that the draft tries to solve is increased resolution times for the unlucky few who hit the resolver when the record has just expired. In order to decrease the added load caused by this, I chose a default that is somewhat longer than a bad resolution experience with a few failures along the way. C: STOP was added to prevent doing a cache-fill request on every recursive request for records that have TTL of HAMMER_TIME. D: I was (tilting at windmills and) trying to get folk to not use TTLs of a few seconds in the records :-) From reading the unbound prefetch thing, I suspect maybe a better solution would be: HAMMER_TIME defaults to 2 (or 1 or something) seconds If the original TTL is HAMMER_TIME, then only do the cache-fill when the TTL is 10% of the original TTL. This means that: if HAMMER_TIME is 2 and the original TTL is 600 seconds -- the auth servers will see approximately 0.3% additional traffic. if HAMMER_TIME is 2 and the original TTL is 60 seconds -- the auth servers will see approximately 3.3% additional traffic. if HAMMER_TIME is 2 and the original TTL is 1 seconds -- the auth servers will see approximately 10% additional traffic. W R's, John ___ 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 -- Go on, prove me wrong. Destroy the fabric of the universe. See if I care. -- Terry Prachett ___ 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] Fwd: New Version Notification for draft-wkumari-dnsop-hammer-00.txt
I like the idea. A fews ago we needed to write a local cache for our total system framework to create a single source API query for all of our apps within the framework using DNS. The cache database was prepared with a query frequency field (QFF) with the idea in the future to come up with come correlation where an TTL override can be used. In other words, if the QFF is low, then we just follow the TTL time to requery an expired recording. If the QFF was high, then this is where a HAMMER time idea would kick in. I would venture that the efficiency or payoff of a HAMMER time is lower when the TTL is high. So its payoff comes into play when there are low TTL values. So possibly, what the HAMMER draft can include is a set of boundary conditions or TTL range for when the HAMMER time is applicable. I think a formula can be created. -- HLS On 7/1/2013 5:43 PM, Warren Kumari wrote: Hi there, We would like to draw your attention to a new draft. If describes a simply optimization that, with minimal to no state, keeps popular records in recursive server's caches. W Begin forwarded message: From: internet-dra...@ietf.org Subject: New Version Notification for draft-wkumari-dnsop-hammer-00.txt Date: July 1, 2013 5:40:44 PM EDT To: Roy Arends r...@nominet.org.uk, Suzanne Woolf wo...@isc.org, Warren Kumari war...@kumari.net A new version of I-D, draft-wkumari-dnsop-hammer-00.txt has been successfully submitted by Warren Kumari and posted to the IETF repository. Filename:draft-wkumari-dnsop-hammer Revision:00 Title: Highly Automated Method for Maintaining Expiring Records Creation date: 2013-07-01 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-hammer-00.txt Status: http://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer Htmlized:http://tools.ietf.org/html/draft-wkumari-dnsop-hammer-00 Abstract: This document describes a simple DNS cache optimization which keeps the most popular records in the DNS cache. No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft. --Anon. ___ 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
[DNSOP] Batch Multiple Query Packet
I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. If it doesn't already exist or not considered in the past as an unfeasible concept, I am interest in seeing if this is something worth pursuing. Technical Background reasoning. With the advent of new protocols, especially those offering a domain policy construct, the TXT record is used as the fastest entry point with the widest support for query resolution. Yet there are (at least were) technical concerns that this not serve to benefit DNS for large scale usage, therefore considerations are giving to include a migration path to use new registration of RR types. This migration path comes with the recognition for a short term overhead of using a dual type query concept and long term hope for the new RR type to become the non-overhead single query satisfying result. The overall issue is two folds: 1) one where publishers may have to redundantly create two records and the DNS resolvers will always have to do a two queries to maximize widest support, and 2) The continued possible dearth of DNS servers (see RFC 3597 Handling of Unknown DNS Resource Record (RR) Types) that do not support unnamed RR types and/or the recursion requirement. If DNS server offered support for a Batch Query of multiple packets under a single call, this may help with the above migration overhead concerns. Is this something worth pursuing as a new I-D for DNS servers? Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
Paul Vixie wrote: On 2012-02-28 12:27 AM, Edward Lewis wrote: At 13:35 -0500 2/27/12, Hector Santos wrote: If it doesn't already exist or not considered in the past as an unfeasible concept, I am interest in seeing if this is something worth pursuing. One (not the only, Ohta replied with another) of the oft-cited obstacles is the presence of only one RCODE field in the packet. (What if one query would be NXDOMAIN and the other has an answer?) indeed, this is why multiple queries were not supported in the original DNS, and it's why EDNS doesn't have it either. the number of signalling bits needed to explain what went on with the multiple queries made folks' heads explode. the logic is still online if you want to see it: http://nsa.vix.com/~vixie/edns1.txt. Thanks Paul. Great material. I'm just winging it at this point. First, I was focusing on the batching of related types, i.e. a protocol with new RR type but has an initial default intro record and fallback to TXT. The goal is to have a single call that will yield a managed result to assist with the current concerns and waste associated with the migration of TXT to the new RR type usage. Second, I considered there is no room for a packet count, but I was thinking of simply bundling two separate packets, i.e. 2*RR for the UPD send and how would the servers read this. If DNS servers will barf, then never mind. :) But if its offers a way to perform this concept with no breakage, perhaps the server will just read the first one and act on it or it will process the residual packet as well. Of course, the client will still need to manage the responses with all the potential delays. Again, just winging it. I don't like kludges. :) -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
