Re: [dns-operations] __p_rcode() deprecated? (glibc/Suse)

* Paul Vixie via dns-operations: > Can someone from glibc (as experienced via Suse Leap 15.6) self-identify so > that we can discuss some changes to /usr/include/resolv.h ? > >> const char * p_class (int) __THROW __RESOLV_DEPRECATED; >> const char * p_time (uint32_t) __THROW __RESOLV_DEPRECATED

Re: [dns-operations] Destination-adjacent source address spoofed DNS queries

* John Kristoff: > This seems DNS operationally relevant and I hope no one will mind the > plug. It was fun to write up a small piece on some curious spoofed DNS > queries we observed. Something that probably would have been overlooked > otherwise. We could probably do this 24x7. :-) > >

Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

* Thor Spruyt: > Packets: > > $ sudo tcpdump -nn -p host 2a02:348:a1:bd32::1 > 19:33:04.426128 IP6 2a02::::1.60034 > 2a02:348:a1:bd32::1.53: 10024 > [1au] DS? www.veilingzaalmelase.be. (53) > 19:33:04.434834 IP6 2a02:348:a1:bd32::1 > 2a02::::1: frag (0|1232) 53 > > 60034: 10024*-

Re: [dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs

* Viktor Dukhovni: > * For RRSIG and NSEC3, authoritative servers MAY respond with REFUSED, or, > for RRSIG, assuming the qname exists, MAY return either a synthetic answer > of their choice or some non-empty subset of the actual RRSIG records. For > synthetic replies, a zero TTL an

Re: [dns-operations] Quad9 DNSSEC Validation?

* Winfried Angele: > I guess they've turned off validation for irs.gov because of a > former failure. I think it goes beyond that. It extends to GOV and MIL as a whole, it seems. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https:/

Re: [dns-operations] Support for ED25519/ED448 DS records by OpenSRS

* Simon Arlott via dns-operations: > Supposedly it is to protect registrants from bad data but it would be > trivial to simply enter the wrong numbers in the individual component DS > record web forms that everyone is fond of. The registry signs the DS RRset with its own key. It's good practice

Re: [dns-operations] Monitoring for impending expiration of domains?

* Lyle Giese: > Yea, put them on auto renew via a credit card and change credit cards or > the card expires.  Now how many places was the old card used and it > might be a year before it comes around to bite us. And then accounting > doesn't know who used that card and who has access to that pl

Re: [dns-operations] A? ftp://netgear.routerlogin.net/shares/.

* Jeroen Massar: > It is pretty amazing that the DNS software between the thing that > has that and our recursors even accepted the /'s in the query, note > the dot at the end. It's in RFC 2317, more or less: 1 CNAME 1.0/25.2.0.192.in-addr.arpa. 2 CNAME 2.0/

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

* Phil Pennock: > Double-check: in such a scenario, if the request is for the recursive to > validate DNSSEC and this zone is not opt-out, then the recursive would > HAVE to get the data from the child, because the parent won't have RRSIG > records for the glue NS, right? DNSSEC is designed under

Re: [dns-operations] resolver cache question

* Mark Allman: >> One could use a Bloom filter to avoid caching (most) lookup >> results that are encountered just once. Or start out with an >> artifically lowered TTL combined with prefetching. > > I am not sure what you mean. If a given lookup isn't in a bloom > filter, add it to the bloom fi

Re: [dns-operations] resolver cache question

* Mark Allman: > I just finished reading a paper that basically tries to figure out > if a hostname is worth caching or not [1]. This isn't the first > paper like this I have read. This sort of thing strikes me as a > solution in search of a problem. The basic idea is that there are > lots of h

Re: [dns-operations] Split view autoconfiguration

* Petr Menšík: > I'll try to rephrase. Connection provides list of domains, it considers > internal. All names in that domains should be resolved using DNS servers > provided by that connection. Because common network connection managed > by NM or systemd-networkd does not have "internal domains"

Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request

* John Levine: > In article <20200908181130.gd4...@straasha.imrryr.org> you write: >>> Seems to me that would be true for any software that uses the usual >>> BSD or linux socket calls that match the host and port ... > >>You're conflating binding the UDP socket which specifies the *local end* >>o

Re: [dns-operations] Nameserver responses from different IP than destination of request

* Warren Kumari: > On Mon, Aug 31, 2020 at 2:11 PM Florian Weimer wrote: >> >> * Puneet Sood via dns-operations: >> >> > We would be interested in hearing other operator's experience here. >> > Are recursive servers seeing similar behavior from

Re: [dns-operations] Nameserver responses from different IP than destination of request

* Puneet Sood via dns-operations: > We would be interested in hearing other operator's experience here. > Are recursive servers seeing similar behavior from authoritative > servers? If yes, are you discarding these responses? > Are there authoritative server operators who still need the > flexibil

Re: [dns-operations] FlagDay 2020 UDP Size

* Tony Finch: > Stub resolvers should do the same if they have enough brain to do so :-) They are quite forgetful by design on some systems. But in general, this issue is not a problem for them because they do not enable EDNS. ___ dns-operations mailin

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

