Re: [dns-operations] DNS Operations

2024-03-03 Thread Turritopsis Dohrnii Teo En Ming via dns-operations
--- Begin Message ---
On Monday, March 4th, 2024 at 12:35 AM, Stephane Bortzmeyer  
wrote:

> On Sun, Mar 03, 2024 at 04:05:43PM +,
> Turritopsis Dohrnii Teo En Ming via dns-operations 
> dns-operati...@dns-oarc.net wrote
> 
> a message of 98 lines which said:
> 
> > I define most popular as the largest number of DNS server installed
> > throughout the whole world.
> 
> 
> OK but this is very questionable:
> 
> * some DNS servers have one user, some have millions,
> * resolver or authoritative server? They are two quite different types
> of DNS servers,
> * anyway, nobody knows how many DNS servers are there (except may be
> the NSA?)

Will the National Security Agency knows how many DNS servers there are in the 
whole world?

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

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


Re: [dns-operations] DNS Operations

2024-03-03 Thread Turritopsis Dohrnii Teo En Ming via dns-operations
--- Begin Message ---
On Sunday, March 3rd, 2024 at 2:06 AM, John Levine  wrote:

> It appears that Lee ler...@gmail.com said:
> 
> > OK - that was bad phrasing on my part :(
> > How about the most popular DNS server software that end-users chose to
> > run at home?
> 
> 
> For the 0.01% of end users that manage their own networks, well, OK.
> 
> On my home network I have an old mini ATX box running FreeBSD, on
> which I use unbound. It works great for me.
> 
> R's,
> John

On my home network, I have an Intel Celeron hardware appliance that runs 
pfsense firewall (which is based on FreeBSD) and it also uses Unbound.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

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


Re: [dns-operations] DNS Operations

2024-03-03 Thread Stephane Bortzmeyer
On Sun, Mar 03, 2024 at 04:05:43PM +,
 Turritopsis Dohrnii Teo En Ming via dns-operations 
 wrote 
 a message of 98 lines which said:

> I define most popular as the largest number of DNS server installed
> throughout the whole world.

OK but this is very questionable:

* some DNS servers have one user, some have millions,
* resolver or authoritative server? They are two quite different types
  of DNS servers,
* anyway, nobody knows how many DNS servers are there (except may be
  the NSA?)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] DNS Operations

2024-03-03 Thread Turritopsis Dohrnii Teo En Ming via dns-operations
--- Begin Message ---
On Sunday, March 3rd, 2024 at 1:43 AM, Lee  wrote:

> On Sat, Mar 2, 2024 at 8:55 AM David Conrad wrote:
> 
> > Hi,
> > 
> > On Mar 2, 2024, at 4:57 AM, Lee ler...@gmail.com wrote:
> > 
> > > On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via 
> > > dns-operations dns-operati...@dns-oarc.net wrote:
> > > 
> > > > As I checked with ChatGPT, it says ISC BIND DNS Server is the most 
> > > > popular DNS server software in the world.
> > 
> > ChatGPT is the weaponization of “I saw it on the Internet so it must be 
> > true."
> > 
> > > I'm guessing that "most popular" is what most home users use
> > 
> > Probably.
> > 
> > > - which seems to be pi-hole
> > 
> > I’d be very surprised if this were the case. I’d have thought the vast 
> > majority of what end users would use (at least on the recursive side) would 
> > be whatever their ISP was providing, which I strongly suspect is not 
> > pi-hole.
> 
> 
> OK - that was bad phrasing on my part :(
> How about the most popular DNS server software that end-users chose to
> run at home?
> 
> So whatever their ISP supplies doesn't count, as well as things like
> the default software on OpenWRT. I was trying to limit it to just
> what home users picked to run at home - not whatever default they were
> given.
> 
> Why? Because that might be better that what I picked to run at home.
> 
> Regards,
> Lee

I personally don't think end users need to run DNS server software at home.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

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


Re: [dns-operations] DNS Operations

2024-03-03 Thread Turritopsis Dohrnii Teo En Ming via dns-operations
--- Begin Message ---
On 2/3/2024 9:54 pm, David Conrad wrote:
> Hi,
>
> On Mar 2, 2024, at 4:57 AM, Lee  wrote:
>> On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via 
>> dns-operations  wrote:
>>>
>>> As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
>>> DNS server software in the world.
>
> ChatGPT is the weaponization of “I saw it on the Internet so it must be true."
>
>> I'm guessing that "most popular" is what most home users use
>
> Probably.
>
>> - which seems to be pi-hole
>
> I’d be very surprised if this were the case.  I’d have thought the vast 
> majority of what end users would use (at least on the recursive side) would 
> be whatever their ISP was providing, which I strongly suspect is not pi-hole. 
>
>> If you want to define "most popular" as what the root servers 
>
> This would be an odd definition of “most popular”.
>
>> If you want to define "most popular" as DNS servers accessible on the 
>> Internet, I'd kind of like to know too.  Maybe bind, maybe not.. I dunno.
>
>
> Historically (as in the 80s and 90s), it was probably BIND because it was 
> pretty much the only DNS package out there. My memory was that when Microsoft 
> came out with Active Directory (and, to a lesser extent djbdns), BIND’s 
> market share dropped rapidly. There was (is) a tool known as “fpdns” that 
> could be used to provide interesting stats on what DNS servers were running, 
> but I believe this stopped being effective as developers ‘fixed’ the 
> information leakage fpdns made use of.
>
> Fortunately, there are a lot of name servers, both authoritative and 
> recursive, out there these days so monoculture concerns aren’t that 
> significant anymore.
>
> Regards,
> -drc
>

It is compulsory for Microsoft Active Directory Domain Controllers to have a 
DNS server. And Microsoft provided a Windows-based GUI DNS server.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore






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


Re: [dns-operations] DNS Operations

2024-03-03 Thread Turritopsis Dohrnii Teo En Ming via dns-operations
--- Begin Message ---
On Saturday, March 2nd, 2024 at 9:39 PM, Lee  wrote:

> On Sat, Mar 2, 2024 at 3:57 AM Lee ler...@gmail.com wrote:
> 
> > On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via
> > dns-operations dns-operati...@dns-oarc.net wrote:
> > 
> > > As I checked with ChatGPT, it says ISC BIND DNS Server is the most 
> > > popular DNS server software in the world.
> 
> 
> I've never tried it, but "DNS fingerprinting tool" might let you find
> out for yourself:
> https://www.dns-oarc.net/tools/fpdns
> 
> Regards,
> Lee

Thanks for the link.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

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


Re: [dns-operations] DNS Operations

2024-03-03 Thread Turritopsis Dohrnii Teo En Ming via dns-operations
--- Begin Message ---





Sent with Proton Mail secure email.

On Saturday, March 2nd, 2024 at 4:57 PM, Lee  wrote:

> On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via
> dns-operations dns-operati...@dns-oarc.net wrote:
> 
> > As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
> > DNS server software in the world.
> 
> 
> I'm guessing that "most popular" is what most home users use - which
> seems to be pi-hole
> 
> If you want to define "most popular" as what the root servers use then
> maybe NSD:
> $ cat root-server-types
> #!/bin/bash
> # what software are the root servers running?
> grep -o . <<< "abcdefghijklm" | while read X ; do
> printf "%s\t" ${X}.root-servers.net.
> printf "%s\n" "$(dig -c ch -t txt version.bind
> @${X}.root-servers.net. +short)"
> done
> 
> If you want to define "most popular" as DNS servers accessible on the
> Internet, I'd kind of like to know too. Maybe bind, maybe not.. I
> dunno.
> 
> Regards,
> Lee

