Re: [dns-operations] CDS query issues (google issue?)

[Roy Arends]

Seems like you’ve encountered a bug in DiG,

The query works fine for me, over TCP.

Roy

> On 21 Aug 2023, at 15:56, Jacques Latour via dns-operations 
>  wrote:
> 
> 
> From: Jacques Latour 
> Subject: CDS query issues (google issue?)
> Date: 21 August 2023 at 15:56:58 GMT+1
> To: "dns-operations@lists.dns-oarc.net" 
> Cc: Jesse Carter , "oliv.schac...@switch.ch" 
> 
> 
> 
> Hi all,
>  Quick one, we’re getting an error when doing this CDS query over TPC?  Just 
> me? Seems like a google bug?
>  $ dig ewmc.ca cds @ns-cloud-c4.googledomains.com. +tcp
> netmgr/tcpdns.c:302: fatal error: RUNTIME_CHECK(result == ISC_R_SUCCESS) 
> failed
> Aborted (core dumped)
>  But works on UDP…
>  $ dig ewmc.ca cds @ns-cloud-c4.googledomains.com. +notcp +short
> 13687 8 2 B10B9D6ACF05F22DFC3602DBAB830F541B8C9F0228F79D56B531F777 B8FE9AD1
>  Thanks,
>  Jack
>   
> CLASSIFICATION:PUBLIC
> 
> 
> ___
> 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] in-addr.arpa. "A" server "loopback network" misconfiguration

[Roy Arends]

Try dns-...@arin.net

Hope this helps

Roy

> On 22 Jun 2023, at 15:42, Viktor Dukhovni  wrote:
> 
> On Thu, Jun 22, 2023 at 10:30:33AM -0400, Matthew Pounsett wrote:
> 
>> Have you tried contacting the IANA or the IAB?  Those are the two
>> organizations responsible for the technical and administrative for
>> that zone... and I note that neither of them are copied on your email.
>> Directly reaching out to either or both of them may be more productive
>> than posting to dns-operations.
> 
> Which of the below would you suggest?
> 
>SOA rname:ns...@iana.org
>WHOIS Administrative: i...@iab.org
>WHOIS Technical:  tld-cont...@iana.org
> 
> -- 
>Viktor.
> ___
> 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] Resolvers seeing repeated bursts of identical queries

[Roy Arends]

> On 9 Jan 2023, at 15:22, Viktor Dukhovni  wrote:
> 
> On Mon, Jan 09, 2023 at 01:55:29PM +0000, Roy Arends wrote:
> 
>> I’ve often seen this behaviour.
>> 
>> One confirmed explanation was (but there may be more/other) that this
>> is the result of a stateful firewall. While the rules are pushed,
>> traffic through it is buffereduntil the last rule is pushed, after
>> which the buffer is flushed to world, resulting in a barrage of
>> queries from the resolver behind the firewall. It depends on the
>> resolver what happens with the ID. Some will re-issue the query after
>> no response, some re-issue with new ID. 
> 
> The repetition of the same DNS query ID and exclusively the same qname
> somewhat argues against the firewall theory, because ~100 instances of
> just retransmissions of the same query from a resolver seems unlikely,
> especially within the time it takes a firewall to reload its ruleset.

This was a confirmed case (the bulk same q-id q-name q-type src-addr thing 
stood out). Repeatable. It may not be the only explanation, though, but it is 
not theory.

It took a few seconds for the specific firewall to reload rules (Checkpoint was 
the fw in question iirc).

The resolver box would receive a dst host/net unreachable from the FW box, 
which was about 5 ms away, which resulted in the resolver box re-sending the 
exact same query, and this looped a bit. The FW would buffer the request and 
upon the “allow 53 UDP” rule loading, a burst of buffered queries were send 
(partly towards our DNS servers).

I have no access to the specific details, as I’ve left Nominet. However, 
colleagues posted a few of similar stories about spammy DNS related behaviour 
at the time. 

ymmv

Roy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Resolvers seeing repeated bursts of identical queries

[Roy Arends]

I’ve often seen this behaviour.

One confirmed explanation was (but there may be more/other) that this is the 
result of a stateful firewall. While the rules are pushed, traffic through it 
is buffereduntil the last rule is pushed, after which the buffer is flushed to 
world, resulting in a barrage of queries from the resolver behind the firewall. 
It depends on the resolver what happens with the ID. Some will re-issue the 
query after no response, some re-issue with new ID. 

I never got confirmation of the firewall make. This was about 8 years ago.

Roy

> On 9 Jan 2023, at 08:50, sth...@nethelp.no wrote:
> 
> We are receiving a significant amount of query bursts on our resolvers
> with the following characteristics:
> 
> - A client IP doing a burst of queries for the same name repeatedly,
> very quickly.
> - The query is typically an A query.
> - A burst often has 50 - 100 queries for the same name within a few
> milliseconds.
> - All the queries within one burst have the same DNS query ID (but
> different IP id and source port number).
> - The same client IP producing such bursts of identical queries also
> sends regular queries (one query per name, DNS query IDs vary).
> 
> Example of (part of) query burst - in this case the client sends
> bursts of 84 queries within less than 1 ms:
> 
> 09:24:56.593259 IP 194.19.79.131.58089 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593283 IP 194.19.79.131.38426 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593307 IP 194.19.79.131.56931 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593346 IP 194.19.79.131.42976 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593350 IP 194.19.79.131.11638 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 09:24:56.593366 IP 194.19.79.131.22476 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> ...
> 09:24:56.594364 IP 194.19.79.131.41548 > 193.75.75.193.53: 24781+ A? 
> www.jointraining.com. (38)
> 
> followed by another burst of 84 queries in around 1.1 ms:
> 
> 09:24:56.594416 IP 194.19.79.131.38426 > 193.75.75.193.53: 28221+ A? 
> www.facebook.com. (34)
> 09:24:56.594475 IP 194.19.79.131.42976 > 193.75.75.193.53: 28221+ A? 
> www.facebook.com. (34)
> 09:24:56.594501 IP 194.19.79.131.58089 > 193.75.75.193.53: 28221+ A? 
> www.facebook.com. (34)
> 09:24:56.594560 IP 194.19.79.131.14419 > 193.75.75.193.53: 28221+ A? 
> www.facebook.com. (34)
> 09:24:56.594561 IP 194.19.79.131.56931 > 193.75.75.193.53: 28221+ A? 
> www.facebook.com. (34)
> 09:24:56.594562 IP 194.19.79.131.18576 > 193.75.75.193.53: 28221+ A? 
> www.facebook.com. (34)
> ...
> 09:24:56.595596 IP 194.19.79.131.41232 > 193.75.75.193.53: 28221+ A? 
> www.facebook.com. (34)
> 
> I *suspect* the bursts and the regular queries are actually produced
> by different clients on the inside of a firewall with NAT - but note I
> don't *know* this is the case.
> 
> Does anybody know of software / applications that would produce such
> query bursts? Note that I don't believe the query bursts are caused by
> L2 loops or similar, because
> 
> - These problems have lasted for weeks
> - And they occur for several different (unrelated) customers
> 
> Steinar Haug, AS2116
> ___
> 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] DNS request for ./NS with two extra bytes at the end

