Re: [dns-operations] help with a resolution
On Tue, Jan 07, 2020 at 08:37:45PM -0500, Viktor Dukhovni wrote: > That's easy, the domain is delegated signed: > > pike-aviation.com. IN DS 41388 7 1 > fc9228e1b977dcd5c830a5c0101532e225e173cf FWIW, the DS RRset and DNSKEYs have been in place since ~2018-01-10. domain | alg | flags | inception | bits --+-+---++-- pike-aviation.com | 7 | 256 | 2018-01-10 | 1024 pike-aviation.com | 7 | 256 | 2018-01-10 | 1024 pike-aviation.com | 7 | 257 | 2018-01-10 | 2048 DNSKEY lookups have been failing since ~2019-12-23: domain | rtype | failtime --+---+ pike-aviation.com |48 | 2019-12-23 -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] help with a resolution
Your DNSSEC is broken - see https://dnsviz.net/d/pike-aviation.com/dnssec/ .com says that the domain is signed (with keyid 41388), but there is no DNSKEY in the zone. W On Tue, Jan 7, 2020 at 8:33 PM William C wrote: > > Hi > > Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9 > etc) can't resolve this domain? > > $ dig pike-aviation.com @8.8.8.8 > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15133 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;pike-aviation.com. IN A > > ;; Query time: 17 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed Jan 08 08:53:56 CST 2020 > ;; MSG SIZE rcvd: 46 > > > But the domain's auth servers did respond it. > > $ dig pike-aviation.com @ns70.domaincontrol.com > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @ns70.domaincontrol.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5923 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1472 > ;; QUESTION SECTION: > ;pike-aviation.com. IN A > > ;; ANSWER SECTION: > pike-aviation.com. 3600IN A 67.205.137.55 > > ;; AUTHORITY SECTION: > pike-aviation.com. 3600IN NS ns70.domaincontrol.com. > pike-aviation.com. 3600IN NS ns69.domaincontrol.com. > > ;; Query time: 10 msec > ;; SERVER: 173.201.72.45#53(173.201.72.45) > ;; WHEN: Wed Jan 08 08:55:58 CST 2020 > ;; MSG SIZE rcvd: 114 > > > > Thank you. > ___ > 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
Re: [dns-operations] help with a resolution
On Wed, Jan 08, 2020 at 08:56:41AM +0800, William C wrote: > Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9 > etc) can't resolve this domain? > > $ dig pike-aviation.com @8.8.8.8 > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15133 That's easy, the domain is delegated signed: pike-aviation.com. IN DS 41388 7 1 fc9228e1b977dcd5c830a5c0101532e225e173cf but a query for its zone apex DNSKEY RRset returns: pike-aviation.com. IN SOA ns69.domaincontrol.com. d...@jomax.net. 2020010702 28800 7200 604800 600 so the entire domain is "bogus": https://dnsviz.net/d/pike-aviation.com/dnssec/ so either publish a DNSKEY RRset that includes and is signed by a key that matches the DS RRset, and then sign the rest of the zone with one of the keys in that RRset, OR else ask your registrar to request a drop of the DS RRset from the .com zone. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] help with a resolution
Hi Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9 etc) can't resolve this domain? $ dig pike-aviation.com @8.8.8.8 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15133 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;pike-aviation.com. IN A ;; Query time: 17 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Jan 08 08:53:56 CST 2020 ;; MSG SIZE rcvd: 46 But the domain's auth servers did respond it. $ dig pike-aviation.com @ns70.domaincontrol.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @ns70.domaincontrol.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5923 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;pike-aviation.com. IN A ;; ANSWER SECTION: pike-aviation.com. 3600IN A 67.205.137.55 ;; AUTHORITY SECTION: pike-aviation.com. 3600IN NS ns70.domaincontrol.com. pike-aviation.com. 3600IN NS ns69.domaincontrol.com. ;; Query time: 10 msec ;; SERVER: 173.201.72.45#53(173.201.72.45) ;; WHEN: Wed Jan 08 08:55:58 CST 2020 ;; MSG SIZE rcvd: 114 Thank you. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Surprising behaviour by certain authoritative name servers
Niall O'Reilly wrote: > > What's surprising is that an authoritative name server > shows both a decremented TTL value (as if it were answering > from cache) and the AA flag. > > I'm not sure which of the following labels is the best fit > for this behaviour: > > - normal and expected (but so far outside my experience), > - strange but harmless, > - downright wrong. I would argue somewhere between the last two :-) During the IETF dnsop ANAME work I did some thinking about the TTL implications, and I realised that decrementing the TTL on an authoritative server would cause a thundering herd effect due to caches timing out at the same time. But I don't have any measurements that would indicate how much of a problem this is in practice... https://tools.ietf.org/html/draft-ietf-dnsop-aname-04#appendix-C Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy: Southerly or southwesterly, 4 to 6, increasing 7 or gale 8 later in northwest. Moderate or rough, becoming very rough or high. Drizzle and fog patches. Good, occasionally very poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Surprising behaviour by certain authoritative name servers
On 07/01/2020 15:20, Niall O'Reilly wrote: Hi Niall, > What's surprising is that an authoritative name server > shows both a decremented TTL value (as if it were answering > from cache) and the AA flag. It could be tinydns, using this feature: "You may include a timestamp on each line. If ttl is nonzero (or omitted), the timestamp is a starting time for the information in the line; the line will be ignored before that time. If ttl is zero, the timestamp is an ending time (``time to die'') for the information in the line; tinydns dynamically adjusts ttl so that the line's DNS records are not cached for more than a few seconds past the ending time. A timestamp is an external TAI64 timestamp, printed as 16 lowercase hexadecimal characters. For example, the lines +www.heaven.af.mil:1.2.3.4:0:400038af1379 +www.heaven.af.mil:1.2.3.7::400038af1379 specify that www.heaven.af.mil will have address 1.2.3.4 until time 400038af1379 (2000-02-19 22:04:31 UTC) and will then switch to IP address 1.2.3.7." Regards, Anand Buddhdev ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Surprising behaviour by certain authoritative name servers
Hi Niall, On 07-Jan-2020 13:20 CET, wrote: > Hi. > > I've had my attention drawn to some surprising behaviour by > certain authoritative name servers. I'm not sure how best > to categorize this behaviour, and wonder how some of you > might view it. > > What's surprising is that an authoritative name server > shows both a decremented TTL value (as if it were answering > from cache) and the AA flag. > > I'm not sure which of the following labels is the best fit > for this behaviour: > > - normal and expected (but so far outside my experience), > - strange but harmless, > - downright wrong. > > Thanks in advance to whomever is minded to reply. could it be dnsdist in front of an Authoritative, with the `dontAge` setting of newPacketCache set to false? > Thanks especially to Mats Dufberg who, diligently > investigating what I had mistakenly guessed was a problem > in zonemaster, took time to identify, and make me aware of, > what was causing occasional trouble reports. > > Niall -- Nico ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Surprising behaviour by certain authoritative name servers
Hi Niall, On 07-Jan-2020 13:20 CET, wrote: > Hi. > > I've had my attention drawn to some surprising behaviour by > certain authoritative name servers. I'm not sure how best > to categorize this behaviour, and wonder how some of you > might view it. > > What's surprising is that an authoritative name server > shows both a decremented TTL value (as if it were answering > from cache) and the AA flag. > > I'm not sure which of the following labels is the best fit > for this behaviour: > > - normal and expected (but so far outside my experience), > - strange but harmless, > - downright wrong. > > Thanks in advance to whomever is minded to reply. could it be dnsdist in front of an Authoritative, with the `dontAge` setting of newPacketCache set to false? > Thanks especially to Mats Dufberg who, diligently > investigating what I had mistakenly guessed was a problem > in zonemaster, took time to identify, and make me aware of, > what was causing occasional trouble reports. -- Nico ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Surprising behaviour by certain authoritative name servers
Hi Niall, Assumption: Possibly a wrong configured dnsdist [1] cache [2] in front of the authoritative name server. If you miss the "dontAge" switch, that's exactly the effect you'll have. Winfried [1] https://dnsdist.org/ [2] https://dnsdist.org/reference/config.html?highlight=dontAge#newPacketCache Am 07.01.2020 um 13:20 schrieb Niall O'Reilly: Hi. I've had my attention drawn to some surprising behaviour by certain authoritative name servers. I'm not sure how best to categorize this behaviour, and wonder how some of you might view it. What's surprising is that an authoritative name server shows both a decremented TTL value (as if it were answering from cache) and the AA flag. I'm not sure which of the following labels is the best fit for this behaviour: * normal and expected (but so far outside my experience), * strange but harmless, * downright wrong. Thanks in advance to whomever is minded to reply. Thanks especially to Mats Dufberg who, diligently investigating what I had mistakenly guessed was a problem in zonemaster, took time to identify, and make me aware of, what was causing occasional trouble reports. Niall ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Surprising behaviour by certain authoritative name servers
--- Begin Message --- Hi Niall. Yes, we (Three UK) have seen this before, from AWS DNS and Cloudflare. Cloudflare say this is intentional because of the way that their CNAME flattening works. I don't think it's a protocol violation, but (if you're an ISP and run large cacheing servers) it can really muck up your cache! Another thing to watch out for is TTL=0. If the original authoritative TTL is (say) 60s, but repeated queries show an AA answer with decrementing TTL, we have noticed that this can decrement to 0. An AA answer with TTL=0 is legal, but it cannot be cached and it also messed with a piece of equipment that had issues with 0 TTLs (but that's just our problem). I hope that helps. cheers, Greg On Tue, 7 Jan 2020 at 12:24, Niall O'Reilly wrote: > Hi. > > I've had my attention drawn to some surprising behaviour by > certain authoritative name servers. I'm not sure how best > to categorize this behaviour, and wonder how some of you > might view it. > > What's surprising is that an authoritative name server > shows both a decremented TTL value (as if it were answering > from cache) and the AA flag. > > I'm not sure which of the following labels is the best fit > for this behaviour: > >- normal and expected (but so far outside my experience), >- strange but harmless, >- downright wrong. > > Thanks in advance to whomever is minded to reply. > > Thanks especially to Mats Dufberg who, diligently > investigating what I had mistakenly guessed was a problem > in zonemaster, took time to identify, and make me aware of, > what was causing occasional trouble reports. > > Niall > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Surprising behaviour by certain authoritative name servers
Hi. I've had my attention drawn to some surprising behaviour by certain authoritative name servers. I'm not sure how best to categorize this behaviour, and wonder how some of you might view it. What's surprising is that an authoritative name server shows both a decremented TTL value (as if it were answering from cache) and the AA flag. I'm not sure which of the following labels is the best fit for this behaviour: - normal and expected (but so far outside my experience), - strange but harmless, - downright wrong. Thanks in advance to whomever is minded to reply. Thanks especially to Mats Dufberg who, diligently investigating what I had mistakenly guessed was a problem in zonemaster, took time to identify, and make me aware of, what was causing occasional trouble reports. Niall ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