I define most popular as the largest number of DNS server installed throughout 
the whole world.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

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


Re: [dns-operations] DNS Operations

2024-03-02 Thread Randy Bush
> As I checked with ChatGPT

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


Re: [dns-operations] DNS Operations

2024-03-02 Thread Joe Abley
Op 2 mrt 2024 om 14:13 heeft Lee  het volgende geschreven:

> How about the most popular DNS server software that end-users chose to
> run at home?

So I think you need to qualify whether you are talking about authoritative 
servers or recursive servers or forwarders, and what you mean by popular, and 
which homes. It seems possible that by some measures the most popular DNS 
software that end-users choose at home is 8.8.8.8.

But I think more fundamentally I'm wondering what any of these questions have 
to do with DNS operations.


Joe

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


Re: [dns-operations] DNS Operations

2024-03-02 Thread Paul Vixie via dns-operations
--- Begin Message ---
Openwrt is fine. See also pihole. I just run bind9. Knot, powerDNS, and unbound 
are also great. 


p vixie 


On Mar 2, 2024 09:56, Lee  wrote:

On Sat, Mar 2, 2024 at 8:55 AM David Conrad  wrote:
>
> Hi,
>
> On Mar 2, 2024, at 4:57 AM, Lee  wrote:
> > On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via 
> > dns-operations  wrote:
> >>
> >> As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
> >> DNS server software in the world.
>
> ChatGPT is the weaponization of “I saw it on the Internet so it must be true."
>
> > I'm guessing that "most popular" is what most home users use
>
> Probably.
>
> > - which seems to be pi-hole
>
> I’d be very surprised if this were the case.  I’d have thought the vast 
> majority of what end users would use (at least on the recursive side) would 
> be whatever their ISP was providing, which I strongly suspect is not pi-hole.

OK - that was bad phrasing on my part :(
How about the most popular DNS server software that end-users chose to
run at home?

So whatever their ISP supplies doesn't count, as well as things like
the default software on OpenWRT.  I was trying to limit it to just
what home users picked to run at home - not whatever default they were
given.

Why?  Because that might be better that what I picked to run at home.

Regards,
Lee

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

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


Re: [dns-operations] DNS Operations

2024-03-02 Thread John Levine
It appears that Lee  said:
>OK - that was bad phrasing on my part :(
>How about the most popular DNS server software that end-users chose to
>run at home?

For the 0.01% of end users that manage their own networks, well, OK.

On my home network I have an old mini ATX box running FreeBSD, on
which I use unbound. It works great for me.

R's,
John
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] DNS Operations

2024-03-02 Thread Lee
On Sat, Mar 2, 2024 at 8:55 AM David Conrad  wrote:
>
> Hi,
>
> On Mar 2, 2024, at 4:57 AM, Lee  wrote:
> > On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via 
> > dns-operations  wrote:
> >>
> >> As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
> >> DNS server software in the world.
>
> ChatGPT is the weaponization of “I saw it on the Internet so it must be true."
>
> > I'm guessing that "most popular" is what most home users use
>
> Probably.
>
> > - which seems to be pi-hole
>
> I’d be very surprised if this were the case.  I’d have thought the vast 
> majority of what end users would use (at least on the recursive side) would 
> be whatever their ISP was providing, which I strongly suspect is not pi-hole.

OK - that was bad phrasing on my part :(
How about the most popular DNS server software that end-users chose to
run at home?

So whatever their ISP supplies doesn't count, as well as things like
the default software on OpenWRT.  I was trying to limit it to just
what home users picked to run at home - not whatever default they were
given.

Why?  Because that might be better that what I picked to run at home.

Regards,
Lee

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


Re: [dns-operations] DNS Operations

2024-03-02 Thread Ondřej Surý
First of all, this is the wrong question to ask. Who cares what’s the most 
popular anything…

The questions you should be asking are:

- What is the best tool (DNS server) for the task I have?

- Is there a good documentation?

- Can I get help? Is there a forum? Is there a mailing list? Is there a helpful 
community around the product?

- Has the product healthy development? Is there a team or is that a one person 
show? What is the funding model? What is the governance?

- How does the product solve security issue? Is there a procedure for handling 
security issues? Are the developers transparent?

- (bonus) Are the product developers involved in the DNS community? Are they 
involved in the protocol development?

And FFS never ever ask Large Language Models (ChatGPT) if you want to know 
truth. There are no shortcuts to knowledge.

Cheers,
Ondřej (with my ISC BIND 9 hat)
--
Ondřej Surý (He/Him)

> On 15. 2. 2024, at 16:33, Turritopsis Dohrnii Teo En Ming 
>  wrote:
> 
> Subject: DNS Operations
> 
> Good day from Singapore,
> 
> Could you please provide information on the current dominance and market 
> share of ISC BIND DNS server? Is it widely recognized as the most popular DNS 
> server globally?
> 
> Thank you.
> 
> Regards,
> 
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


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


Re: [dns-operations] DNS Operations

2024-03-02 Thread David Conrad via dns-operations
--- Begin Message ---
Hi,

On Mar 2, 2024, at 4:57 AM, Lee  wrote:
> On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via 
> dns-operations  wrote:
>> 
>> As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
>> DNS server software in the world.

ChatGPT is the weaponization of “I saw it on the Internet so it must be true."

> I'm guessing that "most popular" is what most home users use

Probably.

> - which seems to be pi-hole

I’d be very surprised if this were the case.  I’d have thought the vast 
majority of what end users would use (at least on the recursive side) would be 
whatever their ISP was providing, which I strongly suspect is not pi-hole. 

> If you want to define "most popular" as what the root servers 

This would be an odd definition of “most popular”.

> If you want to define "most popular" as DNS servers accessible on the 
> Internet, I'd kind of like to know too.  Maybe bind, maybe not.. I dunno.


Historically (as in the 80s and 90s), it was probably BIND because it was 
pretty much the only DNS package out there. My memory was that when Microsoft 
came out with Active Directory (and, to a lesser extent djbdns), BIND’s market 
share dropped rapidly. There was (is) a tool known as “fpdns” that could be 
used to provide interesting stats on what DNS servers were running, but I 
believe this stopped being effective as developers ‘fixed’ the information 
leakage fpdns made use of.

Fortunately, there are a lot of name servers, both authoritative and recursive, 
out there these days so monoculture concerns aren’t that significant anymore.

Regards,
-drc



signature.asc
Description: OpenPGP digital signature
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] DNS Operations

2024-03-02 Thread Joe Abley
On 2 Mar 2024, at 05:26, Lee  wrote:

> On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via 
> dns-operations  wrote:
> 
>> As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
>> DNS server software in the world.
> 
> I'm guessing that "most popular" is what most home users use - which
> seems to be pi-hole

We don't have to guess!

> What is the most popular DNS software in the world? Please qualify your 
> answer by explaining what measure of popularity you used, including 
> references where possible.

Determining the "most popular" DNS software can be challenging as it depends on 
the criteria used for measurement. However, one common metric used to gauge 
popularity is market share, which can be inferred from various sources such as 
surveys, internet usage statistics, and data from authoritative sources within 
the industry. As of my last update in January 2022, while BIND (Berkeley 
Internet Name Domain) historically held a significant market share and was 
widely regarded as one of the most popular DNS software solutions, the 
landscape might have evolved since then.

To provide a more current and accurate assessment, it's advisable to consult 
recent industry reports, surveys, and data from authoritative sources such as:

DNS-OARC (DNS Operations, Analysis, and Research Center): DNS-OARC provides 
valuable insights into DNS software usage through its workshops, presentations, 
and research publications. Their data could offer a glimpse into the 
distribution of DNS software among top-level domains (TLDs) and major DNS 
operators.
Internet Infrastructure Surveys: Organizations such as W3Techs, Netcraft, and 
BuiltWith periodically conduct surveys and analysis on internet infrastructure, 
including DNS software usage trends. These surveys often provide statistics and 
insights into the distribution of various DNS software solutions across 
websites and internet infrastructure.
Vendor Reports and Surveys: DNS software vendors may release reports or conduct 
surveys among their user base to understand the preferences and usage patterns 
of their customers. Reports from vendors like ISC (Internet Systems 
Consortium), the organization behind BIND, may offer insights into BIND's 
market share and its standing relative to other DNS software.
Industry Analyst Reports: Analyst firms like Gartner, Forrester, and IDC may 
include assessments of DNS software market trends, including market share 
analysis and vendor comparisons, in their reports and research publications.
By consulting these sources and considering their methodologies and data, one 
can better understand the current landscape of DNS software popularity and 
identify the most prevalent solutions in use today.___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] DNS Operations

