Re: [dns-operations] Malware Increasingly Uses DNS as Command and Control Channel to Avoid Detection, Experts Say

[Florian Weimer]

* Bill Owens:

> On Thu, Mar 08, 2012 at 03:00:00PM +0100, Stephane Bortzmeyer wrote:
>> Anyone has details, published results, etc?
>> 
>> IRC is so 20th century, no wonder the zombies now use the DNS to talk
>> together :-)
>
> I think this is the presentation:
>
> http://pen-testing.sans.org/blog/2012/03/07/emerging-attack-vectors-rsa-slide-deck
>
> No real details though. . .

It seems sufficient, though: it's just a prediction, based on some
proof-of-concept tool.
___
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] dns-operations@lists.dns-oarc.net

[Florian Weimer]

* Chris Adams:

> At that point, random botnets are not the problem.  If you get an
> excessive number of queries from a customer, you can shut off the
> customer (because either they have broken software  or they're infected).

This is not what happens in practice because query anomalies tend to
come in clusters, either because customers in the same region tend to
pick up similar malware or because they deliberately use the same
nominally non-malicious software which exhibits query anomalies
(perhaps because you've shipped it to them yourself).

Reflection through broadband routers is a possibility as well,
unfortunately.
___
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] Why would an MTA issue an ANY query instead of an MX query?

[Florian Weimer]

* Kyle Creyts:

> Wouldn't an ANY query to a recursive ONLY return the cached records?

This is implementation-dependent, and you can make sure that the cache
contains sufficient amounts of data anyway.
___
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] dns response rate limiting (DNS RRL) patch available for testing

[Florian Weimer]

* Paul Vixie:

> Vernon Schryver and Paul Vixie have been working on DNS Response Rate
> Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we
> are ready for broader external testing.

It seems rather straightforward to force recursive resolvers to hit
the rate limit.  Why isn't this a problem?
___
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] Why would an MTA issue an ANY query instead of an MX query?

[Florian Weimer]

* Vernon Schryver:

> Emergency patches against ANY to last for a day or two for lack of
> other available tools can make good sense--for a day or so.  But
> spending any long term effort on ANY queries in this context is the
> same "thinking" that brought us SPF as the final ultimate solution
> to the spam problem (FUSSP), because as we all "knew," spam requires
> forged senders.

But unlike spam, these attacks require spoofed source addresses.

Perhaps it's time to admit defeat, call our legislators, and suggest
that they mandate source address validation by service providers.
___
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

[Florian Weimer]

* Craig Faasen:

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

By the way, you should clear the RD bit when querying authoritative
servers.  Setting the RD bit increases the rate of SERVFAIL answers,
compared to queries without the RD bit.
___
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] go daddy refuses to register NS not otherwise associated with go daddy controlled domains

[Florian Weimer]

* Joe Abley:

> This is not very easy to explain, even to people who are
> technologists, so it seems slightly unfair to apportion all the
> blame for the situation on any particular registrar (particularly
> one whose business model is all about hiding complicated details and
> making things easy for non-technical customers).

Isn't it actually pretty simple?

With the old, pre-DNSSEC ATLAS implementation and the prevalent
recursor behavior, these checks were necessary so that you couldn't
take over subdomains of your choice.  I wouldn't rule out that they
still serve a similar purpose today.

Better checks are not possible because the registrar doesn't know if
domain1.example and domain2.example really belong to the same entity
(so that it is kosher to add glue for ns3.domain2.example along with
domain1.example), even when they are maintained from the same account.
It could be a reseller who represent multiple, unrelated customers.
___
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] dotless domains

[Florian Weimer]

* Paul Vixie:

> those are country code top level domains. cctld's enjoy national
> sovereignty

Uhm, most of them are companies, and not subjects of international
law.  Few of them, however, have entered binding contracts with ICANN.
___
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] AT&T DNS Cache Poisoning?

[Florian Weimer]

* Tim Huffman:

> Any ideas what I can do to help my customer? This is the first time
> we've ever had something like this...

Have you checked if other domains you host are affected in a similar
way?
___
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] AT&T DNS Cache Poisoning?

[Florian Weimer]

* Stephane Bortzmeyer:

> On Sun, Oct 28, 2012 at 02:22:04AM -0400,
>  Paul Wouters  wrote 
>  a message of 20 lines which said:
>
>> You missed the announcement of the 450 million downloads by iOS6 of
>> the IANA root key?
>
> Poisoning the cache of an one-user iPhone is fun but less useful than
> poisoning the caches of AT&T, Verizon or Comcast...

If that was the case, we wouldn't have deployed DNSSEC, but reduced
the impact of cache poisoning. 8-/

(You could reuse the same upstream response for X downstream
responses, requery upstream if that limit is reached, and double the
limit each time the upstream response matches what you've seen before,
otherwise you fall back to the start limit.)
___
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] First experiments with DNS dampening to fight amplification attacks

[Florian Weimer]

* Roland Dobbins:

> If the rate-limiting is based upon source IPs, then there's
> potentially a lot of state there.  If the rate-limiting is based
> upon the destination IP, then it guarantees that
> programmatically-generated attack traffic will 'crowd out'
> legitimate requests.

Reflection attacks do not use totally random source addresses, so the
typically state exhaustion vector does not necessarily apply.

(With IPv6, there more bits which could be abused for randomness, but
then, a contradiction between the specification and deployed stacks
make it impossible to serve IPv6 traffic in a stateless fashion, so
the entire discussion is pointless.)
___
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] BIND 9.7 was Re: what nameserver software have you been using?

[Florian Weimer]

* Feng He:

> 于 2012-12-17 23:37, Sebastian Wiesinger 写道:
>> The think is, new BIND versions on Debian are rare, and you're
>> shipping/building a lot of libs and tools with many dependencies so
>> building own packages is complicated.
>>
>> The next(!) stable version of Debian (wheezy) will have bind 9.8(!).
>
> How to make debian 6 to apt-get install BIND 9.8? Thanks.

Find a critical security bug whose fix cannot be backported to BIND
9.7.  Then we'll probably upgrade Debian 6 to BIND 9.8 (assuming that
it's fixed there).  This is what happened in DSA-2054 (for lenny).

Right now, staying with 9.7 has the advantage that we do not have to
issue security updates for broken features in 9.8 and later.  Even if
the bugs in the new code don't affect most users because these
features have to be enabled explicitly, they still have to be fixed at
the distribution level.
___
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] DNS ANY requests / UltraDNS

[Florian Weimer]

* Mark Andrews:

> Instead of just causing everyone to hack their code to force TCP
> just return NOERROR, TC=1 and legitimate client will fallback to TCP
> without all the other side effects of this ill considered change.

This will still break things because prior to the change, large
authoritative ANY responses are truncated without setting TC=1.  After
the change, large ANY responses enter the cache and trigger TC=1
responses to stub resolvers (recursors do not silently truncate ANY
responses, it seems), which may not be prepared to accept such large
responses (or even fall back to TCP).

Some breakage is unavoidable.  Considering that ANY queries rarely
give the results expected by the sender, refusing them outright makes
sense to me.
___
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] DNS ANY requests / UltraDNS

[Florian Weimer]

* Tony Finch:

> Florian Weimer  wrote:
>>
>> This will still break things because prior to the change, large
>> authoritative ANY responses are truncated without setting TC=1.
>
> That isn't true for BIND or ATLAS.

It seems to me it's true for BIND.  You can get much more data in the
additional section of the ANY response over TCP.  Without TCP, it is
simply left out.

I guess it would something like this (except that most BINDs out there
will do EDNS):

; <<>> DiG 9.8.4-P1 <<>> @ns1.msft.net +noedns +norecurse +notcp hotmail.com ANY
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46130
;; flags: qr aa; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;hotmail.com.   IN  ANY

;; ANSWER SECTION:
hotmail.com.3600IN  A   65.55.72.167
hotmail.com.3600IN  A   65.55.72.183
hotmail.com.3600IN  A   65.55.72.135
hotmail.com.3600IN  A   65.55.72.151
hotmail.com.172800  IN  NS  ns2.msft.net.
hotmail.com.172800  IN  NS  ns3.msft.net.
hotmail.com.172800  IN  NS  ns4.msft.net.
hotmail.com.172800  IN  NS  ns5.msft.net.
hotmail.com.172800  IN  NS  ns1.msft.net.
hotmail.com.86400   IN  SOA ns1.msft.net. 
msnhst.microsoft.com. 2012111201 1800 900 2419200 3600
hotmail.com.3600IN  MX  5 mx4.hotmail.com.
hotmail.com.3600IN  MX  5 mx1.hotmail.com.
hotmail.com.3600IN  MX  5 mx2.hotmail.com.
hotmail.com.3600IN  MX  5 mx3.hotmail.com.
hotmail.com.3600IN  TXT "v=spf1 
include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com 
include:spf-d.hotmail.com ~all"

;; ADDITIONAL SECTION:
ns2.msft.net.   3600IN  A   64.4.59.173
ns2.msft.net.   3600IN  2a01:111:2006:6::1:1
ns3.msft.net.   3600IN  A   213.199.180.53

;; Query time: 181 msec
;; SERVER: 65.55.37.62#53(65.55.37.62)
;; WHEN: Thu Jan 10 21:28:38 2013
;; MSG SIZE  rcvd: 512


; <<>> DiG 9.8.4-P1 <<>> @ns1.msft.net +noedns +norecurse +tcp hotmail.com ANY
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64401
;; flags: qr aa; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 58

;; QUESTION SECTION:
;hotmail.com.   IN  ANY

