Re: [dns-operations] DNSbomb attack

[Paul Vixie via dns-operations]

--- Begin Message ---
Apologies please. I meant all DNS responders not merely DNS full resolvers. 


p vixie 


On May 28, 2024 13:08, Paul Vixie via dns-operations 
 wrote:

___ 
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] DNSbomb attack

[Paul Vixie via dns-operations]

--- Begin Message ---
This attack was predicted by DNS RRL in 2012 and as such is not novel. All full 
resolvers should make RRL the default, as BIND9 seems to have done. 


https://circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns
 


I am in full support of ISC's position on this. 


p vixie 


On May 28, 2024 09:10, Ondřej Surý  wrote:

Stephane,

I must say that I am disappointed by the narrative that you are creating here: 
“this is good reading, but ISC disagrees”.

We actually think the proposed attack is very clever way how to abuse the way 
modern resolvers work. Our argument is that the existing (default) BIND 9 
settings already mitigates the attack to a level that’s just enough. And that’s 
described in length in the mentioned blogpost by Nicki.

I don’t know why are you trying to create rift where there’s really none.

Ondřej
--
Ondřej Surý (He/Him)

> On 27. 5. 2024, at 17:12, Stephane Bortzmeyer  wrote:
> 
> The paper is good reading:
> 
> https://dnsbomb.net/
> 
> ISC disagrees:
> 
> https://www.isc.org/blogs/2024-dnsbomb/
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

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

Re: [dns-operations] Strange things at C root name server

[Paul Vixie via dns-operations]

--- Begin Message ---
Yes. See: 


https://c.root-servers.org/ 


p vixie 


On May 24, 2024 13:31, Cameron Banowsky via dns-operations 
 wrote:

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

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

[dns-operations] C-root incident

[Paul Vixie via dns-operations]

--- Begin Message ---
News


2024‑05‑23 - On May 21 at 15:30 UTC the c-root team at Cogent Communications 
was informed that the root zone as served by c-root had ceased to track changes 
from the root zone publication server after May 18. Analysis showed this to 
have been caused by an unrelated routing policy change whose side effect was to 
silence the relevant monitoring systems. No production DNS queries went 
unanswered by c-root as a result of this outage, and the only impact was on 
root zone freshness. Root zone freshness as served by c-root was fully restored 
on May 22 at 16:00 UTC.