[Roy Arends]

I’ve not looked for these, but will look now…

The additional two bytes seems to be the identifier in the DNS header, plus 
one, based on the two messages in the PCAP sample.

Roy

> On 26 May 2022, at 06:40, Stephane Bortzmeyer  wrote:
> 
> [This has no operational consequences, it is just idle curiosity.]
> 
> A server receives a few packets/second coming from several IP
> addresses and querying ./NS (like in priming, or may be in some
> reflection attacks). The server was never a root server, of course.
> 
> What is interesting is that all these packets have two extra bytes at
> the end, after the class. The UDP length is correct, but the DNS
> content is not. I don't show you the output of tshark, because it
> ignores these extra bytes (but you can see them with Wireshark or
> other tools). I attached a small pcap.
> 
> The source IP addresses (which may be spoofed) are all registered in
> China.
> 
> Did anyone see these requests?
> 
> Side question: what should the receiver do? tshark, as I said, drops
> these extra bytes, Wireshark flags no error (but displays the
> bytes). I did not test them with various DNS servers to see how they
> react. Ignoring the extra bytes in the name of the robustness
> principle? Instead, at least one DNS library rejects the packet as
> malformed.
> 
> ___
> 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] Root Key Sentinel - current state of affairs?

[Roy Arends]

Hi Ondrej

> On 23 Jun 2021, at 08:10, Ondřej Surý  wrote:
> 
> Hi,
> 
> during the last RZ KSK rollover we scrambled to add the Root Key Sentinel
> to the code and as far as I know it did give us different data than was 
> expected.

I am going to assume you are referring to RFC8145 (Signaling Trust Anchor 
Knowledge in DNSSEC) and not RFC8509 (A Root Key Trust Anchor Sentinel for 
DNSSEC). My apologies if you meant the latter, as I have no information on that.

> So, my current question is:
> 
> - is it still useful?

Personally, I find it interesting data, but I currently have no business case 
for it.

> - will it be useful for the next RZ KSK rollover?

It may be.

> - is anybody gathering the data right now?

We (the Office of the CTO at ICANN) received accumulated stats from Root Server 
Operators before and during the last rollover. We do not receive them 
currently. While we have access to IMRS traffic data, we do not currently 
process RFC8145 signals.  

> - is anybody planning to gather the data before the next RZ KSK rollover?

I am going to assume that that is going to happen.

Hope this helps!

Warmly,

Roy


> 
> Thanks,
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
> 
> ___
> 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] Possibly-incorrect NSEC responses from many RSOs

[Roy Arends]

> On 2 Mar 2021, at 13:23, Peter van Dijk  wrote:
> 
> On Sat, 2021-02-27 at 17:06 +, Paul Hoffman wrote:
>> 
>> 
>>> Additionally, we expect this may bring some new attention to the
>>> way in which authoritative name servers respond to queries of type
>>> NSEC.  Some implementations respond with referrals, while others
>>> respond with an NSEC RR in the Answer section.  Verisign will be
>>> pleased to work with the community if there are ambiguities in the
>>> relevant RFCs (e.g. 4035) that would benefit from clarification,
>>> as current behavior beyond this subset of our name servers suggests.
>> 
>> The text in Section 3 of RFC 4035 is:
>>   A security-aware name server that receives a DNS query that does not
>>   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
>>   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
>>   MUST NOT perform any of the additional processing described below.
>> The "treat ... as it would any other RRset" seems to say that if an 
>> authoritative server gets a query for /NSEC for a name that has an NSEC 
>> record in the zone, that NSEC record should appear in the Answer section.
> 
> That text appears to have been written for the general case of
> 'querying for data that is authoritative in a zone', ignoring the very
> specific case of 'at a zone cut' that the different (root) server
> responses are about.

The “treat … as it would any other RRset” refers to the DNS Query. It must 
treat the DNS query for type RRSIG, DNSKEY and NSEC as it would treat a query 
for any other RRset. 

So, if the query is for a type at a name at a delegation point, return the 
delegation point. If the query is for type A, NS, , MX, NSEC, DNSKEY, 
type12345, etc, etc, return the delegation point.

If this is not a delegation point, and NSEC happens to exist at the name, 
return NSEC, otherwise NODATA. If the name doesn’t exist, return NXDOMAIN.

It does NOT say “return NSEC” if the query is for NSEC.

Hope this helps.

Roy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

[Roy Arends]

In a few cases, the operator of a zone does not immediately realise that there 
are issues. To overcome that, Matt and I have a proposal in the works 
(DNS-error-reporting) that lets a resolver send an error report on a broken 
zone to a third party, indicated by the same broken zone.

https://tools.ietf.org/html/draft-arends-dns-error-reporting-00 


The point of this is to get things fixed faster.

Hope this helps and apologies for the shameless plug.

Warmly,

Roy



> On 1 Mar 2021, at 19:08, Paul Vixie  > wrote:
> 
> On Tue, Mar 02, 2021 at 05:46:38AM +1100, Mark Andrews wrote:
>> It also doesn???t help that Whois is not particularly useful. It has
>> improved but if you can???t report faults they don???t get fixed.
> 
> right. agreed. the reliable signal for "wrong key or signature" has to be a
> loss of incoming traffic and a lot of complaints from one's own users. we
> won't be solving this with a cron job. NTA adds deliberate assymetry between
> the costs of doing DNSSEC signing wrong and the costs of coping with that.
> 
>> -- 
>> Mark Andrews
> 
> -- 
> Paul Vixie
> ___
> 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] NXDOMAIN status, with answers?

[Roy Arends]