2024-03-02 Thread Lee
On Sat, Mar 2, 2024 at 3:57 AM Lee  wrote:
>
> On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via
> dns-operations  wrote:
> >
> > As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
> > DNS server software in the world.

I've never tried it, but "DNS fingerprinting tool" might let you find
out for yourself:
  https://www.dns-oarc.net/tools/fpdns

Regards,
Lee

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


Re: [dns-operations] DNS Operations

2024-03-02 Thread Lee
On Sat, Mar 2, 2024 at 1:53 AM Turritopsis Dohrnii Teo En Ming via
dns-operations  wrote:
>
> As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular 
> DNS server software in the world.

I'm guessing that "most popular" is what most home users use - which
seems to be pi-hole

If you want to define "most popular" as what the root servers use then
maybe NSD:
$ cat root-server-types
#!/bin/bash
# what software are the root servers running?
grep -o . <<< "abcdefghijklm" | while read X ; do
  printf "%s\t" ${X}.root-servers.net.
  printf "%s\n" "$(dig -c ch -t txt version.bind
@${X}.root-servers.net. +short)"
done

If you want to define "most popular" as DNS servers accessible on the
Internet, I'd kind of like to know too.  Maybe bind, maybe not.. I
dunno.

Regards,
Lee

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


Re: [dns-operations] DNS Operations

2024-03-01 Thread Turritopsis Dohrnii Teo En Ming via dns-operations
--- Begin Message ---







On Friday, February 16th, 2024 at 6:29 AM, Rubens Kuhl via dns-operations 
 wrote:

As I checked with ChatGPT, it says ISC BIND DNS Server is the most popular DNS 
server software in the world.

But can't confirm.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore

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


Re: [dns-operations] DNS Operations

2024-02-15 Thread Bill Woodcock


> On Feb 15, 2024, at 23:29, Rubens Kuhl via dns-operations 
>  wrote:
> What’s your popularity metric ? 

Please don’t feed the trolls.

-Bill



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


Re: [dns-operations] DNS Operations

2024-02-15 Thread Rubens Kuhl via dns-operations
--- Begin Message ---

What’s your popularity metric ? 
Installations ? 
Number of queries served ? 
Number of zones served ? 
Number of OS distributions that include it in the base system ? 


Rubens


> Em 15 de fev. de 2024, à(s) 12:33, Turritopsis Dohrnii Teo En Ming via 
> dns-operations  escreveu:
> 
> 
> De: Turritopsis Dohrnii Teo En Ming 
> Assunto: DNS Operations
> Data: 15 de fevereiro de 2024 às 12:33:25 BRT
> Para: "dns-operations@lists.dns-oarc.net" 
> Cc: "c...@teo-en-ming-corp.com" 
> 
> 
> Subject: DNS Operations
> 
> Good day from Singapore,
> 
> Could you please provide information on the current dominance and market 
> share of ISC BIND DNS server? Is it widely recognized as the most popular DNS 
> server globally?
> 
> Thank you.
> 
> Regards,
> 
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



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


[dns-operations] DNS Operations

2024-02-15 Thread Turritopsis Dohrnii Teo En Ming via dns-operations
--- Begin Message ---
Subject: DNS Operations

Good day from Singapore,

Could you please provide information on the current dominance and market share 
of ISC BIND DNS server? Is it widely recognized as the most popular DNS server 
globally?

Thank you.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore










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


Re: [dns-operations] dns-operations Digest, Vol 206, Issue 7

2023-03-29 Thread Adam Casella via dns-operations
--- Begin Message ---
Just following up on this.  This issue was narrowed down to a need to increase 
the entropy threshold on Chrome’s DNS source port logic on Windows 10 and 11 to 
prevent the built-in DNS client from falling back to TCP.  This impacts all 
Chromium based browsers and the fix can be found here:

Chrome Bug tracking this issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=1413620

Fix (a one-liner) can be found here:

https://chromium.googlesource.com/chromium/src/+/59d686c1417b5aea7b1d94a28bac45d8d8f26fe0

This looks like the fix will be added in Chrome 112 or 113.

Thanks,

Adam Casella | Solutions Architect
Infoblox | infoblox.com
914.953.8571

From: dns-operations  on behalf of 
dns-operations-requ...@dns-oarc.net 
Date: Friday, March 17, 2023 at 5:02 AM
To: dns-operations@lists.dns-oarc.net 
Subject: dns-operations Digest, Vol 206, Issue 7
!---|
  This Message Is From an External Sender
  This message came from outside your organization.
|---!

Send dns-operations mailing list submissions to
dns-operations@lists.dns-oarc.net

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/dns-operations__;!!JYsgTRAg6ZQ!MXjAgDJCvjIDRRgSxERnvnrOZkSR8mexf1W9k2XJL9AybkCjxwS5E4vmtriURf279WZOqjRPlenLYsSZ8ng5N-iboYKq88s$
or, via email, send a message with subject or body 'help' to
dns-operations-requ...@lists.dns-oarc.net

You can reach the person managing the list at
dns-operations-ow...@lists.dns-oarc.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dns-operations digest..."


Today's Topics:

   1. Re: Increase in DNS over TCP from Chrome Browser on Windows
  11 (David Zych)


--

Message: 1
Date: Thu, 16 Mar 2023 11:57:00 -0500
From: David Zych 
To: "dns-operations@lists.dns-oarc.net"

Subject: Re: [dns-operations] Increase in DNS over TCP from Chrome
Browser on Windows 11
Message-ID: <13b9d8bc-55d3-a069-d907-299b8dad9...@illinois.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 3/15/23 11:29, Adam Casella wrote:
> It seems that Chrome is leveraging 1 TCP session per DNS query to prevent 
> tracking of the DNS traffic, which unfortunately does not take advantage of 
> TCP pipelining/multiplexing or out-of-order TCP DNS responses over a single 
> TCP stream.

Hi Adam, thanks for sharing this!

We definitely noticed a dramatic increase in TCP DNS requests circa Mon 
2022-11-07, for which I'm grateful to finally have a plausible explanation.

The use of 1 TCP session per query is especially significant because our 
recursive resolvers have iptables rules designed to prevent them from being 
monopolized by a single misbehaving client, which includes limiting the number 
of parallel inbound 53/tcp connections per client IP.  The sudden increase in 
throttling by that particular iptables rule was quite a surprise.

Thanks,
David

--
David Zych (he/him)
Lead Network Service Engineer

University of Illinois Urbana-Champaign
Office of the Chief Information Officer
Technology Services

Under the Illinois Freedom of Information Act any written communication to or 
from university employees regarding university business is a public record and 
may be subject to public disclosure.


--

Subject: Digest Footer

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/dns-operations__;!!JYsgTRAg6ZQ!MXjAgDJCvjIDRRgSxERnvnrOZkSR8mexf1W9k2XJL9AybkCjxwS5E4vmtriURf279WZOqjRPlenLYsSZ8ng5N-iboYKq88s$


--

End of dns-operations Digest, Vol 206, Issue 7
**
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] dns-operations Digest, Vol 206, Issue 7

2023-03-29 Thread Adam Casella via dns-operations
--- Begin Message ---
Just following up on this.  This issue was narrowed down to a need to increase 
the entropy threshold on Chrome’s DNS source port logic on Windows 10 and 11 to 
prevent the built-in DNS client from falling back to TCP.  This impacts all 
Chromium based browsers and the fix can be found here:

Chrome Bug tracking this issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=1413620

Fix (a one-liner) can be found here:

https://chromium.googlesource.com/chromium/src/+/59d686c1417b5aea7b1d94a28bac45d8d8f26fe0

This looks like the fix will be added in Chrome 112 or 113.

Thanks,

Adam Casella | Solutions Architect
Infoblox | infoblox.com
914.953.8571

From: dns-operations  on behalf of 
dns-operations-requ...@dns-oarc.net 
Date: Friday, March 17, 2023 at 5:02 AM
To: dns-operations@lists.dns-oarc.net 
Subject: dns-operations Digest, Vol 206, Issue 7
!---|
  This Message Is From an External Sender
  This message came from outside your organization.
|---!

Send dns-operations mailing list submissions to
dns-operations@lists.dns-oarc.net

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/dns-operations__;!!JYsgTRAg6ZQ!MXjAgDJCvjIDRRgSxERnvnrOZkSR8mexf1W9k2XJL9AybkCjxwS5E4vmtriURf279WZOqjRPlenLYsSZ8ng5N-iboYKq88s$
or, via email, send a message with subject or body 'help' to
dns-operations-requ...@lists.dns-oarc.net

You can reach the person managing the list at
dns-operations-ow...@lists.dns-oarc.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dns-operations digest..."


Today's Topics:

   1. Re: Increase in DNS over TCP from Chrome Browser on Windows
  11 (David Zych)


--

Message: 1
Date: Thu, 16 Mar 2023 11:57:00 -0500
From: David Zych 
To: "dns-operations@lists.dns-oarc.net"

Subject: Re: [dns-operations] Increase in DNS over TCP from Chrome
Browser on Windows 11
Message-ID: <13b9d8bc-55d3-a069-d907-299b8dad9...@illinois.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 3/15/23 11:29, Adam Casella wrote:
> It seems that Chrome is leveraging 1 TCP session per DNS query to prevent 
> tracking of the DNS traffic, which unfortunately does not take advantage of 
> TCP pipelining/multiplexing or out-of-order TCP DNS responses over a single 
> TCP stream.

Hi Adam, thanks for sharing this!

We definitely noticed a dramatic increase in TCP DNS requests circa Mon 
2022-11-07, for which I'm grateful to finally have a plausible explanation.

The use of 1 TCP session per query is especially significant because our 
recursive resolvers have iptables rules designed to prevent them from being 
monopolized by a single misbehaving client, which includes limiting the number 
of parallel inbound 53/tcp connections per client IP.  The sudden increase in 
throttling by that particular iptables rule was quite a surprise.

Thanks,
David

--
David Zych (he/him)
Lead Network Service Engineer

University of Illinois Urbana-Champaign
Office of the Chief Information Officer
Technology Services

Under the Illinois Freedom of Information Act any written communication to or 
from university employees regarding university business is a public record and 
may be subject to public disclosure.


--

Subject: Digest Footer

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://urldefense.com/v3/__https://lists.dns-oarc.net/mailman/listinfo/dns-operations__;!!JYsgTRAg6ZQ!MXjAgDJCvjIDRRgSxERnvnrOZkSR8mexf1W9k2XJL9AybkCjxwS5E4vmtriURf279WZOqjRPlenLYsSZ8ng5N-iboYKq88s$


