Re: [dns-operations] https://secure-web.cisco.com/1ZjyzJskkYQq7sVMAaORAQUNbtLnCDdiphJXoIUgaA7_oFL6tHC8iV070aZrCZfTyULjhkVi3xJfW5opBdNn-YVZVvneE8CazN4a3cBB_5D0ERlfp-D-9kGVsbAT_XzThiOOKiL1K02Z_t969017Ug

[Warren Kumari]

Ah all sorted then.

Thanks Duane,
W

On Mon, Nov 9, 2020 at 3:30 PM Wessels, Duane  wrote:
>
>
>
> > On Nov 9, 2020, at 11:44 AM, Warren Kumari  wrote:
> >
> > Erm, what sort of glitch? (seems to work for me - wondering if it is
> > transient, or ...)
>
>
> It was easily fixed.  The glitch was a bug in the backend script such that 
> every request led to an "Internal Server Error".
>
> DW
>
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] https://secure-web.cisco.com/1ZjyzJskkYQq7sVMAaORAQUNbtLnCDdiphJXoIUgaA7_oFL6tHC8iV070aZrCZfTyULjhkVi3xJfW5opBdNn-YVZVvneE8CazN4a3cBB_5D0ERlfp-D-9kGVsbAT_XzThiOOKiL1K02Z_t969017Ug

[Wessels, Duane via dns-operations]

--- Begin Message ---


> On Nov 9, 2020, at 11:44 AM, Warren Kumari  wrote:
> 
> Erm, what sort of glitch? (seems to work for me - wondering if it is
> transient, or ...)


It was easily fixed.  The glitch was a bug in the backend script such that 
every request led to an "Internal Server Error".

DW




smime.p7s
Description: S/MIME cryptographic 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] https://trans-trust.verisignlabs.com/

[Warren Kumari]

Erm, what sort of glitch? (seems to work for me - wondering if it is
transient, or ...)

In the meantime, you can try https://www.superficialinjurymonkey.com/
(click DNS Delegation Explorer), it might work for $whatever
trans-trust didn't. Note that this was thrown together while sitting
on a plane, watching Top Gear reruns.

It's likely full of bugs/may explode, killing everyone inside...

W

On Mon, Nov 9, 2020 at 4:18 AM Calvin Browne  wrote:
>
> Hi Guys,
>
>
> seems https://trans-trust.verisignlabs.com/ has developed a glitch - anyone 
> know who to poke (with thanks of course).
>
>
> regards
>
>
> --Calvin
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] dnstap tool

[Tony Finch]

Hoan Vu  wrote:
>
> We are learning to get query log by dnstap tool. For DNSTAP Tool we cannot
> get log query continuosly and directly to the current syslog server, since
> raw log need to capture and then read after stop capture.

Earlier today I saw a tweet from JP Mens about this which might help you
(I have not tried it myself)
https://github.com/dmachard/dnstap-receiver
https://twitter.com/jpmens/status/1325724102078963712

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Southerly, becoming cyclonic later, 4 to 6, occasionally 7
later. Moderate or rough. Occasional rain. Moderate occasionally poor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] How DNS work

[Stephane Bortzmeyer]

On Mon, Nov 09, 2020 at 03:34:32PM +,
 Jim Reid  wrote 
 a message of 60 lines which said:

> A well behaved resolving server will only send a handful of queries
> (if that) to the root every day - ie whenever it needs to lookup a
> TLD that hasn’t been cached.

And may be not even so, if they implement RFC 8198, or RFC 8806.

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

Re: [dns-operations] How DNS work

[Jim Reid]

> On 9 Nov 2020, at 04:15, Hoan Vu  wrote:
> 
> We really wanna know "what is round robin of DNS" and the nature of the rule 
> to choose the DNS Root of Resolver, what factor, algorithm,  that decide 
> the choice of DNS Root.

Why? Nobody needs to care about this - apart from the people who write DNS 
resolvers.

If you *really* want to know, consult the source code. There are quite a few 
open source DNS resolver implementations: BIND, unbound, Knot resolver, 
PowerDNS Recursor, etc.

For everyone else, all they need to know is their resolving servers generally 
query the authoritive server that answers quickest: ie the one that has the 
shortest round-trip time (RTT) for the query and response. This isn’t 
necessarily the authoritative server that’s physically closest. Factors beyond 
your control like network topology, hop count, bandwidth, routing/peering 
policies, server/router load, packet loss, etc. can sometimes mean an 
authoritative server 100km away is quicker to respond than one that’s only 100m 
away.

Resolving servers continuously monitor the RTT to all the authoritative servers 
for some domain and adjust where they send their queries based on what is 
happening in the network - for instance when a link fails or an unresponsive 
server comes back on-line.

“round robin in the DNS" is something very different from this. It’s mostly 
found in (stupid IMO) resolver configurations that use forwarding. In these, 
the server is given a list of servers and just forwards its queries to those 
servers. It mindlessly tries the first one in the list, then the next and so 
on. When it comes to the end of the list, the forwarder goes back to the start 
and cycles through the list again: hence round-robin. These forwarding 
configurations generally don’t care about RTTs and will usually forward queries 
to a server on this list even when they they know that server is dead.

> Suppose that we have one Root Secondary Node of Anycast in our country 
> (example DNS Root K), and we want to direct query of the DNS Cache to the 
> that DNS Root, how can we interfere the resolve process to do that (unless 
> otherwise configure only DNS Root K)

Don’t do that. Unless you’re forced to by law (ie “all DNS queries must remain 
inside our borders” or some stupid rule like that). Just let the resolving 
server decide for itself which servers are quickest to answer queries. It will 
do a far better job of that than you can. And also adapt in real time to 
outages, changes in network topology and so on. If you force a resolving server 
to always query a specific authoritative name server, that creates an avoidable 
and unnecessary single point of failure. It also complicates the management and 
configuration of the local server and day-to-day DNS operations.

If your DNS queries are not going to the nearest anycast node (for some 
definition of nearest) and that’s a concern, fix the underlying issue. Which is 
routing, not DNS. 

I also don’t understand why you seem to be so concerned about optimising 
queries to a root server. A well behaved resolving server will only send a 
handful of queries (if that) to the root every day - ie whenever it needs to 
lookup a TLD that hasn’t been cached.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] https://secure-web.cisco.com/1QObC8qh53iR__TlqRff59E5B8JFiAV2VUGirT2kdLKo0yz-mYw9xle11YYObM5lxuamt1wUA26DRNfoRK6v8IXYl9zUeX7VkWIaBof6KLCFjBHsfqxnMrN2Muac7SkNMlWXCdqDvPKJTAORrYe1s9

[Wessels, Duane via dns-operations]

--- Begin Message ---
Hi Calvin, you can poke me.

DW



> On Nov 9, 2020, at 1:05 AM, Calvin Browne  wrote:
> 
> Caution: This email originated from outside the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe. 
> 
> 
> 
> 
> Hi Guys,
> 
> 
> 
> seems https://trans-trust.verisignlabs.com/ has developed a glitch - anyone 
> know who to poke (with thanks of course).
> 
> 
> 
> regards
> 
> 
> 
> --Calvin
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://secure-web.cisco.com/1FMqJkV7gNbINx1vDfXazKCpr3zOuXT9N9057UPMBMfmLvhPO6UDpMKy56BJCPP6QvU4kTfnSpRBQiMSWbbs22CgJLomyJ05g-47OkggZhX_YF87ua5GFmPtGZ6N8mSwtBle3uNNh3g0gq0QKTGLoz_8Pc3BxD21O_w4exYKJ_gV5_BSOk9biufi118dEseS3ukd0T7E4q7VOEEvY-vGY3PiDu13L5LQhGkCLZbKgvPCNLgKTZTI97BthigpvvQdSgvy7AVC_FnNLo8XMXzfYyQ/https%3A%2F%2Flists.dns-oarc.net%2Fmailman%2Flistinfo%2Fdns-operations



