Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Wed, Jan 06, 2021 at 06:10:58PM -0500, Viktor Dukhovni wrote: This is a mistake that confuses input processing with output processing. Not necessarily. I think the implementor could decide that you're either doing IDNA or you're not, and if you expect non-IDNA stuff to be returned you should turn off IDNA (which is presumably why it's off for non-TTYs). I can easily imagine an implementation of a tool that simply will not return things to you if it's not IDNA-conforming. (I can see an argument also why that might be surprising, but that's a different matter.) This is in some ways akin to the browser rule that it won't show you a U-label unless it happens to be "in your configured language" (which, FWIW, I think has its own surprises). When converting the first label to presentation form, which does not since it does NOT start "xn--", applying IDNA rules makes no sense at all. I don't think that's what 5890 says. It says 'For IDNA-aware applications, the three types of valid labels are "A-labels", "U-labels", and "NR-LDH labels",' so a label starting with - is just invalid, no matter what. You're arguing, I think, that for a tool like dig, taking a domain name off the wire and restricting that domain name to IDNA is wrong. I think it's an implementation choice regarding what one is supposed to do with invalid data coming from the wire, but it's pretty clear it's surprising to at least some people in this context. Note that IDNA2008 does expect implementations to do local processing on domain names, and it's an interesting question whether that includes things that come back from resolution: the entire thing is written as though there's user input that is then converted for lookup, but this particular case seemed originally to crop up in the context where IDNs are probably unexpected but where IDNA was turned on. The point of IDNA was supposed! to be not just "least surprise" but also "internationalize LDH", and non-LDH labels just automatically violate that. Another way to say it is, if there's no eyeballs who need to read the identifier then you shouldn't use IDNA at all. The implementation is correct, but the context is wrong. The implementation is still not correct in any case, because it takes some NON-LDH labels and not others when IDNA is turned on, and that's bound to be incorrect under IDNA2008. (It strikes me that there might be another possibility, which is that dig is also attempting to work for IDNA2003, in which case this might still a bug but not in the way I was arguing.) Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Wed, Jan 06, 2021 at 03:59:04PM -0500, Andrew Sullivan wrote:
> So, I think what it means is that, with the IDN support turned on, dig
> is IDNA-aware and therefore shouldn't accept any NON-LDH label. As it
> happens, it accepts some NON-LDH labels but not others, which maybe
> _is_ a bug, but not the one people were complaining about. ;-)
This is a mistake that confuses input processing with output processing.
In the case in question, dig(1) is NOT reading textual labels to
interpret as domain names, it has a *wire* domain name inside a DNS
packet, that it needs to display to the user. That wire domain name
(with prefixes) is:
<1>-<5>house<3>gov<0>
When converting the first label to presentation form, which does not
since it does NOT start "xn--", applying IDNA rules makes no sense at
all. The ONLY correct thing to do there is escaping of special
characters ("\" escape or "\DDD" encoding).
The implementation is correct, but the context is wrong. Doing the
wrong thing correctly is still a bug.
--
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
Geez, it's a long time since I had to take a lot of care on IDNA and non-IDNA protocol cases. But here's my take. On Wed, Jan 06, 2021 at 01:38:43PM -0500, Dave Lawrence wrote: I'm not really following your logic, Andrew (or Mark), for how applying IDNA rules is relevant to interpreting the labels in question. My reading of the dig man page leads me to believe that IDN support basically turns domain name slots in dig (see 5890 §2.3.2.6) into IDNA-aware domain name slots. Now, 5890 §2.3.2.1 says, 'For IDNA-aware applications, the three types of valid labels are "A-labels", "U-labels", and "NR-LDH labels",' and that constrains what labels are permitted. 5890 §2.3.2.2 says an NR-LDH label can be neither an IDN, nor a reserved LDH label (R-LDH), but it can be otherwise anything permitted by §2.3.1. But §2.3.1 defines LDH label according to what is in RFC 952, and RFC 1034 §3.5 as modified by RFC 1123. Most assuredly, that does not permit a label that begins with "-". So, I think what it means is that, with the IDN support turned on, dig is IDNA-aware and therefore shouldn't accept any NON-LDH label. As it happens, it accepts some NON-LDH labels but not others, which maybe _is_ a bug, but not the one people were complaining about. ;-) I think there is good reason to blame the reviewers of 5890 for this being as confusing as it is in the text. In my defence, I will say it was worse in earlier drafts! Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <20210106032410.ga6...@isc.org> you write: >I wonder aloud if dig's default behavior should be to try IDN and >silently fall back to conventional output formatting if it fails. >I imagine there are situations where you'd want the rules strictly >enforced, but I'm not sure if there was a good reason to do that by >default. Given that there is no reason to assume that any particular query or result in dig will be a hostname as opposed to a generic DNS name, that sounds right to me. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
I'm not really following your logic, Andrew (or Mark), for how applying IDNA rules is relevant to interpreting the labels in question. Yes, I read your cited text from RFC 5890, but still am not grokking how it is relevant for dig choking on -.house.gov just because IDN output is enabled. It seems to me it would just get categorized as "NON-LDH labels" per the diagram in 2.3.1, and should then just be ignored as far as IDNA output processing is concerned. Though, in fairness, I will also admit that I don't have much more support for that position, in that "NON-LDH" appears nowhere beyond that diagram, and there's seems to be no explicit statement covering that category in the rest of 2.3.2. Where are you seeing the incorporating text that indicates that encountering them they should attempt to be interpreted as IDNA for output? Why is the unitary hyphen being handled specially there but not, say, # which also appears in the NON-LDH label category? (Which I just tested with no problems.) I'll go back to my earliest assertion that even if isn't properly a bug, boy is it surprising. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Jan 6, 2021, at 10:26 AM, Evan Hunt wrote:
>
> On Wed, Jan 06, 2021 at 03:24:10AM +, Evan Hunt wrote:
>> I wonder aloud if dig's default behavior should be to try IDN and
>> silently fall back to conventional output formatting if it fails.
>> I imagine there are situations where you'd want the rules strictly
>> enforced, but I'm not sure if there was a good reason to do that by
>> default.
>
> Ondrej has just reminded me that IDN conversion is disabled by
> default if stdout isn't a TTY, so the use of dig in scripts should
> be unaffected by this problem. (For example, it works fine if you
> use "dig +dnssec whatever.house.gov | cat".)
For this experiment, dig was being run in a Python script using subprocess.run.
I do not know why dig would think that was a TTY.
r = subprocess.run("dig @8.8.8.8 +dnssec +yaml {} A".format(this_name),
shell=True, capture_output=True, encoding="utf-8", check=True)
Given the errors, I had to add the +noidnout option.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Wed, Jan 06, 2021 at 03:24:10AM +, Evan Hunt wrote: > I wonder aloud if dig's default behavior should be to try IDN and > silently fall back to conventional output formatting if it fails. > I imagine there are situations where you'd want the rules strictly > enforced, but I'm not sure if there was a good reason to do that by > default. Ondrej has just reminded me that IDN conversion is disabled by default if stdout isn't a TTY, so the use of dig in scripts should be unaffected by this problem. (For example, it works fine if you use "dig +dnssec whatever.house.gov | cat".) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Tue, Jan 05, 2021 at 10:11:48PM -0500, John Levine wrote: If it's validating IDNs it makes sense to complain about something like xn--1234 which has an IDN prefix but isn't an A-label. But a label that is just a hyphen isn't a hostname just like _foo isn't a hostname. Why does it complain about one but not the other? Because if you're doing IDNA you have to permit only A-labels and NR-LDH labels, according to RFC 5890. NR-LDH labels are defined in §2.3.2.2, but refer to §2.3.1. In there is this text: [An LDH label] is the classical label form used, albeit with some additional restrictions, in hostnames [RFC0952]. Its syntax is identical to that described as the "preferred name syntax" in Section 3.5 of RFC 1034 [RFC1034] as modified by RFC 1123 [RFC1123]. Briefly, it is a string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets. The restriction on the hyphen not appearing at the beginning is actually not new: RFC 952 says a hostname has to begin with a letter, and 1123 relaxed that to allow either a letter or a digit (what Bob Braden once told me he called "the 3Com exception", apparently due to the reason for the change). The "preferred name syntax" never permitted a hyphen-minus in the initial position of a label, though of course DNS does in principle. So, if dig is in the mode of not doing IDNA, it's reasonable it can return anything; but if it _is_ in the mode of doing IDNA, it has to follow all the other rules too. Best regards, A (as usual, only for myself.) -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Tue, Jan 05, 2021 at 04:52:07AM +, Paul Hoffman wrote: > That all seems correct. However, I brought the issue to this mailing > list, instead of to the UltraDNS folks, because I am using tools that > expect host names instead of domain names (in this case, dig) Note: hostname vs. domain name isn't the problem here; the problem is dig is trying to interpret them as internationalized domain names and the IDN conversion threw an error on "-.house.gov". (I guess hyphens are a particular problem since libidn2 has a specific error code for that - IDN2_HYPHEN_STARTEND. I don't recall all the IDN syntax rules offhand.) I wonder aloud if dig's default behavior should be to try IDN and silently fall back to conventional output formatting if it fails. I imagine there are situations where you'd want the rules strictly enforced, but I'm not sure if there was a good reason to do that by default. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article you write: >dig by default is not built with IDN support. If you request IDN support at >build time >+[no]idnin and +[no]idnout are enabled which then expect valid IDN names on >the command >line for +idnin and in the output for +idnout. That can't be right. I can use dig for underscored names which aren't IDNs either and it doesn't complain. If it's validating IDNs it makes sense to complain about something like xn--1234 which has an IDN prefix but isn't an A-label. But a label that is just a hyphen isn't a hostname just like _foo isn't a hostname. Why does it complain about one but not the other? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
> On 6 Jan 2021, at 08:01, John Levine wrote: > > In article <20210105204121.c4d925829...@ary.qy> you write: >> In article <853ece14-271f-4e93-9473-d1dbde836...@icann.org> you write: >>> On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote: Paul Hoffman writes: > I am using tools that expect host names instead of domain names (in > this case, dig); I think I must be misunderstanding something, or at least haven't imagined widely enough the possibilities of your meaning here. dig has a particular expectation for hostnames either owning or in the rdata of an NSEC record? That's surprising to me. Not inconceivable, of course, but definitely surprising. >>> >>> I started this thread with: >>> dig +dnssec +noidnout anynameyouwant.house.gov a >>> Try that without the +noidnout option. >> >> With DiG 9.16.10 I get the same result either way. What do you get? > > Oh, OK, I tried a different name and got: > > dig: '-.house.gov.' is not a legal IDNA2008 name (string start/ends with > forbidden hyphen), use +noidnout > > That's a dig bug. It's a perfectly valid DNS name albeit a fairly ugly one. dig by default is not built with IDN support. If you request IDN support at build time +[no]idnin and +[no]idnout are enabled which then expect valid IDN names on the command line for +idnin and in the output for +idnout. It is not a bug for a tool to tell you that you have not got valid IDN names in the response or on the input. It may be not the behaviour you desire but it is not a bug. 'IDN_DISABLE=1;export IDN_DISABLE’ or equivalent will disable IDN processing by default in all versions of dig with IDN support. Now if you feel that strict IDN processing is not the behaviour you want you are free to submit a merge request with non-strict IDN behaviour. > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <20210105204121.c4d925829...@ary.qy> you write: >In article <853ece14-271f-4e93-9473-d1dbde836...@icann.org> you write: >>On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote: >>> >>> Paul Hoffman writes: I am using tools that expect host names instead of domain names (in this case, dig); >>> >>> I think I must be misunderstanding something, or at least haven't >>> imagined widely enough the possibilities of your meaning here. dig >>> has a particular expectation for hostnames either owning or in the >>> rdata of an NSEC record? That's surprising to me. Not inconceivable, >>> of course, but definitely surprising. >> >>I started this thread with: >> dig +dnssec +noidnout anynameyouwant.house.gov a >>Try that without the +noidnout option. > >With DiG 9.16.10 I get the same result either way. What do you get? Oh, OK, I tried a different name and got: dig: '-.house.gov.' is not a legal IDNA2008 name (string start/ends with forbidden hyphen), use +noidnout That's a dig bug. It's a perfectly valid DNS name albeit a fairly ugly one. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Jan 5, 2021, at 12:41 PM, John Levine wrote: > > In article <853ece14-271f-4e93-9473-d1dbde836...@icann.org> you write: >> On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote: >>> >>> Paul Hoffman writes: I am using tools that expect host names instead of domain names (in this case, dig); >>> >>> I think I must be misunderstanding something, or at least haven't >>> imagined widely enough the possibilities of your meaning here. dig >>> has a particular expectation for hostnames either owning or in the >>> rdata of an NSEC record? That's surprising to me. Not inconceivable, >>> of course, but definitely surprising. >> >> I started this thread with: >> dig +dnssec +noidnout anynameyouwant.house.gov a >> Try that without the +noidnout option. > > With DiG 9.16.10 I get the same result either way. What do you get? Using the same version as you: dig: '-.house.gov.' is not a legal IDNA2008 name (string start/ends with forbidden hyphen), use +noidnout Maybe your resolver is not validating? --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <853ece14-271f-4e93-9473-d1dbde836...@icann.org> you write: >On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote: >> >> Paul Hoffman writes: >>> I am using tools that expect host names instead of domain names (in >>> this case, dig); >> >> I think I must be misunderstanding something, or at least haven't >> imagined widely enough the possibilities of your meaning here. dig >> has a particular expectation for hostnames either owning or in the >> rdata of an NSEC record? That's surprising to me. Not inconceivable, >> of course, but definitely surprising. > >I started this thread with: > dig +dnssec +noidnout anynameyouwant.house.gov a >Try that without the +noidnout option. With DiG 9.16.10 I get the same result either way. What do you get? R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
Paul Hoffman writes: > I started this thread with: >dig +dnssec +noidnout anynameyouwant.house.gov a > Try that without the +noidnout option. Interesting. FWIW at first I saw no problem, because my MacBook has an older version of dig in /usr/bin. On my server with 9.16.10, though, the problem appears. At first glance I'd say that's a dig bug, but I do appreciate your point that, even if categorized that way, it is still the kind of potential problem that producers of such records would want to be aware. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote: > > Paul Hoffman writes: >> I am using tools that expect host names instead of domain names (in >> this case, dig); > > I think I must be misunderstanding something, or at least haven't > imagined widely enough the possibilities of your meaning here. dig > has a particular expectation for hostnames either owning or in the > rdata of an NSEC record? That's surprising to me. Not inconceivable, > of course, but definitely surprising. I started this thread with: dig +dnssec +noidnout anynameyouwant.house.gov a Try that without the +noidnout option. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
Paul Hoffman writes: > I am using tools that expect host names instead of domain names (in > this case, dig); I think I must be misunderstanding something, or at least haven't imagined widely enough the possibilities of your meaning here. dig has a particular expectation for hostnames either owning or in the rdata of an NSEC record? That's surprising to me. Not inconceivable, of course, but definitely surprising. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Tue, Jan 05, 2021 at 10:58:19AM -0500, John Levine wrote: > It is not clear to me that this stuff is there to prevent enumeration. > The funky names allow zone updates without having to keep the zone in > canonical order to regenerate the NSEC chain. With NSEC3 it is easy to perturb the SHA1 hashes by (+/-)1, do get fake neighbours with negligible probability of collision with a real neight. With NSEC3, one has to actually check that the "epsilon" functions don't yield ranges overlapping live data, so one still implicitly needs an ordering of the zone, it just does not have to be pre-signed. Now in fact, in the implementation in question, they have the real NSEC chain in place, and I just walk it with sufficiently exotic queries. So one can only conclude that indeed this is an ineffective zone-walking defence, for otherwise why bother? But there could perhaps be a bit more to this that's not entirely obvious. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <701c6017-9eb5-4660-90a2-4ae0e7e93...@icann.org> you write: >That all seems correct. However, I brought the issue to this mailing list, >instead of to the UltraDNS folks, because I am using tools that expect host >names instead of domain names (in this case, dig); now I have to write shims >around them. Other signing-on-the-fly mechanisms might cause similar issues >for dig or other tools. But wouldn't that equally fail on a SRV record with a _tcp name or a DKIM key with _domainkey? If you're poking at the DNS I'd think you need to be prepared for anything the DNS can return. It is not clear to me that this stuff is there to prevent enumeration. The funky names allow zone updates without having to keep the zone in canonical order to regenerate the NSEC chain. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Tue, Jan 05, 2021 at 09:45:33AM +0100, Vladimír Čunát wrote:
> Right, though my interest at this moment was more about how to *output*
> a name: there's lots of freedom and apparently no "preferred" way (in
> RFCs). Maybe it's not bad; otherwise more tools might start relying on
> one particular way of output.
Best practice for domain names (as owner names and as RDATA elements) is
IMHO:
- Escape all literal '\' characters in each label as "\\"
- Escape all literal '.' characters in each label as "\."
- Leave all LDH characters, "*", "/" and "_" unescaped
- Escape everything else as decimal triples "\DDD".
- Then terminate each label with an unescaped "."
If the output is not an RR but a standalone domain name for application
use, generally leave out the final ".".
The reason to not escape "/" is that it is used in some common
PTR names, and escaping it would make the output less readable.
The remaining special characters are then controls, octets with the high
bit set and:
!"#$%&'()*+,:;<=>?@[]^`{|}~
I can't think of compelling reasons to not escape most of the rest of
the above, but clearly "dig" is more relaxed, and leaves "!", "~" and
some other punctuation and symbol characters alone that are not special
in zone files. It will escape at least:
"$;()@[]
--
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On 1/5/21 8:21 AM, Viktor Dukhovni wrote: On Tue, Jan 05, 2021 at 08:07:16AM +0100, Vladimír Čunát wrote: Off the top of my head, I don't even now how exactly is the escaping specified in RFCs. That's easy, any*non-digit* character can be escaped with a preceding "\", or alternatively as a 3-digit*decimal* \DDD sequence. Right, though my interest at this moment was more about how to *output* a name: there's lots of freedom and apparently no "preferred" way (in RFCs). Maybe it's not bad; otherwise more tools might start relying on one particular way of output. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
Paul Hoffman wrote: > That all seems correct. However, I brought the issue to this mailing list, > instead of to the UltraDNS folks, because I am using tools that expect host > names instead of domain names (in this case, dig); now I have to write shims > around them. Other signing-on-the-fly mechanisms might cause similar issues > for dig or other tools. While the manpage doesn't use the word, I believe dig processes owner names rather than hostnames. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Tue, Jan 05, 2021 at 08:07:16AM +0100, Vladimír Čunát wrote: > Off the top of my head, I don't even now how exactly is the escaping > specified in RFCs. That's easy, any *non-digit* character can be escaped with a preceding "\", or alternatively as a 3-digit *decimal* \DDD sequence. The text in 1035 is: \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. \DDDwhere each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On 1/5/21 5:52 AM, Paul Hoffman wrote: I brought the issue to this mailing list, instead of to the UltraDNS folks, because I am using tools that expect host names instead of domain names (in this case, dig); now I have to write shims around them. In case it helps you, kdig escapes punctuation characters like '!' and '~' (contrary to original dig, apparently). Off the top of my head, I don't even now how exactly is the escaping specified in RFCs. --Vladimir ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Tue, Jan 05, 2021 at 04:52:07AM +, Paul Hoffman wrote: > >> ~.anynameyouwans~.house.gov. 882 INNSEC > >> anynameyouwant!.house.gov. RRSIG NSEC > >> !~.house.gov. 882 IN NSEC-.house.gov. RRSIG NSEC > > > > Consequently, these choices are largely rational, whether they're > > "optimal" is a matter of what one chooses to prioritise. > > That all seems correct. However, I brought the issue to this mailing > list, instead of to the UltraDNS folks, because I am using tools that > expect host names instead of domain names (in this case, dig); now I > have to write shims around them. Other signing-on-the-fly mechanisms > might cause similar issues for dig or other tools. Indeed anyone else who has been getting away with assuming ~LDH names in NSEC RRs should be prepared for this, and perhaps even more surprising formats. For example, I can elicit "\\\@.house.gov" as an NSEC right bound from this domain, so escaping/unescaping may be required... I've also found a way to walk the zone anyway, so the whole charade is mostly pointless. It would be far better to just use the real names, take advantage of aggressive negative caching, and ignore the zone- walking non-problem. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
On Jan 4, 2021, at 7:44 PM, Viktor Dukhovni wrote: > > On Tue, Jan 05, 2021 at 02:39:27AM +, Paul Hoffman wrote: > >> Greetings again. Those of us who research DNSSEC adoption in the real >> world are being a bit stymied by some of the sign-on-the-fly systems, >> such as this one, apparently from UltraDNS. (Similar results are given >> for any nonexistent name in house.gov, such as "www1".) > > These are certainly *interesting* choices, but the result is a valid > denial of existence, which for some reason chooses to optimise to defend > against zone walking (of a zone whose content is entirely predictable, > and likely a matter of public record, ...), rather than improved > negative caching. Not a choice I'd make for this zone, but on a purely > technical level, the proofs work. > > If the zone is known a priori to only contain regular LDH names and the > occasional "*" or "_", then the possible character range of "real" names > is a subset of: > >!…*…-…0–9…A–Z…_…a–z…~ > > with the two endpoints excluded. In which case, any actual successor, > in lexical order, of some label "foo" (<62 octets long) sorts after > "foo!", and its predecessor sorts before "~.fon~". > >> ~.anynameyouwans~.house.gov. 882 IN NSECanynameyouwant!.house.gov. >> RRSIG NSEC >> !~.house.gov.882 IN NSEC-.house.gov. RRSIG NSEC > > Consequently, these choices are largely rational, whether they're > "optimal" is a matter of what one chooses to prioritise. That all seems correct. However, I brought the issue to this mailing list, instead of to the UltraDNS folks, because I am using tools that expect host names instead of domain names (in this case, dig); now I have to write shims around them. Other signing-on-the-fly mechanisms might cause similar issues for dig or other tools. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