--

End of dns-operations Digest, Vol 206, Issue 7
**
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


[dns-operations] dns-operations dontprobe reminder 20150701-0000

2015-07-02 Thread dns-operations-owner
Dear All,

This is a reminder, sent out once every 3 months that the DNS-OARC
runs the 'Don't Probe List' on behalf of the community.  This is a
database listing IP addresses and hostnames of DNS servers that 
should be excluded from Internet-wide DNS scans conducted by 
researchers.

Researchers are invited to request secure access to the latest version
of the database, while DNS operators are invited to submit any systems
they wish to have excluded from such scanning.

For more information on the 'Don't Probe List', please follow the link
provided below:

https://www.dns-oarc.net/oarc/services/dontprobe

Best regards,

DNS-OARC Admin


___
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 Digest, Vol 105, Issue 26

2014-10-23 Thread Bob Harold


 Date: Wed, 22 Oct 2014 15:38:14 -0400
 From: Andrew Sullivan a...@anvilwalrusden.com
 To: dns-operati...@dns-oarc.net
 Subject: Re: [dns-operations] resolvers considered harmful
 Message-ID: 20141022193814.gi37...@mx1.yitter.info
 Content-Type: text/plain; charset=us-ascii

 On Wed, Oct 22, 2014 at 11:19:45AM -0700, David Conrad wrote:
 
  That cost is discussed in the paper (section 5).

 Their model doesn't make it a large increase, and I think that's
 because of their unrealistic assumptions about actual use.  The
 problem is that the really popular domains on the Internet (Google is
 one example they do discuss) have completely different patterns than
 everyone else.  The mitigation technique of increasing TTLs imposes a
 cost on the operator of the popular domain (a cost in terms of
 flexibility).  The authors seem to think this is no large cost, and I
 disagree.

 --
 Andrew Sullivan

 I think one of the assumptions that is likely wrong is the cache times.
Many computers are turned off at the end of the day, which clears the
cache, so the numbers should be recalculated with one day max cache time as
a possible worst case.

Also, the two day TTL's on top-level zones are already too long.  If I am
forced to move from one DNS provider to another, being down for two days is
a problem.  Anything longer is even worse.

-- 
Bob Harold
University of Michigan
___
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 Digest, Vol 92, Issue 13

2013-09-20 Thread fujiwara
 From: Paul Vixie p...@redbarn.org
 Tony Finch wrote:
 Paul Vixie p...@redbarn.org wrote:
 for unsigned responses, i think a v6 max-udp-size of 1220 and a v4
 max-udp-size of 512 is what's called for.

 Why not be optimistic and assume ethernet MTUs?
 
 the ipv6 design calls for 1220, for reasons that don't seem clear to me,
 but which i don't want to override.

1280 ?

Reading old mail archive is interesting:
  http://marc.info/?l=ipngm=98731938716244w=3

--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp
___
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 Digest, Vol 92, Issue 13

2013-09-19 Thread Tony Finch
Vernon Schryver v...@rhyolite.com wrote:

   - a quick sample of DNSEC A answers finds them all larger than 1220 bytes

... but they can be much smaller if you turn on minimal responses. e.g.
for cam.ac.uk, 1283 vs 209 bytes; for dotat.at, 910 vs 221 bytes.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
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 Digest, Vol 92, Issue 13

2013-09-19 Thread Tony Finch
Paul Vixie p...@redbarn.org wrote:

 for unsigned responses, i think a v6 max-udp-size of 1220 and a v4
 max-udp-size of 512 is what's called for.

Why not be optimistic and assume ethernet MTUs?

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
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 Digest, Vol 92, Issue 13

2013-09-19 Thread Paul Vixie


Tony Finch wrote:
 Paul Vixie p...@redbarn.org wrote:
 for unsigned responses, i think a v6 max-udp-size of 1220 and a v4
 max-udp-size of 512 is what's called for.

 Why not be optimistic and assume ethernet MTUs?

the ipv6 design calls for 1220, for reasons that don't seem clear to me,
but which i don't want to override.
___
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 Digest, Vol 92, Issue 13

2013-09-12 Thread Aaron Campbell
On 2013-09-11, at 11:50 PM, Paul Vixie p...@redbarn.org wrote:

 A DNS UDP responder shall, when transmitting a message which does not 
 include embedded cryptographic marks such as TSIG or DNSSEC signatures, use 
 an effective DNS message payload size which is calculated as MIN(OFFERED, 
 MIN(DISCOVERED, ESTIMATED) - OVERHEAD)) where OFFERED is the EDNS BUFSIZE 
 received from the initiator, and DISCOVERED is the path MTU if known or 
 else the outbound interface MTU, and ESTIMATED is chosen as 576 for IPv4 or 
 1280 for IPv6 as the minimum guaranteed size of an IP datagram, and 
 OVERHEAD is chosen as 64 for IPv4 or 48 for IPv6 as the maximum likely size 
 of the IP and UDP headers.
 
 Shouldn't OVERHEAD actually be 68 for IPv4?
 
 i am counting 40 for the ipv6 header and 8 for the udp header. where are you 
 getting your 68 number from?

48 is correct for IPv6.  But max IPv4 header size is 60 bytes, plus 8 for UDP 
is 68.

-Aaron
___
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 Digest, Vol 92, Issue 13

2013-09-11 Thread Aaron Campbell
On 2013-09-11, at 2:30 AM, Paul Vixie p...@redbarn.org wrote:

 A DNS UDP responder shall, when transmitting a message which does not 
 include embedded cryptographic marks such as TSIG or DNSSEC signatures, use 
 an effective DNS message payload size which is calculated as MIN(OFFERED, 
 MIN(DISCOVERED, ESTIMATED) - OVERHEAD)) where OFFERED is the EDNS BUFSIZE 
 received from the initiator, and DISCOVERED is the path MTU if known or else 
 the outbound interface MTU, and ESTIMATED is chosen as 576 for IPv4 or 1280 
 for IPv6 as the minimum guaranteed size of an IP datagram, and OVERHEAD is 
 chosen as 64 for IPv4 or 48 for IPv6 as the maximum likely size of the IP and 
 UDP headers.

Shouldn't OVERHEAD actually be 68 for IPv4?

Also, already mentioned in 2671bis, but OFFERED shouldn't be used unless it is 
at least 512.  (Values lower than 512 MUST be treated as equal to 512.)

-Aaron
___
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 Digest, Vol 92, Issue 13

2013-09-11 Thread Paul Vixie