(https://c.root-servers.org/)

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

[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] Filtering policy: false positive rate

[Paul Vixie via dns-operations]

--- Begin Message ---
I think the examples being used in this thread are too narrow. In RPZ a 
firewall rule might trigger on something other than the QNAME. For 
example the trigger could be one of the NSDNAMEs in the resolution path, 
or on the address (A or ) associated with some NSDNAME in the 
resolution path, or on the address (A or ) of an answer. The meaning 
of "false" in the term "false positive" quickly goes out of scope. What 
we have are rules that trigger on nothing, others that trigger on the 
wrong thing, some that trigger on the right thing, and some that trigger 
on too much.


Also I wish everybody would stop saying "blocking". This isn't always 
that. We filter DNS content because it's the gateway to much harm, and 
as we learn about harms, we either monitor, or drop, or redirect, or 
"block" (if the trigger happens to be on the QNAME in which case we can 
replace the real answer with an NXDOMAIN) the DNS paths to those harms. 
NXDOMAIN insertion is usually unwise for non-QNAME triggers.


--
P Vixie

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

Re: [dns-operations] xn--mgbai9azgqp6j broken

[Paul Vixie via dns-operations]

--- Begin Message ---
I think uptime has high correlation to utility. 


p vixie 


On Oct 23, 2023 11:39, Stephane Bortzmeyer  wrote:

On Thu, Oct 19, 2023 at 02:02:22PM +,
Carr, Brett via dns-operations  wrote 
a message of 265 lines which said:

> This may have been mentioned before as I think it has been broken for quite 
> some time but:
> 
> None of the delegated NS’s for xn--mgbai9azgqp6j (IDN for .pk) seem to be 
> responding to queries.
> 
> Anyone on list from .pk or who knows them?

It is indeed for a long time. I wrote to them, never a reply.
___
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 over TCP response fragmentation

[Paul Vixie via dns-operations]

--- Begin Message ---
if the dns responder uses write() or send() or sendto() for the two 
octets of framing length, rather than writev() or sendmsg(), the 
kernel's default will be to "push" each buffer as a segment. that's 
where the one- or two-octet segments are probably coming from. this 
default can usually be changed by a socket-level system call. but even 
with writev() or sendto() older kernels (such as those in appliances and 
middle boxes) to treat each "iov" element as a separate buffer to be 
sent in a separate segment. and even if the dns responder does 
everything it can to avoid these small and/or separate segments, the 
kernel may have old congestion-window calculation. see also the first 
answer to this stackexchange question:


https://networkengineering.stackexchange.com/questions/54915/initial-tcp-congestion-window-sizes

congestion window doesn't show up on the wire so it won't be in the 
.pcapng file you sent. usually we estimate congestion window by looking 
at what size segments a sender transmits.


this survey is very interesting and deserves its own campaign. you might 
reach out to the MANRS+ team at ISOC to see if they want to take this on.


vixie

re:

Jan Petto wrote on 2023-10-03 02:25:

Hello,

my name is Jan Petto and I am currently studying computer science at TU 
Darmstadt, Germany. During the research for my thesis, I have found some 
odd behavior regarding DNS over TCP, which neither I nor my supervisor 
can explain. I am hoping somebody here can tell me what I am observing:


For my research, I am sending DNS requests over TCP to many different 
recursive DNS servers all over the world. A significant portion of these 
servers is sending the DNS response in two separate TCP segments, even 
though it would easily fit into one packet. Only after my client has 
acknowledged the first segment, the second part of the response is sent. 
The first TCP segment always contains only one or two bytes, never more.


I know a DNS message sent over TCP is prefixed by a two-byte field 
containing the message length. My first thought was that the first TCP 
segment contains this length field, and the second segment contains the 
DNS message, but then I discovered cases where only one of the two 
length bytes was contained in the first segment. In any case, sending 
the message length as a separate packet does not make much sense to me 
from an application design perspective. Maybe this is some sort of 
attack mitigation?


I have attached a packet capture containing two such examples. You can 
reproduce the behavior with any DNS client, e.g. dig:


# dig example.org +tcp @100.37.202.139

Also attached is a list of public DNS server IP addresses, where I have 
observed this behavior. They were found via scans of the IP address 
space, I have no affiliation with these servers.


I would greatly appreciate any input as to why so many servers are 
sending their responses in such a way.


Kind regards,
Jan


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




--
P Vixie

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

Re: [dns-operations] Google Public DNS has enabled case randomization globally

[Paul Vixie via dns-operations]

--- Begin Message ---



Paul Vixie via dns-operations wrote on 2023-07-29 17:35:

back in the day, only one rdns server was downcasing on cache miss,
and it was one of google's. dave presotto fixed it in about a day.


apologies (obvious). it was an authority for l.google.com, not rdns.

--
P Vixie

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

Re: [dns-operations] Google Public DNS has enabled case randomization globally

[Paul Vixie via dns-operations]

--- Begin Message ---



Evan Hunt wrote on 2023-07-29 13:58:

(Resending because I accidentally replied privately.)

likewise.

Evan Hunt wrote on 2023-07-29 13:55:

On Sat, Jul 29, 2023 at 09:07:21AM -0700, Paul Vixie wrote:

...

would the google dns team be willing to contribute to this draft in
the ietf dns wg? we have not pressed the matter since 2008 simply
because noone cared. with google now deploying it for quad8, i
think we might get a different result today than we got 14 years
ago.

Case randomization has been supported in quite a lot of resolvers
for quite a long while. I know for sure that unbound and knot
resolver both have it. (BIND doesn't, I'm not sure why not; we just
never got around to it, I suppose.)

perhaps there would be many reviewers, then.

If, on top of these other implementations, google is now deploying 
it, then they must have found it non-harmful, which would imply that

all or nearly all currently-deployed authoritative server software
must be repsonding to case-randomized queries correctly.
back in the day, only one rdns server was downcasing on cache miss, and 
it was one of google's. dave presotto fixed it in about a day.



As I recall, the 0x20 draft was mostly discussion of the problem
space; the> only normative part was a protocol clarification that the
question section has to be copied bit-for-bit into replies. ...
no. retry and fallback were specified. google's logic as described 
up-thread is more subtle than what we recommended. that's where a 
standard is needed, though i think we should also refer to every RFC 
where bit-for-bit naming in cache misses is implied or stated.



If I'm mistaken about that, and it's still only implicit, then I'd
support clarifying the protocol in that way. If it's already been
clarified, though, then I'm not sure why a 0x20 RFC is needed now.
we need to share knowledge about how to live with this change, simply 
because until the 0x20 draft came along, unexpected behaviour was able 
to be codified far and wide. sort of like drop-all-fragments was able to 
become the norm in the decades before EDNS.


--
P Vixie

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

Re: [dns-operations] Google Public DNS has enabled case randomization globally

[Paul Vixie via dns-operations]

--- Begin Message ---
>


would the google dns team be willing to contribute to this draft in the 
ietf dns wg? we have not pressed the matter since 2008 simply because 
noone cared. with google now deploying it for quad8, i think we might 
get a different result today than we got 14 years ago.


Tianhao Chi via dns-operations wrote on 2023-07-26 09:46:

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




--
P Vixie

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

Re: [dns-operations] Cache efficiency (was: Re: DNS .com/.net resolution problems in the Asia/Pacific region)

[Paul Vixie via dns-operations]

--- Begin Message ---



Robert Edmonds wrote on 2023-07-20 14:50:

Mark Andrews wrote:

...


Yes, there are lookups that can take a long time to perform with a cold
cache. By putting lots of users behind large, centralized caches we can
insulate users from a lot of cold cache lookups, but these centralized
resolvers then become concentrated points of failure, convenient
monitoring points, etc.


i have also found the cache hit performance to be notably worse when 
talking to an off-campus recursive than when talking on-campus. it is 
not only the cache miss performance (as driven by population size) which 
should concern us. 10ms vs 1ms doesn't matter for windowing workflows or 
for human perception but it adds up in ask-and-wait workflows not driven 
by human tentacles and optics.



Personally, I'd like to see the "full resolver"
role be re-distributed and move out as close as possible to the
endpoints, given that the original justification for the stub
resolver/full resolver split was a lack of resources at the endpoints --
in the 1980's. But if you have full resolvers running on individual
endpoints, or on network elements that serve individual households, etc.
you're much more likely to run into cold cache lookups and it would be
nice to be able to accelerate or avoid those cold lookups.


those are unpleasant extremes. can we consider a middle ground, like 
campus-level and isp-level name servers as were common before the 
opendns era, as having population sizes that led to good cache reuse? 
notably, another advantage from that rdns granularity is that the cache 
miss shares connectivity with subsequent transactions, obviating some of 
the complexities like EDNS client subnet which only came into existence 
because of the global anycast trend (quad this, quad that, quad etc.)



Here are some random ideas for improving the efficiency of cold or
lukewarm caches.

1. Cache occlusion rather than replacement of outranked data. The DNS
protocol reuses the same record type (NS) for both the non-authoritative
delegation nameserver record set served by the parent zone as well as
the authoritative nameserver record set served by the child zone. RFC
2181 § 5.4.1 says that resolvers "should replace" the data from the
parent zone when they receive authoritative data from the child zone,
but the parent zone often has a much longer TTL on the records that it
serves. (E.g., the twitter.com data from the .com zone has a 2-day TTL,
while the twitter.com NS record set from the twitter.com zone has a <4
hour TTL.)>
If resolver caches were able to retain the longer-lived NS records from
the parent and "occlude" them when a shorter-lived NS record from the
child is cached, then utilize them again when they become unoccluded
upon the expiration of the child NS record, it would avoid sending
unnecessary queries to the parent. It would also be arguably more
compatible with the lower case "should replace" text in RFC 2181 § 5.4.1
than a "parent-centric" resolver implementation.


draft-ietf-dnsop-ns-revalidation could be tuned to make that happen.


2. Persist some or all of the resolver's cached NS and nameserver
address records to disk. These are typically long-lived records and I'd
gladly trade a few tens of MB of disk space in exchange for better P99+
resolution latency after a restart. Perhaps this could also include the
RTTs, EDNS capabilities, etc. that is sometimes called the
"infrastructure cache".


while i don't think i have any "disks" left, i agree with what you mean. 
we had cache dump/restore on shutdown/startup in bind4 but pulled it out 
in bind8 as a complexity vs. utility tradeoff.



3. You mention CNAME chains, but NS delegations are another source of
indirection that may require additional upstream lookups, especially if
the nameserver names are in several different TLDs (as a reliability
hedge?). There are a couple of things that could be done here:

a) Delegations within the same organization often reflect internal
organizational boundaries. One team may want to give control over part
of the namespace to another team, without handing over write permissions
for the whole zone, so the typical solution is to carve out a child zone
for the other team, and host that zone on the same provider as the
parent zone. If the cloud-based DNS providers that many organizations
use offered a more granular, less than whole zone permissions model, it
would cut down on the number of child zones that are created solely to
reflect intra-organizational boundaries.