;; ANSWER SECTION:
hotmail.com.3600IN  A   65.55.72.183
hotmail.com.3600IN  A   65.55.72.135
hotmail.com.3600IN  A   65.55.72.151
hotmail.com.3600IN  A   65.55.72.167
hotmail.com.172800  IN  NS  ns1.msft.net.
hotmail.com.172800  IN  NS  ns2.msft.net.
hotmail.com.172800  IN  NS  ns3.msft.net.
hotmail.com.172800  IN  NS  ns4.msft.net.
hotmail.com.172800  IN  NS  ns5.msft.net.
hotmail.com.86400   IN  SOA ns1.msft.net. 
msnhst.microsoft.com. 2012111201 1800 900 2419200 3600
hotmail.com.3600IN  MX  5 mx4.hotmail.com.
hotmail.com.3600IN  MX  5 mx1.hotmail.com.
hotmail.com.3600IN  MX  5 mx2.hotmail.com.
hotmail.com.3600IN  MX  5 mx3.hotmail.com.
hotmail.com.3600IN  TXT "v=spf1 
include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com 
include:spf-d.hotmail.com ~all"

;; ADDITIONAL SECTION:
ns1.msft.net.   3600IN  A   65.55.37.62
ns1.msft.net.   3600IN  2a01:111:2005::1:1
ns2.msft.net.   3600IN  A   64.4.59.173
ns2.msft.net.   3600IN  2a01:111:2006:6::1:1
ns3.msft.net.   3600IN  A   213.199.180.53
ns3.msft.net.   3600IN  2a01:111:2020::1:1
ns4.msft.net.   3600IN  A   207.46.75.254
ns4.msft.net.   3600IN  2404:f800:2003::1:1
ns5.msft.net.   3600IN  A   65.55.226.140
ns5.msft.net.   3600IN  2a01:111:200f:1::1:1
mx4.hotmail.com.3600IN  A   65.54.188.110
mx4.hotmail.com.3600IN  A   65.54.188.126
mx4.hotmail.com.3600IN  A   65.55.92.168
mx4.hotmail.com.3600IN  A   65.55.92.184
mx4.hotmail.com.3600IN  A   65.55.37.88
mx4.hotmail.com.3600IN  A   65.55.37.104
mx4.hotmail.com.3600IN  A   65.55.37.120
mx4.hotmail.com.3600IN  A   65.5

Re: [dns-operations] DNS ANY requests / UltraDNS

[Florian Weimer]

* Tony Finch:

> Florian Weimer  wrote:
>>
>> It seems to me it's true for BIND.  You can get much more data in the
>> additional section of the ANY response over TCP.  Without TCP, it is
>> simply left out.
>
> Oh right, that's standard semantics, RFC 2181 section 9. I thought you
> were saying that the answer section was being truncated without setting
> TC.

And I'm not sure anymore that it matters because recursive resolvers
will message the additional section as needed, anyway.
___
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] responding to spoofed ANY queries

[Florian Weimer]

> The problem is amplification.

No, the actual problem is source address spoofing.

> It can only be mitigated.

The spoofing problem could be mitigated if we actually wanted to, and
were willing to punish those who try to send their pollution to the
rest of the network.

We just need to admit that self-regulation by the industry has failed
to address this matter adequately.
___
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] responding to spoofed ANY queries

[Florian Weimer]

* Paul Vixie:

>> The spoofing problem could be mitigated if we actually wanted to, and
>> were willing to punish those who try to send their pollution to the
>> rest of the network.
>
> no. there is no "we" in this context.

I meant the "we" in "we the people".  Punishment for community-harming
behavior should be the prerogative of the sovereign, anyway.

>> We just need to admit that self-regulation by the industry has failed
>> to address this matter adequately.
>
> and having so admitted, what will we do next or do differently?

We could lobby for law that makes those who push packets with forged
source addresses (so that original network operator cannot be
identified anymore) liable for the damage these packets cause.

> the internet is extra-legal because it is extra-national.

Doesn't really matter.  If a network peer doesn't have the same
liability as you do, you better put in filters.
___
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] DNS ANY requests / UltraDNS

[Florian Weimer]

* Mark Andrews:

> So now recursive servers need to try all the authoritative servers
> trying to get a find non broken server.  Then they will return SERVFAIL
> to the clients which you the hope will do something sensible with the
> SERVFAIL response.
>
> This is a DoS attack on the recursive resolvers.  STOP IT.

If BIND has a denial-of-service vulnerability, you need to fix it in
your code.  Anyone can serve a zone that triggers the vulnerability,
so begging authoritative server operators to play along nicely does
not solve the problem.
___
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] ID of IPv4 fragments and DNS and the future RFC

[Florian Weimer]

* Stephane Bortzmeyer:

> The future RFC 6864, currently in AUTH48 state, talks about the
> unicity of the ID (datagram identifier) field for IPv4. Its section
> 5.2 is of interest to us: basically, it says that senders of
> "non-atomic packets" (a non-atomic packet is an IPv4 packet which is
> fragmented or will possibly be, since it has no DF bit: unlike a HTTP
> server, the traffic of a DNS server is typically mostly made of
> non-atomic packets) MUST rate-limit such packets to enforce the old
> (RFC 791) rule that ID must be unique for the duration of a packet in
> the network (typically two minutes, a number I've always find very
> high).

A typical initial TTL is 64, so the packet lives for at most 64
seconds.  (Originally, the TTL was measured in seconds, and decrement
by at least 1 at every hop.)

> Is there a practical consequence for us?

Strictly speaking, it forbids stateless authoritative servers because
counters for rate limiting have to be recorded somewhere.

> My first guess is No since the unicity is only per couple {src,
> dest} and there is no chance a DNS server will have to send more
> than 6.4 Mbps to a given destination (6.4 is the maximum throughput
> with a 1500 B MTU with the ID unicity limit).

1000 responses per second doesn't seem that much, though.

(Fortunately, IPv6 comes with a 32 bit fragment ID...)
___
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] Enom's name server broken?

[Florian Weimer]

* Fan Of Network:

> I'd expect Enom to keep replying to queries as they used to before list of
> authoritative name servers for my domain was changed. In ideal world they
> should do that for TTL on parent server (here .com so 2 days)

In an ideal world, they would serve the new zone contents, with the
new NS RRset in particular. 8-)
___
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] Monday rant againt the uses of the Public Suffix List

[Florian Weimer]

* Vernon Schryver:

> It might also be worth noting that co.uk as well as com, org and
> the few other TLDs that I tried just now lack A, , and MX RRs,
> so a browser could use a DNS test to reject some supercookies.

Doesn't work.  There aren't address records for enyo.de, but I could
currently set cookies for .enyo.de in browsers.  The address records
rule would break that, and I'm sure some web sites rely on it.

> However, please pardon me for being too stupid and senile to
> understand a difference that matters to me as a user between
> legitimate and other kinds of third party cookies such as between
> an HTTP server at www.example.com setting a cookie for domain.com
> from the same HTTP server setting a cookie at com or co.uk.

It's true that for cookies, the public suffix list doesn't make that
much sense.  Direct cookie-based tracking is too visible and leads to
questions.  Different, domain-specific cookies which vary over time
can still be correlated in the backend and are vastly better in this
regard.

The public suffix list is still useful for URL bar highlighting and
browser extensions such as NoScript.  Those are fairly narrow
applications, though.

___
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] DNS Issue

[Florian Weimer]

* Joe Abley:

> The assumption is that "firewall" means "device that keeps
> state". This could be a firewall, or a NAT, or an in-line DPI
> device, or something similar. We're not talking about stateless
> packet filters.

I think you still can't serve UDP over IPv6 without per-client sate,
keeping both full RFC conformance and interoperability with the
existing client population.  Pre-fragmentation to 1280 or so bytes
isn't enough, you also have to generate atomic fragments.  But the
latter cannot be processed by some clients, so you cannot send out
atomic fragments unconditionally (even if there were a socket option
to do that).

Many large servers do not even pre-fragment to 1280 bytes, so they
rely on path MTU information in the destination cache for
communication with clients on sub-1500-MTU links.  I wonder when this
statefullness of IPv6 UDP traffic will cause practical problems,
probably as soon as the traffic levels exceeds what can be comfortably
kept in the server cache.

Enough ranting today.  I suspect this issue will only get addressed
when enough operators experience it first-hand, like the EDNS0
fallback issue.
___
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] DNS Issue

[Florian Weimer]

* Tony Finch:

> Florian Weimer  wrote:
>>
>> I think you still can't serve UDP over IPv6 without per-client sate,
>> keeping both full RFC conformance and interoperability with the
>> existing client population.  Pre-fragmentation to 1280 or so bytes
>> isn't enough, you also have to generate atomic fragments.
>
> Or don't fragment and restrict the EDNS buffer size to 1280.

Unfortunately, that's still not compliant.  Those responses can
trigger ICMP Packet Too Big messages, and then you're supposed to
generate atomic fragments (that is, send a single-packet unfragmented
response with a Fragmentation header).

It's one of those things in the IPv6 specification which should go,
but 6man *loves* them, unfortunately.

(By the way, if you've got a system which generates atomic fragments,
you should set a lower EDNS buffer size than 1280.)
___
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] Best Practices

[Florian Weimer]

* Paul Vixie:

>> a) Secure configuration guidelines (RRL you can't make part of that, because 
>> it requires too much tuning IMHO).
>
> rrl's defaults work fine on every authority server i've tried.

That's probably because those servers don't see traffic from resolvers
which in turn have clients that send queries which are a little bit
creative.