Aaron Campbell wrote:
 On 2013-09-11, at 2:30 AM, Paul Vixie p...@redbarn.org wrote:

 A DNS UDP responder shall, when transmitting a message which does not 
 include embedded cryptographic marks such as TSIG or DNSSEC signatures, use 
 an effective DNS message payload size which is calculated as MIN(OFFERED, 
 MIN(DISCOVERED, ESTIMATED) - OVERHEAD)) where OFFERED is the EDNS BUFSIZE 
 received from the initiator, and DISCOVERED is the path MTU if known or else 
 the outbound interface MTU, and ESTIMATED is chosen as 576 for IPv4 or 1280 
 for IPv6 as the minimum guaranteed size of an IP datagram, and OVERHEAD is 
 chosen as 64 for IPv4 or 48 for IPv6 as the maximum likely size of the IP 
 and UDP headers.

 Shouldn't OVERHEAD actually be 68 for IPv4?

i am counting 40 for the ipv6 header and 8 for the udp header. where are
you getting your 68 number from?

 Also, already mentioned in 2671bis, but OFFERED shouldn't be used unless it 
 is at least 512.  (Values lower than 512 MUST be treated as equal to 512.)

a fine plan. orange, can you produce an EDNS0-ter draft along these lines?
___
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 Digest, Vol 92, Issue 13

2013-09-10 Thread Yasuhiro Orange Morishita / 森下泰宏
 And I know the IP specification defines the minimal MTU size to 576.
 So, we may need a very short RFC for updating the definition of MTU,
 ^
to 1280

-- Orange

 in RFC 791.

From: Yasuhiro Orange Morishita / 森下泰宏 yasuh...@jprs.co.jp
Date: Wed, 11 Sep 2013 02:02:34 +0900 (JST)

 Paul-san,
 
  for unsigned responses, i think a v6 max-udp-size of 1220 and a v4
  max-udp-size of 512 is what's called for.
 
 I believe typical datalinks of MTU=576 are (were) X.25 and SLIP
 (Of course, it's not RRL's one).  And I believe both links are deprecated.
 
 And I know the IP specification defines the minimal MTU size to 576.
 So, we may need a very short RFC for updating the definition of MTU,
 in RFC 791.
 
 -- Orange
 
 From: Paul Vixie p...@redbarn.org
 Date: Mon, 09 Sep 2013 07:31:42 -0700
 
  ...
  
  Yasuhiro Orange Morishita / 森下泰宏 wrote:
   Paul-san, and folks,
  
   Now we (including me) have known the dangers and limitations,
   so should we set max-udp-size to 1220 on every authoritative servers?
  
  for unsigned responses, i think a v6 max-udp-size of 1220 and a v4 
  max-udp-size of 512 is what's called for. i've not seen an explanation of 
  how dnssec-covered data can be poisoned, even with fragment attacks. 
  orange, can you write RFC 6891-bis?
  
  the messaging that would go out with this is, everybody needs to sign their 
  dns data, and everybody needs to validate, and if you're planning to send 
  large responses then your authority servers must be v6 reachable, and your 
  v4 performance will be low due to tcp.
  
  vixie
  
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] dns-operations Digest, Vol 92, Issue 13

2013-09-10 Thread Yasuhiro Orange Morishita / 森下泰宏
Paul-san,

 for unsigned responses, i think a v6 max-udp-size of 1220 and a v4
 max-udp-size of 512 is what's called for.

I believe typical datalinks of MTU=576 are (were) X.25 and SLIP
(Of course, it's not RRL's one).  And I believe both links are deprecated.

And I know the IP specification defines the minimal MTU size to 576.
So, we may need a very short RFC for updating the definition of MTU,
in RFC 791.

-- Orange

From: Paul Vixie p...@redbarn.org
Date: Mon, 09 Sep 2013 07:31:42 -0700

 ...
 
 Yasuhiro Orange Morishita / 森下泰宏 wrote:
  Paul-san, and folks,
 
  Now we (including me) have known the dangers and limitations,
  so should we set max-udp-size to 1220 on every authoritative servers?
 
 for unsigned responses, i think a v6 max-udp-size of 1220 and a v4 
 max-udp-size of 512 is what's called for. i've not seen an explanation of how 
 dnssec-covered data can be poisoned, even with fragment attacks. orange, can 
 you write RFC 6891-bis?
 
 the messaging that would go out with this is, everybody needs to sign their 
 dns data, and everybody needs to validate, and if you're planning to send 
 large responses then your authority servers must be v6 reachable, and your v4 
 performance will be low due to tcp.
 
 vixie
 
___
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 Digest, Vol 92, Issue 13

2013-09-10 Thread Paul Vixie


Yasuhiro Orange Morishita / 森下泰宏 wrote:
 And I know the IP specification defines the minimal MTU size to 576.
 So, we may need a very short RFC for updating the definition of MTU,
  ^
 to 1280

 -- Orange

 in RFC 791.

i do not think that the definition of mtu is wrong. if i were going to
update 6891-bis (which is itself 2671-bis) the logic i would draft is:

---

A DNS UDP responder shall, when transmitting a message which does not
include embedded cryptographic signatures such as TSIG or DNSSEC
signatures, use an effective DNS message payload size which is
calculated as MIN(OFFERED, MIN(DISCOVERED, ESTIMATED) - OVERHEAD)) where
OFFERED is the EDNS BUFSIZE received from the initiator, and DISCOVERED
is the path MTU if known or else the outbound interface MTU, and
ESTIMATED is chosen as 576 for IPv4 or 1280 for IPv6 as the minimum
guaranteed size of an IP datagram, and OVERHEAD is chosen as 64 for IPv4
or 48 for IPv6 as the maximum likely size of the IP and UDP headers.

This specification does not define a maximum for any future IP transport
protocol, and so both initiators and responders should be prepared to
receive messages as large as the 9 kilobyte ethernet jumbogram size in
preparation for future transport protocol development.

---

i'm trying to decide whether that should ought to be a must. and, i
know the number is 9K not 64K, because of buffer memory considerations
on today's embedded servers.

vixie

___
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 Digest, Vol 92, Issue 13

2013-09-10 Thread Paul Vixie
excuse me, i left an edit out of my earlier proposal.

Paul Vixie wrote:

 i do not think that the definition of mtu is wrong. if i were going to
 update 6891-bis (which is itself 2671-bis) the logic i would draft is:

 ---



A DNS UDP responder shall, when transmitting a message which does not
include embedded cryptographic marks such as TSIG or DNSSEC signatures,
use an effective DNS message payload size which is calculated as
MIN(OFFERED, MIN(DISCOVERED, ESTIMATED) - OVERHEAD)) where OFFERED is
the EDNS BUFSIZE received from the initiator, and DISCOVERED is the path
MTU if known or else the outbound interface MTU, and ESTIMATED is chosen
as 576 for IPv4 or 1280 for IPv6 as the minimum guaranteed size of an IP
datagram, and OVERHEAD is chosen as 64 for IPv4 or 48 for IPv6 as the
maximum likely size of the IP and UDP headers.