i'd hate to see us adopt a cloud-centric model. whatever we do to 
improve NS-chain performance -- and i think your first two suggestions 
would do this -- should also benefit the normal delegation, notify, and 
transfer system.



b) Make nameserver address indirection *optional* without requiring a
backwards-incompatible protocol change.


*cough*.

--
P Vixie

--- End Message ---
___
dns-operations mailing list

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

[Paul Vixie via dns-operations]

--- Begin Message ---



Ondřej Surý wrote on 2023-07-18 13:25:

...

There’s already mechanism for not serving a stale RRSIGs. The EXPIRE field in 
the SOA record should be set to a value that’s lower than the RRSIG resigning 
interval (the minimal interval between now and shortest RRSIG expiry in the 
zone).

i stand corrected.

--
P Vixie

--- 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 .com/.net resolution problems in the Asia/Pacific region

[Paul Vixie via dns-operations]

--- Begin Message ---

i have two comments here.

Ondřej Surý wrote on 2023-07-18 11:54:

With my implementor’s hat on, I think this is wrong approach. It (again) adds a 
complexity to the resolvers and yet again based (mostly) on isolated incident. 
I really don’t want yet another “serve-stale” in the resolvers. I have to yet 
see an evidence that serve-stale has helped anything since the original 
incident, but now every resolver has to have it because people want it.


i think serve-stale is a protocol violation and should be described that 
way in an RFC and that any implementation who chooses to provide it 
should also emit a syslog() warning when it is enabled. so, yes. but, 
also no, because gavin's suggestion is nothing like serve-stale. see below.



On 18. 7. 2023, at 20:38, Gavin McCullagh  wrote:

I'd like to reach out to NLNet about changing Unbound to do this, so I want to 
make sure people have a chance to disagree.  Feel free to voice your 
disagreement (and reasons) here if you do.


i don't think this should be an implementation option. we should define 
stale-sigs in an RFC and describe them as "like servfail or formerr", 
and require in all three cases (stale sigs, servfail, formerr) that at 
least one other ns.nsdname be consulted before signaling failure on the 
original request.


this level of complexity is the cost of full resolving. we have to limit 
the amount of work done by stubs, but we do that by migrating the work 
to the recursives.


--
P Vixie

--- 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 .com/.net resolution problems in the Asia/Pacific region

[Paul Vixie via dns-operations]

--- Begin Message ---
On Thu Jul 13, 2023 at 7:16 PM UTC, Gavin McCullagh wrote:
> ...
>
> I assume lots of us on this mailing list operate authoritative dns
> servers.  When one of our PoPs or nameservers is unresponsive, most of us
> rely on retries against other nameservers (aka PoPs) to ensure this is a
> non-event.  When one of our PoPs is serving stale, it is varying levels of
> bad depending on how stale it is.  But under DNSSEC stale RRSIGs are
> obvious and it seems like a stale server could be a non-event, if the
> resolver is allowed to retry.

+1.

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

Re: [dns-operations] Ani Piracy - RPZ Feed

[Paul Vixie via dns-operations]

--- Begin Message ---

if such is found, please submit it for inclusion here:

https://dnsrpz.info/

re:

Renyk de'Vandre wrote on 2023-05-26 05:11:

Hi All,

Can anyone recommend a good quality anti-piracy RPZ feed?   Looking to 
block access to video/music piracy websites.


Many Thanks!


--
P Vixie

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

[dns-operations] why DNS can't have nice things

[Paul Vixie via dns-operations]

--- Begin Message ---
once an embedded dns recursive server works well enough, it ships, is 
widely deployed, and becomes abandonware. the apps which don't work are 
found (by others) later. there is no complaint path.



; <<>> DiG 9.16.33 <<>> api.dnsdb.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54714
;; flags: qr rd ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;api.dnsdb.info.IN  A

;; ANSWER SECTION:
api.dnsdb.info. 0   IN  CNAME   dnsdb.info.
dnsdb.info. 0   IN  A   104.244.13.65
dnsdb.info. 0   IN  A   104.244.14.69
ns5.dnsmadeeasy.com.0   IN  A   208.94.148.13
ns5.dnsmadeeasy.com.0   IN  2600:1800:5::1
ns6.dnsmadeeasy.com.0   IN  A   208.80.124.13
ns6.dnsmadeeasy.com.0   IN  2600:1801:6::1
ns7.dnsmadeeasy.com.0   IN  A   208.80.126.13
ns7.dnsmadeeasy.com.0   IN  2600:1802:7::1

;; Query time: 0 msec
;; SERVER: 172.26.16.1#53(172.26.16.1)
;; WHEN: Fri Apr 14 12:27:20 UTC 2023
;; MSG SIZE  rcvd: 301


so, greetings from the botconf (strasbourg) wifi network, where the 
A/ records of the authority servers are placed in the answer section 
rather than the additional data section, and there is no authority 
section which would help a stub resolver understand why these A/ RRs 
are present. also, TCP/53 does not answer. no RST, no ICMP, no nothing.


i would likely never have discovered the asinfo bug in dnsdbq had i not 
visited this particular hotel, who deserved higher quality from their 
wifi vendor, but is powerless (as am i) to get it fixed upstream. so:



diff --git a/asinfo.c b/asinfo.c
index 21fca4b..573a662 100644
--- a/asinfo.c
+++ b/asinfo.c
@@ -174,11 +174,8 @@ asinfo_from_dns(const char *dname, char **asnum, char 
**cidr) {
ns_rr rr;

DEBUG(1, true, "asinfo_from_dns(%s)\n", dname);
-   if ((res.options & RES_INIT) == 0) {
+   if ((res.options & RES_INIT) == 0)
res_ninit();
-   /* use a TCP connection and keep it open */
-   res.options |= RES_USEVC|RES_STAYOPEN;
-   }
n = res_nquery(, dname, ns_c_in, ns_t_txt, buf, sizeof buf);
if (n < 0) {
if (res.res_h_errno == HOST_NOT_FOUND)
@@ -210,6 +207,8 @@ asinfo_from_dns(const char *dname, char **asnum, char 
**cidr) {
result = strdup(strerror(errno));
break;
}
+   if (ns_rr_type(rr) != ns_t_txt)
+   goto next_rr;
rdata = ns_rr_rdata(rr);
rdlen = ns_rr_rdlen(rr);
ntxt = 0;
@@ -295,6 +294,7 @@ asinfo_from_dns(const char *dname, char **asnum, char 
**cidr) {
free(txt[n]);
txt[n] = NULL;
}
+ next_rr:;
}
return result;
 }


(https://github.com/dnsdb/dnsdbq)
--
P Vixie

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

Re: [dns-operations] [Ext] Re: Cloudflare TYPE65283

[paul vixie via dns-operations]

--- Begin Message ---
<8, RSA-SHA1 vs RSA-SHA1-NSEC3).  But a new 
on-the-fly denial of existence might prove to be worth it in operations.>>


Well, we are overdue for starting over on dnssec, which we used to do every two 
years or so. But does the next generation have the will to do so?


p vixie

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

Re: [dns-operations] [DNSOP] bind fails to continue recursing on one specific query

[Paul Vixie via dns-operations]

--- Begin Message ---

i think there's language slippage in this thread.

Peter DeVries wrote on 2023-03-29 03:51:


On Tue, Mar 28, 2023, 9:23 PM Dave Lawrence > wrote:


...

It is very poor form for nameservers to intentionally not respond to
queries under normal operation.  Now if you were getting hammered by
an unreasonable volume of them that would be another thing.


so, normal operation != during a ddos.

1/4 - 1/3 of all incoming queries matched this signature during DDoS 
attacks.  It was potentially a quick help.

see also:

http://www.redbarn.org/dns/ratelimits

noting that just about all modern DNS servers have RRL now:

https://duckduckgo.com/?q=dns+rrl=v344-1=web

i suggest linguistic caution when talking about not answering queries. 
DNS RRL is nonmodal and must be nonmodal. we must not answer questions 
that should not have been sent, and many of these are easily detected.


hopefully DNS RRL will be on by default at some nearby point in time.

--
P Vixie

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

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

[Paul Vixie via dns-operations]

--- Begin Message ---
if the same IP is asking the same qname over and over, then you might 
want to look into DNS RRL, which was originally a BIND thing but which 
all open source name servers now possess in some form. it was crafted 
for authority (really, root and TLD) servers, but does also work for 
recursives.


http://www.redbarn.org/dns/ratelimits

(i guess i'll go fix the https version of that service, again.)

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

Re: [dns-operations] Browser Public suffixes list

[Paul Vixie via dns-operations]

--- Begin Message ---



Viktor Dukhovni wrote on 2022-08-27 11:06:

On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote:

 ...
see: https://www.ietf.org/mailman/listinfo/dbound


Another aspect of the problem, is that the browsers unified the address
bar and the search bar in order to "improve" (make simpler than
possible) the browser user interface.  This creates a fundamental
ambiguity about user intent.  Did the user type a URL sans scheme prefix
or a search term?  Using the PSL to "disambiguate" is a hack.


browsers gonna browse. there's nothing we can do about that in the 
protocols. time was, any character-by-character current value in the 
browser bar which was syntactically valid as a domain name (by regex 
without reference to a PSL or any other dictionary) would be sent to the 
DNS resolver. apparently this wasn't monetizing enough. we march on.


--
P Vixie

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

Re: [dns-operations] Browser Public suffixes list

[Paul Vixie via dns-operations]

--- Begin Message ---

this...

Meir Kraushar via dns-operations wrote on 2022-08-27 02:56:
2) The need to maintain a list dedicated to browser issues is out of our 
scope. I'm sure there are good reasons to have it, like you said, there 
is gap between the worlds.


...is why the IETF DBOUND (domain boundaries) working group was 
originally formed, and why efforts are underway to resuscitate it.


see: https://www.ietf.org/mailman/listinfo/dbound

--
P Vixie

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

Re: [dns-operations] mail.protection.outlook.com has EDNS issues

[Paul Vixie via dns-operations]

--- Begin Message ---



Matthew Richardson wrote on 2022-07-06 07:52:

...

Alternatively, is this the sort of issue in which DNS-OARC could become
involved by way of outreach to MS about the problems?  The lack of EDNS0
will probably become an increasing problem over time.  This DNS setup is
used for ALL email to Office365 business users, which is not a small
quantity.


https://github.com/dns-violations/dns-violations

https://ednscomp.isc.org/

--
P Vixie

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

Re: [dns-operations] [Ext] How should work name resolution on a modern system?

[Paul Vixie via dns-operations]

--- Begin Message ---



David Conrad wrote on 2022-06-16 08:26:
... What ISC defined as “views" in BIND 9 is simply an implementation of an 
independent namespace. The fact that it is (now) most frequently used in 
the context of an independent address space is irrelevant.


when considering BIND9, bob halley and i knew of many BIND4 and BIND8 
installations who ran a different name server instance for each IP 
interface address, in order that different audiences would receive 
different results. this seemed to us like the long way around, and we 
wanted BIND9 to handle this situation natively.


while RFC 1597 (later reissued as RFC 1918) was widely practiced at the 
time BIND9 was designed, it's true as david recounts above that the 
primary use case we had for "views" was enterprise-internal naming 
systems. (when i did some consulting for sony electronics, we had to 
keep 43/8 addresses from leaking to the outside world.)


see also .

--
P Vixie

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

Re: [dns-operations] How should work name resolution on a modern system?

[Paul Vixie via dns-operations]

--- Begin Message ---



Dave Lawrence wrote on 2022-06-15 10:33:

Viktor Dukhovni writes:

Single label names passed to getaddrinfo(3) should not result in single
label "A" or "" DNS queries.


http://ai./


https://www.icann.org/en/system/files/files/sac-053-en.pdf

--
P Vixie

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

Re: [dns-operations] CNAME at the apex breaks DNSSEC DS lookups from caches

[Paul Vixie via dns-operations]

--- Begin Message ---



Evan Hunt wrote on 2022-04-17 02:58:

...

I was the original author of the ANAME draft, and I thought it was a
terrible idea, and said so at the time. The only reason I wrote it was that
I believed browser vendors would remain unwilling to adopt a more sensible
alternative, and as soon as my pessimism turned out to be unfounded, I was
quite happy to drop the proposal.


the browsers are doing something that makes more sense to them.

https://www.domaintools.com/resources/blog/the-use-cases-and-benefits-of-svcb-and-https-dns-record-types

--
P Vixie

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

[dns-operations] DMV.CA.GOV to WCP please?

[Paul Vixie via dns-operations]

--- Begin Message ---

the name servers are:


dmv.ca.gov. 604763  IN  NS  ns7.net.ca.gov.
dmv.ca.gov. 604763  IN  NS  infohqp5.ad.dmv.ca.gov.
dmv.ca.gov. 604763  IN  NS  ns6.net.ca.gov.
dmv.ca.gov. 604763  IN  NS  infoeqp5.ad.dmv.ca.gov.
dmv.ca.gov. 604763  IN  NS  ns5.net.ca.gov.


two of those are in RFC 1918 space:


infohqp5.ad.dmv.ca.gov. 604800  IN  A   172.18.0.251

...

infoeqp5.ad.dmv.ca.gov. 604784  IN  A   172.20.0.251


this runs afoul of my "no nameserver IPs in RFC 1918" rule:


31-Dec-2021 04:42:35.439 rpz: info: client @0x139107a00 
2001:559:8000:cd::4#46993 (dmv.ca.gov): rpz NSIP NXDOMAIN rewrite 
dmv.ca.gov/NS/IN via 12.0.0.16.172.rpz-nsip.dns-policy.vix.com


thus, i can't look up the details on how to register my truck.

help? i could remove the rule, but, i may not be alone.

--
P Vixie

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

Re: [dns-operations] [Ext] What is the reason of J-Root doesn't serve the arpa zone?

[Paul Vixie via dns-operations]

--- Begin Message ---



Paul Hoffman wrote on 2021-12-03 19:28:

On Dec 3, 2021, at 7:05 PM, Paul Vixie via dns-operations 
 wrote:


2870 was wrong in this respect, and should be revised to allow ARPA.


Why that, instead of the direction taken by RFC 9120? RFC 9120 was sponsored by 
the IAB, and the draft that led to it (draft-iab-arpa-authoritative-servers) 
was discussed in DNSOP earlier this year.


the IAB has been pretty much hit or miss on DNS topics. depends on who 
they are and who they listen to. merit isn't predicted either way.


internet work won't commence without being able to get a delegation from 
either the root or ARPA servers. the only reason they are separate zones 
is so they can be administered separately. they don't and we can't 
benefit from disparate reachability. so any moving parts is too many.


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

Re: [dns-operations] What is the reason of J-Root doesn't serve the arpa zone?

[Paul Vixie via dns-operations]

--- Begin Message ---



Wessels, Duane via dns-operations wrote on 2021-12-03 15:39:

In November 2002 K, L, and M were added to the NS list for arpa,
but J was not.  We can't speak to decisions made by the other
operators, but Verisign chose not to put j.root-servers.net in the
NS set based on the language of RFC 2870.


2870 was wrong in this respect, and should be revised to allow ARPA.

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