ISC-TN-2012-1 is unfortunately not very clear about the actual key
used to determine the bucket to account against.  Section 2.2.1 claims
that "many possible questions can yield the same answer" and suggests
that the rate limit applies to those "same answers" (which apparently
do not include the transaction ID or question section), but section
3.1 talks about the QNAME.
___
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] Best Practices

[Florian Weimer]

* Vernon Schryver:

>> ISC-TN-2012-1 is unfortunately not very clear about the actual key
>> used to determine the bucket to account against.
>
> What is the relevance of the shortcomings of
> http://ss.vix.su/~vixie/isc-tn-2012-1.txt to whether RRL works on
> authority (or even recursive**) servers without too much tuning?

I used it (perhaps naïvely) as the reference for the default settings
and their potential impact.  Is there a better source (except the
source code itself)?

>>   Section 2.2.1 claims
>> that "many possible questions can yield the same answer" and suggests
>> that the rate limit applies to those "same answers" (which apparently
>> do not include the transaction ID or question section), but section
>> 3.1 talks about the QNAME.
>
> It wouldn't make sense to rate limit based on transaction IDs,
> because they're supposed to be functionally unique.

Sure, I brought this up to point out that the "same answer" concept
needs explanation.

> The R in RRL stands for "response", and so rate limits should ignore
> the question section as much as possible.
> For non-empty, non-error, non-wildcard generated, non-referral
> responses, the key is {class,qname,qtype,client IP block}.

Okay, that makes sense, but contradicts the previous sentence.  I
don't quite get how you can ignore the question section, but extract
QNAME and QTYPE.

> Section 2.2.1 is about the special cases where answers are too similar.
> The rate limit for NXDOMAIN responsess is applied to the domain
> from the SOA, because response rate limiting would not be a useful
> DNS reflection attack mitigation mechanism if it treated the identical
> responses to the practically infinite number of different
> .example.com questions the same.

I'm worried what happens if I send garbage .example.com
queries through a legitimate resolver, and how that would imapct
(legitimate) queries for not-so-random.example.com.

> Recursive servers should generally not need RRL, because they
> shouldn't be open and so needn't worry about reflection DDoS
> attacks.

On the other hand, accidental DoS of resolver service triggered by
garbage queries from badly written clients is a problem, isn't it?
It's not something RRL intends to solve, but I worry that it makes
matters worse.
___
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] DNS Attack over UDP fragmentation

[Florian Weimer]

* Ondřej Surý:

> I think it should be quite safe to cap the maximum EDNS0 to 1280
> (the minimum IPv6 MTU) and set DF flag in all responses.

Setting the DF flag on responses will be counterproductive because you
must not perform path MTU discovery, either by disabling in the stack,
or by filtering the ICMP packets.  That part has been published as
well, it seems.

Anyway, that, plus lowering the MTU to 1200 or so, should do the
trick.  (I think 1280 is still a bit on the large side.)

Exploiting this vulnerability successfully over the Internet against
resolvers processing real-world traffic still seems difficult to me,
at least if the resolver uses the Linux TCP/IP stack.  This is not
completely idle speculation because some of us tried to implement this
attack several times over the past few years, putting in quite a bit
of effort and failed.  Compare this to the TTL evasion vulnerability,
for which attacks were really easy to implement.

(But keep in mind that other stacks have different beahviors and
defaults, and could well be much more vulnerable.)

On the other hand, if someone puts all the pieces together, and it
turns out that there is a combination of tweaks, zone- and
server-specific logic that actually works, changing server defaults in
a security update to reduce the maximum EDNS buffer size to 1200 bytes
by default, and modifying the server (and kernel) to ignore path MTU
information when sending packets, is a workable response.
Consequently, I haven't pushed for a more proactive approach to this
vulnerability so far.

Deploying IPv6 also happens to help, due to the increased fragment ID
size.  Like reflective denial-of-service attacks, this potential
attack could be greatly mitigated by source IP address validation at
the ISP level.
___
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] DNS Attack over UDP fragmentation

[Florian Weimer]

* Paul Vixie:

> how much more money, brains, and time are we going to collectively waste
> on dns (so, a WOMBAT) to solve the problems dnssec solves, rather than
> just deploying dnssec?

Because DNSSEC does not prevent cache poisoning, it only detects it.
Once your cache is poisoned, it is difficult to continue.  I doubt
many resolvers can tell a successful cache poisoning attack from a
plain old mis-signed zone or other DNSSEC mishap.  Unbound tries to do
better, but the protocol makes that ridiculously difficult because
it's so hard to obtain signatures of the name servers you want to
query.  In retrospect, not signing delegations and glue was a huge
mistake.
___
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] DNS Attack over UDP fragmentation

[Florian Weimer]

* Mark Andrews:

> In message <20130906074928.ga19...@nic.fr>, Stephane Bortzmeyer writes:
>> The way I understand it: with Kaminsky and/or Shulman, you can still
>> poison a DNS cache. The downstream validating resolver will detect it
>> and send back SERVFAIL to the end user. But this end user won't be
>> able to connect to his/her bank.
>
> Well if you only half deploy DNSSEC this will happen.

Well, there aren't any plans to sign ROOT-SERVERS.NET, are there?

So even a hypothetical resolver that avoids long-term caching of bad,
DNSSEC-signed data will still go belly-up if it ever learns incorrect
address information for the root zone.

Now you can special-case ROOT-SERVERS.NET, but it's quite common to
host the name servers in unsigned zones (GTLD-SERVERS.NET, NSTLD.COM,
GOV-SERVERS.NET, GTLD.BIZ, and so on).

> Proper deployment of DNSSEC requires that the cache does validation.

Well, I guess that's progress. :-)
___
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] DNS Attack over UDP fragmentation

[Florian Weimer]

* Daniel Kalchev:

> Might be the appropriate time to think how to depend less on caching
> is now?  Or cache only after validation?

It's certainly possible to reduce caching for unstable data.  Say you
use a certain piece of cached information four times initially, then
you revalidate.  If the data stays the same, you then use it the
cached copy eight times, then sixteen and so on.  On a change, you
fall back to caching it for four uses.

Tricky parts is how you revalidate—based on the current cache
contents, or the cache contents when the record was first cached?
Which one is more secure?

Despite this elaborate description, this approach is in its effect
quite close to sending every query twice and caching the response only
if both responses are equivalent.  Otherwise, you'd use the response
just once.
___
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 and Re: DNS Attack over UDP fragmentation

[Florian Weimer]

* Edward Lewis:

> The above has a few non-sequiters.  First, yes, the cache poisoning
> is prevented, after it is detected.  What you are complaining though
> is that this means the end user is blocked from reaching the desired
> service - as a result of the poisoning being thwarted.

Yes, that's what would happen.

I just want to point out that *if* there's a trivial spoofing attack
(comprising a few thousand packets, but not billions) against DNS, we
still have a problem.  DNSSEC is not a cure for problems on the
transport layer or below.
___
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] Should medium-sized companies run their own recursive resolver?

[Florian Weimer]

* Paul Hoffman:

> A fictitious 100-person company has an IT staff of 2 who have
> average IT talents. They run some local servers, and they have
> adequate connectivity for the company's offices through an average
> large ISP.
>
> Should that company run its own recursive resolver for its
> employees, or should it continue to rely on its ISP?

Insufficient data, I would say.  If their devices do not have some
built-in caches, supplying a local cache can clearly be beneficial.

There might be some reason to run an authoritative server for internal
zones (forward or reverse), and then you need a local resolver to
inject your data.

But it's also likely that their DHCP solution comes with some DNS
cache.  If it doesn't and it unconditionally hands out ISP resolver
addresses, they may need quite a bit more than just a local DNS
resolver or two to actually convince their devices to use their own
resolvers.
___
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] Should medium-sized companies run their own recursive resolver?

[Florian Weimer]

* David Conrad:

> Running a recursive server is (should be) far easier than running
> the vast majority of other "local servers".  If it isn't, they're
> using the wrong recursive server.  With the exception of root key
> rollover, running a recursive server is a fire-and-forget type
> service (modulo some initial configuration to avoid being an open
> resolver).

There's a tendency to selectively block DNS traffic, which can be a
pain to debug.  Various network issues might only affect DNS recursor
traffic.

I agree that on a clean network, a DNS recursor should be easy to set
up and maintain, but you often learn after the fact that your network
isn't so clean after all. :-(
___
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] Should medium-sized companies run their own recursive resolver?

[Florian Weimer]

* Vernon Schryver:

> The question had nothing to do about J. Sixpack with 37 televisions,
> phones, and other devices behind a NAT router owned by and remotely
> maintained by Comcast.

Perhaps because they are already running a DNS cache on the local
network. :-P
___
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] Can MX be working with CNAME?

[Florian Weimer]

* Paul Vixie:

> while it's true that it is worse to have a cname used to link an MX to
> its target, it is not true that pointing a CNAME at an MX will nec'ily
> end well. in the above example, Sendmail in its default configuration
> will rewrite on the next hop the From: header so that it shows
> @plus-china.l.google.com.

That's a sendmail bug.  But RFC 1123 actually requires that you
rewrite the MAIL FROM and RCPT TO arguments in the SMTP envelope (see
section 5.2.2).

> i think this is not the behaviour that google's trying to achieve
> here. and Sendmail may or may not be wrong to rewrite headers, but
> it's the default config, just the same.

Wrong for headers, right for the envelope, historically speaking.
According to RFC 5321, rewriting is no longer correct.
___
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] ALERT: .QA CCTLD in wrong hands currently