> On 8 Feb 2021, at 14:00, Anthony Lieuallen via dns-operations 
> mailto:dns-operati...@dns-oarc.net>> wrote:
> 
> 
> From: Anthony Lieuallen mailto:alieu...@google.com>>
> Subject: NXDOMAIN status, with answers?
> Date: 8 February 2021 at 14:00:49 GMT
> To: dns-operati...@dns-oarc.net 
> 
> 
> An interesting corner case has recently been brought to our attention, and 
> I'm hoping for some additional viewpoints to help me understand how best to 
> handle it.
> 
> An operator reported problems with our recursive resolver, after recently 
> enabling DNSSEC.  The cause seems to be that the authoritative server is 
> returning an answer (a CNAME, in case it matters) but with NXDOMAIN status.  
> When we see NXDOMAIN we abort our recursive resolving behavior.  Later we get 
> to the DNSSEC validation phase, but because we stopped at the NXDOMAIN we 
> never got the DNSKEYs for the zone, and we thus fail to validate, and return 
> SERVFAIL.
> 
> Other resolvers seem to be handling this domain successfully, so I'm 
> wondering:
> 
> * Is this (NXDOMAIN status, but CNAME and RRSIG in the answer) valid, per the 
> spec?

Yes. The canonical name (the right-hand side of the CNAME, the name in the 
rdata) does not exist. That is, the alias points to something that doesn’t 
exist. Is the canonical name in the same zone as the owner name of the CNAME 
record?

> * Either way, how should a recursive handle such an authoritative response?

This is a valid, albeit rare, terminating response. You can not trust the RCODE 
in the response. You have proof of existence of the CNAME (it has an RRSIG), 
and there may be a set of NSEC(or NSEC3) records proving absence of the 
canonical name (provided the canonical name should be in the same zone). If the 
latter (proof of absence) is not there, you should restart the query with the 
canonical name.

Hope this helps

Roy

> 
> 
> ___
> 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

[dns-operations] dnspooq

[Roy Arends]

fyi

https://www.jsof-tech.com/disclosures/dnspooq/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)

[Roy Arends]

Hi Viktor,