smime.p7s
Description: S/MIME cryptographic 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] How DNS work

[Stephane Bortzmeyer]

On Mon, Nov 09, 2020 at 11:15:12AM +0700,
 Hoan Vu  wrote 
 a message of 122 lines which said:

> And we have already do lab, and then the DNS Cache work out of
> order, the DNS Root is choiced rondomly.

As explained in the APNIC article, it depends on the resolver. BIND,
Knot, Unbound and the others do not use the same algorithm.

> the nature of the rule to choose the DNS Root of Resolver, what
> factor, algorithm, 

Sometimes, it is more or less documented, but you'll probably have to
read the source code and, as you did, experiment in the lab to find out.

> Our final taget to want to know can we control the operation of the
> DNS Cache. Suppose that we have one Root Secondary Node of Anycast
> in our country (example DNS Root K), and we want to direct query of
> the DNS Cache to the that DNS Root, how can we interfere the resolve
> process to do that

Well, if it is free software (like PowerDNS, Unbound, BIND, etc), you
have to modify the source code (not for the faint of heart).

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

Re: [dns-operations] dnstap tool

[Matthew Ghali]

Hi! We have the dnstap binary running under daemontools' 'supervise', and pipe 
its output either to 'logger' for syslogging, or an 'aws logs push' process to 
ingest directly to Cloudwatch Logs. Since the example golang binary simply 
writes to standard out, it was easy to wire up.

matt

> On Nov 9, 2020, at 5:47 AM, Hoan Vu  wrote:
> 
> 
> Dear!
> 
> We are learning to get query log by dnstap tool. For DNSTAP Tool we cannot 
> get log query continuosly and directly to the current syslog server, since 
> raw log need to capture and then read after stop capture.
> I wanna to know how to get the query log continously when using DNSTAP TOOL 
> of your DNS and other DNS of organizations have already applied. Can you 
> share with us and help us to deploy DNSTAP TOOL to our DNS Authoritative 
> Secondary.
> Thanks!
> ___
> 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

[dns-operations] dnstap tool

[Hoan Vu]

Dear!

We are learning to get query log by dnstap tool. For DNSTAP Tool we cannot
get log query continuosly and directly to the current syslog server, since
raw log need to capture and then read after stop capture.
I wanna to know how to get the query log continously when using DNSTAP TOOL
of your DNS and other DNS of organizations have already applied. Can you
share with us and help us to deploy DNSTAP TOOL to our DNS Authoritative
Secondary.
Thanks!
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] How DNS work

[Hoan Vu]

Dear!



We are learning the operation of the DNS, we have find the document of
Apnic *"The Root of the DNS"* (
https://labs.apnic.net/presentations/store/2017-03-12-root-servers-explained.pdf
, *slide:18 "Which Root!"*, document said that " *Which letter they pick is
up to the resolver. Some do round robin, some latch on to the one they
think is faster. There are no particular rules that resolvers use here.
It’s not clear that resolvers use any particular heuristic to guide their
choice of root server letter, nor is it clear that it matters in any case."*
And we have already do lab, and then the DNS Cache work out of order, the
DNS Root is choiced rondomly.

We really wanna know "what is round robin of DNS" and the nature of the
rule to choose the DNS Root of Resolver, what factor, algorithm,  that
decide the choice of DNS Root. Our final taget to want to know can we
control the operation of the DNS Cache. Suppose that we have one Root
Secondary Node of Anycast in our country (example DNS Root K), and we want
to direct query of the DNS Cache to the that DNS Root, how can we interfere
the resolve process to do that (unless otherwise configure only DNS Root K).

What about round robin to choose with the top level domain, second level
domain, ... ?

 Does the rule round robin depend on the DNS Software of DNS Cache
(resolver) or DNS Root, DNS top level domain,?

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