[Florian Weimer]

* Kauto Huopio:

> And facebook.qa and tons of .qa govt domains etc. Note also this:
>
> google.com.qa.  14400   IN  MX  0 google.com.qa.

That would actually be valid (but redudant).  It causes mail for
google.com.qa to be delivered to the host at google.com.qa, based on
the A/ records of the domain.
___
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] Opinions sought .... have I come to the right place?

[Florian Weimer]

* Stephan Lagerholm:

> Keep in mind that most cache system are using Least Recent Used
> Algorithm for their cache without any removal of expired records.  

Doesn't BIND use an unbound cache by default?

| max-cache-size
| 
| […] A value of 0 is special, meaning that records are purged from
| the cache only when their TTLs expire. […] The default is 0.


___
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] Opinions sought .... have I come to the right place?

[Florian Weimer]

* Joe Abley:

>> | max-cache-size
>> | 
>> | […] A value of 0 is special, meaning that records are purged from
>> | the cache only when their TTLs expire. […] The default is 0.
>> 
>> 
>
> Someone from ISC should probably weigh in, but if that really means
> that on a busy cache the in-memory cache can grow beyond the extent
> of physical RAM and start swimming with the sharks in swap, that
> seems like a weird default.

I think we've already discussed that somewhere.

There are two other halfway plausible choices: a ridiculously low
default value (Unbound, PostgreSQL) or something scaled arbitrarily
with available memory (Hotspot reserves a quarter of physical RAM).

None of these choises is really ideal.  Many users will never change
the defaults until they hit a problem, so I can understand to some
degree why you would prefer defaults which increase performance under
benign circumstances, like BIND and Hotspot.
___
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] Is it illegal to query the .berlin TLD servers?

[Florian Weimer]

* Randy Bush:

> as to the content of the txt rr, it seems to say you may not transfer
> the zone file.  not being able to transfer the zone file is rather
> common.

The TLDs for which zone files are not available for download are now
in the minority.  Per their ICANN agreement, the BERLIN zone should be
downloadable as well.
___
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] Official WHOIS redirector for TLDs

[Florian Weimer]

Is there are offical, documented WHOIS redirector for TLDs with some
long-term interface stability.  WHOIS.IANA.ORG might do the job, but I
couldn't find official documentation pointing to it.
___
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] Official WHOIS redirector for TLDs

[Florian Weimer]

* Rubens Kuhl:

> Em 19/03/2014, à(s) 14:30:000, Florian Weimer  escreveu:
>
>> Is there are offical, documented WHOIS redirector for TLDs with some
>> long-term interface stability.  WHOIS.IANA.ORG might do the job, but I
>> couldn't find official documentation pointing to it.
>
> Do you mean WebWHOIS ?

No, the good old port 43 protocol.

> All new gTLDs are required to have whois.nic. for port 43
> services, and it's usual for that URL to also have WebWHOIS. The
> tricky part is knowing who is implementing http://whois.nic.
> and who is implementing https://whois.nic..

You also need to know what is a new TLD.
___
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] Official WHOIS redirector for TLDs

[Florian Weimer]

* Kim Davies:

> On Mar 19, 2014, at 10:30 AM, Florian Weimer  wrote:
>
>> Is there are offical, documented WHOIS redirector for TLDs with some
>> long-term interface stability.  WHOIS.IANA.ORG might do the job, but I
>> couldn't find official documentation pointing to it.

> Regarding interface stability, while we have no formal commitments
> in this area, we have no intention to change the current format (in
> the sense of parsing the output) and only potentially add new fields
> to it in the future.

Thanks!  I think this is good enough for our (Debian's) purposes.
___
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] Opened Pandora's box of Cache Poisoning

[Florian Weimer]

* T. Suzuki:

> Additional page:
> http://www.e-ontap.com/dns/pandora_acjp_e/

Isn't this just the well-known phenomenon that once you can poison
into a resolver cache under a specific name, you can poison all names?
___
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] Looking for wildcard record served by a stable signed TLD nameserver

[Florian Weimer]

* Mark Andrews:

> What's needed here is for OS maintainers to actually "maintain"
> their OS's by including maintainence releases of the software they
> are shipping and not just cherry-pick security fixes back into older
> releases.  There are bugs which don't rise to the level of requiring
> a security advisary but are still critical bugs which need to fixed.

Common lore suggests that BIND is best compiled from source, so the
impact of downstreams in this area is fairly limited.  Sure, you get
the latest and greatest at the time of installation, but what happens
after that?

As far as I understand it, this is not about some version of BIND in
Fedora failing, but issues at ISP resolvers, so Fedora's maintenance
(which actually tracks upstream fairly aggressively) doesn't come into
play.
___
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] EDNS with IPv4 and IPv6 (DNSSEC or large answers)

[Florian Weimer]

* Franck Martin:

> What is the recommended setup for EDNS?
> -limit size to <1500? on both IPv4 and IPv6?

Limit to packet size 1200 or less, and tell the kernel to disregard
any path MTU information it has.

> -allow UDP fragmentation on IPv4 and IPv6, how securely?

Fragmentation in IPv4 is inherently insecure and introduces a DNS
cache poisoning vulnerability.

As specified, fragmentation in IPv6 is broken because the sender needs
to keep track of clients which have requested atomic fragments.  It is
best to disregard this requirement and simply never send any packets
with fragment headers, atomic or not.
___
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] EDNS with IPv4 and IPv6 (DNSSEC or large answers)

[Florian Weimer]

* Hannes Frederic Sowa:

> On Tue, Sep 23, 2014, at 23:41, Mark Andrews wrote:
>> As for atomic fragments, it is a seperate issue out of control of
>> the nameserver.
>
> Because of a possible DoS vector atomic fragments will be deprecated
> soon:
> 

Not too surprisingly, this issue was already discussed before RFC 6946
was published, and several participants recommended to abolish atomic
fragments for various reasons, including denial-of-service issues.  At
least it's finally getting fixed.
___
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] ShellShock exploit through the DNS

[Florian Weimer]

* Paul Vixie:

> #
> Tony Finch
> Tuesday, October 14, 2014 5:31 AM
>
> A CGI script invoked by Apache httpd with HostnameLookups On
> (the default is Off, a safer setting is Double)
>
> thanks, that makes sense. the security advisory posted here did not
> mention any real world examples. i agree that apache with
> HostnameLookups turned on, on redhat or apple systems where /bin/sh
> is bash, is a real world example.

There have been reports that this is a problem with the Apple system
resolver.

Red Hat Enterprise Linux does not have this vector.  It uses the
regular glibc resolver, which is based on the old BIND stub resolver,
and this code has both escaping from wire format to the textual
representation (which destroys the magic pattern) and the res_hnok
check (which rejects shell meta-characters).
___
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] need someone else to look at these servers

[Florian Weimer]

* Mark Andrews:

> The servers (or the firewalls in front of them) are not RFC 103[45]
> compliant.  DNS is a query/response protocol.  If you don't get a
> response the server is broken.

Running a UDP service which responds to unrecognizable packets is
precisely what you should not do because it can result in never-ending
packet loops.

> If you can't parse the packet,
> you *construct* a response which is just the DNS header with the
> rcode set to FORMERR, the id set to that of the query and qr set
> to 1, aa set to 0, aa set to 0, ad set to 0, rd copied, ra set as
> appropriate (not that it really matters), cd copied if you support
> DNSSEC otherwise set to 0, z set to 0.  This isn't rocket science.
> It is not hard to do this.

Reflecting the packet in this way may have been compliant in the RFC
1034/1035 days, but it is explicitly outlawed by RFC 6891 section 7
(you cannot strip the OPT record as required if you cannot parse the
packet).  I pointed out prior to publication that EDNS0bis explicitly
imposed a requirement on implementations which do not implement this
specification, but this comment was sadly ignored.
___
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] ShellShock exploit through the DNS

[Florian Weimer]

* P. Vixie:

> On October 18, 2014 4:06:07 PM EDT, Florian Weimer  wrote:
>
>>Red Hat Enterprise Linux does not have this vector.  It uses the
>>regular glibc resolver, which is based on the old BIND stub resolver,
>>and this code has both escaping from wire format to the textual
>>representation (which destroys the magic pattern) and the res_hnok
>>check (which rejects shell meta-characters).
>
> Wow. That code has been hugely unpopular but it turns out there may
> have been a pont to it other than protecting sendmail qf files back
> in 1995. Thanks for sharing.
>
> What about getnameinfo and getaddrinfo?

nss_dns has the behavior I described above.  If you use other NSS
modules for host name resolution, you may get different behavior.
(I'm not even sure if reverse lookups through LDAP even work,
I have never seen such a thing.)
___
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] need someone else to look at these servers

[Florian Weimer]

* Mark Andrews:

> Yet somehow firewall vendors choose to do everything BUT what they
> were instructed to do thereby causing a denial of service.

A lot of what you propose is quite reasonable, but requires extensive
gymnastics to align with the RFCs, which do not actually foster
interoperability in the way they impose certain requirements on
implementation behavior.  There were proposals to add better protocol
negotiation capabilities to DNS, but there wasn't enough interest in
them back when the IETF was still working on the protocol.

> Unknown types should get NOERROR, NXDOMAIN or YXDOMAIN as a response.

Real-world implementations disagree:

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse +nsid @f.root-servers.net 
www.isc.org TYPE128
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 31534
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 66 72 61 31 61 2e 66 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e 6f 72 67 
 (f) (r) (a) (1) (a) (.) (f) (.) (r) (o) (o) (t) (-) (s) (e) (r) (v) (e) (r) 
(s) (.) (o) (r) (g)
;; QUESTION SECTION:
;www.isc.org.   IN  TYPE128

;; Query time: 13 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Sun Oct 19 15:47:08 2014
;; MSG SIZE  rcvd: 68

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse +nsid @f.root-servers.net 
www.isc.org MAILA +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 35585
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; NSID: 66 72 61 31 61 2e 66 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e 6f 72 67 
 (f) (r) (a) (1) (a) (.) (f) (.) (r) (o) (o) (t) (-) (s) (e) (r) (v) (e) (r) 
(s) (.) (o) (r) (g)
;; QUESTION SECTION:
;www.isc.org.   IN  MAILA

;; Query time: 12 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Sun Oct 19 15:48:22 2014
;; MSG SIZE  rcvd: 68

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse +bufsize=1200 +nsid +dnssec 
@g.root-servers.net www.isc.org MAILA
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse +bufsize=1200 +nsid +dnssec 
@g.root-servers.net www.isc.org TYPE1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

> Algorithm determines the response code.  NOTIMP is NOT the correct
> response to a unknown qtype based on RFC 1034.

What can I say—I agree, but that's not how existing DNS
implementations behave.

> Did I say REFLECT a packet?   I said CONSTRUCT a packet.  In
> particular one that is 12 bytes long, consisting of only a DNS
> packet header.

And you really want the client to process this response, even with the
QNAME mismatch?  Not sure if this is a good idea, unless you have very
good recovery code for spoofed FORMERRs.

___
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] resolvers considered harmful

[Florian Weimer]

* Mark Allman:

>   The Domain Name System (DNS) is a critical component of the Internet
>   infrastructure that has many security vulnerabilities.  In particular,
>   shared DNS resolvers are a notorious security weak spot in the system.
>   We propose an unorthodox approach for tackling vulnerabilities in
>   shared DNS resolvers: removing shared DNS resolvers entirely and
>   leaving recursive resolution to the clients.

This is a bit over the top.  I've suggested multiple times that one
possible way to make DNS cache poisoning less attractive is to cache
only records which are stable over multiple upstream responses, and
limit the time-to-live not just in seconds, but also in client
responses.  Expiry in terms of client responses does not cause a cache
expiration, but a new upstream query once the record is needed again.
If it the new response matches what is currently in the cache, double
the new client response time-to-live count from the previous starting
value.  If not, start again at the default low value (perhaps even 1).

Doing this for infrastructure records is a bit tricky, but I'm sure
something can be worked out.
___
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] resolvers considered harmful

[Florian Weimer]

* David Conrad:

> On Oct 22, 2014, at 10:27 AM, Florian Weimer  wrote:
>> I've suggested multiple times that one
>> possible way to make DNS cache poisoning less attractive is to cache
>> only records which are stable over multiple upstream responses, and
>> limit the time-to-live not just in seconds, but also in client
>> responses.  
>
> Why not just turn on DNSSEC?

Important zones are still unsigned, so I can understand why there is a
desire for altenative solutions.
___
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] resolvers considered harmful

[Florian Weimer]

* Paul Vixie:

> BIND9 runs fine on windows and macos laptops. so, without even touching
> the real growth area of the edge (which is mobile devices like smart
> phones), you can get a sense of how rarely you'll be able to perform dns
> lookups, if you just switch to 127.0.0.1 as your name server (override
> this in your dhcp settings) and run a recursive dns server there.

I have run recursive resolvers on more-or-less consumer-grade Internet
connectivity for more than a decade.  It works reasonably well,
although adjusting the EDNS buffer size might be necessary, and some
resolver hardening options result in so many UDP flows that NAT
devices give up.

But the only time I ran into persistent problems running my own
resolver was when I still used a host in data center for VPN
termination, and the data center operator blocked 53/UDP to the
ISC.ORG name servers.
___
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] resolvers considered harmful

[Florian Weimer]

* Paul Vixie:

> i believe that this fallback scheme is the only way you, or drc, or
> florian, is able to get useful work done in this configuration.

To clarify, I don't use dnssec-trigger, and I don't really employ
mobile devices for personal use.
___
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] cool idea regarding root zone inviolability

[Florian Weimer]

* Paul Vixie:

> at:
>
> http://www.diplomacy.edu/policybriefs
>
> we see:
>
> http://www.diplomacy.edu/sites/default/files/DiploFoundation%20Policy%20Brief%20No%204%20WEB.pdf

Wouldn't be a first to step to cover root server *operators* (and root
DNS server sites) to audits, lift them out of obscurity, and introduce
some form of accountability?

It's not a bad idea to make sure that the data that goes into the root
system isn't compromised, but right now, anyone can already review
that, and there is even some public documentation for the update
process.  Contrast this with the situation on the operator side, where
important information such as site selection criteria is only
available under NDA (if at all).
___
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] knot-dns

[Florian Weimer]

* Roland Dobbins:

> While it sounds good on phosphor, the concept of code diversity is so
> abstract, compared to the significant operational challenges and
> associated security challenges of operating separate systems
> performing the same functions (sort of), but differently, that any
> potential benefit is generally outweighed by the negative impact to
> security posture of said challenges.

In particular, running different implementations behind a load
balancer on the same public IP address can break EDNS detection by
resolvers, and crafted queries sent to a resolver can make data
unavailable to that resolver (until a timeout occurs).
___
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] knot-dns

[Florian Weimer]

* David Conrad:

>> In particular, running different implementations behind a load
>> balancer on the same public IP address can break EDNS detection by
>> resolvers, and crafted queries sent to a resolver can make data
>> unavailable to that resolver (until a timeout occurs).
>
> Huh?

Yeah.

> If you're running multiple implementations behind a load balancer
> and one is not following the protocol specifications such that it
> breaks EDNS detection, the answer is to fix the broken resolver or
> run a different resolver that responds correctly, not run an
> identical code base.

The problem is that the EDNS protocol does not have a proper
handshake.  If implementations reply differently to the same query, a
resolver may hit one implementation, receive some sort of failure
indication, try again without EDNS, hit the other implementation,
receive a reply, and conclude that the IP address in question is not
EDNS-tolerant.
___
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] knot-dns

[Florian Weimer]

* David Conrad:

> Software diversity is a tool that network administrators use to
> improve resiliency in their infrastructure.  I agree it is not a
> silver bullet but if I was building out critical infrastructure like
> (oh say) a root server or a resolver cloud that my customers depend
> on, I would want to minimize the risk that my infrastructure was
> vulnerable to a single bug.

When you aim for diversity, you get the union of all bugs, not the
intersection.  (Same with complex firewalling software: the
application which needs to be protecting needs to be *really* bad that
a firewall in front of it makes the overall bug count go down.)  Even
the effect on resiliency is limited because bugs in independently
written pieces of software are not random, but are somewhat correlated.

And regarding denial of service, ripping out TCP/IP and replacing it
with something that has working denial-of-service capabilities (by
pushing the impact closer to the sources, say) is simply not an option
for many operators.
___
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] [dDoS] Good discussion on the Rackspace attack and DNS resiliency

[Florian Weimer]

* Colm MacCárthaigh:

> There's a good question embedded in that discussion:  when a resolver
> fails to get an answer from all of the authoritative nameservers for a
> domain, why not use the last known answer, even if it's stale.
>
> Yes, that clearly violates the TTL of the rrset, but wouldn't be
> over-all better for the health of the internet?

It's very difficult to implement properly, so that it does not
increase the impact of hijacks.  Even the best possible implementation
may encourage additional denial of service attacks, to prevent
resolvers from learning that the hijack event is over.

I also suspect that these hosters have a fairly long tail in the set
of requests they service, so this approach might still fail a large
percentage of requests in the end, not improving matters all that
much.

___
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] DNS training at the NSA

[Florian Weimer]

* Stephane Bortzmeyer:

> On  p. 9 (NSA slides,
> leaked to the press), the DNS resolution process is strange, as if
> recursion, instead of iteration, were used by all DNS servers of the
> world, including the root name servers. Too much haste in using
> PowerPoint? Ignorance? Deliberate attempt to obfuscate the issue?

I think those arrows express delegation, not packet flow.
Does the difference matter?
___
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] extra records in resolver answer, any benefit?

[Florian Weimer]

* Tony Finch:

> bert hubert  wrote:
>>
>> It is all optional, and nobody does anything with that data. In fact stub
>> resolvers do very little with what they receive. So for example, even the
>> additional processing for an MX record is completely ignored mostly.
>
> Yes.
>
> The difficulty with MX (and SRV) additional data is that you don't get a
> clear indication whether the target address records are nonexistent or
> just unavailable, so it tends to be easier to look them up regardless of
> the contents of the additional section.

Exactly.  Exim tried to do the optimization, but did not cover a
corner case, and we had very obscure intermittent mail delivery
failures as a result.  Not nice.
___
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] Mozilla Firefox and ANY queries

[Florian Weimer]

* Olafur Gudmundsson:

> That is the lamest justification I have seen in a long time.
> Translation: We use crap API to lookup A records that does not give
> us TTL values, which we want to use.  Asking for ANY on the other
> hand gives us TTL
>
> #1 it is not hard to write a better DNS API, if all you care about
> is DNS addresses

The final part is the problem.  Name resolution has to include other
information source besides DNS, and it's difficult to merge this data
with your own DNS resolver (whether you wrote it yourself, or it's
some library you got from somewhere).
___
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] Mozilla Firefox and ANY queries

[Florian Weimer]

* Mark Andrews:

> getaddrinfo was designed to extended.  It wouldn't be hard to add ttl
> information to getaddrinfo, just add a ai_ttl to the structure at the
> end and define a flag to say whether it is valid.  

struct addrinfo cannot be extended in this way because its size is
part of the ABI, and callers are even encouraged to allocate struct
addrinfo objects to pass the hints.

I've already found one Debian package which embeds a struct addrinfo
field in the middle of a struct defined in a header file (the shishi
Kerberos implementation).  Unfortunately, changing struct addrinfo in
the way you propose has an extremely high risk of breaking
applications.

It is possible to extend getaddrinfo without change the size of struct
addrinfo, but this will require accessor functions for the new fields.
___
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] Mozilla Firefox and ANY queries

[Florian Weimer]

* Paul Hoffman:

> On Mar 1, 2015, at 2:47 AM, Florian Weimer  wrote:
>> The final part is the problem.  Name resolution has to include other
>> information source besides DNS, and it's difficult to merge this data
>> with your own DNS resolver (whether you wrote it yourself, or it's
>> some library you got from somewhere).
>
> Difficult, but not impossible. The getdns API included non-DNS
> information from the beginning, and Verisign is working on getting
> that part into their implementation.

The API design isn't the real issue here, it is interacting with the
Name Service Switch in a way that is compatible with all existing NSS
modules.
___
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] Mozilla Firefox and ANY queries

[Florian Weimer]

* Mark Andrews:

> In message <87k2z0vksq@mid.deneb.enyo.de>, Florian Weimer writes:
>> * Mark Andrews:
>> 
>> > getaddrinfo was designed to extended.  It wouldn't be hard to add ttl
>> > information to getaddrinfo, just add a ai_ttl to the structure at the
>> > end and define a flag to say whether it is valid.  
>> 
>> struct addrinfo cannot be extended in this way because its size is
>> part of the ABI, and callers are even encouraged to allocate struct
>> addrinfo objects to pass the hints.
>
> And that is something that can be dealt with by setting a flag bit
> when calling getaddrinfo.  As I stated getaddrinfo is designed to be
> extended.

This is doesn't work for an important case, which I mentioned in the
next paragraph:

>> I've already found one Debian package which embeds a struct addrinfo
>> field in the middle of a struct defined in a header file (the shishi
>> Kerberos implementation).  Unfortunately, changing struct addrinfo
>> in the way you propose has an extremely high risk of breaking
>> applications.

We don't have the luxury of recompiling the entire world if we change
something in libc.  We tried something similar with another
supposedly-extensible struct, and all hell broke lose as a result.
Changing the size of struct addrinfo simply not an option for us.
___
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] Mozilla Firefox and ANY queries

[Florian Weimer]

* Stephane Bortzmeyer:

> On Fri, Feb 27, 2015 at 12:02:57AM -0500,
>  Sadiq Saif  wrote 
>  a message of 30 lines which said:
>
>> Checking local resolver logs and am seeing a large amount of ANY queries
>> originating from Firefox, is anybody else seeing such behavior?
>
> https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/
>
> Today, we are announcing that we are deprecating the DNS ANY
> meta-query. In a few weeks we'll be responding to those queries with
> rcode 4 / Not Implemented.
>
> [...]

Some resolvers will ask all authoritative servers for the domain when
they receive a NOTIMP response.  Others will not cache the resulting
SERVFAIL response.

So unless this is intended as some way to punish resolver operators
who have clients sending ANY queries, this is probably not such a good
idea.
___
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] DNSSEC: Needs for zone transitions to Insecure

[Florian Weimer]

Are there still situations where a zone owner may have to transition
the zone to Insecure temporarily to keep it available (or make it
available again)?  What about transfers between registrars?

Are there zone signing mistakes which may need this step?
___
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: Needs for zone transitions to Insecure

[Florian Weimer]

* Patrik Fältström:

>> On 20 Mar 2015, at 07:33, Florian Weimer  wrote:
>> 
>> Are there still situations where a zone owner may have to transition
>> the zone to Insecure temporarily to keep it available (or make it
>> available again)?  What about transfers between registrars?
>> 
>> Are there zone signing mistakes which may need this step?
>
> With my experience as a dns hosting entity, that is also a registrar, I have 
> a few comments.
>
> - There is always a reason why DNS Hosting Provider and/or Registrar
> is changed. Most of the time because the old party "did not do their
> job". So most of the time something is already broken in the old
> setup.

There are also totally benign reasons, like cleanup after M&A or
the regular switching of vendors.

Overall, these are probably lost in the noise, but on my end, I'm
particularly interested in those.

> I.e. I see people today in most cases "just do the move" and either
> just ignore the issue, or they set the zone to be insecure. In
> Sweden with high percentage of validation, taking zone unsigned is
> quite normal in the cases where it is easy/possible to do so at the
> donating registrar/dns hosting provider.

Ah, interesting.  Thanks for sharing.

___
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] about anti-ddos DNS hostings

[Florian Weimer]

* Edward Lewis:

> It's not just a matter of the rich getting richer and the poor getting
> poorer, it's a matter rooted in a technical fault in the architecture of
> the system.

It's not a technical fault.  There's little liability for forwarding
packets with forged source addresses, or designing networks with that
flaw built into them.  There's no technical solution to that.  You
can't stop pollution by creating better filters because there is
always an incentive not to filter your waste at all.
___
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] sibling glue

[Florian Weimer]

* Tony Finch:

> A question for those who know more about registry rules than me...

Practically speaking, a registry-style zone operator must filter out
sibling glue, or there will be domain hijacks.  The zone operator does
not know the structure of the reselling chain and cannot determine if
two zones are run by the same entity and can therefore properly
cross-glued.

I don't know if this is done consistently.  Probably not.

By the way, has anyone reviewed OpenStack Designate for such issues?
(It's supposed to support multiple tenants.)
___
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] Mass deletion of .tw sub-domains?

[Florian Weimer]

* Viktor Dukhovni:

> Is anyone at liberty to shed some light on what transpired to account
> for such a large change?  The deleted domains do look rather "random"
> to me.  Did some sort of large-scale abuse get shut down?
>
> [ FWIW, below my signature is a lightly encoded sample of 200 randomly
>   chosen deleted .tw domains. ]

I did some checks on a few of those.  WHOIS is still populated, and
they seem to share name servers.  The names may be random, but they
seem to have *something* in common.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Link-local IP addresses for a resolver?

[Florian Weimer]

* Stephane Bortzmeyer:

> Informal survey: do you know an ISP (preferably a big one with a lot
> of various clients) which advertises a DNS resolver with an IPv6
> link-local address?
>
> In France, Orange is doing that (with RA announces) and it seems to me
> a bit risky (since some clients may forget to keep track of the scope,
> the network interface where the advertisment was received). Are there
> other ISP doing it?

We added scope ID support to /etc/resolv.conf in upstream glibc a
couple of years ago, in 2008.  I can easily see that others may not
have done this, so I agree that there could be problems.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Link-local IP addresses for a resolver?

[Florian Weimer]

* Mark Andrews:

>> On 25 Sep 2019, at 6:13 am, John Levine  wrote:
>> 
>> In article  you 
>> write:
>>> Florian Weimer  wrote:
>>>> 
>>>> We added scope ID support to /etc/resolv.conf in upstream glibc a
>>>> couple of years ago, in 2008.  I can easily see that others may not
>>>> have done this, so I agree that there could be problems.
>>> 
>>> I did a bit of a survey in 2014 and found that prominent DNS
>>> libraries didn't support link-local addresses back then
>>> http://lists.cluenet.de/pipermail/ipv6-ops/2014-July/010035.html
>>> Maybe it's better now :-)
>> 
>> How are they with RFC 4193 ULAs?  I've been using a cache at a ULA on
>> my two-segment home network and it seems to work fine.
>> 
>> (And why would you use link local rather than ULA for your DNS
>> resolver, anyway?)
>
> ISP’s advertings ULA’s to customers have similar problems with
> advertising LL to customers.

ULAs do not need scope IDs, so some of the problems are avoided.

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

Re: [dns-operations] sophosxl.net problem?

[Florian Weimer]

* James Stevens:

> Would it be reasonable for an authoritative-only DNS Server to reject
> / ignore / throttle requests with RD=1 ?

It confuses people who try to debug issues with the dig tool.  Some
servers already do it.

Some system adminstrators want to list authoritative name servers in
/etc/resolv.conf for some reason, and that would break too.

Thanks,
Florian


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

Re: [dns-operations] sophosxl.net problem?

[Florian Weimer]

* James Stevens:

> Health-checks (e.g. pingdom etc) with RD=1 seem pretty common.

They do not work reliably because failure rates for some large
authoritative servers with RD=1 are significantly higher than with RD=0
(or at least were about ten years ago).  I remember a bug in monitoring
software which reported sporadic failure for perfectly healthy servers,
and it turned out that the cause was a bug where the software sent RD=1
queries instead of RD=0 queries.  The failure was stochastic, though.
It oculd have been software or configuration divergence a cluster behind
a load balancer But if I recall correctly, the failure rate was quite a
bit lower than that, so there was probably another factor involved.

Thanks,
Florian


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

Re: [dns-operations] sophosxl.net problem?

[Florian Weimer]

* Paul Vixie:

>> It seems that a dual-mode BIND9 server does return recursive data
>> in answer to queries with "RD=0", but such answers then also have
>> "AA=0".
>
> sounds like a bug, some of which did slip through BIND9's cracks.