> On 18 Jan 2021, at 06:57, Viktor Dukhovni  wrote:
> 
> TL;DR.  The BCP NSEC/NSEC3 choices are IMHO:
> 
>- NSEC  ; for smaller response sizes and realistic
>; acceptance that the zone data is not secret
>; This also facilitates aggressive negative
>; caching, reducing query loads.
> 
>- NSEC3 1 0 0 - ; for zones that prefer to discourage zone-walking
>; at the cost of larger DoE response packets.
> 
>- NSEC3 1 1 0 - ; for just a handful of the largest TLDs, where
>; building the full NSEC3 chain is a non-trivial
>; burden.  Pretty much .COM, but perhaps a few more.
> 
> Three recent data points are perhaps an indication that the message
> about best-practice in this space has not yet been widely assimilated
> even at TLDs.  [ "Leaf" zones lower down the tree have even less just
> cause to enable NSEC3 opt-out. ]
> 
> In particular, the recently launched ".spa" and ".amazon" gTLDs, and
> newly signed ".aero" are using NSEC3 with opt-out, and wasteful extra
> hash iterations (I find the shared "salt" value somewhat "amusing"):
> 
>h01ujevptngfpnlqv5o7ljtr5mgpmmuu.aero. IN NSEC3 (
>  1 1 100 332539ee7f95c32a H024I3M5E7N82AKIEKRKG4JKJB4JOSH8
>  NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
>g19djt2akj752esm388ouk6aj02qo882.spa. IN NSEC3 (
>  1 1 100 332539ee7f95c32a ALB20V7NTUH2AJJD7JJ7L9IG7MICR7RF
>  A NS SOA MX TXT SRV RRSIG DNSKEY NSEC3PARAM )
> 
>kdp5tstbb6u4p70q8e3l7ea74ksvg6lc.amazon. IN NSEC3 (
>  1 1 10 76a1ff9f Q2R4LHDLQ71EMMA9JVAF2IIQDEAT9JDV
>  NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534 )
> 
> but the full zone file is (or will soon be) accessible via CZDS and
> is otherwise in good measure available from other informal sources
> (certificate transparency logs, zmap, ...).
> 
> To the extent that NSEC3 still makes sense for TLDs, the closest
> examples to best-current-practice are .GOOG, .DEV, .PAGE, ...
> 
>25um4oo0vkc0v0tcjprl5qj82pv2e3ui.goog. IN NSEC3 (
>  1 0 1 8f3fee3d92a4c131 2HM8UMA28IIQ4SUBT347HQ7FII5RJVEH
>  NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
>6n3ds9aanpq49o7cm0cdh9382a0jh2n5.dev. IN NSEC3 (
>  1 0 1 b7b0891083980e59 6N3MCHJEC01UPT3IR676PLEQGRVJ2UTC
>  NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
>98cqn8pmrp6sdug39rvmhse4cg61linm.page. IN NSEC3 (
>  1 0 1 b335b7536f34f743 98CUIOFUAMGOBON90HPNK6HJTVM42OBQ
>NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
> where there's no opt-out, and just one extra SHA1 iteration (though zero
> IMHO is just as effective and cheaper).  The non-empty salt is
> pointless, but basically harmless.
> 
> For the largest extant TLDs, which are not yet ready to abandon opt-out,
> the BCP examples are .COM and .NET where NSEC3 is used exclusively for
> the "opt-out" support, (empty salt, 0 extra iterations):
> 
> CK0POJMG874LJREF7EFN8430QVIT8BSM.com. IN NSEC3 (
>   1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A
>   NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
> A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. IN NSEC3 (
>   1 1 0 - A1RUUFFJKCT2Q54P78F8EJGJ8JBK7I8B
>   NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
> But for new gTLDs, I'd argue that they're far from likely to get
> anywhere near the size of .NET any time soon (or ever), and that
> "opt-out" is entirely the wrong tradeoff.
> 
> The storage cost of listing every domain in the NSEC3 chain for a
> typical-size TLD (pretty much all except .COM) is modest, and there's no
> reason to sacrifice denial of existence security for little to no gain.
> 
> Similarly, the 100 iterations just slow down the authoritative servers
> and validating resolvers for no good reason.
> 
> I'd like to encourage the operators of TLD zones to use either
> simply NSEC (IIRC .ORG have indicated intent to move to NSEC),
> or where modest zone-walking protection is deemed appropriate,
> use NSEC3 with no opt-out, no salt, and no extra iterations.
> 
> Just the first (implicit) SHA1 iteration is quite enough to
> discourage most zone-walkers, and the zone content of TLDs
> is far from secret.  Even where zone feeds are not generally
> available, I am typically able to obtain 75-90% of the names
> in a TLD zone from other sources, without resorting to any
> zone walks.

Hi Viktor,

I agree with you. 

Large iteration values put a heavy burden on validating resolvers, opt-out 
should _only_ be used if the cost of signing a large, 
unsigned-delegation-centric zone prohibits normal operations, and lastly, if 
salt is not regularly changed, it is useless and might as well not be used at 
all to save a few bytes in responses. NSEC should be the norm, NSEC3 the 
exception.

Please note that moving from NSEC3 to NSEC should be done carefully, but is not 
impossible. The Swedish Internet Foundation (IIS.SE) has done this last year 
for both .SE and .NU.

https://internetstiftelsen.se/en/tech/first-large-top-level-domain-to-transition-from-nsec3-to-nsec/
 

Re: [dns-operations] QTYPEs 65 and 65479

[Roy Arends]

More info:

https://mailarchive.ietf.org/arch/msg/add/MbOOWPVHRHM_wvbKhfHuzUTwimI/ 


Roy

> On 16 Sep 2020, at 09:04, Greg Choules via dns-operations 
>  wrote:
> 
> 
> From: Greg Choules 
> Subject: QTYPEs 65 and 65479
> Date: 16 September 2020 at 09:04:58 GMT+1
> To: dns-operations@lists.dns-oarc.net
> 
> 
> Hello all.
> Recently, whilst looking for something else, tcpdump on one of our recursive 
> servers showed we are receiving queries with (from its point of view) 
> unrecognised types. Wireshark doesn't have a decode for them yet either. 
> There aren't many, yet. But it's more than just noise.
> A quick reverse lookup on the sources shows them all to be iPhone X or later.
> 
> Can anyone shed some light on what these are and whether we should be doing 
> something about them?
> 
> thanks, Greg
> 
> 
> ___
> 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] QTYPEs 65 and 65479

[Roy Arends]

For qtype 65:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/00/?include_text=1 


These types are not special. Resolvers should treat them as “unknown RRs” and 
just resolve them.

Roy

> On 16 Sep 2020, at 09:04, Greg Choules via dns-operations 
>  wrote:
> 
> 
> From: Greg Choules 
> Subject: QTYPEs 65 and 65479
> Date: 16 September 2020 at 09:04:58 GMT+1
> To: dns-operations@lists.dns-oarc.net
> 
> 
> Hello all.
> Recently, whilst looking for something else, tcpdump on one of our recursive 
> servers showed we are receiving queries with (from its point of view) 
> unrecognised types. Wireshark doesn't have a decode for them yet either. 
> There aren't many, yet. But it's more than just noise.
> A quick reverse lookup on the sources shows them all to be iPhone X or later.
> 
> Can anyone shed some light on what these are and whether we should be doing 
> something about them?
> 
> thanks, Greg
> 
> 
> ___
> 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] New OARC Chat Platform

[Roy Arends]

+1

> On 25 Aug 2020, at 10:13, Jim Reid  wrote:
> 
> 
> 
>> On 25 Aug 2020, at 03:30, Fred Morris  wrote:
>> 
>> I think the question has to be: why would someone be joining this chat 
>> channel and who would they be?
> 
> No. The question should be why are we having this silly discussion?
> 
> There’s no justification for this outburst of shed-painting.
> 
> Quite simply, we should trust Matt and his colleagues to make sensible 
> decisions about the tools they provide for DNS-OARC. A lot of factors go into 
> those decisions. Some of them are complicated. Others depend on detail that 
> isn’t apparent to the membership - GDPR compliance or commercially sensistive 
> info from suppliers for instance. IMO, we should leave Matt, Denesh, etc to 
> get on with it. If they screw up or the chosen platform(s) turn out to be 
> unsatisfactory, that’s a discussion for the board and/or AGM.
> 
> FWIW, I don’t care what chat platform is used. Provided it runs on a server 
> that sits in a rack that’s painted yellow.

I prefer “tuscan” or “daffodil” over yellow, but I can live with it :-)

+1 on the rest of your message

Roy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] prefetching and thundering herds

[Roy Arends]

I the java version of unbound, we had an option to set a TTL in a response from 
the caching resolver to the stub resolver to, say, 1 minute. The purpose of 
this was so that you can’t “probe” a caching resolver to see exactly when a 
record expires in case you wanted to mount a spoofing attack against the cache. 
This was pre Kaminsky.

This would seem to defend against a thundering herd, at the cost of an 
increased load.

Roy

> On 15 Jul 2020, at 12:42, Tony Finch  wrote:
> 
> I've been wondering about the effects of stub resolvers with caches as
> clients of recursive servers. To what extent do they cause a thundering
> herd effect where all the cache entries expire with the same deadline?
> The herd will arrive when the RRset expires so most of those clients will
> hit maximum latency and stress the server's query deduplication mechanism.
> 
> (I don't think I have enough traffic to get a useful answer from my
> servers right now.)
> 
> If thundering herds happen, do they thunder enough to help explain the
> lack of benefit from prefetching observed by PowerDNS?
> 
> Or maybe is the herd is too small to thunder? Instead there's a more
> gentle swell of queries after the TTL expires?
> 
> https://lists.dns-oarc.net/pipermail/dns-operations/2019-April/018605.html
> 
> If there is much of a herd, would it make sense to give some proportion of
> the clients a slightly reduced TTL so that they will trigger prefetch
> before the rest of them requery?
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Bailey: Southwest 4 or 5, increasing 6 or 7 later. Moderate or rough,
> occasionally very rough later in far northwest. Drizzle, fog patches. Moderate
> or poor, occasionally very poor.
> ___
> 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] DNSViz Access to C-root

[Roy Arends]

> On 2 Jul 2020, at 21:03, Matthew Pounsett  wrote:
> 
> All we did was make C-root visible to DNSViz.

Hi Matt,

Good work on fixing this, Matt. Out of curiosity, how did you do this?

Warmly,

Roy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Roy Arends]

> On 26 Nov 2019, at 12:46, David Conrad  wrote:
> 
> It would appear a rather large percentage of queries to the root (like 50% in 
> some samples) are random strings, between 7 to 15 characters long, sometimes 
> longer.  I believe this is Chrome-style probing to determine if there is 
> NXDOMAIN redirection. A good example of the tragedy of the commons, like 
> water pollution and climate change.

Yep.

https://chromium.googlesource.com/chromium/src/+/32352ad08ee673a4d43e8593ce988b224f6482d3/chrome/browser/intranet_redirect_detector.cc
Line 79: "// We generate a random hostname with between 7 and 15 characters.”

https://ithi.research.icann.org/graph-m3.html
Table "Queries to frequently found name patterns” shows that the frequency 
distribution for queries between 7 and 15 characters are near flat (around 5.2% 
per character length) AND an order higher than ANY other queries.

“Coincidence? I think NOT!”  