This specification does not define a maximum for any future IP transport
protocol, and so both initiators and responders should be prepared to
receive messages as large as the 9 kilobyte ethernet jumbogram size in
preparation for future transport protocol development.


 ---

 i'm trying to decide whether that should ought to be a must. and,
 i know the number is 9K not 64K, because of buffer memory
 considerations on today's embedded servers.

 vixie

___
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 Digest, Vol 92, Issue 13

2013-09-09 Thread Yasuhiro Orange Morishita / 森下泰宏
Paul-san, and folks,

Now we (including me) have known the dangers and limitations,
so should we set max-udp-size to 1220 on every authoritative servers?

-- Orange

From: Paul Vixie p...@redbarn.org
Date: Mon, 09 Sep 2013 04:47:44 -0700

 regrettably, the author of RFC 2671 knew the dangers and limitations of
 fragmented IP, but specified it anyway.
 
 see especially: http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html
 
 (where the authors of WRL-87-3 were two early mentors of the later
 author of RFC 2671, who not only ought to have, but did, know better.)
 
 vixie
 
 re:
 
 Haya Shulman wrote:
  Yasuhiro-san :-)
 
  Nice find, thanks for sharing!!
  I will add reference to it in our works.
 
  On Sun, Sep 8, 2013 at 3:00 PM,
  dns-operations-requ...@lists.dns-oarc.net
  mailto:dns-operations-requ...@lists.dns-oarc.net wrote:
 
 
 
  Message: 6
  Date: Sun, 08 Sep 2013 tel:2013 17:30:57 +0900 (JST)
  From: Yasuhiro Orange Morishita /   yasuh...@jprs.co.jp
  mailto:yasuh...@jprs.co.jp
  To: aa...@arbor.net mailto:aa...@arbor.net
  Cc: dns-operati...@mail.dns-oarc.net
  mailto:dns-operati...@mail.dns-oarc.net, edmo...@mycre.ws
  mailto:edmo...@mycre.ws
  Subject: Re: [dns-operations] DNS Attack over UDP fragmentation
  Message-ID: 20130908.173057.37558842.yasuh...@jprs.co.jp
  mailto:20130908.173057.37558842.yasuh...@jprs.co.jp
  Content-Type: Text/Plain; charset=utf-8
 
  Aaron-san, Haya-san, and folks,
 
  I've found the following RFC, it's published in 2007 tel:2007.
 
RFC 4963 tel:4963 - IPv4 Reassembly Errors at High Data Rates
http://tools.ietf.org/html/rfc4963
 
  And I've cited Security Considerations of this RFC as below:
 
  BTW, When the RFC was I-D, it's titled IPv4 Fragmentation Considered
  Very Harmful.
 
http://tools.ietf.org/html/draft-heffner-frag-harmful-03
 
  So, we should have been discussing this issue before DNSSEC
  deployment.
 
  -- Orange
 
  ---
  7. Security Considerations
 
 If a malicious entity knows that a pair of hosts are communicating
 using a fragmented stream, it may be presented with an
  opportunity to
 corrupt the flow.  By sending high fragments (those with offset
 greater than zero) with a forged source address, the attacker can
 deliberately cause corruption as described above.  Exploiting this
 vulnerability requires only knowledge of the source and destination
 addresses of the flow, its protocol number, and fragment
  boundaries.
 It does not require knowledge of port or sequence numbers.
 
 If the attacker has visibility of packets on the path, the attack
 profile is similar to injecting full segments.  Using this attack
 makes blind disruptions easier and might possibly be used to cause
 degradation of service.  We believe only streams using IPv4
 fragmentation are likely vulnerable.  Because of the nature of the
 problems outlined in this document, the use of IPv4
  fragmentation for
 critical applications may not be advisable, regardless of security
 concerns.
  ---
 
 
  From: Aaron Campbell aa...@arbor.net mailto:aa...@arbor.net
  Date: Sat, 7 Sep 2013 tel:2013 08:27:47 -0300
 
   On 2013-09-06, at 1:42 PM, Robert Edmonds edmo...@mycre.ws
  mailto:edmo...@mycre.ws wrote:
  
Aaron Campbell wrote:
Here is a thought, but I will defer to the protocol experts
  on plausibility.  The resolver knows the size of each DNS message
  it parses.  What if it didn't trust glue records contained within
  large (i.e.,  1400 bytes or so) responses?  In these cases, the
  resolver sends a separate query to resolve the dangling authority
  NS records.  This introduces overhead, but only for large replies.
   It also makes a few assumptions, namely that the fragmentation
  point is something around 1500 bytes (and not something lower),
  and that the attack is only practical against the glue records,
  not the authority section.  May be able to play games with name
  compression there though? perhaps it is as least worth discussing
  as an additional barrier.
   
this sounds vaguely similar to unbound's
  harden-referral-path option,
though it applies to all lookups.
  
  
   I researched this, and found that it was first described here:
  
  
  
  http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01#section-3.3
  
   The option is currently marked experimental due to not being
  RFC standard, and performance concerns.  If the option were
  applied only to large responses (specifically to mitigate this
  type of attack), that would reduce the performance impact.
  
   -Aaron
   ___
  

Re: [dns-operations] dns-operations Digest, Vol 91, Issue 33

2013-08-27 Thread Bob Harold
Joe wrote:


 Date: Tue, 27 Aug 2013 11:27:56 -0400
 From: Joe Abley jab...@hopcount.ca
 ...
 Cc: dns-operations@lists.dns-oarc.net
 Subject: Re: [dns-operations] Implementation of negative trust
 anchors?

 ...



 I've long wished for a more general facility where upon successful [AI]XFR
 I could shell out to an arbitrary local executable and do whatever checks I
 wanted before signaling with exit status that this zone is ok to serve.
 With a bit of state held on disk about previous zones you could include
 some of those temporal checks and perhaps catch a few more problems.

 Joe


In BIND 8, at a previous company, I renamed the named-xfer executable to
named-xfer-real, and put a script at named-xfer that called
named-xfer-real with a temporary output file, then checked the zone for
sanity, and saved a diff log, then copied the file to the real file
location and signaled BIND that it had transferred. The master had some
automation that occasionally produced only a partial zone, so the checks
were an absolute necessity.  And the diff log told me exactly when changes
hit my servers.  (All my DNS servers had this setup.)

I don't think BIND 9 uses a separate zone transfer program, so it would be
more difficult now.  I could have a separate script check for updates, do
the transfer, move the file into place, and signal BIND, where BIND is
configured to think it is the master, and reads the zones from files.  Or I
could have a second copy of BIND on a different IP as a slave, and watch
the log for transfers, then copy them to the main BIND configured as master.

The extra checking is nice, but it increases the complexity.
___
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 Digest, Vol 91, Issue 33

2013-08-27 Thread Stephan Lagerholm
Joe, Bob and others,
 
 Date: Tue, 27 Aug 2013 11:27:56 -0400
 From: Joe Abley jab...@hopcount.ca
 ...
 Cc: dns-operations@lists.dns-oarc.net
 Subject: Re: [dns-operations] Implementation of negative trust
        anchors?

...
 
I've long wished for a more general facility where upon successful [AI]XFR I 
could shell out to an arbitrary local executable and do whatever checks I 
wanted before signaling with exit status that this zone is ok to serve. 
With a bit of state held on disk about previous zones you could include some 
of those temporal checks and perhaps catch a few more problems.

Joe

In BIND 8, at a previous company, I renamed the named-xfer executable to 
named-xfer-real, and put a script at named-xfer 

Have you seen credns from Nlnetlabs? It is doing what you are trying to 
accomplish. 

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

2012-05-09 Thread Chris Adams
Once upon a time, Patrick W. Gilmore patr...@ianai.net said:
 If you are looking for DDoS resilience, the answer is not X times normal.  
 A DDoS is not a multiple of your normal traffic, it is whatever the botnet 
 can throw at you.

The OP asked about caching DNS servers.  In general, you should only be
providing caching DNS services to your own network, not the Internet at
large.  Inside your network, you should be implementing BCP38; you
shouldn't have to deal with spoofing within your own network.

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).

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
___
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

2012-05-07 Thread bert hubert
On Mon, May 07, 2012 at 09:13:50AM -0400, Stephane Handfield wrote:
 Hello DNS operators,
 
 I want to know what rules you follow in terms of capacity planning for your
 DNS. I am mainly interested in the best planning practice for caching  DNS.
 Definitly our rules need to reflect a lots of our own reality, in term of
 agility of deployment, risks, etc. But I'm really interested to know if
 exists any rule of thumb which mostly apply to any situations.

Here's one. One resolving request per 'broadband residential internet'
subscriber per ten seconds.  This is the 'smooth peak nuber'.

Holds up quite well, although this number is a bit old. It might be eeking
towards one request per five seconds now.

Adjust width of thumb accordingly!

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

2012-05-07 Thread Iñigo Ortiz de Urbina
On Mon, May 7, 2012 at 8:27 PM, Steven Carr sjc...@gmail.com wrote:
 I think you'll probably find that, averaged out over say a period of 1 hour,
 an active user will perform at least 1 query every 1-2 seconds.

 Twitter, Facebook, anything that uses Ajax and not to mention tons of other
 CDNs, Ad Networks etc. eat DNS queries like candy and then the underlying OS
 querying for various services which will inevitably end up at your resolver.

 Then don't forget IPv6, most of the new browsers already send a query for
  at the same time they query for A.


On my laptop, I am using dnssec-trigger and consuming unbound logs
with a local Splunk instance. There's plenty of  queries, as well
as PTRs (utorrent's geolocation feature and the like). Twitter app
accounts for 8% of the queries, approximately (I cant tell about
Facebook).

Here's a detailed table:

A   391,016 79.693% 
PTR 55,315  11.274% 
43,092  8.782%  
TXT 825 0.168%  
SOA 327 0.067%  
NS  47  0.01%   
SRV 6   0.001%  
MX  5   0.001%  
TYPE1169  3 0.001% - Berkeley's ICSI Netalyzr tests

This is making around 490,600 queries since January 1st, which gives
roughly 2.6 queries per minute. Keep in mind laptop isnt always on,
unlike modern desktops. You can make your own numbers if you consider
I am using the laptop for some 6 hours a day on average, to get a way
more real estimate. You can, also, easily measure it yourself.

Best,

 Steve




 On 7 May 2012 14:42, bert hubert bert.hub...@netherlabs.nl wrote:

 On Mon, May 07, 2012 at 09:13:50AM -0400, Stephane Handfield wrote:
  Hello DNS operators,
 
  I want to know what rules you follow in terms of capacity planning for
  your
  DNS. I am mainly interested in the best planning practice for caching
   DNS.
  Definitly our rules need to reflect a lots of our own reality, in term
  of
  agility of deployment, risks, etc. But I'm really interested to know if
  exists any rule of thumb which mostly apply to any situations.

 Here's one. One resolving request per 'broadband residential internet'
 subscriber per ten seconds.  This is the 'smooth peak nuber'.

 Holds up quite well, although this number is a bit old. It might be eeking
 towards one request per five seconds now.

 Adjust width of thumb accordingly!

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



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



-- 
- Así que este es el futuro del hombre: calentarse a los rayos del
sol, bañarse en las claras corrientes de agua, y comer los frutos de
la tierra olvidando todo trabajo y fatiga.

- Bueno, y por qué no?

El tiempo en sus manos
___
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

2012-05-07 Thread bert hubert
On Mon, May 07, 2012 at 07:27:49PM +0100, Steven Carr wrote:
 I think you'll probably find that, averaged out over say a period of 1
 hour, an active user will perform at least 1 query every 1-2 seconds.

Given the 'duty cycle' of a broadband connection, these numbers are not wide
of the one every 5-10 seconds mentioned below.

 Then don't forget IPv6, most of the new browsers already send a query for
  at the same time they query for A.

I've seen Chrome send out queries while typing a URL for partial domain
names.  I'm not quite sure how queries for 'd' 'dns' 'dns-o' 'dna-oarc'
'dns-oarc.net' help though.

Bert

 
 Steve
 
 
 
 On 7 May 2012 14:42, bert hubert bert.hub...@netherlabs.nl wrote:
 
  On Mon, May 07, 2012 at 09:13:50AM -0400, Stephane Handfield wrote:
   Hello DNS operators,
  
   I want to know what rules you follow in terms of capacity planning for
  your
   DNS. I am mainly interested in the best planning practice for caching
   DNS.
   Definitly our rules need to reflect a lots of our own reality, in term of
   agility of deployment, risks, etc. But I'm really interested to know if
   exists any rule of thumb which mostly apply to any situations.
 
  Here's one. One resolving request per 'broadband residential internet'
  subscriber per ten seconds.  This is the 'smooth peak nuber'.
 
  Holds up quite well, although this number is a bit old. It might be eeking
  towards one request per five seconds now.
 
  Adjust width of thumb accordingly!
 
 Bert
  ___
  dns-operations mailing list
  dns-operations@lists.dns-oarc.net
  https://lists.dns-oarc.net/mailman/listinfo/dns-operations
  dns-jobs mailing list
  https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
 

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

___
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