Aren't there cases where BIND 9 caches data in a
supposedly-authoritative-only view because the data is needed to send
NOTIFY queries to the right addresses?
___
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!

[Florian Weimer]

* Mark Allman:

> Left here to be ripped apart ... :-)

The query numbers are surprisingly low.  To me at last.

Do we know why the number of root instances has increased?  Is it
because of the incoming data is interesting?
___
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!

[Florian Weimer]

* Jim Reid:

>> On 25 Nov 2019, at 20:54, Florian Weimer  wrote:
>> 
>> The query numbers are surprisingly low.  To me at last.
>
> What do you consider to be a lot of queries? The root server system
> collectively handles 500K-1M queries per second. That seems rather a
> lot to me. YMMV.

But globally?  For the entire planet?

It's certainly beyond what I can run out of my basement using spare
parts, but it's also not a mindbogglingly huge number.  I would have
expected something that's clearly impossible to handle from a single
box.

>> Is it because of the incoming data is interesting?
>
> Define interesting.

The data could have monetary value.  Passwords that are otherwise
difficult to come by might be leaking.
___
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!

[Florian Weimer]

* Jim Reid:

>> On 25 Nov 2019, at 22:19, Florian Weimer  wrote:
>> 
>>> What do you consider to be a lot of queries? The root server system
>>> collectively handles 500K-1M queries per second. That seems rather a
>>> lot to me. YMMV.
>> 
>> But globally?  For the entire planet?
>
> Yes. If you consider a well-behaved recursive resolver would only
> query the root a few times a day (probably < 10), a query load of
> 0.5-1M/second seems on the high side, even for the whole planet.

Up until recently, well-behaved recursive resolvers had to forward
queries to the root if they were not already covered by a delegation.
RFC 7816 and in particular RFC 8198 changed that, but before that, it
was just how the protocol was expected to work.
___
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!

[Florian Weimer]

* Jim Reid:

>> On 26 Nov 2019, at 09:16, Florian Weimer  wrote:
>> 
>> Up until recently, well-behaved recursive resolvers had to forward
>> queries to the root if they were not already covered by a delegation.
>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>> was just how the protocol was expected to work.
>
> So what? These RFCs make very little difference to the volume of
> queries a resolving server will send to the root. QNAME minimisation
> has no impact at all: the root just sees a query for .com instead of
> foobar.com.

QNAME minimization allows a resolver to blacklist (say) the CORP
subtree, based on the NXDOMAIN response for CORP.  If the full query
is sent to the root, it is only possible to cache the NXDOMAIN for the
exact QNAME, and not its siblings.  (This assumes that the root deals
with empty non-terminals in the expected way, but that seems to be a
reasonable assumption for the root zone.)
___
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!

[Florian Weimer]

* Mark Allman:

> Let me try to get away from what is or is not "big" and ask two
> questions.  (These are legit questions to me.  I have studied the
> DNS a whole bunch, but I do not operate any non-trivial part of the
> DNS and so that viewpoint is valuable to me.)
>
> (1) Setting aside history and how things have been done and why
> (which I am happy to stipulate is rational)... At this point,
> are there tangible benefits for getting information about the
> TLD nameservers to resolvers as needed via a network service?
>
> (2) Are there fundamental problems that would arise in recursive
> resolvers if the information about TLD nameservers was no longer
> available via a network service, but instead had to come from a
> file that was snarfed periodically?

What's the change rate for the root zone?  If there is a full
transition of the name server addresses for a zone, how long does it
typically take from the first change to the completion of the sequence
of changes?

If the answer, “this has never happened”, then using a fairly static
data source should probably be okay (similar to how the browser PKI is
maintained).  Due to the way DNSSEC works with its periodic renewal of
signatures, validating non-recursive resolvers will automatically
verify the freshness of the local root zone copy.  Even if there are
few such clients, I expect that for most operators, it will
effectively prevent undetected decay due to a stale root zone (where
more and more stale delegations accumulate until performance is
seriously impacted, and fresh bootstrap using external data is
needed).

The other question is whether that data source will make it harder for
ICANN or someone else to hand over control over the TLD in a
unilateral manner.  And then it's not even clear whether that's a good
thing or not.

Other uncertainties relate to the size of the root zone.  It seems
that the phase of aggressive growth is more or less over.  But
hard-coding an assumption that resolvers can load the root zone into
memory is on a different level because it limits policy basically for
forever.

I've thought a bit whether the root domain list should be pushed into
(non-validating) stub resolvers, but I don't think that's possible
because people really like to use local domains.

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

[Florian Weimer]

* Jared Mauch:

>> On Nov 27, 2019, at 5:26 PM, Florian Weimer  wrote:
>> 
>> What's the change rate for the root zone?  If there is a full
>> transition of the name server addresses for a zone, how long does it
>> typically take from the first change to the completion of the sequence
>> of changes?
>
> There are regular changes. 

But does anyone swap out the name servers for a TLD over the course of
five days?
___
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!

[Florian Weimer]

* Ondřej Surý:

>> On 27 Nov 2019, at 23:08, Florian Weimer  wrote:
>> 
>> What's the change rate for the root zone?
>
> https://twitter.com/diffroot

Selective quoting does not help to further the discussion.  Raw change
rates do not tell us if zones keep at least of some of their servers
at constant addresses over really, really long periods of time.

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

[Florian Weimer]

* Ondřej Surý:

>> Raw change rates do not tell us if zones keep at least of some of
>> their servers at constant addresses over really, really long
>> periods of time.
>
> .bank
> - deleted NS {ac1|ac2}.nstld.com. and added NS {a|b|c}.nic.bank. on November 
> 20
> and
> - deleted NS {ac3|ac4}.nstld.com. and added NS {d|e|f}.nic.bank. on November 
> 23
>
> Does that answer your question?

{a,b,c,d,e,f}.nic.bank and ac{1..4}.nstld.com seem to have
non-overlapping addresses.

I think this means that a simple update protocol (such as that
currently used for tzdata, or the root key and initial set of DNS
server address) will not be very reliable (at least until these
practices change).

I'm not sure if a different update protocol would be much of an
improvement over using the current with NSEC synthesis enabled.  (It
would be nice if resolver software allowed configuring that for the
root separately.)

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

[Florian Weimer]

* Stephane Bortzmeyer:

> It doesn't matter. Everything is done in a few days. For a resolver
> updating its copy of the root every month, this is enough to break
> things.

Agreed.  A fancy distribution protocol would be needed instead.

(I see parallels here with compiler changes where people claim
“neglible performance overhead” when it's around 5%, which in reality
can translate into a reversal of many years of work on the
optimizers.)

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

[Florian Weimer]

* Jason Livingood:

> Seems like the answer then is to have the resolver check for updates
> more frequently. The file is tiny and so this is not in the least
> going to be resource-intensive. Just check every XX minutes.

I had hoped that we could use distribution update mechanisms for the
zone, like we do today for the initial set of priming targets for the
root, or for tzdata.  But that's clearly not enough.

The real question is whether any distribution will be a substantial
improvement over what we have today with NSEC-based NXDOMAIN synthesis
for the root.  I doubt it.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] EDNS Client Subnet (ECS) in queries sent to Google Public DNS

[Florian Weimer]

* Alexander Dupuy via dns-operations:

> If any reader of this list is sending DNS requests with the EDNS Client
> Subnet (ECS) option to 8.8.8.8, please read this post on our announcement
> list  that
> discusses changes Google is planning in how we handle requests with ECS. It
> is also relevant for developers of software that sends ECS to recursive
> resolvers.

| we plan to start sending REFUSED responses
| […]
| in encrypted DNS over HTTPS […]
| for domain names where we are forbidden to forward client-provided ECS



How would a DoH client know that the recursive resolver is “forbidden
to forward” ECS data?

Do clients have to retry without ECS if they get a REFUSED response
now?  That looks like bad protocol design.  If you need to signal an
error in this case (instead of dropping the ECS data while
forwarding), it has to be a separate error indicator.  REFUSED does
not really work if retry without ECS is needed.

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

Re: [dns-operations] any registries require DNSKEY not DS?

[Florian Weimer]

* Warren Kumari:

> On Wed, Jan 22, 2020 at 9:19 PM Viktor Dukhovni  
> wrote:
>>
>> On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
>>
>> > Are there any registries that configure secure delegations from DNSKEY
>> > records (and do their own conversion to DS records) rather than accepting
>> > DS records from the registrant?
>>
>> In answer to the converse question, at least some registries appear to
>> allow (or have allowed in the past) DS RRs with unverified content:
>
>
> This actually seems OK to me -- nonsensical, but OK.

It makes attacks on the underlying hash function for the DS record
easier.  Constructing colliding prefixes is much harder if the prefix
itself contains the hash over something else (because you also have to
construct that something).
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Something happening in the root?

[Florian Weimer]

* Ray Bellis:

> On 23/01/2020 21:15, Paul Hoffman wrote:
>
>> Ad the problem seems fixed now, at least from the vantage points
>> I use (which hit Cloudflare at various places).
>
> There was a problem with some Cloudflare operated instances

Does this mean we have 13th root server operator?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant records

[Florian Weimer]

* Matthew Richardson:

> Thanks - I also had thought the NODATA response was wrong, but wanted a
> second opinion...
>
> However, is this going to cause any practical problems?

It breaks search list processing in the stub resolver.

Thanks,
Florian


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

Re: [dns-operations] Any known AD=1 intolerant iterative resolvers?

[Florian Weimer]

* Viktor Dukhovni:

> The reason I ask, is that the MUSL libc stub resolver has no support for
> EDNS and so no DO=1, but Postfix DANE support still needs to see the AD
> bit from the local resolver, which is not sent when there's no AD=1 in
> the query.
>
> My instinct is that it is now safe to just always send AD=1 in queries,
> which would partly resolve the issue, but if that is liable to break
> lookups via some extant resolvers, then AD=1 would need to be
> configurable via options in /etc/resolv.conf or similar.

This approach does not work because you do not know whether the
recursive resolver merely echoes back the AD bit, or has actually
performed DNSSEC validation.

I'm also not sure if the AD bit will be set for local authoritative
data in the recursive resolver, which did not undergo DNSSEC
validation.  You cannot use the AA bit in addition to the AD bit
because some recursive resolvers relay that bit if the answer does not
come from the cache (some versions of BIND 8 did that, others probably
followed).

So the answer to the question whether you can send AD=1 queries
without increasing the query failure rate does not really matter
because Postfix cannot use that anyway.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Any known AD=1 intolerant iterative resolvers?

[Florian Weimer]

* Viktor Dukhovni:

> On Wed, Apr 15, 2020 at 07:23:37AM +0200, Florian Weimer wrote:
>
>> > My instinct is that it is now safe to just always send AD=1 in queries,
>> > which would partly resolve the issue, but if that is liable to break
>> > lookups via some extant resolvers, then AD=1 would need to be
>> > configurable via options in /etc/resolv.conf or similar.
>> 
>> This approach does not work because you do not know whether the
>> recursive resolver merely echoes back the AD bit, or has actually
>> performed DNSSEC validation.
>
> That's not the question I'm asking.
>
>> I'm also not sure if the AD bit will be set for local authoritative
>> data in the recursive resolver, which did not undergo DNSSEC
>> validation.
>
> That's not the question I'm asking.
>
>> So the answer to the question whether you can send AD=1 queries
>> without increasing the query failure rate does not really matter
>> because Postfix cannot use that anyway.
>
> Well, in practice it can and does, and it works reliably with e.g. BIND,
> unbound, ... as the immediate (local) upstream resolver.  If the
> upstream resolver is not local, all bets are off anyway and the warranty
> is void.
>
> I just need to know whether a stub resolver that does not support DO=1
> can safely, by default, send AD=1.
>
> Your points are valid in general, but entirely out of scope in the
> supported case, because the forwarder is a modern resolver on the
> loopback interface.  But the stub resolver setting AD=1 needs to
> not encounter breakage also in the unsupported (for Postfix) cases.

My concern is that given the limitations of the AD flag, there is no
value in sending it by default, without explicit configuration.  So
even if it is save to send the flag by default (in the sense that it
does not increase query failure rates), you can't use the flag in
responses.  Ergo, there is no incentive to send it by default.

At least that's what I was thinking while writing my response. 8-)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] At least 3 CloudFlare DNS-hosted domains with oddball TLSA lookup ServFail

[Florian Weimer]

* Vladimír Čunát:

> (I don't react to the SERVFAIL from CloudFlare auth.)
>
> On 4/19/20 8:55 AM, Viktor Dukhovni wrote:
>> the NSEC RR promises TLSA records, among a rather oddball mix of
>> other rrtypes
>
> I believe that's normal for CloudFlare authoritatives, and so far I've
> noticed no real problems from that, apart from effects like less
> efficient caching.  Description:
> https://blog.cloudflare.com/black-lies/#dnsshotgun

For me, queries to alla.ns.cloudflare.com for
_25._tcp.mx01.mx-hosting.ch/IN/TLSA time out (even over TCP).  That
breaks denial of existence and thus DANE.  There is no obvious
client-side workaround because the NSEC RRset says that the TLSA RRset
exists.

Could this work if the authoriative server returned an RRSIG signature
of an empty TLSA RRset?

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

Re: [dns-operations] For darpa.mil, EDNS buffer == 1232 is *too small*. :-(

[Florian Weimer]

* Daniel Griggs:

> Just to add to that, I’ve been working with Azure recently and they
> warn that any packets over 1400 bytes will be fragmented, which
> seems crazy, but there it is.
>
> IMHO It doesn’t seems unreasonable though to aim to support networks
> that the majority use and to let broken networks be broken.

And how would you apply this rule to the Azure case?

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

Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Florian Weimer]

* Stephane Bortzmeyer:

> Several users on Twitter reported problems accessing Banque Populaire
> (a French bank) https://www.banquepopulaire.fr
> https://www.ibps.loirelyonnais.banquepopulaire.fr
> https://www.ibps.bpaca.banquepopulaire.fr
> https://www.ibps.mediterranee.banquepopulaire.fr/
>
> From the limited reports, all errors point to a DNS issue. (For one
> user, adding the IP address in /etc/hosts solved the problem.)
>
> But testing with existing resolvers and with the RIPE Atlas probes do
> not show a widespread outage.

I can reproduce this to some extent:

$ dig +norecurse +dnssec @nsisp1.i-bp.banquepopulaire.fr. 
www.banquepopulaire.fr. MX

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +norecurse +dnssec 
@nsisp1.i-bp.banquepopulaire.fr. www.banquepopulaire.fr. MX
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 59096
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.banquepopulaire.fr.IN  MX

;; Query time: 41 msec
;; SERVER: 91.135.182.250#53(91.135.182.250)
;; WHEN: Sat May 30 18:36:35 CEST 2020
;; MSG SIZE  rcvd: 51

$ dig +norecurse +dnssec @nsisp1.i-bp.banquepopulaire.fr. 
www.banquepopulaire.fr. TYPE1000

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +norecurse +dnssec 
@nsisp1.i-bp.banquepopulaire.fr. www.banquepopulaire.fr. TYPE1000
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

A recursive resolver will turn these responses into SERVFAILs.

I suspect this can cause resolvers to cache bad server reachability
information, leading to name resolution error for A and  queries
as well.

Or it could just be a client that uses RFC 2782:

$ dig +norecurse +dnssec @nsisp1.i-bp.banquepopulaire.fr. 
_http._tcp.www.ibps.loirelyonnais.banquepopulaire.fr SRV

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +norecurse +dnssec 
@nsisp1.i-bp.banquepopulaire.fr. 
_http._tcp.www.ibps.loirelyonnais.banquepopulaire.fr SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49919
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_http._tcp.www.ibps.loirelyonnais.banquepopulaire.fr. IN SRV

;; Query time: 39 msec
;; SERVER: 91.135.182.250#53(91.135.182.250)
;; WHEN: Sat May 30 18:47:02 CEST 2020
;; MSG SIZE  rcvd: 81
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] FlagDay 2020 UDP Size

[Florian Weimer]

* Tony Finch:

> Stub resolvers should do the same if they have enough brain to do so :-)

They are quite forgetful by design on some systems.  But in general,
this issue is not a problem for them because they do not enable EDNS.
___
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

[Florian Weimer]

* 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] Nameserver responses from different IP than destination of request

[Florian Weimer]

* 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] [Ext] Nameserver responses from different IP than destination of request

[Florian Weimer]

* John Levine:

> In article <20200908181130.gd4...@straasha.imrryr.org> you write:
>>> Seems to me that would be true for any software that uses the usual
>>> BSD or linux socket calls that match the host and port ...
>
>>You're conflating binding the UDP socket which specifies the *local end*
>>of the UDP socket (and behaves as you describe) with the somewhat less
>>common practice of "connecting" the UDP socket (done by DNS resolvers of
>>various stripes) which then also limits the *remote peer* ...
>
> Right, but I'd think that would be the usual way to do it. I suppose
> the alternative is for each request, pick a port, do a send using that
> port, then do a separate recv on the same port, but unless you're
> actively trying to work around the wrong IP bug, why would you do
> that?

It's the only way to get source port randomization on systems where
the kernel picks a predictive source port number when binding a
socket.  You keep open a few thousand sockets all the time and choose
one randomly to send the query.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Split view autoconfiguration

[Florian Weimer]

* Petr Menšík:

> I'll try to rephrase. Connection provides list of domains, it considers
> internal. All names in that domains should be resolved using DNS servers
> provided by that connection. Because common network connection managed
> by NM or systemd-networkd does not have "internal domains" property,
> systemd-resolved and dnssec-trigger uses DHCP search (119) option.

Is it really a list, though?

I expect corporate networks to use RPZ to manage things like
typo-squatting, so it's going to be very long, and perhaps not even
readily disclosable for contractual reasons.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243, Managing
Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


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

Re: [dns-operations] resolver cache question

[Florian Weimer]

* Mark Allman:

> I just finished reading a paper that basically tries to figure out
> if a hostname is worth caching or not [1].  This isn't the first
> paper like this I have read.  This sort of thing strikes me as a
> solution in search of a problem.  The basic idea is that there are
> lots of hostnames that are automatically generated---for various
> reasons---and only ever looked up one time.  Then there is an
> argument made that these obviously clog up resolver caches.
> Therefore, if we can train a fancy ML classifier well enough to
> predict these hostnames are ephemeral and will only be resolved the
> once---because they are automatically generated and so have some
> tells---then we can save cache space (and effort) by not caching
> these.

One could use a Bloom filter to avoid caching (most) lookup results
that are encountered just once.  Or start out with an artifically
lowered TTL combined with prefetching.

The authoritative server operators know that their zones are used for
what is essentially an RPC.  Don't they set a zero TTL?  So maybe this
is about ignoring low TTLs to increase cache hit rates.  Unfortunately
this report is behind a paywall, and I'm not going to spend $35.95 to
find out if the authors have considered Bloom filters and the rest.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations