In message ,
Stephane Bortzmeyer wrote:
>Doing this sort of survey on the wild (and wide) Internet leads
>rapidly into a deep rabbit hole :-)
>
>If you go that way, one may also add to the requirments: "test the
>name servers returned, to see if they actually reply (and with bit
>AA)".
Yes. Th
In message <20210909103322.ga27...@fantomas.sk>,
Matus UHLAR - fantomas wrote:
>On 09.09.21 03:20, Ronald F. Guilmette wrote:
>>I don't want and don't need SOA records. I want and need only the relevant
>>NS records.
>
>server in some cases send the SOA.
In message ,
Stephane Bortzmeyer wrote:
>On Tue, Sep 07, 2021 at 10:48:57AM -0400,
> Matthew Pounsett wrote
> a message of 32 lines which said:
>
>> Yeah, you can pretty reliably get the answer in one or two steps by
>> requesting the NS set for the FQDN. You'll either get your answer, or
>>
In message
Matthew Pounsett wrote:
>On Tue, 7 Sept 2021 at 03:45, Stephane Bortzmeyer wrote:
>
>> The only solution is chasing the delegations from the root (which is
>> what dig +trace is doing). Caching speeds it, this is why it is
>> better to go through your resolver than using dig +trace.
In message ,
Stephane Bortzmeyer wrote:
>> I know that I can get this information by using "dig +trace", but that seems
>> to be rather slow to me (wall clock time), and I want to be doing
>> this a lot.
>
>The only solution is chasing the delegations from the root (which is
>what dig +trace is
Greetings all,
Please forgive me if this question is a bit off-topic for this list.
I can be sure if it is or isn't until I get the answer.
My question is rather a simple one. Given some FQDN `D' and given
some DNS record type 'T' (e.g. either A or or perhaps even PTR) does
there exist some
In message ,
Anand Buddhdev wrote:
>On 21/06/2019 22:01, Ronald F. Guilmette wrote:
>> I'll switch to using the 9.14.3 or 9.15.0 dig command as soon as possible.
>> Until then I have a nice temprary workaround, which is to just append
>> @a.root-servers.net to my di
In message ,
Anand Buddhdev wrote:
>On 21/06/2019 04:55, Ronald F. Guilmette wrote:
>
>> What is it about unbound/local-unbound that makes it not plug and play well
>> with dig +trace? What is it that Google's public name servers are doing
>> that a local runni
In message <4e8f2e2c-7571-44dd-b012-57543debd...@ncartron.org>,
Nico Cartron wrote:
>Are you sure it's not your setup?
>I have plenty of dig running on FreeBSD (with bind-utils 9.14) and also
>Debian and they work just fine.
You know what? I think we may both be right.
Checking now, I think I
In message <9ba154cc-2272-46ec-a793-47ff31dca...@arin.net>, you wrote:
>Hi Ronald,
>You usually need to reinstall packages and ports after you do a major
>version upgrade to FreeBSD.
I guess that I did not make myself clear. Everything on this system is
freshly installed, from scratch.
I have t
I just recently "upgraded" my old FreeBSD system to the latest, 12.0
release. Now, something that used to work doesn't seem to work anymore,
specifically "dig +trace" seems to no longer function at all.
Example:
% dig +trace -x 195
In message <20180321055215.jm3ybhkz4vqgs...@mycre.ws>,
Robert Edmonds wrote:
>{... long explanation of why things are as they are, snipped...}
Thanks for all this Robert. I guess it all makes sense. I just
loath complexity. But sometimes it is unavoidable.
>If you are parsing packets and c
In message ,
Tony Finch wrote:
>BIND9 was a new codebase with very different internal library APIs, and an
>ambition to completely revamp the libc -> resolver interface - this is
>what the lwresd stuff was about. But no unix adopted this new design into
>its libc, so the ambition withered.
>
>S
In message <20180320205558.23ld7b2orcfky...@mycre.ws>,
Robert Edmonds wrote:
>Rick Dicaire wrote:
>> For libbind9, https://packages.ubuntu.com/trusty/libbind9-90
>
>You would also need the ".so" symlink in order to link with -lbind9,
>which is in this package:
>https://packages.ubuntu.com/trust
In message <20180320205115.wanrlpfisxx6g...@mycre.ws>,
Robert Edmonds wrote:
>It should be in the SYNOPSIS section :-)
>
>http://manpages.ubuntu.com/manpages/trusty/en/man3/resolver.3.html
>...
>Link with -lresolv.
Doh! yea. You're right. It's right there. Didn't notice.
(Argu
In message <20180320193041.d2bwvgkgyvqem...@mycre.ws>,
Robert Edmonds wrote:
>> I am porting some code of mine from FreeBSD to this Ubuntu system
>> and I'm getting the following unresolved symbols at link time:
>>
>> __res_query
>> __res_mkquery
>> __res_send
>>
>> It seems appar
Apologies in advance to all. I am probably just making some
bonehead mistake or small typo, but...
Can someone please instruct me as to the proper way to link to
libbind9 on Ubuntu 14.02 LTS?
I am porting some code of mine from FreeBSD to this Ubuntu system
and I'm getting the following unresol
Regarding the _res structure and the resolver library res_send()
function...
I have been unable to find any clear statement on the exact semantics
of the .retrans and .retry fields of the _res structure, specifically
with respect to the res_send() function.
The man page for resolver(5) seems to
In message <56796.1464377...@server1.tristatelogic.com>, I wrote:
>Over the past week or more, I have occasionally tried to drop
>in and read the forum discussions on this one particular site:
>
> www.amlinuxmedia.com
>
>Strangely, my own local name server seems to be able to resolve
>that name
Over the past week or more, I have occasionally tried to drop
in and read the forum discussions on this one particular site:
www.amlinuxmedia.com
Strangely, my own local name server seems to be able to resolve
that name only intermittently. First it resolved OK, then it doesn't
for awhile, th
My apologies for my earlier, arguably off-topic questions.
Now I have a real honest-to-goodness BIND question.
I have the following simple zone file installed as "test0.tristatelogic.com":
===
$TTL 3600
@ IN SOA
My apologies if this question might also be considered a bit
off-topic for this list.
Is the maximum possible size of a DNS packet (just the payload part...
not including IP and UDP headers) 64k bytes?
I have some old code which assumes that, perhaps incorrectly.
___
In message ,
Tony Finch wrote:
>Ronald F. Guilmette wrote:
>> To be more specific and concrete about it, here is a small
>> example Perl program I wrote:
>>
>>ftp://ftp.tristatelogic.com/pub/punybug.pl
>>
>> When *I* run this, it prints out several &q
I hope this post won't be considered too far off topic.
I've already sent this same question off to the guy who is the
current maintainer of the Net::IDN::Punycode Perl module, but
while I'm still impatiently awaiting his response I'm thinking
that maybe folks here could enlighten me.
In a nutsh
In message <54289195.2070...@ripe.net>,
Anand Buddhdev wrote:
>If you wanted your script to be robust, then you would program it with
>the names of all 13 root name servers, and have it try the zone
>transfers from a random server each time, and trying another one in case
>of failure.
Yes, act
In message <54288592.6030...@staticsafe.ca>,
staticsafe wrote:
>I suggest using:
>xfr.lax.dns.icann.org
>xfr.cjr.dns.icann.org
>
>As mentioned on http://www.dns.icann.org/services/axfr/.
Oh! Excellent! This is *exactly* what I needed! Thanks ever so
much.
Regards,
rfg
In message <54287c3f.60...@ripe.net>,
Anand Buddhdev wrote:
>... Unlike other query types, an AXFR is not recursively
>looked up by a resolver.
Ah! Ok. That certainly explains the failure then. Thank you for
enlightening me!
>> P.S. Strangely, this rather different query _does_ work:
>>
Is it possible to use dig to AXFR the root zone? I mean without having
any special foreknowledge of which specific root zone servers will and
will not accept the AXFR request? If so, how would I do that, exactly?
I tried this:
dig . axfr
but I just got back a "Transfer failed" error m
In message <20140927122322.ga4...@totoro.home.mukund.org>,
Mukund Sivaraman wrote:
>On Sat, Sep 27, 2014 at 04:31:07AM -0700, Ronald F. Guilmette wrote:
>> For a special project, I need to be able to create resource
>> records within a BIND zone file where some of the dom
For a special project, I need to be able to create resource
records within a BIND zone file where some of the domain
labels in some of the FQDNs on the left-hand-side will need
to be either (a) literal asterisks or else (b) literal
exclamation marks.
What's the most proper way to do this? Can I
In message <51baa714.9020...@dougbarton.us>,
Doug Barton wrote:
>It's obvious you're frustrated (understandable), and enthusiastic
>(commendable), but you might want to consider dialing down your
>"rhetoric" a bit.
Great idea! I have only one small question... Would you be willing to
provi
In message <20130614050625.850cf35e5...@drugs.dv.isc.org>,
Mark Andrews wrote:
>In message <15120.1371179...@server1.tristatelogic.com>, "Ronald F. Guilmette"
> writes:
>> >* Large numbers of ISPs claim they implement BCP 38.
>>
>> I claime
In message <201306140321.r5e3l7py017...@calcite.rhyolite.com>,
Vernon Schryver wrote:
>> From: "Ronald F. Guilmette"
>
>} That is an interesting contention. Is there any evidence of, or even any
>} reasonably reliable report of any DDoS actually being per
In message <20130614032434.72450.qm...@joyce.lan>,
"John Levine" wrote:
>>So, may I infer that rather than being put off until the end of the
>>century, which seemed to be the previous implementation timeline,
>>pervasive implementation of BCP 38 may now be expected at around the
>>time that 32
In message <20130614023140.7735d35e2...@drugs.dv.isc.org>,
Mark Andrews wrote:
>* Router manufactures have code to support BCP 38 though it defaults to off.
Well then, THAT is going to be a great help in solving the problem, isn't it?
>* Large numbers of ISPs claim they implement BCP 38.
I c
In message <20130614022305.72272.qm...@joyce.lan>,
"John Levine" wrote:
>>>The real solution is BCP 38...
>>
>>I agree completely John. I cannot do otherwise. But I have to ask the
>>obvious elephant-in-the-room question... How is that comming along so far?
>
>Based on discussions I've had wi
In message <20130614020930.c1c1c35e2...@drugs.dv.isc.org>,
Mark Andrews wrote:
>Well the process has started. BCP 38. If you want hurry it along
>complain to your local politician that they need to consider drafting
>legislation that requires ISP's to implement BCP 38 in their networks.
See!
In message <201306140126.r5e1quqj032...@calcite.rhyolite.com>,
Vernon Schryver wrote:
>Indeed. As many have mentioned, DNS reflection attacks are merely
>the current fad...
So it is "just a fad".
Whew! That's a load off! I'm glad that somebody told me. Fortunately
there is still time for
In message <20130614004155.72013.qm...@joyce.lan>,
"John Levine" wrote:
>The real solution is BCP 38...
I agree completely John. I cannot do otherwise. But I have to ask the
obvious elephant-in-the-room question... How is that comming along so far?
Maybe we could find worse ways to spend ou
In message <51ba355b.10...@dougbarton.us>,
Doug Barton wrote:
>No. You can still get pretty good amplification with 512 byte responses.
That is an interesting contention. Is there any evidence of, or even any
reasonably reliable report of any DDoS actually being perpetrated IN PRACTICE
using
In message <201306131753.r5dhrwon093...@calcite.rhyolite.com>,
Vernon Schryver wrote:
>I think that the use of RRL on some roots shows that keeping state
>is not a problem if the state keeping is not utterly stupid.
(I'm not sure what, if anything, I should be reading into that last bit
of a p
In message <51b9fb6a.1090...@tiggee.com>,
David Miller wrote:
>A system that requires the victim to take action to stop attacks...
You mean like the defacto "system" we have right now?
>... might be misconstrued by some to be abdicating the responsibility
>of the upper four levels.
Ummm... I
In message <51b9fb6a.1090...@tiggee.com>,
David Miller wrote:
>This could lead to wrong headed statements like, "Yes, we sent X GB of
>traffic at your network.
Yes.
Last night I reconsidered at some length the scheme I put forward yesterday.
(Please note that I am very deliberately calling it
In message <51b991f7.9070...@imperial.ac.uk>,
Phil Mayers wrote:
>On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote:
>> 2) Has anyone ever proposed adding to the DNS protocol something vaguely
>> reminicent of the old ICMP Source Quench? If so, what becam
I personally have been mad as hell about DNS amplification attacks,
ever since I first had the displeasure of finding myself on the business
end of one back in 2003. In recent days however I've been given reason
to be outraged about them all over again with the news that two organiza-
tions that
In message <39634800-7e01-4878-b1a1-cf384c8a6...@mac.com>,
Chuck Swiger wrote:
>On Sep 14, 2011, at 5:09 PM, Ronald F. Guilmette wrote:
>> In message , you wrote:
>>> Sigh: your mail server is blacklisting email from mac.com.
>>
>> Yes. Sorry about th
In message <4e7131a6.3000...@chrysler.com>,
Kevin Darcy wrote:
>Indeed. It should be noted that not only does the graphiteops.com name
>break the "CNAME and other" rule, but it's a *self-referential* CNAME
>(rdata = graphiteops.com), so if one tried to chase it, one could chase
>infinitely.
web site.)
Anyway, on-list replies are OK, I think. I mean it's not like any of
this is in any way off topic.
>> On Sep 14, 2011, at 2:27 PM, Ronald F. Guilmette wrote:
>>> The second part however seems to go more to my question, which is "What is
>>>
In message <7d9b265c-36bf-40c1-9012-ac0a96fb8...@sackheads.org>, you wrote:
>On Sep 14, 2011, at 4:35 PM, Ronald F. Guilmette wrote:
>
>> Is there a rule that says how a resolver should behave in cases where
>> there is both an A record and also a CNAME record for the
Last night, it appeared to me that nslookup was resolving the name
"graphiteops.com" to IP address 72.52.4.95.
Today however it is no longer doing that, reporting instead:
% 127.0.0.1
Address:127.0.0.1#53
Non-authoritative answer:
graphiteops.com canonical name = graphiteops.com.
G
When called, res_query must be passed the base address of a buffer
(`answer'), and the maximum length of that buffer (`anslen'). Upon
return, res_query returns the count of bytes bytes actually used in
the target buffer (i.e. the response packet size) or else -1 for errors.
Assuming that one wis
51 matches
Mail list logo