Running dig on a newly built Linux machine I see
the below output (and man page explaining it).
To me this just seems wrong. Mucking with the
bare metal here is not desirable. The zone *is*
x n - - x k c 2 a l 3 h y e 2 a . , it is not
the native script version (which is unprintable
on th
Den 2012-07-09 17:39, Edward Lewis skrev:
$ dig xn--xkc2al3hye2a. ns
dig +trace xn--xkc2al3hye2a
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
2 last zerro is bad sign
___
dns-operations mailing list
dns-operations@lists
On 9 Jul 2012, at 16:39, Edward Lewis wrote:
Should DiG's output be unchanged or is this "good?" Should the OS
vendors be asked to stop this?
IMO, dig should only display what's actually in the DNS packets. Some
other tool(s) can be used to render IDNs into whatever non-ASCII
scripts/fon
Weird...first private reply to me, someone says
they can't see the message. What I did was a cut
and past from terminal in MacOS into the Eudora
I've been using since just before it was
discontinued.
Below, what I see makes it look like there's more
than one layer of IDN messing with my min
At 17:53 +0200 7/9/12, Benny Pedersen wrote:
Den 2012-07-09 17:39, Edward Lewis skrev:
$ dig xn--xkc2al3hye2a. ns
dig +trace xn--xkc2al3hye2a
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
2 last zerro is bad sign
The name isn't a problem, it's dig. From anothe
On 2012-07-09, at 12:14 PM, Jim Reid wrote:
> On 9 Jul 2012, at 16:39, Edward Lewis wrote:
>
>> Should DiG's output be unchanged or is this "good?" Should the OS vendors
>> be asked to stop this?
>
> IMO, dig should only display what's actually in the DNS packets.
By default, yes.
> Some ot
On Jul 9, 2012, at 9:17 AM, Edward Lewis wrote:
> At 17:53 +0200 7/9/12, Benny Pedersen wrote:
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
>> 2 last zerro is bad sign
Not really. Some folks like minimal-response.
> The name isn't a problem, it's dig.
Sounds like a
At 10:04 -0700 7/9/12, David Conrad wrote:
Sounds like a "+no-ulabel" option feature request for dig ('cause dig
needs more options). I'm sure ISC will be happy to take your money to
implement said feature :-).
I'm not sure it's a DiG/ISC issue. Even when I tried the man page
"fix" the prob
The part you pasted in is encoded as UTF-16, but the message body
content type was set to ISO-8859-1:
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Mixed encodings in the same body isn't portable. I had to use:
cat msg | iconv -f utf-16
to see the UTF-16 part (which then of c
when forwarding unbound to a bind instance with dnssec support enabled,
but dnssec validation disabled, and when querying for a wildcard instance
(eg foo.fedorapeople.org), bind's reply to unbound is not satisfactory to
unbound. It seems unbound is expecting an NSEC/RRSIG over the NS record
set i
On Mon, Jul 9, 2012 at 12:18 PM, Paul Wouters wrote:
>
> when forwarding unbound to a bind instance with dnssec support enabled,
> but dnssec validation disabled, and when querying for a wildcard instance
> (eg foo.fedorapeople.org), bind's reply to unbound is not satisfactory to
> unbound. It se
In message , Paul Wouters w
rites:
>
> when forwarding unbound to a bind instance with dnssec support enabled,
> but dnssec validation disabled, and when querying for a wildcard instance
> (eg foo.fedorapeople.org), bind's reply to unbound is not satisfactory to
> unbound. It seems unbound is exp
On Tue, 10 Jul 2012, Mark Andrews wrote:
BIND bug, the "NOQNAME" NSEC/NSEC3 proof extraction is a side effect
of validation.
Do you have a tracking/reference number for me?
That said if you are talking through a recursive server that server
should be validating as there are situations that a
In message , Paul Wouters wri
tes:
> On Tue, 10 Jul 2012, Mark Andrews wrote:
>
> > BIND bug, the "NOQNAME" NSEC/NSEC3 proof extraction is a side effect
> > of validation.
>
> Do you have a tracking/reference number for me?
>
> > That said if you are talking through a recursive server that serv
In message , Paul Wouters wri
tes:
> > BIND bug, the "NOQNAME" NSEC/NSEC3 proof extraction is a side effect
> > of validation.
>
> Do you have a tracking/reference number for me?
RT#21409
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
15 matches
Mail list logo