https://youtu.be/MDpuTqBI0RM?t=53

Roy


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] root? we don't need no stinkin' root!

[Roy Arends]

Mark

> On 26 Nov 2019, at 14:49, Mark Allman  wrote:
> 
> 
>> It would appear a rather large percentage of queries to the root
>> (like 50% in some samples) are random strings, between 7 to 15
>> characters long, sometimes longer.  I believe this is Chrome-style
>> probing to determine if there is NXDOMAIN redirection. A good
>> example of the tragedy of the commons, like water pollution and
>> climate change.
> 
> I will note that there have been quite a number of studies over the
> last 20 years that show > 95% of the queries are junk of one kind or
> another.  Someone mentioned Duane's nice paper.  But, this
> observation started with Brownlee, et.al.'s 2001 paper.  Point
> being, Chrome might cause some of this now, but it has been there
> long before Chrome started this particularly probing.

Chrome might cause some of this? That is quite an understatement. If the number 
is around 50%, it is not "some of this". If this 50% disappears, the rest of 
the crap will still be there, and will probably be still > 90 %.

> What's more... in my rudimentary poking of the DITL data [*] it
> seems that 25-50% of the "resolvers" that query the root *never*
> send a legit query.  I.e., we can't ascribe a lot of this junk to
> resolvers that could just work better somehow.

and what percentage of traffic do these 25-50% resolvers account for? 

Roy

> 
> [*] There may be numbers on this sort of thing in the Brownlee,
>Wessels, etc. papers ... I just can't recall them off the top of
>my head.
> 
> allman
> 
> --
> https://www.icir.org/mallman/
> @mallman_icsi
> ___
> 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] Root-servers returning TC=1 after 5 NXDOMAINS

[ Roy Arends]

 On 10 Feb 2015, at 14:06, Emil Natan shly...@gmail.com wrote:
 
 If this is an issue with the F-root only it would be easier to use hints file 
 with the F excluded instead of managing local root zone and keeping it up to 
 date.

Doesn’t work with all resolvers: some will ask a server in the hints what the 
root-servers are, and so F will be right back in the picture.

Roy


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Root-servers returning TC=1 after 5 NXDOMAINS

[ Roy Arends]

 On 10 Feb 2015, at 11:02, bert hubert bert.hub...@netherlabs.nl wrote:
 
 Hi everybody,
 
 Recently at a large deployment, we ran into f.root-servers.net returning
 TC=1 to all our queries. We took this up with ISC who quickly informed us
 that this is a setting they run with if you exceed more than 5 NXDOMAIN
 responses/s.
 
 The installation in question services millions of subscribers, and sadly
 gets a lot of silly queries which leak to the root. We're unsure how to
 stay below 5 NXDOMAINs/s permanently.
 
 You can reproduce this behaviour like this:
 
 $ for a in {1..10}; do dig www.no-such-tld-$a -4 @f.root-servers.net ; done  
 log
 $ grep -E 'TCP|status:' l
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 54154
 (...)
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 4798
 ;; Truncated, retrying in TCP mode.
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 1549
 
 We've since tried to curtail our queries to the root severly, but we still
 get TC=1 responses a lot, which slows down our resolution.

Have you thought about running a local copy of the root zone?

 We shared our concerns with ISC, but it might be good to have a broader
 discussion on if it makes sense to set the bar so very low.

It doesn’t make sense to set the bar low on a single instance. What might 
happen is that due to some server selection algorithm, this server gets a 
penalty and the resolver flocks to other root-servers.

Roy



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Root-servers returning TC=1 after 5 NXDOMAINS

[ Roy Arends]

 On 10 Feb 2015, at 12:40, bert hubert bert.hub...@netherlabs.nl wrote:
 
 On Tue, Feb 10, 2015 at 11:34:35AM +, ? Roy Arends wrote:
 We've since tried to curtail our queries to the root severly, but we still
 get TC=1 responses a lot, which slows down our resolution.
 
 Have you thought about running a local copy of the root zone?
 
 More frequently now, yes. But I wonder if that is the intention. Is there an
 official policy on root-servers that allow AXFR yet?

Not sure if there is.

 Can one count on this
 working?

Not sure on that either.

I fetch my local copy here: ftp://rs.internic.net/domain/root.zone

Has been working for years.

 
 We shared our concerns with ISC, but it might be good to have a broader
 discussion on if it makes sense to set the bar so very low.
 
 It doesn’t make sense to set the bar low on a single instance. What might
 happen is that due to some server selection algorithm, this server gets a
 penalty and the resolver flocks to other root-servers.
 
 The penalty of TCP/IP by the way is so slight this does not change
 nameserver selection in my case. If you'd count the cost of the original
 query PLUS the TC=1 redirect, it might matter a bit more.

Ack.

Roy


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] AAAA record for c.root-servers.net

[ Roy Arends]

On 28 Mar 2014, at 16:59, Barber, Piet pbar...@verisign.com wrote:

 Try now. 

Not here yet:

wget -O- http://www.internic.net/domain/named.root
--2014-03-28 17:01:53--  http://www.internic.net/domain/named.root
Resolving www.internic.net... 192.0.32.9, 2620:0:2d0:200::9
Connecting to www.internic.net|192.0.32.9|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3048 (3.0K) [text/plain]
Saving to: `STDOUT'

 0% [   

] 0 
  --.-K/s  ;   This file holds the information on root 
name servers needed to
;   initialize cache of Internet domain name servers
;   (e.g. reference this file in the cache  .  file
;   configuration file of BIND domain name servers).
;
;   This file is made available by InterNIC 
;   under anonymous FTP as
;   file/domain/named.cache
;   on server   FTP.INTERNIC.NET
;   -OR-RS.INTERNIC.NET
;
;   last update:Jan 3, 2013
;   related version of root zone:   2013010300
;
; formerly NS.INTERNIC.NET
;
.360  IN  NSA.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.  360  A 198.41.0.4
A.ROOT-SERVERS.NET.  360    2001:503:BA3E::2:30
;
; FORMERLY NS1.ISI.EDU
;
.360  NSB.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.  360  A 192.228.79.201
;
; FORMERLY C.PSI.NET
;
.360  NSC.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.  360  A 192.33.4.12
;
; FORMERLY TERP.UMD.EDU
;
.360  NSD.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.  360  A 199.7.91.13
D.ROOT-SERVERS.NET.  360    2001:500:2D::D
;
; FORMERLY NS.NASA.GOV
;
.360  NSE.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.  360  A 192.203.230.10
;
; FORMERLY NS.ISC.ORG
;
.360  NSF.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.  360  A 192.5.5.241
F.ROOT-SERVERS.NET.  360    2001:500:2F::F
;
; FORMERLY NS.NIC.DDN.MIL
;
.360  NSG.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.  360  A 192.112.36.4
;
; FORMERLY AOS.ARL.ARMY.MIL
;
.360  NSH.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.  360  A 128.63.2.53
H.ROOT-SERVERS.NET.  360    2001:500:1::803F:235
;
; FORMERLY NIC.NORDU.NET
;
.360  NSI.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.  360  A 192.36.148.17
I.ROOT-SERVERS.NET.  360    2001:7FE::53
;
; OPERATED BY VERISIGN, INC.
;
.360  NSJ.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.  360  A 192.58.128.30
J.ROOT-SERVERS.NET.  360    2001:503:C27::2:30
;
; OPERATED BY RIPE NCC
;
.360  NSK.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.  360  A 193.0.14.129
K.ROOT-SERVERS.NET.  360    2001:7FD::1
;
; OPERATED BY ICANN
;
.360  NSL.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.  360  A 199.7.83.42
L.ROOT-SERVERS.NET.  360    2001:500:3::42
;
; OPERATED BY WIDE
;
.360  NSM.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.  360  A 202.12.27.33
M.ROOT-SERVERS.NET.  360    2001:DC3::35
; End of File
100%[==]
 3,048   --.-K/s   in 0s  

2014-03-28 17:01:54 (6.32 MB/s) - `-' saved [3048/3048]

Roy

 
 
 On 3/28/14, 11:28 AM, Chris Thompson c...@cam.ac.uk wrote:
 
 An  record for c.root-servers.net (2001:500:2::c) has appeared in the
 zone and in the additional section of priming responses from the root
 servers,
 but ftp://{ftp,rs}.internic.net/domain/named.{cache,root} do not include
 it yet.
 
 Should I just wait patiently until they do?  :-)
 
 -- 
 Chris Thompson   University of Cambridge Computing Service,
 Email: c...@ucs.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue,
 Phone: +44 1223 334715   Cambridge CB3 0RB, United Kingdom.
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
 
 ___
 dns-operations mailing list

Re: [dns-operations] Atlas Probe - Result question hostname.bind = clboh-dns-cac-307

[ Roy Arends]

There is a hostname named: clboh-dns-cac-307.ohiordc.rr.com, with address 
65.24.26.42, also in Ohio.

Maybe related?

Roy

On 07 Feb 2014, at 16:27, Chris Baker cba...@dyn.com wrote:

 Hello Everyone,
 
 I have been running a collection of US Atlas probe CHAOS queries for the 
 hostname.bind of our anycast announced nameserver IPs to get a sense for what 
 is reaching what name server. One of the probes has an interesting response.
 
 Probe ID : 14064
 Firmware Version : 4580 Hosted by Komodo Labs : Springsboro, Ohio 
 The results I am getting from the CHAOS query for hostname.bind @ 
 208.78.70.34 is below
 
 hostname.bind. 0 CH TXT clboh-dns-cac-307 
 
 I was wondering if anyone else had experienced similar oddities and if they 
 were traced back to a specific provider, device, … etc
 
 Thank you all for your time,
 Chris Baker
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNSSEC at ICANN: still no check?

[ Roy Arends]

I don’t understand the problem. Do you expect nic.red to be dnssec-signed?

Roy

On 20 Jan 2014, at 16:10, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 .red and .rich both have a nic.$TLD which is unsigned. The lack of DS
 is not validated, since only one NSEC3 is returned. It seems similar
 to the problem of .онлайн / .xn--80asehdb three months ago.
 
 % dig SOA nic.red
 
 ;  DiG 9.8.4-rpz2+rl005.12-P1  SOA nic.red
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 52972
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;nic.red. IN SOA
 
 ;; Query time: 879 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Jan 20 17:09:05 2014
 ;; MSG SIZE  rcvd: 36
 
 % dig DS nic.red 
 
 ;  DiG 9.8.4-rpz2+rl005.12-P1  DS nic.red
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34835
 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;nic.red. IN DS
 
 ;; AUTHORITY SECTION:
 red.  82 IN SOA a0.nic.red. noc.afilias-nst.info. (
   100061 ; serial
   10800  ; refresh (3 hours)
   3600   ; retry (1 hour)
   2764800; expire (4 weeks 4 days)
   900; minimum (15 minutes)
   )
 red.  82 IN RRSIG SOA 7 1 86400 20140210022600 (
   20140120012600 31835 red.
   U4a3e+kX3o8kRxqulzS+RdEplbqg4ZwqT98q3NgGZUVY
   jaYoO9xu4jJ9ynIMb+v0BkhfrOeFIwKFt7KL8s8qKSbi
   FVJRFliCCSDJF7A+KKI96DltInT7D26XaIxPQQVnj/F6
   G2MFJ/SKn5Iy4X8KENPNK9H9TuygMZSdiCxMA8U= )
 4iafiqi7pvouh4fbdvcmrap96fj3lefb.red. 82 IN RRSIG NSEC3 7 2 900 
 20140210022600 (
   20140120012600 31835 red.
   Px2DkjVJsutn2Xu/Hzf2h1VCseQdURaAqdLNHp3OYzMd
   c4koecXH/yWeqSv9w9UhJWd2ksxTihkjoq3nz7GezL03
   1E5XgReyte0JYNlILdTUOD8CJmsN+/hPYGSX16NeWnn9
   poGcDOmoAPUn0x4ywlR7lAHEITPlDXxV3p8am+A= )
 4iafiqi7pvouh4fbdvcmrap96fj3lefb.red. 82 IN NSEC3 1 1 1 D399EAAB 
 6EIVIDT04UJLNSB9HA6K5QRIKLTRRA49
 
 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Mon Jan 20 17:09:26 2014
 ;; MSG SIZE  rcvd: 496
 
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNSSEC at ICANN: still no check?

[ Roy Arends]

On 20 Jan 2014, at 16:29, Stephane Bortzmeyer bortzme...@nic.fr wrote:

 On Mon, Jan 20, 2014 at 04:24:53PM +,
 ? Roy Arends r...@dnss.ec wrote 
 a message of 121 lines which said:
 
 I don’t understand the problem. Do you expect nic.red to be
 dnssec-signed?
 
 Not at all. I expect its non-signature to be validated, but it isn’t.

A, gotcha.

The problem is indeed the absence of type NS in the type bit maps, as you (and 
Peter van
Dijk) showed in your previous mail.

According to RFC5155:

8.9.  Validating Referrals to Unsigned Subzones

   The delegation name in a referral is the owner name of the NS RRSet
   present in the authority section of the referral response.

   If there is an NSEC3 RR present in the response that matches the
   delegation name, then the validator MUST ensure that the NS bit is
   set and that the DS bit is not set in the Type Bit Maps field of the
   NSEC3 RR. 


“Must ensure that the NS bit is set and that the DS bit is not set”.

Good catch.

Since NS bit wasn’t set in the NSEC3 record…


Roy





 
 
 % dig SOA nic.red
 
 ;  DiG 9.8.4-rpz2+rl005.12-P1  SOA nic.red
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 54620
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;nic.red. IN SOA
 
 ;; Query time: 712 msec
 ;; SERVER: ::1#53(::1)
 ;; WHEN: Mon Jan 20 17:29:20 2014
 ;; MSG SIZE  rcvd: 36
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] to RD or not to RD, that is the question.

[✅ Roy Arends]

On 25 Nov 2013, at 16:15, Alex Nicoll anic...@cert.org wrote:

 I find myself in a bit of a quandary, and so I thought I'd turn to the gurus 
 here for some help.
 
 I needed to do some basic DNSSEC testing on a domain, and began by grabbing a 
 list of the authoritative name servers for the domain.  I then queried each 
 name server for some basic records that I know exist (SOA, A records, etc) to 
 get ensure the RRSIGs come back and can be validated.  On 7 of the 10 
 authoritative name server, I can query WITHOUT using the RD flag in the 
 message header, and get the expected results.  On the other three, querying 
 without the RD flag yields no records, but also no error.  When querying the 
 three WITH the RD flag, I get the expected responses.
  
 
 As far as I can understand the RFCs, all authoritative name servers should 
 have a local copy of the zone, which means that they should be able to answer 
 the queries without recursion.  Is this a correct assumption?

That is a correct assumption. As far as I understand, an authoritative server 
satisfies three requirements. 1) the domain in question is delegated to the 
server in question by its parent. 2) the server in question responds with the 
AA bit, or responds with a delegation to the next level 3) the server in 
question is configured to serve the zone in question.

Can you share the domain in question with the list? It often helps to get a 
confirmation of the data that you see.

   If it isn't, then I need to modify my scan script, but if it is, can I 
 assume that means the nameservers need to be fixed, or at least marked 
 non-authoritative?

There is quite a lot of brokeness in the world of DNS. Without data to check, 
it might be that your script needs work, the servers need work, the network 
between the two needs work, or all three :-).

Hope this helps,

Roy


 
 Thanks!
 
 -Alex 
 
 Vaporware:  A much discussed piece of software that doesn’t actually exist.
 Cloud:  Condensed Vapor.
 
 
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] 20130625 survey version.bind

[Roy Arends]

cute:

   '\; DROP DATABASE mysql\; --

Also:
Пошли нахер

UTF-8 in a txt record! Well done. (don't translate, nsfw)

Roy

On Jun 26, 2013, at 1:45 AM, Jared Mauch ja...@puck.nether.net wrote:

 The openresolver project surveyed version.bind from those resolvers that 
 respond from port 53 based on the 20130616 dataset.
 
 I know this will be of value to some people in understanding what resolvers 
 may be reaching their systems.
 
 Here are the results:
 
 http://openresolverproject.org/version.bind.20130616.20130625.parsed.txt
 
 Enjoy!
 
 - Jared
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] A question about changing nameservers

[Roy Arends]

On May 28, 2013, at 11:07 AM, Feng He fen...@nsbeta.info wrote:

 Hello,
 
 My platform DNSbed.com has cloudwebdns.com as the nameserver domain.
 The DNS of cloudwebdns.com is currently hosted by:
 dns1.registrar-servers.com.
 dns2.registrar-servers.com.
 dns3.registrar-servers.com.
 dns4.registrar-servers.com.
 dns5.registrar-servers.com.
 
 Today I changed the nameservers to our own nameservers:
 ns1.cloudwebdns.com.
 ns2.cloudwebdns.com.
 ns3.cloudwebdns.com.
 ns4.cloudwebdns.com.
 
 I have added the zone to named.conf, created zone files, and reloaded BIND. 
 But when I added a record by nsupdate, it got the error:
 
 response to SOA query was unsuccessful
 
 When I dig to localhost:
 dig cloudwebdns.com soa @localhost
 
 Got the status ServFail.
 
 Can you tell me what has happened?

It seems that ns1/ns2/ns3/ns4.cloudwebdns.com is indeed now serving dnsbed.com.
If you want to update the zone 'dnsbed.com', nsupdate will try to find the 
primary authoritative server, by issuing an SOA record for dnsbed.com, which 
results in:

dnsbed.com. SOA ns0.cloudwebdns.com. {etc,etc}

So, that response obviously worked, however, nsupdate will now try to send an 
update to ns0.cloudwebdns.com. (209.141.56.35).

That address (209.141.56.35) is not publicly responding for dns. So, unless 
your localhost interface is on that exact system (209.141.56.35), you won't get 
a response from ns0.cloudwebdns.com.

Hope this helps, but I might be on the wrong track here. 

Roy





___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Querying version.bind illegal?

[Roy Arends]

On May 23, 2013, at 2:39 PM, Vitalie Cherpec vita...@penguin.ro wrote:

 Hi,
 
 I've developed a DNS checking tool (http://www.dnsinspect.com/). 
 After 5 years of running it without any issues, I've received today a
 compliant through my ISP from a big company in a foreign country.
 
 They pretend that my VPS is attacking their infrastructure while
 querying their DNS server's version and this request can be regarded
 as cyber-terror attack (my tool tries only to warn users exposing the
 DNS software version).
 
 I've blacklisted their DNS servers from being queried in the future,
 but I would like to know if querying version.bind is illegal (in
 some countries)?

I have not heard of this being illegal.

This is not legal advice.

Roy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] open resolver versio.bind responses

[Roy Arends]

On Apr 16, 2013, at 1:21 PM, Jared Mauch ja...@puck.nether.net wrote:

 Greetings,
 
 I took the latest 'Open Resolver' list and queried the hosts another time 
 with a version.bind query.
 
 You can view the results here:
 
 http://openresolverproject.org/version.bind.report.txt

Interesting list. I assume that some resolvers are actually happy to try and 
resolve version.bind chaos txt on your behalf, and so you might see the 
version.bind response from either the IANA roots or some alternative servers.

Roy 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] open resolver versio.bind responses

[Roy Arends]

On Apr 16, 2013, at 3:46 PM, Joe Abley jab...@hopcount.ca wrote:

 
 On 2013-04-16, at 10:39, Roy Arends r...@dnss.ec wrote:
 
 Interesting list. I assume that some resolvers are actually happy to try and 
 resolve version.bind chaos txt on your behalf, and so you might see the 
 version.bind response from either the IANA roots or some alternative servers.
 
 Is there actually any resolver that will do a recursive lookup for a CH class 
 query?

Never underestimate the …. oh never mind :-)

 Where would they find a delegation? There are no CH class hints to use..

They wouldn't, they assume that locally configured root-hints are responsible 
for all other classes as well.

Roy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Recently closed open resolver and reflection attacks

[Roy Arends]

On Mar 7, 2013, at 7:06 AM, Edward Lewis ed.le...@neustar.biz wrote:

 
 On Mar 6, 2013, at 20:33, Paul Vixie wrote:
 if the authority server in question is configured to be a primary or 
 secondary server for a zone which is at or above the qname, then the correct 
 answer is either authoritative-positive, authoritative-negative, or servfail.
 
 Or a non-authoritative referral but then again there's also FROMERR and come 
 to think of it other results involving CNAME, DNAME and even a wildcard match.
 
 I have over time tried to come up with a state machine description of what 
 DNS returns but never could complete the task.  The protocol is too 
 hap-hazzard in architecture to be nicely reverse engineered.  Sigh.
 
 if said authoritity server is not configured to be a primary or secondary 
 for any zone at or above the qname, then the proper response is refused. 
 (not an upward delegation as a i once had it in bind8 -- my apologies to 
 all.)
 
 We chose SERVFAIL instead of REFUSED for that - in the sense that the service 
 failed by sending the querier to the wrong place.  I don't think either is 
 better than the other, just saying this because it's not always clear what's 
 the right RCODE.

We often see resolvers trying the next authoritative server for a domain when a 
server responds with SERVFAIL, and eventually comes back when all other servers 
respond with SERVFAIL, repeating the query over and over[1]. When a server 
responds with REFUSED, we do not see that behaviour, and our expectation is 
that for the time being, the REFUSED issuing server is not consulted for a 
specific domain.

Requests to a server for a domain that it is not responsible for, should not 
return servfail, as that would cause well behaving resolvers to come back for 
requests for that domain, as SERVFAIL indicates (again, imho) a temporal 
failure. 

To classify behaviour I often see, the bulk of well behaving resolvers behave 
in the following way:

SERVFAIL: Keep the server in the server selection set, try others first.
REFUSED, NOTIMP, FORMERR: Remove the server from the server selection set, try 
others.

I have not seen any real distinguishable different behaviours between refused, 
notimp and formerr, other than queries logged. 

Hope this helps,

Roy

[1] BIND responds with SERVFAIL to a query where the QNAME is longer than 255 
bytes. When all the servers for a domain are BIND, this often leads to a burst 
of requests, striped over all the authoritative servers for that domain. 
Naturally, a resolver should not emit a query with a QNAME longer than 255 
bytes, however, we do not choose the resolvers we respond to, and thus simply 
deal with these bursts. A FORMERR would (imho) be the appropriate response. 

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Massive DNS poisoning attacks in Brazil

[Roy Arends]

dnssec-trigger is your friend.

Roy

Sent from my iPhone

On 2 Oct 2012, at 20:54, Paul Vixie p...@redbarn.org wrote:

 On 2012-10-02 7:48 PM, Warren Kumari wrote:
 DNSSEC on the *host / stub* would have though.
 
 this doesn't work at the moment, even when there's code on the stub that
 supports it, which is rare and experimental. i occasionally turn on a
 recursive name server on my laptop, but it's very rare that udp/53 is
 allowed through a wireless gateway in a hotel or coffee shop, and when
 it is, edns usually triggers an immune response because the gateway
 knows that additional data sections of queries are empty. when this
 doesn't fail, the multipacket response is damaged by dropping all
 fragments after the first one.
 
 if ietf hadn't declared the dns protocol finished, and were not even now
 working to close up the dnsext working group, i'd propose that we
 develop a standard for carrying edns over tcp/80 and/or tcp/443, which
 is for most mobile users what the internet consists of.
 
 i'm not sure how we expect DANE to make any difference when we don't
 have working last mile DNSSEC.
 
 paul
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Name server turning off RD bit in response - just curious

[Roy Arends]

There is a little bit more off:

1) All classes are converted to 'IN', try dig with CLASS12345 (or any class 
other than 1) and you'll get
;; Question section mismatch: got name-services.com/A/IN

2) single label qnames often get expanded weirdly

dig @dns5.name-services.com com

;  DiG  @dns5.name-services.com com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 62972
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;com.   IN  A

;; ANSWER SECTION:
:\005com.\005com.   3600IN  A   69.64.147.243

(first character looks random)

No doubt there is more unexpected random behaviour. 

Roy

On Aug 7, 2012, at 1:40 PM, Faasen, Craig craig.faa...@roche.com wrote:

 Hello,
 
 I noticed that the rd flag was missing from the output of a standard 
 (recursive) dig against some (*) of the name-services.com name servers:
 $ dig @dns5.name-services.com. name-services.com. | grep flags
 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
 
 (*) dns1 and dns5 show this behavior, dns2-4 are normal.
 
 Using dig.pl (Net::DNS::Toolkit):
 $ dig.pl -h @dns5.name-services.com. name-services.com.
 
  ID  = 4439
  QR  = 0
  OPCODE  = QUERY
  AA  = 0
  TC  = 0
  RD  = 1
  RA  = 0
  Z   = 0
  AD  = 0
  CD  = 0
  RCODE   = NOERROR
  QDCOUNT = 1
  ANCOUNT = 0
  NSCOUNT = 0
  ARCOUNT = 0
 
  ID  = 4439
  QR  = 1
  OPCODE  = QUERY
  AA  = 1
  TC  = 0
  RD  = 0
  RA  = 0
  Z   = 0
  AD  = 0
  CD  = 0
  RCODE   = NOERROR
  QDCOUNT = 1
  ANCOUNT = 1
  NSCOUNT = 5
  ARCOUNT = 5
 
 ;  dig.pl 1.11  -h @dns5.name-services.com. name-services.com.
 ;;
 ;; Got answer.
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4439
 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
 
 snip
 
 RD is set to 1 in the query, but is 0 in the response.
 Which is not compliant with RFC 1035: RD Recursion Desired - this bit may be 
 set in a query and is copied into the response.
 
 Out of curiosity, any idea why a name server would want to change the RD bit 
 ? (except to break an unsuspecting script ;)
 
 Thanks and regards,
 -- craig
 
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs