Re: [dns-operations] Strange behavior of covid.cdc.gov
Thankfully cdc.gov is also served by auth00.ns.uu.net and auth100.ns.uu.net and they aren’t serving a incomplete version of akam.cdc.gov. Recursive servers will eventually get a valid referral rather than bogus (unsigned) answers from ns[123].cdc.gov for akam.cdc.gov. Mark > On 1 Sep 2020, at 00:47, Stephane Bortzmeyer wrote: > > On Mon, Aug 31, 2020 at 10:12:04PM +0900, > Yasuhiro Orange Morishita / 森下泰宏 wrote > a message of 18 lines which said: > >> But it seems to be a little bit strange. The auth servers of cdc.gov >> zone serve unneed (and unsigned) akam.cdc.gov zone. But they still >> have DS RR for real akam.cdc.gov zone. > > They also do not return a proper delegation: > > % dig +dnssec +norec @icdc-us-ns2.cdc.gov. A akam.cdc.gov > ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +norec > @icdc-us-ns2.cdc.gov. A akam.cdc.gov > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43497 > ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ; COOKIE: 70d47b392dfb22d2662352815f4d0d3fe1c90df99f508386 (good) > ;; QUESTION SECTION: > ;akam.cdc.gov.IN A > > ;; AUTHORITY SECTION: > akam.cdc.gov. 3600 IN SOA a1-43.akam.net. adhelpdsk.cdc.gov. ( > 612558384 ; serial > 300; refresh (5 minutes) > 180; retry (3 minutes) > 1209600; expire (2 weeks) > 3600 ; minimum (1 hour) > ) > > ;; Query time: 98 msec > ;; SERVER: 198.246.96.92#53(198.246.96.92) > ;; WHEN: Mon Aug 31 16:46:23 CEST 2020 > ;; MSG SIZE rcvd: 129 > > % dig +dnssec +norec @icdc-us-ns2.cdc.gov. DNSKEY akam.cdc.gov > ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +norec > @icdc-us-ns2.cdc.gov. DNSKEY akam.cdc.gov > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44336 > ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ; COOKIE: 2e27a9b171983390a21696a65f4d0d54710de953e8dd107b (good) > ;; QUESTION SECTION: > ;akam.cdc.gov.IN DNSKEY > > ;; AUTHORITY SECTION: > akam.cdc.gov. 3600 IN SOA a1-43.akam.net. adhelpdsk.cdc.gov. ( > 612558384 ; serial > 300; refresh (5 minutes) > 180; retry (3 minutes) > 1209600; expire (2 weeks) > 3600 ; minimum (1 hour) > ) > > ;; Query time: 98 msec > ;; SERVER: 198.246.96.92#53(198.246.96.92) > ;; WHEN: Mon Aug 31 16:46:44 CEST 2020 > ;; MSG SIZE rcvd: 129 > > Whuch may explain the strange error messages of DNSviz (the IP > addresses are for the parent zone). > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
On Tue, Sep 01, 2020 at 01:36:49AM +, Paul Hoffman wrote: > On Aug 31, 2020, at 6:02 PM, Brian Dickson > wrote: > > I think the only way to get meaningful data would be an active experiment, > > involving an authority server (or set of servers) for a domain set up just > > this way. > > We disagree. Another way to get meaningful data would be from someone's > logs, if we can find people who are logging. > > ... as you say, "we disagree". the reason this requires actual science is that the results aren't meaningful unless you have some clue about what we didn't see. you know that the plural of anecdote isn't data: the observation that something bad is not happening to somebody doesn't mean it's not happening to anybody. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
On Aug 31, 2020, at 6:02 PM, Brian Dickson wrote: > I think the only way to get meaningful data would be an active experiment, > involving an authority server (or set of servers) for a domain set up just > this way. We disagree. Another way to get meaningful data would be from someone's logs, if we can find people who are logging. > That is the kind of thing that Geoff and George are good at, so if they want > to do such an experiment and let us all know the results, I think that would > be interesting. That, too. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
On Mon, Aug 31, 2020 at 08:00:00PM +0200, Florian Weimer wrote: > * Puneet Sood via dns-operations: > > > We would be interested in hearing other operator's experience here. > > Are recursive servers seeing similar behavior from authoritative > > servers? If yes, are you discarding these responses? > > Are there authoritative server operators who still need the > > flexibility afforded by RFC 1035? > > If I recall correctly, while helping to run an academic network I > encountered this issue on the authoritative server side. That was > close to twenty years ago, and even back then, it did not occur to us > to push the resolvers to accept these incorrectly sourced responses, > instead of getting the authoritative server operator to fix their > setup. ... right. same. this misbehaviour is why we added logic to BIND4.9 to reject wrong-sourced responses, both in the stub and full resolvers. > ... Or maybe I'm not correctly remembering things, and it wasn't > DNS but Sun RPC. (Hard to believe that even early BIND 4 didn't get > this right, and what else could they have been running?) early BIND assumed singly-homed servers, and later BSD kernels used the interface address as the source address for unbound UDP sockets. however, earlier (4.3BSD and earlier) kernels always used the first configured interface as the source address for unbound UDP sockets, and this broke _everything_ on multi-homed hosts. including Sun RPC, NTP, DNS of course, and NFS. Sun's fix for this in late SunOS was to ignore the source address of UDP responses because it was unreliable. anyone using SunOS on a multi-homed server ended up switching to open source versions of the affected protocols. it was a real mess, easily on-par with the .rhosts debacle that led to Sun's "fix" for the gethostbyaddr() to have it call gethostbyname() on each returned name, rather than doing this in ruserok() and similar. those were bad times. > Anyway, in my current world, most recursive DNS servers operate behind > some sort of stateful packet filter, so the server operators on their > own cannot make these incorrectly source responses work because the > systems under their direct control never receive them. of the 27 million RDNS servers, 26.9 million of them are home gateways with the oldest and worst DNS and kernel UDP implementations ever seen. they do in fact need the relative safety of being behind stateful fire walls. of the other ~100K, most are not behind stateful firewalls, and about half are not behind anything other than a host-based firewall like "pf". so i agree with your observation but i quibble with your method of reaching your agreeable position. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
On Mon, Aug 31, 2020 at 5:09 PM Paul Hoffman wrote: > On Aug 31, 2020, at 2:47 PM, Viktor Dukhovni > wrote: > > > > Quite likely the domains that are completely broken (none of the > > nameservers respond from the right IP) are simply parked, and nobody > > cares whether they they actually work or not. > > > > The only reason you're seeing queries for them may be that folks doing > > DNS measurements, query all the domains we can find including the parked > > ones that nobody actually cares to have working. > > These assumptions seem... assumptiony. I'd love to see some data from > anyone who is collecting it on which NS names or IPs are exhibiting the > behavior. > I don't disagree, but the data would really only be visible to anyone on-path or at either end of the resolver-to-authority transaction. I think the only way to get meaningful data would be an active experiment, involving an authority server (or set of servers) for a domain set up just this way. That is the kind of thing that Geoff and George are good at, so if they want to do such an experiment and let us all know the results, I think that would be interesting. But I can't compel them to do that, and absent them choosing to do that, I think the general consensus is it's fine to let the broken stuff be broken. (The interesting result would be on the resolver side, as to which resolvers, if any, accept broken answers, and if possible, inferring the resolver operator's software being used.) Brian ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
On Tue, Sep 01, 2020 at 12:01:07AM +, Paul Hoffman wrote: > On Aug 31, 2020, at 2:47 PM, Viktor Dukhovni wrote: > > > > Quite likely the domains that are completely broken (none of the > > nameservers respond from the right IP) are simply parked, and nobody > > cares whether they they actually work or not. > > > > The only reason you're seeing queries for them may be that folks doing > > DNS measurements, query all the domains we can find including the parked > > ones that nobody actually cares to have working. > > These assumptions seem... assumptiony. I'd love to see some data from > anyone who is collecting it on which NS names or IPs are exhibiting > the behavior. Sure, but when most of the world's resolvers can't resolve a domain, it is not much of a leap to conclude that the operators of said domain don't much care to see it working (unless the problem is transient and quickly corrected). The longer the time that this sort of thing sits unaddressed, the less we should care about it any more than the operator does. On the other hand, if the problem is in the "quickly corrected" bucket, again we don't need to compromise DNS integrity for everybody else by generally accepting non-matching replies. If a particular resolver is able to apply emergency exceptions for a particular important zone, that'd be their choice I guess, but even that seems to be solving the wrong problem, why expect all the resolvers to fix a problem rightly solved at the source. Scoping out the extent of the problem is an interesting exercise in measurement, but should have no operational relevance for anyone other than the guilty parties, should they care to actually see their domain resolved. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
On Aug 31, 2020, at 2:47 PM, Viktor Dukhovni wrote: > > Quite likely the domains that are completely broken (none of the > nameservers respond from the right IP) are simply parked, and nobody > cares whether they they actually work or not. > > The only reason you're seeing queries for them may be that folks doing > DNS measurements, query all the domains we can find including the parked > ones that nobody actually cares to have working. These assumptions seem... assumptiony. I'd love to see some data from anyone who is collecting it on which NS names or IPs are exhibiting the behavior. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
On Mon, Aug 31, 2020 at 02:19:08PM -0400, Warren Kumari wrote: > The bit that I'm failing to understand is why these continue to exist > -- if everyone (or, everyone other than Google) are ignoring / > dropping these, how / why are they still on the Internet? Is it just > the $whatever are sending these are always deployed next to something > that ain't broke and the operator just hasn't noticed? > Or are perhaps more things accepting these than we expect? Quite likely the domains that are completely broken (none of the nameservers respond from the right IP) are simply parked, and nobody cares whether they they actually work or not. The only reason you're seeing queries for them may be that folks doing DNS measurements, query all the domains we can find including the parked ones that nobody actually cares to have working. Make these break, please! Nobody has any just cause to complain, and reducing the security of all other lookups to accommodate a tiny minority of domains that have broken via most other resolvers for a couple of decades is not a sound tradeoff. -- Viktor. P.S. I rather disagree with Paul that this is a operational practice question. The treatment of such response has an a priori *right* answer, and not following the specifications is an operational error that does not admit of an interpretation as an operational work-around. If some such domains need to work, they know what they need to do, or can be pointed in the right direction. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
* Warren Kumari: > On Mon, Aug 31, 2020 at 2:11 PM Florian Weimer wrote: >> >> * Puneet Sood via dns-operations: >> >> > We would be interested in hearing other operator's experience here. >> > Are recursive servers seeing similar behavior from authoritative >> > servers? If yes, are you discarding these responses? >> > Are there authoritative server operators who still need the >> > flexibility afforded by RFC 1035? >> >> If I recall correctly, while helping to run an academic network I >> encountered this issue on the authoritative server side. That was >> close to twenty years ago, and even back then, it did not occur to us >> to push the resolvers to accept these incorrectly sourced responses, >> instead of getting the authoritative server operator to fix their >> setup. > > The bit that I'm failing to understand is why these continue to exist > -- if everyone (or, everyone other than Google) are ignoring / > dropping these, how / why are they still on the Internet? Is it just > the $whatever are sending these are always deployed next to something > that ain't broke and the operator just hasn't noticed? > Or are perhaps more things accepting these than we expect? If such problems exist, they might not occur consistently for all source addresses. A subset of client addresses can route the response in such a way that the expected source address is produced on the public Internet. Or the affected zones have other name servers that hide the problem until you start looking for it. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
On 8/31/20 12:40 PM, Puneet Sood via dns-operations wrote: > Is there an online tool that does mark up on RFCs to show which other > RFCs are referring to specific sections in it? I suspect you may find: https://powerdns.org/dns-camel/ helpful here. Keith ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
* Puneet Sood via dns-operations: > We would be interested in hearing other operator's experience here. > Are recursive servers seeing similar behavior from authoritative > servers? If yes, are you discarding these responses? > Are there authoritative server operators who still need the > flexibility afforded by RFC 1035? If I recall correctly, while helping to run an academic network I encountered this issue on the authoritative server side. That was close to twenty years ago, and even back then, it did not occur to us to push the resolvers to accept these incorrectly sourced responses, instead of getting the authoritative server operator to fix their setup. Or maybe I'm not correctly remembering things, and it wasn't DNS but Sun RPC. (Hard to believe that even early BIND 4 didn't get this right, and what else could they have been running?) Anyway, in my current world, most recursive DNS servers operate behind some sort of stateful packet filter, so the server operators on their own cannot make these incorrectly source responses work because the systems under their direct control never receive them. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
--- Begin Message --- On Sat, Aug 29, 2020 at 11:50 AM Paul Hoffman wrote: > > On Aug 28, 2020, at 3:24 PM, Puneet Sood via dns-operations > wrote: > > We would be interested in hearing other operator's experience here. > > Are recursive servers seeing similar behavior from authoritative > > servers? If yes, are you discarding these responses? > > Are there authoritative server operators who still need the > > flexibility afforded by RFC 1035? > > Please note that Puneet was asking for other operators' experiences, not the > opinions of those of us who believe we should tell Google what to do. (And, > yes, I certainly put myself in the latter category.) I, too, would like to > hear if other resolver operators see this, and if possible to what extent > they are seeing it, and if we're really lucky to hear at least a few names > for which this is happening. The latter is not to name-and-shame, but instead > to be able to talk to the authoritative operators about what their > configuration is so that we can maybe guide others away from this path. Paul is right. We do plan to close this oversight in our request/response validation. Before doing that we wanted to see how prevalent it is and not cause unnecessary breakage. -Puneet > > --Paul Hoffman --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
--- Begin Message --- On Sat, Aug 29, 2020 at 12:18 AM Robert Edmonds wrote: > > Puneet Sood via dns-operations wrote: > > RFC 1035 section 7.3 (https://tools.ietf.org/html/rfc1035) > > Some name servers send their responses from different > > addresses than the one used to receive the query. That is, a > > resolver cannot rely that a response will come from the same > > address which it sent the corresponding query to. This name > > server bug is typically encountered in UNIX systems. > > > > RFC 2181 (https://tools.ietf.org/html/rfc2181#section-4) > >Most, if not all, DNS clients, expect the address from which a reply > >is received to be the same address as that to which the query > >eliciting the reply was sent. This is true for servers acting as > >clients for the purposes of recursive query resolution, as well as > >simple resolver clients. The address, along with the identifier (ID) > >in the reply is used for disambiguating replies, and filtering > >spurious responses. This may, or may not, have been intended when > >the DNS was designed, but is now a fact of life. > > > >Some multi-homed hosts running DNS servers generate a reply using a > >source address that is not the same as the destination address from > >the client's request packet. Such replies will be discarded by the > >client because the source address of the reply does not match that of > >a host to which the client sent the original request. That is, it > >appears to be an unsolicited response. > > See also RFC 5452 section 9.1 > (https://tools.ietf.org/html/rfc5452#section-9.1) which puts the > clarification in RFC 2181 into mandatory RFC 2119 language. > > 9.1. Query Matching Rules > >A resolver implementation MUST match responses to all of the >following attributes of the query: > >o Source address against query destination address > >o Destination address against query source address > >o Destination port against query source port > >o Query ID > >o Query name > >o Query class and type > >before applying DNS trustworthiness rules (see Section 5.4.1 of >[RFC2181]). > >A mismatch and the response MUST be considered invalid. Thanks Rob for that reference. It is quite clear. I didn't follow the "Updated By" links from 1035 to this section :( Is there an online tool that does mark up on RFCs to show which other RFCs are referring to specific sections in it? > > -- > Robert Edmonds --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
In article you write: >should tell Google what to do. (And, yes, I certainly put myself in the latter >category.) I, too, would like to hear >if other resolver operators see this, ... Is there a summary anywhere of what common resolver software like bind and unbound do? I use unbound, but when I look at the unbound documentation I can't tell. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Strange behavior of covid.cdc.gov
On Mon, Aug 31, 2020 at 10:12:04PM +0900, Yasuhiro Orange Morishita / 森下泰宏 wrote a message of 18 lines which said: > But it seems to be a little bit strange. The auth servers of cdc.gov > zone serve unneed (and unsigned) akam.cdc.gov zone. But they still > have DS RR for real akam.cdc.gov zone. They also do not return a proper delegation: % dig +dnssec +norec @icdc-us-ns2.cdc.gov. A akam.cdc.gov ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +norec @icdc-us-ns2.cdc.gov. A akam.cdc.gov ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43497 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 70d47b392dfb22d2662352815f4d0d3fe1c90df99f508386 (good) ;; QUESTION SECTION: ;akam.cdc.gov. IN A ;; AUTHORITY SECTION: akam.cdc.gov. 3600 IN SOA a1-43.akam.net. adhelpdsk.cdc.gov. ( 612558384 ; serial 300; refresh (5 minutes) 180; retry (3 minutes) 1209600; expire (2 weeks) 3600 ; minimum (1 hour) ) ;; Query time: 98 msec ;; SERVER: 198.246.96.92#53(198.246.96.92) ;; WHEN: Mon Aug 31 16:46:23 CEST 2020 ;; MSG SIZE rcvd: 129 % dig +dnssec +norec @icdc-us-ns2.cdc.gov. DNSKEY akam.cdc.gov ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +norec @icdc-us-ns2.cdc.gov. DNSKEY akam.cdc.gov ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44336 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 2e27a9b171983390a21696a65f4d0d54710de953e8dd107b (good) ;; QUESTION SECTION: ;akam.cdc.gov. IN DNSKEY ;; AUTHORITY SECTION: akam.cdc.gov. 3600 IN SOA a1-43.akam.net. adhelpdsk.cdc.gov. ( 612558384 ; serial 300; refresh (5 minutes) 180; retry (3 minutes) 1209600; expire (2 weeks) 3600 ; minimum (1 hour) ) ;; Query time: 98 msec ;; SERVER: 198.246.96.92#53(198.246.96.92) ;; WHEN: Mon Aug 31 16:46:44 CEST 2020 ;; MSG SIZE rcvd: 129 Whuch may explain the strange error messages of DNSviz (the IP addresses are for the parent zone). ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
On Aug 31, 2020, at 12:40 AM, Thomas Mieslinger wrote: > > On 8/29/20 5:50 PM, Paul Hoffman wrote: >> On Aug 28, 2020, at 3:24 PM, Puneet Sood via dns-operations >> wrote: >>> We would be interested in hearing other operator's experience here. >>> Are recursive servers seeing similar behavior from authoritative >>> servers? If yes, are you discarding these responses? >>> Are there authoritative server operators who still need the >>> flexibility afforded by RFC 1035? >> >> Please note that Puneet was asking for other operators' experiences, not the >> opinions of those of us who believe we should tell Google what to do. (And, >> yes, I certainly put myself in the latter category.) I, too, would like to >> hear if other resolver operators see this, and if possible to what extent >> they are seeing it, and if we're really lucky to hear at least a few names >> for which this is happening. The latter is not to name-and-shame, but >> instead to be able to talk to the authoritative operators about what their >> configuration is so that we can maybe guide others away from this path. > > At my employer we discard this kind of responses. We could analyze how > often we see them but we wait until someone calls customer care for "DNS > not working". A percentage of responses would be great, as would the percentage of the authoritative servers doing this. And, yes, I totally get that I'm asking you to do work that you don't need to do because the customers aren't calling. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Strange behavior of covid.cdc.gov
On Mon, Aug 31, 2020 at 9:23 AM Yasuhiro Orange Morishita / 森下泰宏 wrote: > > Hi, > > Now covid.cdc.gov seems to be DNSSEC validation error. > Google Public DNS and some DNSSEC-enabled resolvers return SERVFAIL. > e.g. dig covid.cdc.gov @8.8.8.8 > > But it seems to be a little bit strange. The auth servers of cdc.gov > zone serve unneed (and unsigned) akam.cdc.gov zone. But they still > have DS RR for real akam.cdc.gov zone. > > This is output of digs. > <https://www.dropbox.com/s/alfb1ftvzpd6qcv/20200831-covid.cdc.gov.txt> ... and for those of us who prefer the pretty graph version: https://dnsviz.net/d/covid.cdc.gov/dnssec/ Another thing that is interesting is: $ dig covid.cdc.gov @ns1.cdc.gov [SNIP] ;; ANSWER SECTION: Covid.cdc.gov. 3600 IN CNAME covid.akam.cdc.gov. covid.akam.cdc.gov. 3600 IN CNAME covid.cdc.gov.edgekey.net. The uppercase 'C' in the 'Covid.cdc.gov. 3600 IN CNAME covid.akam.cdc.gov.' from the auth is interesting... Not wrong, just interesting... W > > -- Orange > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- 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 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Strange behavior of covid.cdc.gov
Hi, Now covid.cdc.gov seems to be DNSSEC validation error. Google Public DNS and some DNSSEC-enabled resolvers return SERVFAIL. e.g. dig covid.cdc.gov @8.8.8.8 But it seems to be a little bit strange. The auth servers of cdc.gov zone serve unneed (and unsigned) akam.cdc.gov zone. But they still have DS RR for real akam.cdc.gov zone. This is output of digs. <https://www.dropbox.com/s/alfb1ftvzpd6qcv/20200831-covid.cdc.gov.txt> -- Orange ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
On 8/29/20 5:50 PM, Paul Hoffman wrote: On Aug 28, 2020, at 3:24 PM, Puneet Sood via dns-operations wrote: We would be interested in hearing other operator's experience here. Are recursive servers seeing similar behavior from authoritative servers? If yes, are you discarding these responses? Are there authoritative server operators who still need the flexibility afforded by RFC 1035? Please note that Puneet was asking for other operators' experiences, not the opinions of those of us who believe we should tell Google what to do. (And, yes, I certainly put myself in the latter category.) I, too, would like to hear if other resolver operators see this, and if possible to what extent they are seeing it, and if we're really lucky to hear at least a few names for which this is happening. The latter is not to name-and-shame, but instead to be able to talk to the authoritative operators about what their configuration is so that we can maybe guide others away from this path. At my employer we discard this kind of responses. We could analyze how often we see them but we wait until someone calls customer care for "DNS not working". To me this is similar to the endless discussion around "why can't I use a cname in MX or NS". RFC2181 is pretty clear about NS/MX or "Server Reply Source Address Selection" and I don't see a reason why I should risk the stability of my systems to make it work for a small fraction of the internet. Just my 5¢ Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