* Stephane Bortzmeyer: > Several users on Twitter reported problems accessing Banque Populaire > (a French bank) https://www.banquepopulaire.fr > https://www.ibps.loirelyonnais.banquepopulaire.fr > https://www.ibps.bpaca.banquepopulaire.fr > https://www.ibps.mediterranee.banquepopulaire.fr/ > > Fr

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

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

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

* Vladimír Čunát: > (I don't react to the SERVFAIL from CloudFlare auth.) > > On 4/19/20 8:55 AM, Viktor Dukhovni wrote: >> the NSEC RR promises TLSA records, among a rather oddball mix of >> other rrtypes > > I believe that's normal for CloudFlare authoritatives, and so far I've > noticed no real

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

* Viktor Dukhovni: > On Wed, Apr 15, 2020 at 07:23:37AM +0200, Florian Weimer wrote: > >> > My instinct is that it is now safe to just always send AD=1 in queries, >> > which would partly resolve the issue, but if that is liable to break >> > lookups via some

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

* Viktor Dukhovni: > The reason I ask, is that the MUSL libc stub resolver has no support for > EDNS and so no DO=1, but Postfix DANE support still needs to see the AD > bit from the local resolver, which is not sent when there's no AD=1 in > the query. > > My instinct is that it is now safe to ju

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

* Matthew Richardson: > Thanks - I also had thought the NODATA response was wrong, but wanted a > second opinion... > > However, is this going to cause any practical problems? It breaks search list processing in the stub resolver. Thanks, Florian ___

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

* Ray Bellis: > On 23/01/2020 21:15, Paul Hoffman wrote: > >> Ad the problem seems fixed now, at least from the vantage points >> I use (which hit Cloudflare at various places). > > There was a problem with some Cloudflare operated instances Does this mean we have 13th root server operator? _

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

* Warren Kumari: > On Wed, Jan 22, 2020 at 9:19 PM Viktor Dukhovni > wrote: >> >> On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote: >> >> > Are there any registries that configure secure delegations from DNSKEY >> > records (and do their own conversion to DS records) rather than accept

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

* Alexander Dupuy via dns-operations: > If any reader of this list is sending DNS requests with the EDNS Client > Subnet (ECS) option to 8.8.8.8, please read this post on our announcement > list that > discusses changes Google is plan

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

* Jason Livingood: > Seems like the answer then is to have the resolver check for updates > more frequently. The file is tiny and so this is not in the least > going to be resource-intensive. Just check every XX minutes. I had hoped that we could use distribution update mechanisms for the zone, l

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

* Stephane Bortzmeyer: > It doesn't matter. Everything is done in a few days. For a resolver > updating its copy of the root every month, this is enough to break > things. Agreed. A fancy distribution protocol would be needed instead. (I see parallels here with compiler changes where people cla

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

* Ondřej Surý: >> Raw change rates do not tell us if zones keep at least of some of >> their servers at constant addresses over really, really long >> periods of time. > > .bank > - deleted NS {ac1|ac2}.nstld.com. and added NS {a|b|c}.nic.bank. on November > 20 > and > - deleted NS {ac3|ac4}.nstl

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

* Ondřej Surý: >> On 27 Nov 2019, at 23:08, Florian Weimer wrote: >> >> What's the change rate for the root zone? > > https://twitter.com/diffroot Selective quoting does not help to further the discussion. Raw change rates do not tell us if zones keep at leas

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

* Jared Mauch: >> On Nov 27, 2019, at 5:26 PM, Florian Weimer wrote: >> >> What's the change rate for the root zone? If there is a full >> transition of the name server addresses for a zone, how long does it >> typically take from the first change to t

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

* Mark Allman: > Let me try to get away from what is or is not "big" and ask two > questions. (These are legit questions to me. I have studied the > DNS a whole bunch, but I do not operate any non-trivial part of the > DNS and so that viewpoint is valuable to me.) > > (1) Setting aside history a

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

* Jim Reid: >> On 26 Nov 2019, at 09:16, Florian Weimer wrote: >> >> Up until recently, well-behaved recursive resolvers had to forward >> queries to the root if they were not already covered by a delegation. >> RFC 7816 and in particular RFC 8198 changed that, b

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

* Jim Reid: >> On 25 Nov 2019, at 22:19, Florian Weimer wrote: >> >>> What do you consider to be a lot of queries? The root server system >>> collectively handles 500K-1M queries per second. That seems rather a >>> lot to me. YMMV. >> >> Bu

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

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

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

* Mark Allman: > Left here to be ripped apart ... :-) The query numbers are surprisingly low. To me at last. Do we know why the number of root instances has increased? Is it because of the incoming data is interesting? ___ dns-operations mailing list

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

* Paul Vixie: >> It seems that a dual-mode BIND9 server does return recursive data >> in answer to queries with "RD=0", but such answers then also have >> "AA=0". > > sounds like a bug, some of which did slip through BIND9's cracks. Aren't there cases where BIND 9 caches data in a supposedly-auth

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

* James Stevens: > Health-checks (e.g. pingdom etc) with RD=1 seem pretty common. They do not work reliably because failure rates for some large authoritative servers with RD=1 are significantly higher than with RD=0 (or at least were about ten years ago). I remember a bug in monitoring software

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

* James Stevens: > Would it be reasonable for an authoritative-only DNS Server to reject > / ignore / throttle requests with RD=1 ? It confuses people who try to debug issues with the dig tool. Some servers already do it. Some system adminstrators want to list authoritative name servers in /etc

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

* Mark Andrews: >> On 25 Sep 2019, at 6:13 am, John Levine wrote: >> >> In article you >> write: >>> Florian Weimer wrote: >>>> >>>> We added scope ID support to /etc/resolv.conf in upstream glibc a >>>> couple of years ag

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

* Stephane Bortzmeyer: > Informal survey: do you know an ISP (preferably a big one with a lot > of various clients) which advertises a DNS resolver with an IPv6 > link-local address? > > In France, Orange is doing that (with RA announces) and it seems to me > a bit risky (since some clients may fo

Re: [dns-operations] Mass deletion of .tw sub-domains?

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

Re: [dns-operations] sibling glue

* Tony Finch: > A question for those who know more about registry rules than me... Practically speaking, a registry-style zone operator must filter out sibling glue, or there will be domain hijacks. The zone operator does not know the structure of the reselling chain and cannot determine if two

Re: [dns-operations] about anti-ddos DNS hostings

* Edward Lewis: > It's not just a matter of the rich getting richer and the poor getting > poorer, it's a matter rooted in a technical fault in the architecture of > the system. It's not a technical fault. There's little liability for forwarding packets with forged source addresses, or designing

Re: [dns-operations] DNSSEC: Needs for zone transitions to Insecure

* Patrik Fältström: >> On 20 Mar 2015, at 07:33, Florian Weimer wrote: >> >> Are there still situations where a zone owner may have to transition >> the zone to Insecure temporarily to keep it available (or make it >> available again)? What about transfers betwee

[dns-operations] DNSSEC: Needs for zone transitions to Insecure

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

Re: [dns-operations] Mozilla Firefox and ANY queries

* Stephane Bortzmeyer: > On Fri, Feb 27, 2015 at 12:02:57AM -0500, > Sadiq Saif wrote > a message of 30 lines which said: > >> Checking local resolver logs and am seeing a large amount of ANY queries >> originating from Firefox, is anybody else seeing such behavior? > > https://blog.cloudflare

Re: [dns-operations] Mozilla Firefox and ANY queries

* Mark Andrews: > In message <87k2z0vksq@mid.deneb.enyo.de>, Florian Weimer writes: >> * Mark Andrews: >> >> > getaddrinfo was designed to extended. It wouldn't be hard to add ttl >> > information to getaddrinfo, just add a ai_ttl to the struct

Re: [dns-operations] Mozilla Firefox and ANY queries

* Paul Hoffman: > On Mar 1, 2015, at 2:47 AM, Florian Weimer wrote: >> The final part is the problem. Name resolution has to include other >> information source besides DNS, and it's difficult to merge this data >> with your own DNS resolver (whether you wrote it

Re: [dns-operations] Mozilla Firefox and ANY queries

* Mark Andrews: > getaddrinfo was designed to extended. It wouldn't be hard to add ttl > information to getaddrinfo, just add a ai_ttl to the structure at the > end and define a flag to say whether it is valid. struct addrinfo cannot be extended in this way because its size is part of the ABI,

Re: [dns-operations] Mozilla Firefox and ANY queries

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

Re: [dns-operations] extra records in resolver answer, any benefit?

* Tony Finch: > bert hubert wrote: >> >> It is all optional, and nobody does anything with that data. In fact stub >> resolvers do very little with what they receive. So for example, even the >> additional processing for an MX record is completely ignored mostly. > > Yes. > > The difficulty with

Re: [dns-operations] DNS training at the NSA

* Stephane Bortzmeyer: > On p. 9 (NSA slides, > leaked to the press), the DNS resolution process is strange, as if > recursion, instead of iteration, were used by all DNS servers of the > world, including the root name servers. Too much haste in using

Re: [dns-operations] [dDoS] Good discussion on the Rackspace attack and DNS resiliency

* Colm MacCárthaigh: > There's a good question embedded in that discussion: when a resolver > fails to get an answer from all of the authoritative nameservers for a > domain, why not use the last known answer, even if it's stale. > > Yes, that clearly violates the TTL of the rrset, but wouldn't b

Re: [dns-operations] knot-dns

* David Conrad: > Software diversity is a tool that network administrators use to > improve resiliency in their infrastructure. I agree it is not a > silver bullet but if I was building out critical infrastructure like > (oh say) a root server or a resolver cloud that my customers depend > on, I

Re: [dns-operations] knot-dns

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

Re: [dns-operations] knot-dns

* Roland Dobbins: > While it sounds good on phosphor, the concept of code diversity is so > abstract, compared to the significant operational challenges and > associated security challenges of operating separate systems > performing the same functions (sort of), but differently, that any > potenti

Re: [dns-operations] cool idea regarding root zone inviolability

* Paul Vixie: > at: > > http://www.diplomacy.edu/policybriefs > > we see: > > http://www.diplomacy.edu/sites/default/files/DiploFoundation%20Policy%20Brief%20No%204%20WEB.pdf Wouldn't be a first to step to cover root server *operators* (and root DNS server sites) to audits, lift them out of obscu

Re: [dns-operations] resolvers considered harmful

* Paul Vixie: > i believe that this fallback scheme is the only way you, or drc, or > florian, is able to get useful work done in this configuration. To clarify, I don't use dnssec-trigger, and I don't really employ mobile devices for personal use. ___

Re: [dns-operations] resolvers considered harmful

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

Re: [dns-operations] resolvers considered harmful

* David Conrad: > On Oct 22, 2014, at 10:27 AM, Florian Weimer wrote: >> I've suggested multiple times that one >> possible way to make DNS cache poisoning less attractive is to cache >> only records which are stable over multiple upstream responses, and >> li

Re: [dns-operations] resolvers considered harmful

* Mark Allman: > The Domain Name System (DNS) is a critical component of the Internet > infrastructure that has many security vulnerabilities. In particular, > shared DNS resolvers are a notorious security weak spot in the system. > We propose an unorthodox approach for tackling vulnerabi

Re: [dns-operations] need someone else to look at these servers

* Mark Andrews: > Yet somehow firewall vendors choose to do everything BUT what they > were instructed to do thereby causing a denial of service. A lot of what you propose is quite reasonable, but requires extensive gymnastics to align with the RFCs, which do not actually foster interoperability

Re: [dns-operations] need someone else to look at these servers

* Mark Andrews: > The servers (or the firewalls in front of them) are not RFC 103[45] > compliant. DNS is a query/response protocol. If you don't get a > response the server is broken. Running a UDP service which responds to unrecognizable packets is precisely what you should not do because it

Re: [dns-operations] ShellShock exploit through the DNS

* P. Vixie: > On October 18, 2014 4:06:07 PM EDT, Florian Weimer wrote: > >>Red Hat Enterprise Linux does not have this vector. It uses the >>regular glibc resolver, which is based on the old BIND stub resolver, >>and this code has both escaping from wire format to the

Re: [dns-operations] ShellShock exploit through the DNS

* Paul Vixie: > # > Tony Finch > Tuesday, October 14, 2014 5:31 AM > > A CGI script invoked by Apache httpd with HostnameLookups On > (the default is Off, a safer setting is Double) > > thanks, that makes sense. the security advisory posted here did not > mention any real world

Re: [dns-operations] EDNS with IPv4 and IPv6 (DNSSEC or large answers)

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

Re: [dns-operations] EDNS with IPv4 and IPv6 (DNSSEC or large answers)

* Franck Martin: > What is the recommended setup for EDNS? > -limit size to <1500? on both IPv4 and IPv6? Limit to packet size 1200 or less, and tell the kernel to disregard any path MTU information it has. > -allow UDP fragmentation on IPv4 and IPv6, how securely? Fragmentation in IPv4 is inhe

Re: [dns-operations] Looking for wildcard record served by a stable signed TLD nameserver

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

Re: [dns-operations] Opened Pandora's box of Cache Poisoning

* T. Suzuki: > Additional page: > http://www.e-ontap.com/dns/pandora_acjp_e/ Isn't this just the well-known phenomenon that once you can poison into a resolver cache under a specific name, you can poison all names? ___ dns-operations mailing list dns-op

Re: [dns-operations] Official WHOIS redirector for TLDs

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

Re: [dns-operations] Official WHOIS redirector for TLDs

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

[dns-operations] Official WHOIS redirector for TLDs

Is there are offical, documented WHOIS redirector for TLDs with some long-term interface stability. WHOIS.IANA.ORG might do the job, but I couldn't find official documentation pointing to it. ___ dns-operations mailing list dns-operations@lists.dns-oarc.

Re: [dns-operations] Is it illegal to query the .berlin TLD servers?

* Randy Bush: > as to the content of the txt rr, it seems to say you may not transfer > the zone file. not being able to transfer the zone file is rather > common. The TLDs for which zone files are not available for download are now in the minority. Per their ICANN agreement, the BERLIN zone sh

Re: [dns-operations] Opinions sought .... have I come to the right place?

* Joe Abley: >> | max-cache-size >> | >> | […] A value of 0 is special, meaning that records are purged from >> | the cache only when their TTLs expire. […] The default is 0. >> >> > > Someone from ISC should probably weigh in, but if

Re: [dns-operations] Opinions sought .... have I come to the right place?

* Stephan Lagerholm: > Keep in mind that most cache system are using Least Recent Used > Algorithm for their cache without any removal of expired records. Doesn't BIND use an unbound cache by default? | max-cache-size | | […] A value of 0 is special, meaning that records are purged from | the

Re: [dns-operations] ALERT: .QA CCTLD in wrong hands currently

* Kauto Huopio: > And facebook.qa and tons of .qa govt domains etc. Note also this: > > google.com.qa. 14400 IN MX 0 google.com.qa. That would actually be valid (but redudant). It causes mail for google.com.qa to be delivered to the host at google.com.qa, based on the A/

Re: [dns-operations] Can MX be working with CNAME?

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

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

* Vernon Schryver: > The question had nothing to do about J. Sixpack with 37 televisions, > phones, and other devices behind a NAT router owned by and remotely > maintained by Comcast. Perhaps because they are already running a DNS cache on the local network. :-P _

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

* David Conrad: > Running a recursive server is (should be) far easier than running > the vast majority of other "local servers". If it isn't, they're > using the wrong recursive server. With the exception of root key > rollover, running a recursive server is a fire-and-forget type > service (mo

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

* Paul Hoffman: > A fictitious 100-person company has an IT staff of 2 who have > average IT talents. They run some local servers, and they have > adequate connectivity for the company's offices through an average > large ISP. > > Should that company run its own recursive resolver for its > employ

Re: [dns-operations] DNSSEC and Re: DNS Attack over UDP fragmentation

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

Re: [dns-operations] DNS Attack over UDP fragmentation

* Daniel Kalchev: > Might be the appropriate time to think how to depend less on caching > is now? Or cache only after validation? It's certainly possible to reduce caching for unstable data. Say you use a certain piece of cached information four times initially, then you revalidate. If the da

Re: [dns-operations] DNS Attack over UDP fragmentation

* Mark Andrews: > In message <20130906074928.ga19...@nic.fr>, Stephane Bortzmeyer writes: >> The way I understand it: with Kaminsky and/or Shulman, you can still >> poison a DNS cache. The downstream validating resolver will detect it >> and send back SERVFAIL to the end user. But this end user wo

Re: [dns-operations] DNS Attack over UDP fragmentation

* Paul Vixie: > how much more money, brains, and time are we going to collectively waste > on dns (so, a WOMBAT) to solve the problems dnssec solves, rather than > just deploying dnssec? Because DNSSEC does not prevent cache poisoning, it only detects it. Once your cache is poisoned, it is diffic

Re: [dns-operations] DNS Attack over UDP fragmentation

* Ondřej Surý: > I think it should be quite safe to cap the maximum EDNS0 to 1280 > (the minimum IPv6 MTU) and set DF flag in all responses. Setting the DF flag on responses will be counterproductive because you must not perform path MTU discovery, either by disabling in the stack, or by filterin

Re: [dns-operations] Best Practices

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

Re: [dns-operations] Best Practices

* Paul Vixie: >> a) Secure configuration guidelines (RRL you can't make part of that, because >> it requires too much tuning IMHO). > > rrl's defaults work fine on every authority server i've tried. That's probably because those servers don't see traffic from resolvers which in turn have clients

Re: [dns-operations] DNS Issue

* Tony Finch: > Florian Weimer wrote: >> >> I think you still can't serve UDP over IPv6 without per-client sate, >> keeping both full RFC conformance and interoperability with the >> existing client population. Pre-fragmentation to 1280 or so bytes >> i

Re: [dns-operations] DNS Issue

* Joe Abley: > The assumption is that "firewall" means "device that keeps > state". This could be a firewall, or a NAT, or an in-line DPI > device, or something similar. We're not talking about stateless > packet filters. I think you still can't serve UDP over IPv6 without per-client sate, keepin

Re: [dns-operations] Monday rant againt the uses of the Public Suffix List

* Vernon Schryver: > It might also be worth noting that co.uk as well as com, org and > the few other TLDs that I tried just now lack A, , and MX RRs, > so a browser could use a DNS test to reject some supercookies. Doesn't work. There aren't address records for enyo.de, but I could currentl

Re: [dns-operations] Enom's name server broken?

* Fan Of Network: > I'd expect Enom to keep replying to queries as they used to before list of > authoritative name servers for my domain was changed. In ideal world they > should do that for TTL on parent server (here .com so 2 days) In an ideal world, they would serve the new zone contents, wit

Re: [dns-operations] ID of IPv4 fragments and DNS and the future RFC

* Stephane Bortzmeyer: > The future RFC 6864, currently in AUTH48 state, talks about the > unicity of the ID (datagram identifier) field for IPv4. Its section > 5.2 is of interest to us: basically, it says that senders of > "non-atomic packets" (a non-atomic packet is an IPv4 packet which is > fra

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

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

Re: [dns-operations] responding to spoofed ANY queries

* Paul Vixie: >> The spoofing problem could be mitigated if we actually wanted to, and >> were willing to punish those who try to send their pollution to the >> rest of the network. > > no. there is no "we" in this context. I meant the "we" in "we the people". Punishment for community-harming be

Re: [dns-operations] responding to spoofed ANY queries

> The problem is amplification. No, the actual problem is source address spoofing. > It can only be mitigated. The spoofing problem could be mitigated if we actually wanted to, and were willing to punish those who try to send their pollution to the rest of the network. We just need to admit tha

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

* Tony Finch: > Florian Weimer wrote: >> >> It seems to me it's true for BIND. You can get much more data in the >> additional section of the ANY response over TCP. Without TCP, it is >> simply left out. > > Oh right, that's standard semantics, RFC

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

* Tony Finch: > Florian Weimer wrote: >> >> This will still break things because prior to the change, large >> authoritative ANY responses are truncated without setting TC=1. > > That isn't true for BIND or ATLAS. It seems to me it's true for BIND. You can

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

* Mark Andrews: > Instead of just causing everyone to hack their code to force TCP > just return NOERROR, TC=1 and legitimate client will fallback to TCP > without all the other side effects of this ill considered change. This will still break things because prior to the change, large authoritati

Re: [dns-operations] BIND 9.7 was Re: what nameserver software have you been using?

* Feng He: > 于 2012-12-17 23:37, Sebastian Wiesinger 写道: >> The think is, new BIND versions on Debian are rare, and you're >> shipping/building a lot of libs and tools with many dependencies so >> building own packages is complicated. >> >> The next(!) stable version of Debian (wheezy) will have b

Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks

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

  1   2   >