Re: Two domains reporting errors
On 28 Sep 2014, at 08:37 , LuKreme krem...@kreme.com wrote: This is all very interesting. To be honest, I first figured out how to generate named.con and the domain failed Sigh. named.conf and the domain files. I swear, my typos and OS X autocorrect do *not* get along. -- K is for KATE who was struck by an axe L is for Leo who swallowed some tacks ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Two domains reporting errors
OS X/iOS autocorrect doesn't work well for technology conversations, period. It's always changing words and acronyms to other things more interesting. I swear it waits till the moment you hit send. -- *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS |-*O*- ||_// Biomedical | Ryan Novosielski - Senior Technologist || \\ and Health | novos...@rutgers.edumailto:novos...@rutgers.edu- 973/972.0922 (2x0922) || \\ Sciences | OIRT/High Perf Res Comp - MSB C630, Newark `' On Sep 28, 2014, at 10:39, LuKreme krem...@kreme.commailto:krem...@kreme.com wrote: On 28 Sep 2014, at 08:37 , LuKreme krem...@kreme.commailto:krem...@kreme.com wrote: This is all very interesting. To be honest, I first figured out how to generate named.con and the domain failed Sigh. named.conf and the domain files. I swear, my typos and OS X autocorrect do *not* get along. -- K is for KATE who was struck by an axe L is for Leo who swallowed some tacks ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.orgmailto:bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AXFR root zone
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 message. Regards, rfg P.S. Strangely, this rather different query _does_ work: dig @k.root-servers.net . axfr So, um, it appears that k will allow the AXFR but, I gather, other root zone servers won't (?) As Seinfeld would say What's up with that? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR root zone
On 28/09/2014 22:41, Ronald F. Guilmette wrote: Hi Ronald, Is it possible to use dig to AXFR the root zone? I mean without having Yes, it is. 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 message. This query is sent to one of the *recursive* servers in your /etc/resolv.conf file, so it can't provide you with a zone transfer of the root zone. Unlike other query types, an AXFR is not recursively looked up by a resolver. P.S. Strangely, this rather different query _does_ work: dig @k.root-servers.net . axfr So, um, it appears that k will allow the AXFR but, I gather, other root zone servers won't (?) Speaking as the operator of K-root, I can confirm that K allows zone transfers. That's why this query works. Regards, Anand Buddhdev RIPE NCC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR root zone
In message 54287c3f.60...@ripe.net, Anand Buddhdev ana...@ripe.net 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: dig @k.root-servers.net . axfr So, um, it appears that k will allow the AXFR but, I gather, other root zone servers won't (?) Speaking as the operator of K-root, I can confirm that K allows zone transfers. That's why this query works. Wow! I am delighted that I've been able to get an answer to my question direct from the horse's mouth as we say... and on a Sunday even! So, um, THANK YOU for that. But please allow me a couple of follow-up questions also... It appears to me that the a root server _does not_ allow the zone transfer. My guess is that the operators of that server wished to prevent every impertinent fellow (like me) and his brother from all writing scripts which would run frequently and which would always suck copies of the root zone from the most obvious candidate, i.e. a.root-servers.net. Is that approximately correct? Or are the operators of the a server just less friendly/accomodating folks than you? ;-) Do 100% of the other (non-a) root zone servers support axfr for the root zone? (I only checked b, c, and your's, k, but those all seem to do so.) Is the openness of your server (to root zone axfrs) a policy choice that I can rely on, i.e. that is likely to be in place for the forseeable future? I ask because I have indeed written a script which I will be running on the order of once per day, and which needs to be able to suck down a copy of the root zone. May I rely on this continuing to work for the forseeable future if I hardcode my little script with the name k.root-servers.net? Or is there a better choice for the long term? Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR root zone
On 9/28/2014 17:59, Ronald F. Guilmette wrote: I ask because I have indeed written a script which I will be running on the order of once per day, and which needs to be able to suck down a copy of the root zone. May I rely on this continuing to work for the forseeable future if I hardcode my little script with the name k.root-servers.net? Or is there a better choice for the long term? Regards, rfg Hi, I suggest using: xfr.lax.dns.icann.org xfr.cjr.dns.icann.org As mentioned on http://www.dns.icann.org/services/axfr/. I found out about it via a comment in the named.conf shipped in the FreeBSD ports version. -- staticsafe https://staticsafe.ca ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR root zone
I ask because I have indeed written a script which I will be running on the order of once per day, and which needs to be able to suck down a copy of the root zone. May I rely on this continuing to some of the root-servers allow an axfr, but you are probably better off looking at http://www.internic.net, especially http://www.internic.net/domain/. jaap ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR root zone
In message 54288592.6030...@staticsafe.ca, staticsafe m...@staticsafe.ca 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR root zone
On 28/09/2014 23:59, Ronald F. Guilmette wrote: Hi Ronald, Wow! I am delighted that I've been able to get an answer to my question direct from the horse's mouth as we say... and on a Sunday even! So, um, THANK YOU for that. You're welcome :) It appears to me that the a root server _does not_ allow the zone transfer. My guess is that the operators of that server wished to prevent every impertinent fellow (like me) and his brother from all writing scripts which would run frequently and which would always suck copies of the root zone from the most obvious candidate, i.e. a.root-servers.net. Is that approximately correct? Or are the operators of the a server just less friendly/accomodating folks than you? ;-) I'm afraid I cannot speak for Verisign, the operator of A-root. Do 100% of the other (non-a) root zone servers support axfr for the root zone? (I only checked b, c, and your's, k, but those all seem to do so.) Some do, and some don't. I don't know off the top of my head, but you can query and find out. Is the openness of your server (to root zone axfrs) a policy choice that I can rely on, i.e. that is likely to be in place for the forseeable future? Yes, we have chosen to allow zone transfers, so we will keep providing them for the foreseeable future. I ask because I have indeed written a script which I will be running on the order of once per day, and which needs to be able to suck down a copy of the root zone. May I rely on this continuing to work for the forseeable future if I hardcode my little script with the name k.root-servers.net? Or is there a better choice for the long term? 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. However, you're better off using ICANN's dedicated zone transfer servers. See this URL for details: http://www.dns.icann.org/services/axfr/ Regards, Anand Buddhdev RIPE NCC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR root zone
In message 54289195.2070...@ripe.net,
Anand Buddhdev ana...@ripe.net 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, actually. Thank you. A prior version of my script did exactly
that. But I just hacked out all of that rather clumsy code, because
it seems that it is no longer necessary.
However, you're better off using ICANN's dedicated zone transfer
servers. See this URL for details:
http://www.dns.icann.org/services/axfr/
YESS! I'm already on it...
=
...
my $res = Net::DNS::Resolver-new (nameservers = ['xfr.lax.dns.icann.org',
'xfr.cjr.dns.icann.org']);
my @rr_list = $res-axfr ('.');
...
=
Works great!
Thanks again.
Regards,
rfg
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Punycode questions
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 nutshell, I'd just like to know whether or not Punycode encoded strings may ever validly contain either (a) leading periods or else (b) two consecutive periods. Would any strings that contain either of those things be considered to be valid Punycode encoded strings? 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 Invalid punycode! errors. (It may perhaps yield different results for other people who have different versions of the relevant Perl modules installed.) Anyway, this example program is designed and intended to print out those exact errors whenever it sees a string coming back from the encode_punycode function that contains either a leading period or else a pair of consecutive periods. The short example program (at the URL above) was derived from portions of the following test set, used for testing applications that try to make use of the Mozilla Project's so-called Public Suffix List: http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/data/test_psl.txt?raw=1 (See also: https://publicsuffix.org/) So anyway, either the encode_punycode function supplied by the Net::IDN::Punycode Perl module has a serious bug in it, or else there must be something really very basic about Punycode that I just don't understand. I _thought_ that the whole idea of Punycode was that random Unicode/UTF-8 strings could be encoded in a way that wouldn't give name servers, or anything else accustomed to dealing with traditional domain names heartburn. Yes? No? Anyway, although I haven't actually tried it, I do expect that my local copy of BIND would be rather unhappy with me if I were to try to give it a zone file in which some of the labels either began with periods or else contained any consecutives sequences of periods. Am I wrong about that? Regards, rfg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
